敏捷测试策略有效性评估：测试完成情况怎么统计

敏捷测试策略有效性评估中，测试完成情况用“已完成测试项数÷计划测试项数”统计，分子和分母必须落在同一迭代、同一需求范围、同一完成定义下。单独看完成率只能说明执行推进程度，需要与通过率、阻塞率、缺陷发现时机一起解读，才能判断测试策略是否真正有效。下面给出一套可复算的统计口径和计算流程。

要点总览（TL;DR）

• 测试完成情况的核心公式是“已完成测试项数÷计划测试项数”，分子分母必须限定在同一迭代、同一需求范围和同一完成定义下，否则结果不可比。
• 按迭代分别统计执行完成率、通过率和阻塞率：完成率看推进程度，通过率的分母是已执行测试项，阻塞率单独反映环境与依赖问题。
• 取数前先统一测试项粒度、状态定义和完成判定，并记录缺陷的发现阶段与发现迭代，才能把完成情况与缺陷发现时机对照解读。
• 分母为零的分组标注“不适用”，范围变更较大时同时给出初始口径与最新口径两个完成率并说明差异来源。
• 完成率是过程指标，能说明执行推进和阻塞分布，不能单独证明策略有效，需与通过率、缺陷发现时机和迭代质量指标交叉判断。

评估目标：测试完成情况要回答什么问题

统计测试完成情况，目的是回答一个具体问题：在既定迭代周期内，测试策略安排的工作是否按预期被执行完，执行结果是否支撑了质量判断。它服务于策略有效性评估，而非单纯汇报进度。进度汇报关心“还剩多少没测”，策略评估关心“计划安排的测试是否覆盖到位、执行是否顺畅、问题是否被及时暴露”。

因此，完成情况需要与两类信息配合使用。第一类是迭代质量指标，例如缺陷密度、遗留缺陷数、回归通过情况，用来判断测试执行后质量是否稳定。第二类是缺陷发现时机，即缺陷在哪个阶段、哪个迭代被发现，用来判断测试策略是否把问题拦在了合适的位置。完成率高但缺陷大量流入后续阶段，说明测试项安排或执行深度存在问题；完成率低但缺陷发现集中在前端，则需要先排查阻塞原因。

评估结论的用途应限定在策略调整和过程改进上，例如调整测试项粒度、重新分配测试资源、补充某类测试。它不适合直接作为个人绩效排名依据，也不能单独证明某条测试策略带来了质量提升。完成率是过程指标，策略有效性是综合判断，两者之间需要多指标交叉验证。

指标与范围：完成率、通过率、阻塞率怎么定义

三个核心指标分别回答不同问题：执行完成率回答“计划内的测试项做了多少”，通过率回答“做完的测试项里有多少结果符合预期”，阻塞率回答“有多少测试项因环境、依赖或数据问题无法推进”。三者分子分母必须来自同一测试项集合，否则无法横向对照。

指标	公式	分母	时间窗	单位
执行完成率	已完成测试项数÷计划测试项数×100%	统计范围内计划执行的测试项总数	单个迭代周期，从迭代开始到统计截止日	百分比
通过率	通过测试项数÷已执行测试项数×100%	已完成执行的测试项数	同上，与完成率同一截止时点	百分比
阻塞率	阻塞测试项数÷计划测试项数×100%	统计范围内计划执行的测试项总数	同上	百分比

统计层级建议以迭代为主，因为敏捷测试策略通常按迭代制定和调整。需要下钻时可拆到需求维度或测试类型维度，例如功能测试、接口测试、回归测试分别统计。无论选哪个层级，分子分母必须限定在同一层级内，不能用一个需求的完成数除以整个迭代的计划数。时间窗以迭代起止日期为准，统计截止日应固定，避免不同人取数时点不同导致结果不可比。

通过率的分母是已执行测试项，而非计划测试项，这一点容易混淆。若用通过数除以计划数，得到的是“计划内通过比例”，它同时受完成率和通过率影响，解释时容易归因错误。建议分别保留完成率和通过率两个数，需要综合看时再单独计算。

数据口径：测试项、状态与缺陷发现时机的取数规则

测试项粒度决定统计结果是否可复算。常见做法是以一条可独立执行、可独立判定结果的测试用例作为一个测试项。同一用例在不同环境或不同数据下重复执行，若业务上视为多次验证，应分别计数并在记录中标注执行批次；若只是重跑确认，则合并为一条，以最终结果为准。去重规则要在统计前写清楚，例如按“用例编号+迭代+执行批次”唯一识别。

