为什么要对程序做代码覆盖率测试？

关于代码覆盖率，之前6年的工作经历中，只是依稀听闻过。之前的组织里，从未关注过这个指标胡慎，只是有一段时间用NUnit做了单元测试，主要是测试一些关键类关键方法是否正常，对代码覆盖率的印象就真的一直是停留在听闻的程度。汗一个!\x0d\x0a前些时日，关于自动测试的讨论中有人提及到代码覆盖率，激发了我的好奇，到底什么是代码覆盖率?最重要的是于测试工作而言有怎样的价值呢?今天花了一点时间查了一下，有了初步的认识。大致归纳如下：\x0d\x0a一、基本概念\x0d\x0a代码覆盖率是单元测试活动任务之一\x0d\x0a覆盖率分语句覆盖率(即通常所说的行覆盖率)和分支覆盖率。\x0d\x0a二、价值\x0d\x0a代码覆盖率的分析能在一定程度上评判代码质量，一般覆盖率高的代码出错的几率会相对低一些。但是高覆盖率只是表示执行了很多的代码，并不意味着这些代码被很好地执行了。所以，似乎覆盖率测试结果出来并不能帮我准确的评价代码质量。那么我们为什么要做覆盖率测试呢?如何让它给我们带来价值呢?\x0d\x0a1. 尽早评估代码质量\x0d\x0a比如在开发的过程中，定时的去看整个项目的代码覆盖率，监控覆盖报告可以帮助开发团队迅速找出不断增长的但是没有相应测试的代码。例如，在一周开始时运行覆盖报告，显示项目中一个关键的软件包的覆盖率是 70%。如果几天后，覆盖率下降到了 60%，那么您可以推断：软件包的代码行增加了，但是没有为新代码编写相应的测试(或者是新增加的测试不能有效地覆盖新代码)。能够监控事情的发展，无疑是件好事。定期地查阅报告使得设定目标(例如获得覆盖率、维护代码行的测试案例的比例等)并监控事情的发展变得更为容易。如果您发现测试没有如期编写，您可以提前采取一些行动，例如对开发人员进行培训、指导或帮助。\x0d\x0a2. 为功能测试关注点提供情报\x0d\x0a假设覆盖报告在指出没有经过足够测试的代码部分方面非常有效，那么质量保证人员可以使用这些数据来评定裤谈敬与功能测试有关的关注区域，可以更有针对性地加强这些区域的测试，因为没有被测试代码覆盖到的区域，出错的几率应该相对更高。\x0d\x0a3. 估计修改已有代码所需的时间\x0d\x0a对一个开发团队而言，针对代码编写测试案例自然可以增加集体的信心。与没有相应测试案例的代码相比，经过测试的代码更容易重构、维护和增强。测试案例因为暗示了代码在测试工作中是如何工作的，所以还可以充当内行的文档。在另一方面，没有经过相应测试的代码更难于理解和安全地修改。因此，知道代码有没有被测试，并看看实际的测试覆盖数值，可以让侍仿开发人员和管理人员更准确地预知修改已有代码所需的时间。\x0d\x0a当然，这样的理解还是比较浅层的，我想实际应用中除了以上三点之外，还有一个很重要的工作就是提高测试代码的质量来更好的体现代码覆盖率的价值。

在软件测试中，有一个重要的概念叫做代码覆盖率，一般在单元测试中作为测试充分性的重要衡量指标，那么代码覆盖率达到100%是否就算覆盖全了？答案显然是否定的。

那么，100%的代码覆盖率还值得追求吗?

这是当然，这也应该是每个程序员追求的目标之一，但是如果从项目角度考虑ROI(投入产出比)，对于需要快速上线的短期项目，需要注重的是让测试覆盖核心功能代码。如果你的项目是一个长期项目，那么高覆盖率是非常有必要的，它意味着高可维护性，以及更少的bug。

那么对于一个项目来说，覆盖率应罩含该达到多少？

其实没有适用于所有项目的数值，每个项目都应有自己的阈值，但共性是，测试必须覆盖主要业务场景，代码的逻辑物誉笑分支也必须尽可能的覆盖。

如何改进你的项目代码覆盖率？

首先我们要阅读和理解项目代码，找出其中需要测试并且与业务强相关的代码，结合sonar等代码质量管理平台，从代码编写规范、复杂度、重复代码等方面进行代码重构，进一步提高项目的可维护性与可读性。

这也意味着重构，重构的同时，你需要更多的测试来保证你重构代码的正确性。

代码覆盖率的意义

阅读虚销分析之前项目中未覆盖部分的代码，进而反推在前期QA以及相关测试人员在进行黑盒测试设计时是否考虑充分，没有覆盖到的代码是否是测试设计的盲点，为什么没有考虑到？是需求或者UX设计不够清晰，还是测试设计的理解有误。

检测出程序中的废代码，可以逆向反推代码设计中不合理的地方，提醒设计/开发人员理清代码逻辑关系，提升代码质量。

代码覆盖率高不能说明代码质量高，但是反过来看，代码覆盖率低，代码质量绝对不会高到哪里去，可以作为测试自我审视的重要工具之一。

单元测试的覆盖率并不只是为了取悦客户或者管理层的数据，它能够实实在在反应项目中代码的 健康 程度，帮助我们更好的改善了代码的质量，增加了我们对所编写代码的信心。

测试覆盖率和代码覆盖率是衡量代码有效性的最流行方法。这些术陵谨基语有时会同时出现，因为它们的基本原理相同。但是它们并不是那么一致。很多时候，测试团队和开发团队对这两个术语的使用感到困惑。下面详细讨论代码覆盖率和测试覆盖率之间的区别的原因。

