代码覆盖率和测试覆盖率

测试覆盖率和代码覆盖率是衡量代码有效性的最流行方法。 尽管这些术语有时会互换使用，因为它们的基本原理相同。 但是它们并不像您想象的那样相似。 很多时候，我注意到测试团队和开发团队对这两个术语的使用感到困惑。 这就是为什么我想到写一篇文章来详细讨论代码覆盖率和测试覆盖率之间的区别的原因。

代码覆盖率与测试覆盖率：它们有何不同？

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

测试范围：包括测试作为功能需求规范，软件需求规范和其他必需文档的一部分而实现的功能。 例如，如果要对Web应用程序执行跨浏览器测试 ，以确保您的应用程序是否可以从其他浏览器很好地呈现？ 您的测试范围将围绕验证了Web应用程序的浏览器兼容性的浏览器+操作系统组合的数量。

了解了代码覆盖率和测试覆盖率之间的基本区别之后，让我们跳入有关代码覆盖率和测试覆盖率的更多详细信息。

深入了解代码覆盖率

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

为什么要执行代码覆盖率？

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

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

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

如何执行代码覆盖率？

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

• 分支机构覆盖范围–分支机构覆盖范围也称为决策覆盖范围，用于确保决策过程中使用的每个可能的分支都得以执行。 例如，如果您使用代码中的If…Ans条件语句或Do…While语句合并后备跨浏览器兼容性，作为覆盖范围的一部分； 您必须通过提供适当的输入以使跨浏览器兼容的网站来确保对所有分支（即If，Else，Do和While）进行测试。
• 功能覆盖范围–功能覆盖范围可确保测试必要的功能（尤其是导出的功能/ API）。 这还应包括使用不同类型的输入参数测试功能，因为这也将测试功能中使用的逻辑。 一旦测试了代码中的所有功能，功能覆盖率将为100％。
• 语句覆盖率–这是一种重要的代码覆盖率方法，其中必须以某种方式编写测试代码，即源代码中的每个可执行语句至少执行一次。 这也包括极端情况或边界情况。
• 循环覆盖–这种方法是确保源中的每个循环至少执行一次。 可能会根据您在运行时获得的结果来执行某些循环，同样重要的是测试此类循环以使代码万无一失。

为了检查代码覆盖率，使用了一种称为检测的方法。 工具可用于监视性能，插入跟踪信息以及诊断源代码中的任何类型的错误。 仪器种类繁多，取决于所使用的仪器方法，可能会有最小的性能（和时序）开销。

仪器类型

仪器分为三种主要类型

• 代码检测-这里的源代码是在添加检测语句之后编译的。 编译应使用常规工具链完成，编译成功将导致生成检测装配。 例如，为了检查在代码中执行特定功能所花费的时间，可以在功能的“开始”和“结束”中添加检测语句。
• 运行时检测–与代码检测方法相反，此处的信息是从运行时环境（即在执行代码时）收集的。
• 中间代码检测–在这种检测中，通过向已编译的类文件中添加字节码来生成检测类。

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

代码覆盖率工具

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

1. Coverage.py –这是Python的代码覆盖工具。 顾名思义，它可以分析您的源代码并确定已执行代码的百分比。 它是用Python开发的。 它是免费的，您可以参考https://coverage.readthedocs.io/en/coverage-5.0.3/了解更多信息。
2. Serenity BDD –支持Java和Groovy编程语言，Serenity BDD是一个流行的开源库，主要用于更快地编写出色的质量验收测试。 您可以使用故事和史诗进行测试，并为这些故事和史诗计算代码覆盖率。 因此，生成的测试报告实际上更具说明性和叙述性。 您可以将这些自动化测试映射回您的需求中。
   它可以与JUnit，Cucumber和JBehave一起使用。 Serenity BDD可以轻松地与Maven，Cradle，JIRA和Ant集成。 如果您使用Selenium WebDriver或Selenium Grid框架进行自动化测试，则选择Serenity BDD将具有巨大优势，因为它与Selenium兼容。 您可以参考https://www.thucydides.info/#/documentation了解更多信息。
