为什么测试覆盖率如此重要
本帖最后由 测试积点老人 于 2020-10-14 10:22 编辑由于软件中普遍存在的错误，全世界都见证了一些灾难性事件。2008年在英国希思罗机场5号航站楼开业。 工程师对终端的工作充满信心，这与他们的严格测试标准有关。由于行李处理系统在现实情况运行时陷入了瘫痪，导致系统完全关闭。在接下来的10天里，大约42000个行李箱变成了无主之物，顺带着取消了500多次航班。 最终的结果是将事故归因于工程师未能对可能的实际场景进行测试覆盖测试。
接下来，我们将讨论测试覆盖率的相关问题，以及它如何帮助提高软件质量的。
测试覆盖率概述
测试覆盖率被定义为一种测试技术指标，它表明我们的测试用例是否真正完全覆盖了应用程序代码中的各种可能以及在运行这些测试用例时执行了多少代码。
如果有10个需求并创建了100个场景测试用例，并且执行了90个测试用例，则测试覆盖率为90％。现在，基于这个指标，测试人员可以为其余需求创建其他测试用例。以下是测试覆盖率的更多优势。
可以在早期和代码级别发现需求、测试用例和BUG之间的差距。
可以使用测试覆盖率分析来防止BUG的遗漏。
测试覆盖率还有助于进行回归测试、测试用例优先级划分、测试套件扩展和测试套件颗粒化。
测试覆盖技术
语句覆盖
语句覆盖率确保源代码中的所有场景都经过至少一次测试用例中执行。它提供了全部代码块中已执行和未执行的代码块的详细信息。
让我们通过流程图示例来了解它。在给定的示例中，此路径1A-2C-3D-E-4G-5H涵盖了所有语句，因此仅需要一个测试用例即可满足所有要求。一个测试用例意味着一个语句覆盖。
在复杂的代码中，单个路径不足以覆盖所有语句。在这种情况下，测试工程师需要根据实际情况编写多个测试用例来覆盖所有场景。
好处：
它可以直接应用于目标代码，并且不需要处理源代码。
它可以验证代码功能中对于需求是否满足。
缺点：
语句覆盖率仅涵盖每个语句的条件。
语句覆盖率范围对逻辑运算符（比如||和&&）完全不敏感，很容易漏掉。
语句覆盖率是基本覆盖率，因此不能保证100％语句覆盖率。
分支覆盖
几乎没有一个业务场景是可以不需要进行判断的，在任何时候他们都需要分支出代码来满足功能要求。代码中的分支实际上是从一个决策点到另一决策点的跳转。分支覆盖范围检查代码中每个可能的路径或分支是否被覆盖。
分支覆盖率可以通过找到确保覆盖所有边缘的最小路径数来计算。在给定的示例中，没有一条路径可以确保一次覆盖所有边缘。
例如，如果您沿此路径1A-2C-3D-E-4G-5H覆盖最大边缘数A，C，D，E，G和H，则仍然会错过两个边缘B和F 。测试人员需要遵循另一条路径1A-2B-E-4F覆盖其余两个边缘分支。通过组合以上两条路径，可以确保在所有分支均被测试用例覆盖到。
好处：
分支覆盖涵盖了所有条件判断。
分支覆盖验证是否所有分支都已测试。
缺点：
分支覆盖忽略布尔表达式中由于短路算子而出现的分支。
路径覆盖
路径测试是一种结构测试方法，涉及使用程序的源代码来查找每个可能的可执行路径。路径覆盖范围可确保从头到尾覆盖所有路径。在此示例中，有四种可能的路径：
1A-2B-E-4F
1A-2B-E-4G-5H
1A-2C-3D-E-4G-5H
1A-2C-3D-E-4F
好处：
它有助于减少冗余测试。
路径覆盖率提供了较高的测试覆盖率，因为它覆盖了代码中的所有语句和分支。
缺点：
测试每条路径既困难又费时，因为许多路径与分支的数量成指数关系。
在实际业务中，由于数据的关系，许多路径很可能是不通的。
条件覆盖
条件覆盖率检查每个条件的两个结果（true或false）是否均已执行。逻辑判断点的结果仅与检查条件有关。每个条件需要两个测试用例才能实现两个结果。
好处：
条件覆盖范围相互独立地测量条件。
条件覆盖对控制流具有更好的敏感性。
缺点：
类似于分支机构/决策范围，决策点和测试用例指数关系。
对于多条件测试经常，很难避免用例重复
边界值覆盖
对于那些由于输入数字而发生错误的应用程序，边界值覆盖率指标非常有用。大多数BUG都是发生在边界值处。在边界值覆盖范围内，在等效类的端点处选择测试用例。对于此测试覆盖率示例，以下是需要3位数字作为输入的应用程序的边界值。
100（最低）
99（仅低于最小边界值）
999（最大）
1000（仅在最大边界值之上）
好处：
测试小组使用边界值覆盖数据代替测试大量数据集是很容易的。
边界值覆盖易于使用，因为它易于自动化已识别测试的性质和一致性。
缺点：
边界值覆盖无法测试两个输入之间的依赖关系。
边界值覆盖不能覆盖包含布尔函数的代码。
什么是测试覆盖率指标
下面是是5个关键的测试覆盖率指标。
代码级指标
测试执行覆盖率，它也称为已执行测试，是已通过/已执行测试在总测试数量中所占的百分比。
优点是可以通过统计通过和失败的测试次数来获得测试进度的直观描述。
缺点是计数通过的测试用例并不能说明这些测试的质量。例如，某些测试可能会通过，但是在某些非正常时候，程序会触发一些BUG。
功能测试指标
需求范围
需求覆盖率用于确定测试用例满足软件需求的程度。为此，测试工程师只需要将发布或项目的需求数量除以范围需求的总数即可。
测试范围
在需求模块中，可以通过将测试用例链接到需求来统计测试覆盖率。测试覆盖率评估测试或需求变更的影响。通过覆盖多个用例，用需求覆盖测试配置可以提供更精细的粒度。
用例质量
此度量标准用于查看要测试的功能以及符合要求的测试数量。大多数需求包含多个测试用例。了解特定需求正向和逆向的测试场景对于编写特定需求的测试用例非常重要。
测试范围
此标准对利益相关者非常重要，因为它直观展示了应用程序/软件开发对于需求的完成度。
应用程序级别指标
缺陷密度
缺陷密度是对已知缺陷总数的度量除以要测量的软件实体（通常是代码行数、模块数、功能数）的数量。
测试范围
它可以被用于标识需要自动化的模块。如果特定功能的缺陷密度很高，则需要重新测试。为了减少重新测试的工作，可以将已知缺陷的测试用例自动化。
在评估缺陷时，考虑缺陷的优先??级很重要。通常较高优先级的缺陷会作为此度量标准的极其重要的一部分而获得更高的权重。
测试覆盖率矩阵
下面是一个登录功能的矩阵表，用于确保考虑了所有可能要测试的条件/特征。可以将其视为检查清单，以确保以所有可能的组合验证被测对象的某项功能。
如何衡量测试覆盖率
许多质量检查团队在衡量测试覆盖率时不会考虑的一件事：如何衡量测试覆盖率？如何测量测试覆盖率？
测试覆盖率是根据代码行测得的。这是上面讨论的测试执行覆盖率。例如，如果测试工程师已经通过测试用例执行了800行代码，那么在1000行代码中，改项目的测试覆盖率为80％。
如果需要按需求衡量测试的覆盖率，以专注于测试用例库中的更高效的测试用例。一个好的测试用例可以追溯到实现的需求（包括正向和反向的流程），拥有良好的测试用例所要做的就是建立需求可追溯性。
当然也可以通过涵盖某个版本项目迭代范围内的所有要求，从而实现在项目中的可追溯性。通过建立需求可追溯性，可以在任何时间点了解需求需要的测试范围。
提高测试覆盖率
删除无效代码
总覆盖率可以定义为代码覆盖率和测试覆盖率的比率（covered/total）。可以通过减少作为总代码的分母来增加覆盖范围。这可以通过删除Dead代码来实现。良好覆盖率测试可以找到死代码，同样需要删除调试代码和开发人员遗留的测试代码。
可以通过手动测试或使用自动化工具轻松找到无效代码。在删除无效代码之前，测试工程师需要执行功能测试，如果测试完全按照要求执行，则可以删除未使用的代码。测试工程师还可以使用静态测试覆盖率分析工具从源代码中识别未使用的无效代码。
删除冗余代码
删除复制的代码可以像删除无效代码一样提高测试覆盖率。
程序中包含基本代码和代码块，这些代码块在程序中具有很搞重复性。如果找到这些复制的代码并将其删除。通过从源代码中删除复制的代码，可以将测试覆盖率提高5-10％。
增加设备覆盖率
移动设备和操作系统版本投放市场的节奏具有很强的节奏感，而浏览器（例如Chrome和Firefox）也具有相同的特性。每个发行版不仅带来了测试范围方面的挑战，而且还引入了需要额外测试工作的新特性和功能。为了提高最大的测试覆盖范围，就必需提高设备的覆盖率（硬件和软件）。
衡量移动测试覆盖率的方法是通过使用情况和客户分析来了解。列出软件正式环境中最常用的设备，还需要确保其中包括各个版本的iOS和Android的设备。
测试工程师要关注即将发布的设备、操作系统版本和浏览器版本，将其与现有分析结合使用，保证测试设备库的及时更新。
结论
如今，开发工作越来越系统化，企业寻求测试完整性和有效性的方法，用来评估测试工作完成程度和工作完成质量。在所有的标准中，测试覆盖率被认为是最优价值的指标之一。 为了确保的软件测试具有较高水平，就需要采用结构化方法，因为软件测试覆盖率是衡量和确保软件质量的关键因素。
页:
[1]