代码覆盖率：表示通过用Selenium或任何其他测试自动化框架进行的手动测试和自动化测试，测试用例覆盖的代码百分比。例如，如果源代码具有一个简单的if...else循环，则如果测试代码可以覆盖这两种情况（即if＆else），则代码覆盖率将为100％。

测试范围：包括测试作为功能需求规范，软件需求规范和其他必需文档的一部分而实现的功能。例如，如果要对Web应用程序执行跨浏览器测试，以确保应用程序可以在其他浏览器流畅运行。测试覆盖范围是已验证Web应用程序的浏览器兼容性的浏览器+ *** 作系统组合的数量。

开发人员在单元测试期间执行代码覆盖，以验证代码实现，尽可能多执行代码语句。大多数代码覆盖率工具都使用静态工具，将监视执行的语句插入代码中的必要位置。尽管添加检测代码会导致总体应用程序大小和执行时间增加，但与通过执行检测代码生成的信息相比，开销却很小。输出包含一个详细描述测试套件测试范围的报告。

单元测试主要用于在单个单元级别上测试代码。由于单元测试是由开发人员自己编写的，因此他对应该作为单元测试的一部分包含的测试具有更好的可见性。单元测试有助于提高软件的整体质量，但是关于构成单元测试的测试数量始终存在疑问。测试套件中是否有足够数量的测试方案？我们应该添加更多测试吗？代码覆盖率是所有这些问题的重要衡量标准。

随着产品开发的进行，新功能以及BUG修复补丁将添加到发布周期中。这意味着测试代码可能还需要进行更改，以使其与开发过程中所做的软件更改保持一致。在项目开始时设定的测试标准必须与后续的发布周期保持一致，这一点很重要。代码覆盖率可用于确保测试过程符合这些标准，并且质量最好的代码进入生产阶段。

代码覆盖率越高，发生未检测到的错误的概率越低。在某些组织中，质量团队设置在将软件推向生产阶段之前需要实现的最小代码覆盖量。这样做的主要原因是为了减少在产品开发的后期阶段检测到错误的可能性。

代码覆盖范围有不同的级别，代码覆盖率的一些常见的类型为：

为了检查代码覆盖率，使用了一种尺谨称为检测的方法。工具可用于监视性能，插入跟踪信息以及诊断源代码中的任何类型的错误。

仪器分为三种主要类型

根据测试要求，团队应该选择正确的代码覆盖率工具以及该工具支持的最佳检测方法。

有许多支持不同编程语言的代码覆盖工具，其中许多还可以兼用作QA工具。许多工具可以与构建工具和项目管理工具集成在一起，从而使它们更加强大的作用。选择开源代码覆盖率工具时，应检查该工具支持的功能以及该工具是否正在积极开发迭代中。下面是一些流行的开源代码覆盖工具：

与代码覆盖率是白盒测试方法不同，测试覆盖率是黑盒测试方法。以最大范围覆盖FRS（功能需求规范），SRS（软件需求规范），URS（用户需求规范）等中提到的需求的方式编写测试用例。

像代码覆盖率一样，也可以通过不同类型的测试来评估测试覆盖率。但是，应遵循哪种测试完全取决于具体的业务。例如在以用户为中心的Web应用程序中，可能存在UI/UX测试比功能测试具有更高优先级的情况，而在其他类型的应用程序中（例如银行，金融）；可用性测试，安全性测试等可能更为重晌则要。

以下是一些测试覆盖率机制：

要注意的另一个重要点是，测试覆盖范围的目的和含义可能会有所不同，具体取决于执行测试的级别。它还取决于执行黑盒测试的产品类型。用于测试手机的测试覆盖率指标将不同于用于网站测试的指标。一些分类如下：

在代码覆盖率的情况下，度量标准是通过测试用例/测试套件测试的代码的百分比。因此，可以量化测试结果，即在100 LOC（代码行）中，代码覆盖率为80行。这意味着代码覆盖率为80％。由于执行测试是为了验证功能要求，因此无法量化测试覆盖率的结果。还可以提出可以在单个测试中测试多个需求的黑匣子测试。 尽管在少数情况下必须编写测试代码来达到测试覆盖率要求，但是在某些情况下，您可能仍需要使用一些流行的测试框架。两种最受欢迎 的测试框架是：

衡量代码覆盖率和测试覆盖率的影响的基础完全不同。代码覆盖率是通过测试期间覆盖的代码百分比来衡量的，而测试覆盖率是通过测试覆盖的功能来衡量的。 重要的是“其中哪一项最适合项目”？这个问题没有确切的答案，因为解决方案取决于项目的类型和复杂性。在大多数情况下，使用测试覆盖率和代码覆盖率，因为它们在软件项目中同等重要。

测试团队应花费大量时间来了解总体要求并确定测试活动的优先级。为了跟踪进度，他们应该有一个清单，该清单应定期更新（至少在每次发行之后）。测试团队还必须与质量保证（QA）团队保持频繁的沟通，这是很重要的，因为他们具有要发布给客户/客户的产品/项目必须达到的目标（测试/代码）覆盖范围的详细信息。没有专门的经验法则提到测试产品时需要达到的最小代码覆盖率或测试覆盖率百分比。

追求覆盖率只是手段而不是目的。测试同学的终极目的还是要在首先的资源情况下最大显得保障产品质量。不能因为KPI就盲目追求手段的极致，反而本末倒置，最终陷入泥潭不能自拔。

---