3. JaCoCo – JaCoco是Java的代码覆盖工具。 尽管还有其他选项，例如Cobertura和EMMA，但由于长时间没有更新，因此不推荐使用这些工具。 JaCoCo工具是Eclipse Foundation的一部分，它替代了Eclipse中的EMMA代码覆盖率工具。 除了积极开发JaCoCo之外，使用JaCoCo的另一个优势是可以与CI / CD和项目管理工具（例如Maven，Jenkins，Gradle等）无缝集成。请访问官方网站以获取更多信息。
4. JCov – JCov是测试框架不可知代码覆盖工具。 它可以轻松地与Oracle的测试基础架构JavaTest和JTReg集成。 尽管尚未积极开发，但对即时检测和脱机检测的支持是使用JCov的主要优势。 请访问https://wiki.openjdk.java.net/display/CodeTools/jcov了解更多信息。
5. PITest –大多数代码覆盖率工具都会检查代码的分支覆盖率，语句覆盖率，循环覆盖率等，并给出覆盖率结果。 尽管这些信息对于提高测试代码的质量很有用，但是测试并不能告诉您自动化测试在发现错误方面的表现如何。 这是变异测试非常有用的地方。
   PITest是一种非常流行的代码覆盖工具，用于Java和JVM的变异测试。 它通过修改您的测试代码来完成变异测试的工作，并且现在在此修改后的代码上执行单元测试。 如果使用此代码发现了错误，即PITest添加了额外的代码后，则单元测试是万无一失的。 否则，由于尚未发现问题，因此需要更改。 PITest易于使用，快速且正在积极开发中。 它还与流行的CI / CD工具集成在一起，使其更加有用。 有关更多信息，请访问http://pitest.org/ 。

深入了解测试覆盖率

与代码覆盖率是白盒测试方法不同，测试覆盖率是黑盒测试方法。 以最大范围覆盖FRS（功能需求规范），SRS（软件需求规范），URS（用户需求规范）等中提到的需求的方式编写测试用例。由于测试是从这些文档中衍生的，因此自动化的机会很小/没有机会。

如何执行测试覆盖率？

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

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

• 单元测试–这种测试在单元级别/模块级别执行。 在单元级别遇到的错误可能与在集成阶段遇到的问题不同。
• 功能测试–在功能测试中，将根据功能需求规范（FRS）中提到的要求对功能/功能进行测试。
• 集成测试–由于软件是在系统级别进行测试的，因此也称为系统测试。 一旦集成了所有必需的模块，便会执行此类测试。
• 验收测试–全部取决于验收测试的结果，是否将产品发布给最终消费者/客户。 在此，开发人员可以从Web应用程序的测试人员和SME获得绿色通道的批准，然后才将代码更改从暂存环境推送到生产环境 。

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

• 功能覆盖范围–在此情况下，以最大程度覆盖产品功能的方式开发测试用例。 例如，如果为测试人员分配了测试电话拨号程序应用程序的工作， 他应确保所拨打的号码长度正确。 如果测试是在印度完成的，则手机号码最多为10位数字； 否则它应该闪烁一个错误。 与此类似，必须根据产品团队设置的优先级对所有必需和可选功能进行测试。
• 风险范围–每个产品/项目需求文档都有一节提到与项目相关的风险和缓解措施。 尽管某些风险（例如，业务动态的变化）超出了计划/开发/测试团队的范围，但在测试阶段仍需要解决一些风险。
  例如，在开发商业网站时，应该以非常快速的页面访问方式来设置服务器基础结构。 根据访问网站的位置（即国家，城市等），应选择最接近的服务器来加载网站。 否则，整个体验将受到阻碍。 测试团队还应该执行负载测试，其中当多个用户尝试同时访问该网站时即完成性能测试时，即网站上流量巨大的场景。 如果这些测试的结果不好，则可能会导致用户体验低于平均水平（这可能会带来巨大的风险）。
• 需求范围–这里定义测试的方式是最大程度地覆盖各种需求规范文档中提到的产品需求。
  例如，如果您正在测试预安装的SMS应用程序，则需要确保正确设置默认语言，例如，如果手机在英语不是主要语言的国家/地区销售，例如中国； 默认的SMS语言应为中文，并适用于其他客户（例如印度）； 默认语言应为英语。

测试覆盖率工具

在代码覆盖率的情况下，度量标准是通过测试用例/测试套件测试的代码的百分比。 因此，可以量化测试结果，即在100 LOC（代码行）中，代码覆盖率为80行。 这意味着代码覆盖率为80％。 由于执行测试以验证功能要求，因此无法量化测试覆盖率的结果。 您还可以提出可以在单个测试中测试多个需求的黑盒测试，例如，为了在简单的电子邮件登录页面中测试失败情况，您可以编写一个测试用例，输入不带@的电子邮件地址符号，然后尝试继续登录。 这将测试登录页面的功能，并检查用于验证电子邮件地址格式的逻辑是否按要求工作。

尽管在少数情况下必须编写测试代码来达到测试覆盖率要求，但是在某些情况下，您可能仍需要使用一些流行的测试框架。 两种最受欢迎​​的测试框架是：

• JUnit – JUnit是Java的单元测试框架。 它也可以用于UI测试。 它是开源的，并且在TDD（测试驱动开发）的开发中被认为很重要。 开发人员和测试人员使用JUnit编写和执行重复的测试。 这也使它成为回归测试的流行框架。 有关更多信息，请参阅https://junit.org/junit5/ 。