状态定义需要覆盖完整流转。建议至少区分：未开始、执行中、已通过、未通过、阻塞、跳过。完成判定通常把“已通过”和“未通过”计入已完成，因为两者都产生了明确执行结果；“阻塞”和“跳过”不计入已完成，但阻塞应单独统计。跳过项是否进入分母，取决于它是否属于计划范围：计划内但因策略调整明确取消的，应从分母剔除并记录原因；临时跳过但仍在计划内的，保留在分母中并标注。

缺陷发现时机需要记录可追溯字段，至少包括：缺陷关联的测试项、发现阶段（如冒烟、功能测试、回归）、发现所在迭代、严重程度。这样在计算完成情况后，可以按发现阶段分组看缺陷分布，判断测试策略是否把主要问题拦在了前端。缺失值处理要提前约定：状态为空的测试项按未开始计入分母；缺陷未填发现阶段的，单独归为“未标注”，不并入任何阶段做推断。

范围变更要留痕。迭代中途新增或移除测试项时，记录变更日期、变更原因和变更前后数量。统计时可采用两种口径之一：按迭代初始计划口径计算，反映原计划执行情况；按截止日最新范围计算，反映当前实际范围完成情况。两种口径不能混用，报告中应注明采用哪一种。

计算步骤：从原始记录到迭代完成情况

计算流程按以下步骤执行，每一步都保留中间结果，便于复核。

1. 确定统计范围：选定迭代、需求范围和测试类型，锁定计划测试项清单，记录清单版本和截止日期。
2. 清洗测试项记录：按唯一识别规则去重，补齐缺失状态，标记范围变更项，区分计划内取消与临时跳过。
3. 按迭代分组汇总：统计计划测试项数、已完成数、通过数、未通过数、阻塞数、跳过数，形成基础计数表。
4. 计算三个比率：执行完成率、通过率、阻塞率，保留一位小数，同时保留分子分母原始数。
5. 处理分母为零：若某分组计划测试项数为零，该组比率记为“不适用”，不记为零或百分之百，并在报告中说明该组无计划测试项。
6. 合并缺陷发现时机：按发现阶段统计缺陷数，计算各阶段缺陷占比，与完成率、通过率并列呈现。
7. 输出迭代结论：对照策略预期，标注完成率偏低的分组及原因（阻塞、范围变更、资源不足等），形成改进项。

分母为零和范围变更是最常见的两类异常。分母为零时，比率没有数学意义，强行计算会误导读者；正确做法是标注不适用并说明原因。范围变更较大时，建议同时给出初始口径和最新口径两个完成率，并说明差异来源，避免用单一数字下结论。

例子：一个迭代的测试完成情况计算

以下为演示情景，数字仅用于说明计算过程。某迭代计划测试项120条，其中功能测试80条、接口测试40条。迭代结束时，功能测试已完成68条（通过60条、未通过8条），阻塞6条，未开始6条；接口测试已完成36条（通过33条、未通过3条），阻塞2条，未开始2条。

分组	计划数	已完成	通过	未通过	阻塞	完成率	通过率	阻塞率
功能测试	80	68	60	8	6	85.0%	88.2%	7.5%
接口测试	40	36	33	3	2	90.0%	91.7%	5.0%
合计	120	104	93	11	8	86.7%	89.4%	6.7%

合计完成率为104÷120≈86.7%，通过率为93÷104≈89.4%，阻塞率为8÷120≈6.7%。功能测试完成率低于接口测试，阻塞项也更多，说明功能测试环节存在环境或依赖问题，需要优先排查。通过率两组接近，执行质量没有明显分化。

再看缺陷发现时机：该迭代共发现缺陷25个，其中冒烟阶段3个、功能测试阶段15个、回归阶段7个。回归阶段发现的7个缺陷占28%，比例偏高，说明部分问题在功能测试阶段未被拦截。结合完成率看，功能测试有6条阻塞和6条未开始，未执行部分可能正是缺陷漏出的原因之一。评估结论应指向：补齐功能测试阻塞项、检查未执行测试项的覆盖缺口，而非简单认定测试策略无效。

解读与限制：完成率能说明什么、不能说明什么

完成率能说明计划内测试项的执行推进程度，以及执行过程是否顺畅。它可以帮助识别阻塞集中的环节、范围变更的影响和资源投入的缺口。完成率与通过率、阻塞率、缺陷发现时机放在一起，能形成对测试策略执行情况的较完整画像。

