代码覆盖率VS测试覆盖率

　　代码覆盖率VS测试覆盖率
　　测试覆盖率和代码覆盖率是衡量代码有效性的最流行方法。这些术语有时会同时出现，因为它们的基本原理相同。但是它们并不是那么一致。很多时候，测试团队和开发团队对这两个术语的使用感到困惑。下面详细讨论代码覆盖率和测试覆盖率之间的区别的原因。 概念
　　代码覆盖率：表示通过用Selenium或任何其他测试自动化框架进行的手动测试和自动化测试，测试用例覆盖的代码百分比。例如，如果源代码具有一个简单的if...else循环，则如果测试代码可以覆盖这两种情况（即if＆else），则代码覆盖率将为100％。
　　测试范围：包括测试作为功能需求规范，软件需求规范和其他必需文档的一部分而实现的功能。例如，如果要对Web应用程序执行跨浏览器测试，以确保应用程序可以在其他浏览器流畅运行。测试覆盖范围是已验证Web应用程序的浏览器兼容性的浏览器+操作系统组合的数量。 代码覆盖率
　　开发人员在单元测试期间执行代码覆盖，以验证代码实现，尽可能多执行代码语句。大多数代码覆盖率工具都使用静态工具，将监视执行的语句插入代码中的必要位置。尽管添加检测代码会导致总体应用程序大小和执行时间增加，但与通过执行检测代码生成的信息相比，开销却很小。输出包含一个详细描述测试套件测试范围的报告。 为什么要执行代码覆盖率
　　单元测试主要用于在单个单元级别上测试代码。由于单元测试是由开发人员自己编写的，因此他对应该作为单元测试的一部分包含的测试具有更好的可见性。单元测试有助于提高软件的整体质量，但是关于构成单元测试的测试数量始终存在疑问。测试套件中是否有足够数量的测试方案？我们应该添加更多测试吗？代码覆盖率是所有这些问题的重要衡量标准。
　　随着产品开发的进行，新功能以及BUG修复补丁将添加到发布周期中。这意味着测试代码可能还需要进行更改，以使其与开发过程中所做的软件更改保持一致。在项目开始时设定的测试标准必须与后续的发布周期保持一致，这一点很重要。代码覆盖率可用于确保测试过程符合这些标准，并且质量最好的代码进入生产阶段。
　　代码覆盖率越高，发生未检测到的错误的概率越低。在某些组织中，质量团队设置在将软件推向生产阶段之前需要实现的最小代码覆盖量。这样做的主要原因是为了减少在产品开发的后期阶段检测到错误的可能性。 如何执行代码覆盖率
　　代码覆盖范围有不同的级别，代码覆盖率的一些常见的类型为： 分支机构的覆盖范围：分支机构的覆盖范围也称为决策覆盖范围，用于确保决策过程中使用的每个可能的分支都得到执行。例如，如果您要使用代码中的If ... An条件语句或DWhile语句合并后备跨浏览器兼容性，作为覆盖范围的一部分；通过提供适当的输入以使跨浏览器兼容的网站来确保对所有分支（即If，Else，While）进行测试。 功能覆盖范围：功能覆盖范围可确保测试必要的功能（尤其是导出的功能/ API）。这还应包括使用不同类型的输入参数测试功能，因为这也将测试功能中使用的逻辑。一旦测试了代码中的所有功能，功能覆盖率将为100％。 语句覆盖率：这是一种重要的代码覆盖率方法，其中必须以某种方式编写测试代码，即源代码中的每个可执行语句至少执行一次。这也包括极端情况或边界情况。 循环覆盖：这种方法是确保源中的每个循环至少执行一次。可能会根据在运行时获得的结果执行某些循环，同样重要的是测试此类循环以使代码万无一失。
　　为了检查代码覆盖率，使用了一种称为检测的方法。工具可用于监视性能，插入跟踪信息以及诊断源代码中的任何类型的错误。
　　仪器分为三种主要类型 代码检测：这里的源代码是在添加检测语句之后编译的。编译应使用常规工具链完成，编译成功将导致生成检测装配。例如，为了检查在代码中执行特定功能所花费的时间，可以在功能的＂开始＂和＂结束＂中添加检测语句。 运行时检测：与代码检测方法相反，此处的信息是从运行时环境（即在执行代码时）收集的。 中间代码检测：在这种检测类型中，通过向已编译的类文件中添加字节码来生成检测类。
　　根据测试要求，团队应该选择正确的代码覆盖率工具以及该工具支持的最佳检测方法。 代码覆盖率工具
　　有许多支持不同编程语言的代码覆盖工具，其中许多还可以兼用作QA工具。许多工具可以与构建工具和项目管理工具集成在一起，从而使它们更加强大的作用。选择开源代码覆盖率工具时，应检查该工具支持的功能以及该工具是否正在积极开发迭代中。下面是一些流行的开源代码覆盖工具： Coverage.py：这是Python的代码覆盖工具。顾名思义，它可以分析您的源代码并确定已执行代码的百分比。它是用Python开发的。 Serenity BDD：支持Java和Groovy编程语言，Serenity BDD是一个流行的开源库，主要用于更快地编写出色的质量验收测试。它可以与JUnit，Cucumber和JBehave一起使用。Serenity BDD可以轻松地与Maven，Cradle，JIRA和Ant集成。 JaCoCo：JaCoco是Java的代码覆盖工具。尽管还有其他选项，例如Cobertura和EMMA，但由于长时间没有更新，因此不推荐使用这些工具。除了积极开发JaCoCo之外，使用JaCoCo的另一个优势是可以与CI/CD和项目管理工具（例如Maven，Jenkins，Gradle等）无缝集成。 JCov：JCov是一个测试框架不可知代码覆盖工具。它可以轻松地与Oracle的测试基础架构JavaTest和JTReg集成。尽管尚未积极开发，但对即时检测和脱机检测的支持是使用JCov的主要优势。 PITest：这是一个突变测试框架。它有快、可扩展，并与当前测试和构建工具集成好的优点。传统的测试覆盖率（即行，语句，分支等）仅衡量测试执行的代码。 它不会检查测试是否真正能够检测到所执行代码中的错误。 因此，它只能识别绝对未经测试的代码。PITest是一种非常流行的代码覆盖工具，用于Java和JVM的变异测试。它通过修改测试代码来完成突变测试的工作，并且现在已经在修改后的代码上执行了单元测试。PITest易于使用，快速且正在积极开发中。它还与流行的CI/CD工具集成在一起使用。 测试覆盖率
　　与代码覆盖率是白盒测试方法不同，测试覆盖率是黑盒测试方法。以最大范围覆盖FRS（功能需求规范），SRS（软件需求规范），URS（用户需求规范）等中提到的需求的方式编写测试用例。 如何执行测试覆盖率
　　像代码覆盖率一样，也可以通过不同类型的测试来评估测试覆盖率。但是，应遵循哪种测试完全取决于具体的业务。例如在以用户为中心的Web应用程序中，可能存在UI/UX测试比功能测试具有更高优先级的情况，而在其他类型的应用程序中（例如银行，金融）；可用性测试，安全性测试等可能更为重要。
　　以下是一些测试覆盖率机制： 单元测试：这种测试在单元级别/模块级别执行。在单元级别遇到的错误可能与集成阶段遇到的问题不同。 功能测试：在功能测试中，将根据功能需求规范（FRS）中提到的要求对功能/功能进行测试。 集成测试：由于软件是在系统级别进行测试的，因此也称为系统测试。一旦集成了所有必需的模块，便会执行此类测试。 验收测试：全部取决于验收测试的结果，是否将产品发布给最终客户。
　　要注意的另一个重要点是，测试覆盖范围的目的和含义可能会有所不同，具体取决于执行测试的级别。它还取决于执行黑盒测试的产品类型。用于测试手机的测试覆盖率指标将不同于用于网站测试的指标。一些分类如下： 功能覆盖范围：在此情况下，以最大程度覆盖产品功能覆盖范围的方式开发测试用例。 风险覆盖范围：每个产品/项目需求文档都有一节提到与项目相关的风险与缓解措施。尽管某些风险（例如，业务动态变化）不在计划/开发/测试团队的范围内，但是在测试阶段仍需要解决一些风险。 需求范围：这里定义测试的方式是最大程度地覆盖各种需求规范文档中提到的产品需求。 测试覆盖率工具
　　在代码覆盖率的情况下，度量标准是通过测试用例/测试套件测试的代码的百分比。因此，可以量化测试结果，即在100 LOC（代码行）中，代码覆盖率为80行。这意味着代码覆盖率为80％。由于执行测试是为了验证功能要求，因此无法量化测试覆盖率的结果。还可以提出可以在单个测试中测试多个需求的黑匣子测试。 尽管在少数情况下必须编写测试代码来达到测试覆盖率要求，但是在某些情况下，您可能仍需要使用一些流行的测试框架。两种最受欢迎 的测试框架是： JUnit：JUnit是Java的单元测试框架。它也可以用于UI测试。它是开源的，并且在TDD（测试驱动开发）的开发中被认为很重要。开发人员和测试人员使用JUnit编写和执行重复的测试。这也使它成为回归测试的流行框架。 PyUnit：PyUnit（也称为Python单元测试框架）是一种广泛用于单元测试的广泛使用的测试框架。它是JUnit的Python端口，由遵循TDD方法的Python开发人员使用。PyUnit支持测试用例，测试套件，测试装置等的开发。unittest模块是PyUnit框架的核心。 Pytest：Pytest是一个使创建简单及可扩展性测试用例变得非常方便的框架。测试用例清晰、易读而无需大量的繁琐代码。只要几分钟你就可以对你的应用程序或者库展开一个小型的单元测试或者复杂的功能测试。 代码覆盖率与测试覆盖率：哪一个？
　　衡量代码覆盖率和测试覆盖率的影响的基础完全不同。代码覆盖率是通过测试期间覆盖的代码百分比来衡量的，而测试覆盖率是通过测试覆盖的功能来衡量的。 重要的是＂其中哪一项最适合项目＂？这个问题没有确切的答案，因为解决方案取决于项目的类型和复杂性。在大多数情况下，使用测试覆盖率和代码覆盖率，因为它们在软件项目中同等重要。 测试覆盖范围的优势一种测试软件功能并比较不同规范文档（需求，功能，产品，UI/UX等）结果的好方法。 由于作为覆盖范围一部分执行的测试实际上是黑盒，因此执行这些测试可能不需要太多的专业知识。 测试覆盖范围的缺点由于测试主要是黑盒测试，因此没有自动化范围。测试结果必须与预期的输出进行手动比较，因为这些测试是在功能级别而非代码级别执行的。 没有测量测试覆盖率的具体方法。因此，覆盖范围的结果在很大程度上取决于正在执行测试的测试人员的领域能力，并且可能因一个测试人员而异。 代码覆盖范围的优势提供测试代码的有效性以及如何提高覆盖率。 无论使用哪种工具（开源，高级），设置代码覆盖率工具都不会花费太多时间。 通过捕获代码中的错误来帮助提高代码质量。 代码覆盖范围的缺点大多数代码覆盖率工具仅限于单元测试。因此，工具使用的方法可能会有所不同；可能无法将一种工具的代码覆盖率结果与另一种工具进行比较。 搜索最适合的工具可能是一项艰巨的任务，因为需要先从这些工具中比较并尝试功能，然后再选择最适合项目需求的工具。 提供很少支持不同编程语言（例如Java，Python，C#等）的工具。因此，如果团队使用多种编程语言（用于测试代码开发），则需要多个工具。
　　测试团队应花费大量时间来了解总体要求并确定测试活动的优先级。为了跟踪进度，他们应该有一个清单，该清单应定期更新（至少在每次发行之后）。测试团队还必须与质量保证（QA）团队保持频繁的沟通，这是很重要的，因为他们具有要发布给客户/客户的产品/项目必须达到的目标（测试/代码）覆盖范围的详细信息。没有专门的经验法则提到测试产品时需要达到的最小代码覆盖率或测试覆盖率百分比。 不要为了覆盖而覆盖
　　追求覆盖率只是手段而不是目的。测试同学的终极目的还是要在首先的资源情况下最大显得保障产品质量。不能因为KPI就盲目追求手段的极致，反而本末倒置，最终陷入泥潭不能自拔。