软件测试中的测试覆盖率：如何衡量它
托马斯·汉密尔顿
什么是测试覆盖率？
测试覆盖率被定义为软件测试中的一种指标，用于衡量一组测试所执行的测试量。它将包括收集有关在运行测试套件时执行程序的哪些部分的信息，以确定已执行条件语句的哪些分支。
简单来说，它是一种技术，可以确保您的测试正在测试您的代码，或者通过运行测试来测试您执行了多少代码。
测试覆盖率的作用是什么？
在实际项目中，测试覆盖率支持以下四项实际活动：
- 查找一组测试用例未实现的需求区域
- 帮助创建额外的测试用例以增加覆盖率
- 确定测试覆盖率的定量指标，这是质量检查的间接方法
- 识别不会增加覆盖率的无意义的测试用例
软件工程中测试覆盖率的好处
这些活动可以转化为具体的工程效益。
- 可以保证测试的质量
- 它可以帮助确定代码的哪些部分在发布或修复时实际被触及
- 它可以确定应用程序中所有未测试的决策点和路径，从而提高测试覆盖率。
- 防止 缺陷 泄漏
- 时间、范围和成本可得到控制
- 项目生命周期早期阶段的缺陷预防
- 可以轻松找到需求、测试用例和单元级及代码级缺陷之间的差距
测试覆盖率类型
覆盖率从来都不是一个单一的数字。团队 trac同时遇到几种类型，因为每种类型都回答了关于同一套件的不同问题。下表列出了您最常遇到的类型。
| 覆盖类型 | 测量内容 | 最适合使用 |
|---|---|---|
| 报表（行）承保范围 | 可执行行至少运行一次 | 单元测试和遗留代码审计 |
| 分支机构或决策覆盖范围 | 每个决定的真假结果 | 条件和验证逻辑 |
| 条件承保 | 每个布尔子表达式都表示为真或假。 | 复合 AND 或 OR 表达式 |
| 路径覆盖 | 通过模块的独特路径 | 安全关键和资金流 |
| 功能覆盖率 | 测试调用的函数或方法 | API 和服务层 |
| 需求覆盖范围 | 需求至少对应到一个测试 | 接受与trac正式签字 |
| 风险覆盖 | 已确定的高风险区域已进行锻炼 | 短发行周期 |
前五种类型是代码级别的措施，属于 白盒测试而需求和风险覆盖则位于测试计划层面。
两者之间主要区别是什么 Code 覆盖率和测试覆盖率？
Code 覆盖 和测试覆盖率是允许您评估应用程序代码质量的测量技术。
以下是这些覆盖方法的展位之间的一些关键区别：
| 参数 | Code 保障范围 | 测试覆盖率 |
|---|---|---|
| 定义 | Code 覆盖率术语，用于在应用程序运行时执行应用程序代码的情况。 | 测试覆盖率是指总体的测试计划。 |
| 目标 | Code 覆盖率指标可以帮助团队监控其自动化测试。 | 测试覆盖率详细说明了应用程序的书面编码的测试级别。 |
| 亚型 | Code 覆盖率分为语句覆盖率、条件覆盖率、分支覆盖率等子类型。 Toggl电子覆盖范围，FSM 覆盖范围。 | 没有测试覆盖方法的子类型。 |
测试覆盖率公式
要计算测试覆盖率，您需要遵循以下步骤：
步骤1） 计数 Y你所编写的软件的总代码行数。 测试
步骤2） 计数 X当前所有测试用例执行的代码行数。
现在，您需要找到 (X 除以 Y) 乘以 100。此计算的结果就是您的测试覆盖率。
例如：
如果系统组件中的代码行数为 500，而所有现有测试用例执行的代码行数为 50，则您的测试覆盖率为：
(50 / 500) * 100 = 10% // executed lines divided by total lines
测试覆盖率示例
单凭百分比永远无法说明全部问题，如下例所示。
例如1：
例如，如果您要测试的物品是“刀”，那么您需要重点检查它是否能准确切割蔬菜或水果。但是，还有其他方面需要考虑，例如用户是否能够舒适地使用它。
例如2：
例如，如果您想测试记事本应用程序，那么检查其基本功能是必须的。但是，您还需要检查其他方面，例如记事本应用程序在与其他应用程序一起使用时是否能正常响应，用户是否能够理解应用程序的使用方法，以及在用户尝试执行一些非常规操作时是否不会崩溃等等。
测试覆盖率技术
这两个例子都指向同一个结论：达到覆盖率目标与其说是取决于编写多少测试用例，不如说是取决于选择正确的测试设计技术。以下技术可以在保持覆盖率的同时扩大覆盖范围。ping 套房很小。
- 边界值分析： 选择每个有效范围边缘的输入，这些边缘处的缺陷最为集中。参见 边值分析 已处理的案例。
- 等价类划分： 将应用程序以相同方式处理的输入分组，以便单个案例可以安全地表示一整类值。
- 决策表测试: 涵盖单个网格内各种条件的组合及其预期结果。
- 状态转换测试: 遍历应用程序状态之间的每一种有效和无效的移动。
- 基础路径测试: 从控制流图中导出最小独立路径集。
- 基于风险的测试: 根据业务影响对各项功能进行排名，并优先介绍风险最高的功能。
- 探索性测试: 揭示了脚本案例和报道报告中从未提及的漏洞。
如何实现测试覆盖率？
技术选定后，四条既定路线即可提供覆盖范围。
- 测试覆盖率可以通过使用同行评审、检查和演练等静态评审技术来实现
- 将临时缺陷转化为可执行的测试用例
- 在代码级或单元测试级，可以通过利用自动代码覆盖或单元测试覆盖工具来实现测试覆盖
- 可以借助适当的测试管理工具完成功能测试覆盖
如何提高测试覆盖率
建立覆盖范围是第一步；提高覆盖范围是一个可重复的流程。在每个发布周期开始时，都要按此步骤进行操作。
- 以当前数值为基准。 分别运行覆盖率报告并记录语句、分支和需求覆盖率，以便每个模块的差距都能被看到，而不是隐藏在一个项目范围的平均值中。
- 将测试用例与需求对应起来。 建立一个您自己的 trac能力矩阵将每个需求与至少一个测试用例关联起来。任何空白行都表示已确认的缺失，而非疑似缺失。
- 按风险对模块进行排名。 支付、身份验证和数据迁移逻辑需要比静态帮助屏幕更深入的覆盖，因此应该把预算花在失败会造成最大损失的地方。
- 添加负面情况和极端情况。 空输入、过大的值、网络超时和权限错误会导致正常路径测试永远不会触及的分支。
- 将测试级别分层。 结合 单元测试, 集成测试并且进行端到端检查，因为每一层都涵盖了其他层在结构上无法涵盖的内容。
- 自动化回归测试套件。 Promo将稳定病例 自动化测试 并在内部执行它们 CI/CD 管道 每次提交后。
- 删除冗余案例。 删除重复的、增加执行时间但未增加任何未覆盖行的测试。
- Rev每次迭代都观察趋势。 Track 覆盖率旁边 缺陷密度. 漏水量增加是盲区出现的早期预警信号。
⚠️警告： 不要把 100% 的覆盖率当作目标。一个覆盖率达到 85% 且包含强断言的测试套件，比一个覆盖率达到 95% 且只执行代码而不验证任何结果的浅层检查套件，更能有效地保护版本发布。
测试覆盖率的缺点
保险仍然很有价值，但在报告任何百分比之前，有必要说明其局限性。
- 由于没有自动化工具，测试覆盖范围内的大多数任务都是手动的。因此，分析需求和创建测试用例需要花费大量精力。
- 测试覆盖率允许您统计特征，然后根据多个测试进行衡量。然而，判断错误总是存在的。