使用JUnit首先运行Selenium Automation测试脚本

• PyUnit – PyUnit（也称为Python单元测试框架）是一种广泛用于单元测试的广泛使用的测试框架。 它是JUnit的Python端口，由遵循TDD方法的Python开发人员使用。 PyUnit支持测试用例，测试套件，测试装置等的开发。unittest模块是PyUnit框架的核心。 请参阅https://docs.python.org/2/library/unittest.html了解更多信息。

使用PyUnit首先运行Selenium自动化测试脚本

尽管开发人员/测试人员可以使用许多其他工具/测试框架来编写测试代码，但JUnit和PyUnit是各自编程语言中最受欢迎的测试框架。

您应该遵循哪一个？

衡量代码覆盖率和测试覆盖率的影响的基础完全不同。 代码覆盖率是通过测试期间覆盖的代码百分比来衡量的，而测试覆盖率是通过测试覆盖的功能来衡量的。

百万美元的问题是“其中哪一项最适合您的项目”？ 这个问题没有明确的答案，因为解决方案取决于项目的类型和复杂性。 在大多数情况下，使用测试覆盖率和代码覆盖率，因为它们在软件项目中同等重要。

测试覆盖范围的优势

• 一种测试软件功能并比较不同规范文档（需求，功能，产品，UI / UX等）结果的好方法
• 由于作为覆盖范围一部分执行的测试实际上是黑盒，因此执行这些测试可能不需要太多的专业知识。

取决于测试覆盖范围的缺点

• 由于测试主要是黑盒测试，因此没有自动化范围。 测试结果的手动比较必须与预期的输出进行，因为这些测试是在“功能级别”而不是“代码级别”执行的。
• 没有测量测试覆盖率的具体方法。 因此，覆盖范围的结果在很大程度上取决于正在执行测试的测试人员的领域能力，并且可能因一个测试人员而异。

代码覆盖范围的优势

• 提供测试代码的有效性以及如何提高覆盖率
• 无论使用哪种工具（开源，高级），设置代码覆盖率工具都不会花费很多时间。
• 通过捕获代码中的错误来帮助提高代码质量。

代码覆盖范围的缺点

• 大多数代码覆盖率工具仅限于单元测试。
• 因此，工具使用的方法可能有所不同； 您可能无法将一种工具的代码覆盖率结果与另一种工具进行比较。
• 搜索最适合的工具可能是一项艰巨的任务，因为在选择最适合您项目需求的工具之前，您需要比较并尝试这些工具的功能。
• 提供很少支持不同编程语言（例如Java，Python，C等）的工具。因此，如果您的团队使用多种编程语言（用于测试代码开发），则可能需要多个工具。

多少覆盖范围足够？

测试次数更多； 产品的质量越好。 设计，开发和测试团队之间应该经常沟通，以便每个利益相关者都可以了解有关项目活动的详细信息。

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

总而言之，没有专门的经验法则提到测试产品时需要达到的最小代码覆盖率或测试覆盖率百分比。

如何确保最大的代码覆盖率和测试覆盖率？

通过测试获得更好结果的一种方法是将自动化纳入测试计划。 不可能完全自动化整个测试过程，因此您必须制定一个计划。 该计划应突出显示必须手动和通过自动化执行的测试活动。

覆盖率是一个有用的指标，但范围有限。 没有理想的方法可以衡量在测试上花费的精力。 众所周知的事实是100％的覆盖率只是一个神话。

包含不同类型的测试（例如自动化测试，集成测试，手动测试，跨浏览器测试等）的整体方法将非常有用。 它可以帮助您在一个地方衡量不同测试和测试系统的有效性。

不要针对100％的代码覆盖率

您要记录的一件事是，永远不要以为100％的代码覆盖率都认为您的代码更改没有错误。 原因是100％的代码覆盖率表示您的自动化测试脚本覆盖了每一行代码。 但是，我们需要考虑错误的否定和错误的肯定，这可能会使我们脱离所添加代码的现实。 另外，您的Web应用程序中还会有一些未经测试的代码。 您需要仔细考虑未经测试的代码。 如果它是从旧版本中删除的，则可以将其删除；或者，如果它是来自缺少文档的最新修补程序，则对其进行测试。

结论

代码覆盖率是白盒方法，而测试覆盖率是黑盒测试方法。 根据项目的要求和范围，您应该选择测试覆盖率/代码覆盖率/测试覆盖率和代码覆盖率。 您应该确定测试活动的优先级，并为每个活动指定一个暂定期限。 不管使用哪种方法，重要的是要达到更高的覆盖率，因为这将表明代码和产品功能已得到很好的测试。 干杯!

翻译自: https://www.javacodegeeks.com/2020/02/code-coverage-vs-test-coverage-which-is-better.html

代码覆盖率和测试覆盖率