当涉及到软件质量时，我们希望尽可能多地以人工测试代码，实际上，对于每个测试周期，重要的是要考虑多种策略来衡量测试覆盖率，并将系统部署到位。
测试覆盖率是测试质量的度量之一，它告诉我们被测试的应用程序有多少已经过测试。你可以把它想象成打扫房子的地板。想象一下，如果我的清扫范围标准只包括清扫卧室。按照这个标准，如果我打扫了100%的卧室，那是否意味着整个房子是干净的？不，因为还有厨房，餐厅，浴室…你懂的！因此，必须始终小心测试覆盖率，认识到有时它有局限性。
测试覆盖率用于定义软件的某些部分，以便用测试覆盖它们。它还告诉我们何时进行了充分的测试，让我们知道还需要测试什么（从而扩大覆盖范围），并帮助我们定量地了解测试的范围。这是一个很好的衡量标准，即使有 100% 的测试覆盖率，我们也不能保证我们的应用程序 100% 没有错误。
有很多方法可以考虑测试覆盖率。在这里，我们将检查代码覆盖率、面向数据的覆盖率以及测试人员可以使用的大量其他技术。

代码覆盖率

代码覆盖率是衡量测试覆盖率最常用的指标。它测量测试用例覆盖的行数，报告代码中的行总数和测试执行的行数。本质上，它是测试套件运行时程序源代码的执行程度。代码覆盖率越高，未被发现的bug进入生产的可能性就越小。这种测量也可以分解为不同的层次；不仅包括代码行，还包括分支、逻辑构造函数内部的决策等。

面向数据的覆盖

在面向数据的覆盖范围中，有输入和输出参数，每个参数都有自己的域（它们可以拥有的可能值的范围）。如果考虑所有的可能性，你会得到一个笛卡尔积，因为可以测试每一个可能的组合。

其他类型的保险

除了前面提到的方法之外，还有其他几种方法可以涵盖正在测试的产品，如状态机、决策表、决策树、等价划分和边界值等。每种技术都有“错误理论”的支持。错误理论考虑了程序员犯下的典型错误。例如，等价分区和边界值考虑了使用“<”而不是“<=”的错误，误解了业务逻辑等。
此外，还有其他类型的测试覆盖率与代码行或输入测试数据无关。我们必须涵盖的一点是移动碎片化：我们是否涵盖了主要的移动设备、操作系统和屏幕尺寸？当谈到浏览器和操作系统时，我们必须考虑我们的web系统在操作系统和浏览器的任何组合中的行为，以及我们应该测试多少个组合。最后，我们必须考虑测试环境、上下文等。

制定计划以优化长期覆盖范围

假设我们在不同的浏览器上测试不同的特性，并且用不同的测试套件组织了不同的测试用例，每个测试套件都有自己的优先级。我们需要针对所有浏览器执行最关键的命令，但其余的，我们可以决定在不同的浏览器上执行。我们永远不能保证我们已经完成了测试，但是当时间紧迫时，必须明智地尽最大努力降低风险。

结论

测试覆盖标准非常有用，但它们并不能保证任何事情。一些标准与其他标准相关，我们需要使用最适合我们需求的模块，还要考虑每个模块的优先级，并根据优先级和复杂性定义每个模块的覆盖范围。最后，我们可以应用长期覆盖率标准来优化测试覆盖率。
演示工具：www.eolinker.com