软件测试指标：什么是、类型和示例
托马斯·汉密尔顿
什么是软件测试指标？
软件测试指标 是用于评估软件测试过程的进度、质量、生产力和健康状况的定量指标。软件测试指标的目标是提高软件测试过程的效率和有效性，并通过提供有关测试过程的可靠数据来帮助为进一步的测试过程做出更好的决策。
指标以量化的方式表达系统、组件或过程具备特定属性的程度。一个简单的类比是汽车实际的每周油耗与制造商公布的数据之间的比较。
软件测试指标——提高软件测试过程的效率和有效性。
软件测试指标或软件测试测量是对流程或产品某些属性的程度、容量、维度、数量或大小的定量指示。
软件测试测量示例：缺陷总数
为什么测试指标很重要？
“我们无法改进无法衡量的东西。” 测试指标的存在就是为了让测试过程可衡量。
- 决定下一阶段的活动应该是什么。
- 提供证据来支持关于质量的主张或预测。
- 确定需要进行哪种改进。
- 对工艺或技术变更进行论证
阅读更多关于 测试指标的重要性
测试指标的类型
选择合适的指标比收集大量指标更重要。在最终确定指标集之前，请考虑以下几点：
- 确定指标准备的目标受众
- 定义指标目标
- 根据项目需求引入所有相关指标
- 权衡每项指标的成本和收益，以及它在项目生命周期的哪个阶段能发挥最大价值。
手动测试指标
In 软件工程，手动测试指标分为两类
- 基本指标
- 计算指标
基本指标是测试分析师在测试用例开发和执行过程中收集的原始数据（执行的测试用例数，测试用例数）。而计算指标则来自基础指标中收集的数据。测试经理通常会遵循计算指标来编写测试报告（完成度百分比，测试覆盖率百分比).
根据项目或商业模式的不同，最重要的指标通常是：
- 测试用例执行效率指标
- 测试用例准备生产力指标
- 缺陷指标
- 按优先级分类的缺陷
- 缺陷严重程度
- 缺陷滑移率
手动测试与自动化测试指标
上述指标均基于手动执行的测试套件。自动化测试套件的衡量方式有所不同，因为执行工作量不再是限制因素。
| 标准 | 手动测试指标 | 自动化测试指标 |
|---|---|---|
| 主要重点 | 努力和执行进展 | 覆盖范围、稳定性和运行时间 |
| 典型测量 | 每日执行的测试用例数 | 自动化覆盖率 |
| 质量信号 | 每测试小时发现的缺陷 | 不稳定测试率，即不稳定测试的比例 |
| 成本衡量 | 测试工时 | 每次发布的脚本维护工时 |
| 速度测量 | 周期持续时间（天） | 套件执行时间（分钟） |
Automation Coverage = (Test cases automated / Total test cases) x 100 Flaky Test Rate = (Tests with inconsistent results / Total automated tests) x 100
不稳定的测试率需要特别关注。一旦测试率低于 5% 左右，团队就会开始忽略红色版本，此时无论测试覆盖率有多高，测试套件都无法再提供有效信息。
软件工程中的测试指标生命周期
| 指标生命周期的不同阶段 | 每个阶段的步骤 |
|---|---|
| 信号分析 |
|
| 沟通联系 |
|
| 评价 |
|
| 报告 |
|
如何计算测试指标
| 先生＃ | 测试指标的步骤 | 例如： |
|---|---|---|
| 1 | 识别密钥 软件测试 需要测量的过程 | 测试进度 trac王过程 |
| 2 | 在此步骤中，测试人员使用数据作为基线来定义指标 | 每天计划执行的测试用例数量 |
| 3 | 确定要关注的信息，以及关注频率 trac国王和负责人 | 每天的实际测试执行情况将在一天结束时由测试经理记录 |
| 4 | 有效计算、管理和解释定义的指标 | 每天实际执行的测试用例 |
| 5 | 根据定义的指标的解释确定需要改进的领域 | If 测试用例 执行情况未达到既定目标，请调查原因并提出纠正措施。 |
测试指标计算示例
以已执行测试用例的百分比为例进行说明。要将执行状态表示为百分比，请使用以下公式：
Percentage test cases executed= (No of test cases executed/ Total no of test cases written) X 100
如果编写了 250 个测试用例，并且执行了 175 个，则结果为 (175 / 250) x 100 = 70 percent.
同样的模式也适用于其他所有执行参数：未执行的测试用例、通过的测试用例、失败的测试用例和被阻塞的测试用例。它们都只是分子不同但分母相同而已。
最重要的测试指标 Track
本教程末尾的术语表列出了所有常用公式。实际上，一份报表通常只需要八个公式。这些公式往往是决策的关键依据。
| 米制 | 它回答了什么 | 小心 |
|---|---|---|
| 测试用例执行百分比 | 计划运行进行到什么程度了？ | 它没有提及质量，只提到了进步。 |
| 缺陷密度 | 单位尺寸缺陷率，那么哪个模块最弱？ | 取决于统一的尺寸测量方法 |
| 缺陷去除效率 | 我们在产品发布前发现了多少缺陷？ | 只有在获得生产数据后才能最终确定。 |
| 缺陷泄漏 | 有多少缺陷产品最终到达了客户手中？ | 最重要的质量信号 |
| 测试覆盖率 | 需求集有多少得到了满足？ | 高覆盖率但断言薄弱并不能证明什么。 |
| 缺陷严重程度指数 | 这些开放性缺陷是严重的还是只是外观上的？ | 不加权重地统计缺陷会误导人 |
| 平均修复时间 | 团队多久能修复问题？ | 受少数长期缺陷的影响而产生偏差 |
| 测试执行效率 | 一名测试人员每天能完成多少个测试案例？ | 如果用作目标，则会鼓励进行浅层测试。 |
以下两个公式值得添加到词汇表中，因为它们是管理层经常要求使用的公式：
Defect Removal Efficiency = (Defects found before release / Total defects found) x 100
Defect Leakage = (Defects found in production / Defects found before release) x 100
测量陷阱。 任何被用作目标的指标都不再是有效的衡量标准。例如，设定每天 30 个测试用例的生产力目标，测试人员只会编写 30 个无关紧要的测试用例。应该将各项指标作为一个整体来报告，而不是孤立地看待，并且每个生产力指标都应该与一个质量指标关联起来。
软件测试指标公式词汇表
- 返工工作量比率 = （该阶段实际花费的返工工作量/该阶段实际花费的总工作量）X 100
- 需求蔓延 = （新增需求总数/初始需求数量）X100
- 进度差异 = （实际交货日期 - 计划交货日期）
- 在测试中发现缺陷的成本 = （测试所花费的总精力/测试中发现的缺陷）
- 进度延误 = （实际结束日期 - 预计结束日期）/（计划结束日期 - 计划开始日期）X 100
- 通过测试用例百分比 =（通过的测试数/执行的测试总数）X 100
- 失败测试用例百分比 =（失败测试数/执行的测试总数）X 100
- 阻止的测试用例百分比 =（阻止的测试数/执行的测试总数）X 100
- 已修复缺陷百分比 = (已修复缺陷数/已报告缺陷数) X 100
- 接受缺陷百分比 =（开发团队接受的有效缺陷数/报告的缺陷总数）X 100
- 缺陷延迟百分比 =（推迟到未来版本发布的缺陷数/已报告的缺陷总数）X 100
- 严重缺陷百分比 =（严重缺陷/报告的缺陷总数）X 100
- 开发团队修复缺陷的平均时间 =（修复错误所花的总时间/错误数量）
- 每个时间段运行的测试次数 = 测试运行次数/总时间
- 测试设计效率 = 设计的测试数量/总时间
- 测试评审效率 = 审查的测试数量/总时间
- 发现漏洞率或每测试小时缺陷数 = 缺陷总数 / 总测试小时数
