版本测试收尾时，测试报告要回答的核心问题是：测试是否按计划做完、质量是否达到本版本预期、剩余风险是否可接受。支撑这三个判断的指标通常分三类：执行与通过情况、缺陷情况、范围与风险。每个指标都要写清分子分母、统计时间窗和数据来源，结论由多指标组合与遗留风险共同得出，单看通过率或遗留缺陷数都不足以支撑发布判断。
要点总览（TL;DR）
- 收尾测试报告围绕三类指标组织：执行与通过情况、缺陷情况、范围与风险，每个指标写明分子、分母、单位与统计时间窗。
- 通过率的分母是已执行用例数，需与执行率、覆盖率一起解读；覆盖率不足时，高通过率的参考价值下降。
- 缺陷指标要区分新增、关闭、遗留与重开口径，遗留缺陷按严重级别和模块拆解后再判断风险。
- 质量结论由多指标组合与遗留风险共同支撑，分为通过、有条件通过、不通过三档，并列出支撑指标与待办条件。
- 指标只反映已发现的问题，分母为零或样本过小时标注不可比，跨版本比较需先确认口径一致。
收尾报告要回答的质量问题
收尾报告的读者通常是版本负责人、研发负责人和发布决策人。他们需要在有限时间内判断这个版本能不能进入下一环节，因此报告承担的是判断任务，而非数据展示任务。具体来说，报告要支撑三个判断。
测试是否做完了。计划内的用例执行到什么程度，未执行的部分是因为阻塞、环境限制还是主动裁剪，这些都需要在报告中交代清楚。一个执行率只有七成的版本，即使通过率很高，也不能说明测试已经完成。
质量是否达到预期。本版本的需求覆盖是否完整，缺陷发现和关闭的节奏是否正常，遗留缺陷的严重级别分布是否在可接受范围内。这里的“预期”来自版本立项时确定的测试范围和质量要求，报告要做的是把实际数据与预期对照，指出偏差。
剩余风险是否可接受。遗留缺陷集中在哪些模块、影响哪些用户场景、是否有规避方案，未覆盖的需求和用例会带来什么盲区。风险判断需要定性说明配合定量数据，不能只给一个遗留缺陷总数。
本文的范围限定在当前版本的测试收尾结论。组织级的质量趋势分析、跨版本的度量体系设计，以及发布审批流程中的门禁规则设计，属于另外的管理议题，报告只需引用相关结论，不必在本文展开。指标的作用是支撑结论，报告里出现的每一个数字都应当能指向某个判断，罗列大量无人解读的数据会稀释重点。
通过情况与缺陷指标清单
收尾报告建议固定呈现以下指标，按执行与通过、缺陷、范围与风险三组组织。每个指标在报告中以“数值 + 分母 + 时间窗”的形式出现，避免只写一个百分比。
| 指标 | 计算方式 | 单位 | 用途 |
|---|---|---|---|
| 用例执行率 | 已执行用例数 ÷ 计划执行用例数 | 百分比 | 判断测试完成度 |
| 用例通过率 | 通过用例数 ÷ 已执行用例数 | 百分比 | 判断已执行部分的质量 |
| 阻塞用例数 | 因环境、依赖等原因无法执行的用例计数 | 个 | 识别测试中断原因 |
| 未执行用例数 | 计划内尚未执行的用例计数 | 个 | 识别覆盖缺口 |
| 新增缺陷数 | 统计时间窗内新提交的缺陷计数 | 个 | 观察测试发现能力 |
| 关闭缺陷数 | 统计时间窗内状态流转为已关闭的缺陷计数 | 个 | 观察修复进度 |
| 遗留缺陷数 | 截止时点仍未关闭的缺陷计数 | 个 | 评估剩余风险总量 |
| 严重级别分布 | 遗留缺陷按致命、严重、一般、轻微分级计数 | 个 | 判断风险结构 |
| 缺陷密度 | 缺陷数 ÷ 统计对象规模（如需求数、用例数或功能点） | 个/单位 | 横向比较模块质量 |
| 缺陷重开率 | 被重开的缺陷数 ÷ 已关闭缺陷数 | 百分比 | 反映修复质量 |
| 平均修复时长 | 缺陷修复时长总和 ÷ 已修复缺陷数 | 小时或天 | 反映响应效率 |
| 需求覆盖率 | 有用例覆盖的需求数 ÷ 本版本需求总数 | 百分比 | 判断测试范围完整性 |
| 用例覆盖率 | 已执行用例覆盖的需求数 ÷ 本版本需求总数 | 百分比 | 判断实际验证范围 |
缺陷密度需要提前约定分母。用需求数作分母适合按需求维度比较，用用例数作分母适合按测试投入比较，两种口径不能混用。重开率的分子是统计窗口内被重新打开的缺陷数，分母建议用同一窗口内关闭的缺陷数，这样能反映“关掉又回来”的比例。平均修复时长从缺陷提交时间算到修复完成时间，跨团队协作的等待时间是否计入，需要在口径说明中写明。
范围类指标除了覆盖率，还应附一份未覆盖项清单，列出没有用例覆盖的需求、被裁剪的测试范围及其原因。覆盖率数字本身不说明缺口的性质，清单才能让读者判断缺口是否可接受。
数据口径与证据来源
指标可复算的前提是口径固定。收尾报告应在附录或正文中写明以下内容，使读者能按同样规则重新计算。
统计时间窗。明确版本测试的起止日期和统计截止时点。截止时点之后提交或关闭的缺陷不计入本次报告，避免报告发出后数据仍在变化。如果报告需要多次修订，每次修订标注数据快照时间。
数据来源。用例执行数据来自用例管理记录，缺陷数据来自缺陷跟踪系统，需求范围来自需求条目。报告中注明每类数据的导出时间，便于核对。当多个系统的数据存在差异时，以哪个系统为准需要提前约定。
状态口径。“通过”指用例执行结果为通过，因缺陷导致失败后修复并复测通过的用例，按复测结果计入。“遗留”指截止时点状态未关闭的缺陷，包括待修复、修复中、待验证等状态。“重开”指已关闭的缺陷被重新激活，同一缺陷多次重开按次数累计，报告中同时给出重开缺陷数和重开次数。
缺失值与分母为零。某模块没有用例时，执行率不计算，标注“无样本”而非填零。分母为零的比率指标一律标注不可计算，并在报告中说明原因。样本量过小（例如某模块仅执行了三条用例）的比率，建议同时给出绝对数，避免百分比造成误导。
定性结论的证据。遗留缺陷风险判断需附遗留缺陷清单，包含缺陷编号、严重级别、影响模块、当前状态和处理意见。测试范围裁剪需附评审记录或决策说明。报告中的“风险可控”一类结论，应当能指向具体证据，而非仅凭经验判断。
在工具层面，ONES 测试管理支持测试用例与需求、任务关联，测试计划与迭代关联，用例可分配执行人，未通过的用例可快速创建缺陷任务并在测试与研发团队间流转。测试情况概览可查看测试计划的进度和通过率，质量统计报表支持自动生成测试报告并自定义组装模板。这些记录方式让执行数据、缺陷数据和需求范围在同一套工作项中留存，收尾时按版本和时间窗筛选即可得到可复算的数据基础。具体报表字段和状态定义以团队实际配置为准。
指标计算与结论形成步骤
从取数到给出结论，建议按以下步骤操作，每一步都留下可核对的记录。
- 冻结数据快照。在约定的截止时点导出用例执行记录、缺陷记录和需求清单，记录导出时间和筛选条件。后续所有计算基于同一份快照，避免边算边变。
- 逐项计算指标并记录分母。按指标定义表逐项计算，每个比率旁边写出分子、分母和单位。分母为零或样本过小的指标单独标注。
- 拆解遗留缺陷。先按严重级别分组，再按模块或需求分组，形成二维分布。致命和严重级别的遗留缺陷逐条列出影响场景和规避方案。
- 与版本准入预期对照。把计算结果与版本立项时确定的测试范围、质量要求逐项比对，标出达到、接近和偏离的项。偏离项要写明偏差幅度和可能原因。
- 组合多指标形成结论。结论分为通过、有条件通过、不通过三档。给出结论时列出支撑它的主要指标和遗留风险，说明哪些条件需要在发布后跟踪。例如执行率和覆盖率达标、无致命遗留缺陷、严重遗留缺陷均有规避方案，可给出有条件通过，并把遗留缺陷的修复计划作为条件。
结论形成过程中，如果发现某类指标与预期偏差较大，应回到数据核对原因，确认是质量问题还是统计口径问题。口径问题修正后重新计算，质量问题则在报告中如实呈现并纳入风险判断。
一个版本收尾的计算示例
以下为演示情景，数字为虚构，用于说明计算过程。
某版本计划执行用例 500 条，截止时点已执行 460 条，其中通过 414 条，失败 46 条；阻塞用例 15 条，未执行用例 25 条。本版本需求 80 个，有用例覆盖的需求 76 个，已执行用例覆盖的需求 72 个。统计窗口内新增缺陷 120 个，关闭 98 个，截止时点遗留 22 个，其中致命 0 个、严重 3 个、一般 12 个、轻微 7 个。窗口内关闭的缺陷中有 6 个被重开。
| 指标 | 计算过程 | 结果 |
|---|---|---|
| 用例执行率 | 460 ÷ 500 | 92% |
| 用例通过率 | 414 ÷ 460 | 90% |
| 需求覆盖率 | 76 ÷ 80 | 95% |
| 用例覆盖需求率 | 72 ÷ 80 | 90% |
| 缺陷密度（按需求） | 120 ÷ 80 | 1.5 个/需求 |
| 缺陷重开率 | 6 ÷ 98 | 6.1% |
| 遗留缺陷占比 | 22 ÷ 120 | 18.3% |
从执行看，8% 的用例未执行，其中 15 条因环境阻塞、25 条未执行，需要说明未执行用例对应的需求是否已被其他用例覆盖。从覆盖看，4 个需求没有用例覆盖，8 个需求虽有用例但未执行，这 12 个需求构成覆盖缺口，应列入未覆盖项清单。
从缺陷看，遗留 22 个缺陷中严重级别 3 个，需要逐条确认影响模块和规避方案；一般和轻微共 19 个，可结合修复计划判断是否随版本发布。重开率 6.1% 说明关闭的缺陷中有少量修复不彻底，报告可提示关注重开缺陷的分布模块。
示例结论可写为：有条件通过。依据是执行率 92%、通过率 90%、需求覆盖率 95%，无致命遗留缺陷；条件是 3 个严重遗留缺陷在发布前完成修复或提供明确规避方案，12 个未覆盖需求在发布后首个迭代补测，25 条未执行用例说明原因并安排补执行。该结论同时列出支撑指标和待办条件，读者可以按报告中的数据复核判断过程。
指标解读的边界与常见误判
指标是判断的输入，不是质量保证本身。收尾报告中常见的误判有以下几类。
高通过率掩盖覆盖不足。通过率的分母是已执行用例数，如果执行率低或用例本身没有覆盖关键场景，通过率再高也不能说明质量好。解读时应把执行率、覆盖率和通过率放在一起看，覆盖率不足时通过率的参考价值下降。
遗留缺陷为零需要核对口径。遗留数为零可能是缺陷确实已关闭，也可能是关闭口径过宽，例如未验证就标记关闭、把缺陷转为需求或挂起状态后不计入遗留。报告应附关闭缺陷的验证记录，并说明挂起、转需求等特殊状态的处理方式。
分母为零或样本过小的指标不可比。某模块没有用例或只执行了几条用例时，其通过率与执行充分的模块不具可比性。这类指标应标注样本量，必要时用绝对数替代百分比。
指标只反映已发现的问题。缺陷数、通过率都基于已经执行和已经提交的记录，未执行的场景、未设计的用例、用户实际使用中的问题不在指标覆盖范围内。报告可以说明测试范围的边界，提醒读者指标之外仍有未知风险。
跨版本比较需要口径一致。用例拆分粒度、缺陷严重级别定义、统计时间窗长度发生变化时，两个版本的指标不能直接对比。需要比较时，先确认口径一致，或在报告中注明差异。
把这些限制写进报告，不会削弱结论，反而让读者清楚结论的适用条件。收尾报告的价值在于用可复算的数据和明确的证据支撑一个可被检验的判断，指标组合、口径说明和风险清单三者缺一不可。
常见问题
版本测试收尾时，用例执行率不到100%还能给出通过结论吗？
可以，但结论需要附带条件。执行率不足说明测试未完全做完，报告应先说明未执行部分的性质：因环境或依赖阻塞的用例、主动裁剪的范围、还是排期不足遗留的用例。如果未执行用例对应的需求已被其他用例覆盖，风险相对可控；如果关键场景没有执行，即使通过率很高也应给出有条件通过或不通过。示例中执行率92%、需求覆盖率95%，结论为有条件通过，并把未执行用例的补执行安排写成条件。
遗留缺陷数为零，是否可以直接判定质量达标？
需要先核对关闭口径。遗留数为零可能是缺陷确实修复并验证关闭，也可能是关闭口径过宽，例如未验证就标记关闭，或把缺陷转为需求、挂起状态后不计入遗留。报告应附关闭缺陷的验证记录，并说明挂起、转需求等特殊状态的处理方式。同时结合执行率和覆盖率判断：测试范围本身不完整时，遗留为零只能说明已执行部分未发现问题。
缺陷密度用需求数还是用例数作分母？
两种口径都可用，关键是全报告统一并写明。用需求数作分母适合按需求维度比较模块质量，用用例数作分母适合结合测试投入比较。两种口径不能混用，也不能拿一个版本按需求数算的密度去和另一个版本按用例数算的密度直接对比。跨版本比较前先确认分母定义、用例拆分粒度和统计时间窗一致。
报告截止时点之后又提交或关闭了缺陷，数据要不要更新？
建议以约定的截止时点冻结数据快照，报告基于同一份快照计算，并标注导出时间和筛选条件。截止时点之后的变化不并入本次报告，避免报告发出后数字仍在变动。如果确需修订，每次修订标注新的快照时间，并在报告中说明与上一版的差异，便于读者核对结论是否受影响。
ONES 的测试管理能直接支撑这些指标的取数吗？
ONES 测试管理支持测试用例与需求、任务关联，测试计划与迭代关联，用例可分配执行人，未通过的用例可快速创建缺陷任务并在测试与研发团队间流转；测试情况概览可查看测试计划的进度和通过率，质量统计报表支持自动生成测试报告并自定义组装模板。执行数据、缺陷数据和需求范围在同一套工作项中留存，收尾时按版本和时间窗筛选即可得到可复算的数据基础。具体报表字段和状态定义以团队实际配置为准。
