版本测试收尾时，测试报告要回答的核心问题是：在当前测试范围内，这个版本能否交付。支撑结论的证据主要来自两类数据——通过情况反映“测了多少、测得怎么样”，缺陷指标反映“问题收敛到什么程度、还剩什么风险”。本文给出这两类指标的清单、计算公式、分母口径和统计时间窗，并用一组示例数据演示如何把指标组合成有依据的质量结论。
要点总览（TL;DR）
- 通过情况以用例总数、已执行数、通过数、失败数、阻塞数、未执行数六类计数为基础，再计算执行率（已执行数÷用例总数）和通过率（通过数÷已执行数），报告中必须写明分母口径。
- 缺陷指标覆盖新增、修复、关闭、遗留四类状态计数，遗留缺陷按致命、严重、一般、提示分级呈现，并计算缺陷密度（有效缺陷数÷统计对象规模）和缺陷关闭率（已关闭数÷累计有效缺陷数）。
- 质量结论由三条证据组合支撑：通过率与执行率反映测试完成度，遗留缺陷等级分布反映残余风险，缺陷新增与关闭趋势反映收敛情况；单看通过率不足以判断版本可交付性。
- 指标解读需注意边界：高通过率不等于低风险，遗留缺陷数量少但等级高可能风险更大，缺陷密度分母不可比时不宜直接比较，且不设通用达标线，阈值应结合版本目标与历史基线确定。
收尾报告要回答什么质量结论
版本收尾报告的结论对象是当前测试版本和事先约定的测试范围，回答的是“本次测试是否足以支撑交付判断”。它不承担组织级质量趋势分析的职责，也不替代发布审批流程中的门禁规则。报告提供证据，审批依据这些证据做决定，两者分工不同。
一份收尾报告需要支撑三个判断：
- 范围是否测完：计划内的用例执行到什么程度，未执行和阻塞的部分集中在哪些模块，是否影响关键功能验证。
- 缺陷是否收敛：新增缺陷与关闭缺陷的走势是否交叉向下，遗留缺陷的数量和等级是否在可接受区间。
- 遗留风险是否可接受：剩余缺陷分布在哪些功能、什么等级，是否存在已知但暂不修复的问题，需要谁确认。
把这三个问题写成结论清单，再逐条对应指标，可以避免报告变成数据堆砌。例如结论清单可以写成：“核心交易模块用例执行率是否达到计划要求”“致命与严重级遗留缺陷是否清零或有明确处理方案”“近一周新增缺陷是否持续低于关闭缺陷”。每条清单对应一组可复算的数据，报告正文按清单顺序展开。
通过情况看哪些指标与统计范围
通过情况以用例执行状态的四类计数为基础：通过、失败、阻塞、未执行，加上用例总数和已执行数，共六个基础数字。所有比率都由这六个数字推导，报告中先列计数、再列比率，读者可以自行复算。
| 指标 | 公式 | 分母 | 单位 | 统计时间窗 |
|---|---|---|---|---|
| 用例总数 | 统计范围内用例快照计数 | — | 条 | 测试计划启动时的用例版本快照 |
| 已执行数 | 通过数+失败数+阻塞数 | — | 条 | 截至报告生成时刻 |
| 执行率 | 已执行数÷用例总数 | 用例总数 | % | 同上 |
| 通过率 | 通过数÷已执行数 | 已执行数 | % | 同上 |
| 失败率 | 失败数÷已执行数 | 已执行数 | % | 同上 |
| 阻塞率 | 阻塞数÷已执行数 | 已执行数 | % | 同上 |
通过率的分母选择需要特别注意。用“通过数÷已执行数”衡量的是已测部分的稳定性；用“通过数÷用例总数”则把未执行部分也计为未通过，数值更低但更保守。两种口径都有使用场景，报告必须写明采用哪一种，并在版本之间保持一致，否则趋势对比会失真。建议主口径用已执行数作分母，同时附上未执行用例数，让读者自行判断覆盖缺口。
分层统计让通过情况更有解释力。至少按三个维度拆分：按模块看失败和阻塞集中在哪些功能；按优先级看高优先级用例的执行率和通过率是否达标；按测试类型看功能测试、回归测试、兼容性测试各自的完成情况。分层后如果某个模块执行率明显偏低，报告应说明原因，例如环境未就绪或依赖未交付。
统计时间窗和用例版本要固定。用例在测试过程中可能增删改，报告应基于测试计划启动时冻结的用例快照统计总数，执行结果取截至报告生成时刻的最新状态。时间窗写明起止日期，避免读者把不同批次的数据混在一起比较。
缺陷指标的口径与计算方式
缺陷指标覆盖数量、等级、密度和收敛趋势四组。数量类指标先明确状态口径：新增指统计时间窗内创建的缺陷；修复指开发已提交修复但测试尚未验证的缺陷；关闭指测试验证通过并关闭的缺陷；遗留指报告时刻仍处于打开状态（含待修复、修复中、待验证）的缺陷。同一缺陷在不同时间点可能落入不同状态，报告要写明每个数字对应的状态定义和统计时刻。
| 指标 | 公式 | 分母 | 单位 | 剔除规则 |
|---|---|---|---|---|
| 新增缺陷数 | 时间窗内创建的缺陷计数 | — | 个 | 剔除无效、重复、非缺陷记录 |
| 关闭缺陷数 | 时间窗内状态变为已关闭的缺陷计数 | — | 个 | 同上 |
| 遗留缺陷数 | 报告时刻处于打开状态的缺陷计数 | — | 个 | 同上 |
| 缺陷关闭率 | 已关闭数÷累计有效缺陷数 | 累计有效缺陷数 | % | 同上 |
| 缺陷密度 | 有效缺陷数÷统计对象规模 | 用例数或功能点数 | 个/百条用例或个/功能点 | 同上 |
遗留缺陷必须按严重等级分布呈现。常用分级为致命、严重、一般、提示四级，报告用表格列出每级的遗留数量及占比，并单独标注致命和严重级缺陷的处理状态：已修复待验证、计划下版本修复、确认不修复。等级分布比总数更能说明风险，五个一般缺陷和一个致命缺陷对交付判断的影响完全不同。
缺陷密度用于横向比较不同模块或不同版本的问题集中程度。分母可选用例数或功能点数，选择取决于统计对象：以测试投入为参照时用用例数，以产品规模为参照时用功能点数。同一份报告内固定一种分母，跨报告比较时确认分母口径一致。密度数值本身没有绝对好坏，它的价值在于识别异常模块——某模块密度显著高于同版本其他模块，值得单独说明。
收敛趋势用新增与关闭的对比呈现。按周或按天统计新增缺陷数和关闭缺陷数，画成两条序列，观察关闭数是否持续高于新增数、遗留总数是否下降。缺陷关闭率=已关闭数÷累计有效缺陷数，反映整体消化进度；配合遗留缺陷的周环比变化，可以判断收敛是否稳定。趋势数据要覆盖测试后期至少两到三个统计周期，单点数据无法说明走势。
统计前先做有效性清洗。无效缺陷（描述不清、无法复现且确认非产品问题）、重复缺陷（合并到主缺陷）、非缺陷记录（需求变更、环境问题）应从分子分母中剔除，并在报告中注明剔除数量和规则。剔除规则一旦确定，同一版本内保持一致，避免通过调整口径美化数据。
从数据到结论的评估步骤
把指标汇总成结论需要固定顺序，保证不同人按同样步骤能得到同样判断。建议分四步：
第一步，核对数据完整性。检查未执行用例的分布和原因，确认阻塞用例是否有解除计划；检查缺陷状态是否都已流转到最新，避免把已修复未验证的缺陷误计为遗留或漏计。数据缺口要列出来，例如某模块因环境问题未执行，报告中明确标注该模块结论不完整。
第二步，按模块和等级看通过率与遗留缺陷分布。先看整体执行率和通过率，再下钻到模块和优先级。高优先级用例通过率低或致命级遗留缺陷未清零的模块，标记为重点风险区。这一步的产出是一张风险模块清单，而不是一个总分。
第三步，看缺陷收敛趋势。对比测试后期每周的新增与关闭数量，确认关闭数是否稳定高于新增数、遗留总数是否单调下降。如果新增在收尾阶段反弹，需要说明原因，例如回归测试发现新问题或需求变更引入缺陷。
第四步，组合三条证据形成结论并标注不确定项。通过率与执行率说明测试完成度，遗留缺陷等级分布说明残余风险，收敛趋势说明问题是否受控。三条证据指向一致时结论较可靠；出现分歧时，例如通过率高但存在致命级遗留缺陷，结论应如实呈现分歧并给出处理建议。
结论表述可以采用固定模板：结论（当前版本在既定范围内可交付/有条件交付/不建议交付）+支撑数据（执行率、通过率、遗留缺陷等级分布、收敛趋势的关键数字）+遗留风险（未修复缺陷清单及影响范围）+建议（需补充的测试、需确认的风险接受人、下版本跟进项）。模板保证结论有据可查，也方便审批方快速定位分歧点。
一个版本收尾报告的算例
以下为演示用示例数据，不代表任何真实项目结果。
某版本测试计划包含用例 800 条，其中功能测试 500 条、回归测试 200 条、兼容性测试 100 条。截至报告生成时刻：通过 620 条，失败 60 条，阻塞 20 条，未执行 100 条。缺陷方面：累计有效缺陷 150 个，已关闭 110 个，遗留 40 个，其中致命 1 个、严重 6 个、一般 25 个、提示 8 个。测试后期四周的新增缺陷数分别为 30、22、15、9，关闭数分别为 18、25、28、26。
逐项计算：
- 已执行数 = 620 + 60 + 20 = 700 条；执行率 = 700 ÷ 800 = 87.5%。
- 通过率（以已执行数为分母）= 620 ÷ 700 ≈ 88.6%；若以用例总数为分母则为 620 ÷ 800 = 77.5%，报告中注明采用前者。
- 缺陷关闭率 = 110 ÷ 150 ≈ 73.3%。
- 缺陷密度（以用例数为分母）= 150 ÷ 800 ≈ 18.8 个/百条用例。
- 遗留缺陷中致命与严重级合计 7 个，占遗留总数的 17.5%。
- 收敛趋势：第四周新增 9 个、关闭 26 个，关闭数连续三周高于新增数，遗留总数从第三周末的 57 个降至 40 个。
未执行用例 100 条集中在兼容性测试，原因是两台测试设备未到位。处理方式是在报告中单列该缺口，兼容性结论标注为“未完成”，不计入通过率分母，也不据此推断兼容性质量。若某模块用例全部未执行，该模块通过率分母为零，报告中写“不适用”并说明原因，不用 0% 代替。
由上述数据推导的结论表述：当前版本在功能与回归范围内执行率 87.5%、通过率 88.6%，缺陷关闭率 73.3%，后期新增持续低于关闭，整体趋于收敛；遗留 1 个致命缺陷和 6 个严重缺陷需在发布前确认修复或由负责人书面接受风险；兼容性测试因设备原因未完成，建议补齐后更新报告再提交审批。
在工具层面，这类统计依赖用例执行状态和缺陷状态在同一个系统中持续沉淀。ONES 测试管理支持测试用例与需求、任务关联，测试计划与迭代关联，未通过的用例可快速创建缺陷任务并在测试与研发团队间流转；测试情况概览可查看测试计划的进度和通过率，质量统计报表与测试报告模板可用于汇总版本数据。报告中的具体指标项和计算口径仍需按本文定义在模板中确认，以保证分子分母与统计时间窗一致。
指标解读的边界与常见误读
指标是证据，不是保证。解读时注意以下限制：
- 高通过率不等于低风险。通过率只反映已执行用例的结果。如果用例覆盖不足或用例设计偏弱，大量缺陷可能未被触发。报告应同时给出用例对需求的覆盖情况和未执行用例数，让读者判断通过率的分母是否足够。
- 遗留缺陷数量少但等级高，风险可能更大。遗留 3 个缺陷中有 1 个致命级，与遗留 20 个一般级缺陷相比，前者对交付的威胁更直接。等级分布要优先于总数解读。
- 缺陷密度分母不可比时不要直接比较。不同模块的用例粒度、功能点划分方式可能不同，密度差异未必代表质量差异。跨版本比较前确认分母口径一致，否则只做同版本内的相对排序。
- 指标只反映已测范围。未执行的用例、未覆盖的场景、未模拟的负载都不在数据之内。报告结论应限定在测试范围内，不外推到生产环境的全部使用场景。
- 不设通用达标线。执行率、通过率、关闭率没有放之四海皆准的合格值，阈值应结合版本目标、变更规模和历史基线确定。例如新功能版本与紧急修复版本对通过率的要求可以不同，历史基线则提供“本版本相对上版本是否退步”的参照。
- 单指标不能当因果结论。通过率下降可能是用例增加、环境变化或真实质量退化，报告应结合分层数据和缺陷趋势解释原因，避免用一个数字下判断。
把这些边界写进报告的“说明”部分，可以防止读者过度解读，也让结论在审批讨论中经得起追问。
常见问题
测试报告中的通过率应该用已执行数还是用例总数作分母？
两种口径都有使用场景，关键在于报告写明采用哪一种并在版本间保持一致。用已执行数作分母（通过数÷已执行数）衡量已测部分的稳定性；用用例总数作分母（通过数÷用例总数）把未执行部分也计为未通过，数值更低但更保守。建议主口径用已执行数作分母，同时附上未执行用例数，让读者自行判断覆盖缺口。
遗留缺陷数量很少，是否就可以判定版本风险低？
不能仅凭数量判断。遗留缺陷的严重等级分布比总数更能说明风险：遗留3个缺陷中有1个致命级，与遗留20个一般级缺陷相比，前者对交付的威胁更直接。报告应单独标注致命和严重级缺陷的处理状态（已修复待验证、计划下版本修复、确认不修复），并结合通过率与收敛趋势综合判断。
统计缺陷指标时，哪些缺陷应该被剔除？剔除后需要说明吗？
无效缺陷（描述不清、无法复现且确认非产品问题）、重复缺陷（合并到主缺陷）、非缺陷记录（需求变更、环境问题）应从分子分母中剔除。报告中需注明剔除数量和规则，且同一版本内保持一致，避免通过调整口径美化数据。
某个模块的用例全部未执行，通过率怎么呈现？
该模块通过率分母为零，报告中写“不适用”并说明原因（如环境未就绪、依赖未交付），不用0%代替。同时将该模块的结论标注为“未完成”，不计入整体通过率分母，也不据此推断该模块质量。
ONES 测试管理能否直接生成包含这些指标的测试报告？
ONES 测试管理支持质量统计报表和自动生成测试报告，提供测试情况概览查看测试计划进度和通过率，并支持自定义组装测试报告模板。报告中的具体指标项和计算口径仍需按本文定义在模板中确认，以保证分子分母与统计时间窗一致。