完成率不能单独证明测试策略有效。测试项设计得少而浅，完成率可以很高，但覆盖不足；测试项设计得过多过细，完成率偏低，未必代表策略失败，可能是粒度或资源安排问题。完成率也不反映测试深度和缺陷拦截效果，这些需要缺陷发现时机和迭代质量指标补充。

以下情形不宜直接比较完成率：测试项粒度不同的团队或迭代；完成定义不一致，例如一方把阻塞计入完成、另一方不计入；统计时间窗不同，例如一个按迭代截止日、一个按发布日；范围变更未留痕，导致分母口径不明。遇到这些情况，应先统一口径再比较，或改为比较同口径下的趋势变化。

在管理使用上，建议把完成情况作为过程回顾的输入，而不是个人考核的唯一依据。回顾时重点看异常分组和原因，例如阻塞率突然上升、某类测试完成率持续偏低，再据此调整测试计划、资源分配或测试项设计。需要把测试项状态、执行结果和缺陷记录放在同一套流程里管理时，ONES 支持测试用例与需求、任务关联，测试计划与迭代关联，未通过的用例可快速创建缺陷任务并在测试与研发团队间流转，测试计划进度和通过率可在概览中查看，质量统计报表和测试报告可辅助按迭代汇总这些数据。具体指标公式和状态字段仍需团队按本文口径自行约定，以保证统计结果可复算、可比较。

常见问题

迭代中途新增或删除了测试项，完成率按哪个分母算？

两种口径都可以用，关键是选定一种并在报告中注明。按迭代初始计划口径计算，反映原定测试安排的执行情况，适合评估策略制定时的判断是否合理；按截止日最新范围计算，反映当前实际范围的完成情况，适合看当下还剩多少工作。范围变更较大时，建议两个数同时给出，并附上变更日期、原因和数量，让读者知道差异来自哪里。混用口径或用变更后的分母去解释变更前的执行情况，都会让结论失真。

阻塞和跳过的测试项要不要计入完成数？

通常不计入已完成。完成判定一般只把“已通过”和“未通过”算作完成，因为这两类都产生了明确的执行结果；阻塞和跳过没有验证结论，计入完成会高估推进程度。阻塞项应单独统计阻塞率，它是排查环境、依赖和数据问题的直接线索。跳过项的处理取决于是否仍在计划范围内：计划内因策略调整明确取消的，从分母剔除并记录原因；临时跳过但仍属计划范围的，保留在分母中并标注状态。

不同迭代或不同团队的完成率可以直接横向比较吗？

需要先确认口径一致再比较。测试项粒度不同（一条用例算一项还是按步骤拆分）、完成定义不同（阻塞是否计入完成）、时间窗不同（按迭代截止日还是按发布日）、范围变更是否留痕，都会让完成率失去可比性。口径不一致时，更稳妥的做法是比较同一团队同口径下的趋势变化，或者先统一测试项粒度和状态定义，再谈横向对比。跨团队比较还应结合通过率和缺陷发现时机，避免只看一个比率下结论。

完成率很高但回归阶段缺陷偏多，说明什么？

这通常指向测试深度或覆盖安排的问题，而非执行不力。完成率高说明计划内测试项基本执行完了，但回归阶段仍发现较多缺陷，意味着部分问题在功能测试阶段没有被拦截。可以检查几个方向：未执行或阻塞的测试项是否恰好覆盖了缺陷所在模块；测试项设计是否偏浅，缺少边界和异常场景；功能测试与回归之间的范围划分是否合理。评估结论应落到补齐覆盖缺口和调整测试项设计上，而不是简单判定策略无效。

把测试项状态和缺陷记录放在同一套系统里管理，对统计有什么实际帮助？

主要帮助在于取数口径统一和可追溯。测试项状态、执行结果和缺陷记录如果分散在不同工具里，统计前需要人工对齐测试项编号和迭代范围，容易出错且难以复算。放在同一套流程里管理时，测试用例可以与需求、任务关联，测试计划与迭代关联，未通过的用例可直接创建缺陷任务并在测试与研发团队间流转，测试计划的进度和通过率可在概览中查看，质量统计报表和测试报告可按迭代汇总。ONES 在这些环节提供了对应能力，但完成率、阻塞率的具体公式和状态字段仍需团队按本文口径自行约定，系统负责记录和汇总，口径定义仍由团队负责。