回归结果分析报告要回答三个问题：这轮回归覆盖了什么、失败项分别是什么原因、当前版本能否发布。下面给出一张可直接复制填写的空白表，并逐项说明统计口径、失败分类和发布结论的填写规则，最后用一轮完整示例演示。模板适用于变更后对既有能力做验证的回归场景，测试策略制定和单个缺陷的复测跟踪不在本文范围内。
要点总览（TL;DR）
- 模板以一张空白表为核心，分为基本信息、统计口径、失败分类、发布结论四块，可直接复制到文档或表格工具中填写。
- 统计口径要固定回归用例范围（变更影响面+核心链路）、执行数、通过数、失败数、阻塞数、未执行数，并显式声明通过率的分母。
- 失败项按变更引入、环境或数据、用例失效、既有缺陷复现、待定五类归因，每类附证据、处置状态和关联工单，待定项设收敛时限。
- 发布结论用通过率达标、阻塞项清零、高优先级失败已处置三条准入条件逐条判定，输出放行、有条件放行或阻断，并登记遗留项与责任人。
- 必填字段缺失时报告标记为草稿、不可用于发布判定；模板口径变更需记录生效轮次，历史报告不回溯修改。
可复制空白模板：回归结果分析报告表
将下表复制到文档或表格工具中，按行填写。表格分为基本信息、统计口径、失败分类、发布结论四块，其中统计口径和失败分类按实际数量逐行填写，发布结论按准入条件逐条判定后勾选。
| 区块 | 字段 | 填写内容 |
|---|---|---|
| 基本信息 | 版本号 | |
| 变更范围 | ||
| 回归轮次 | 第 轮 | |
| 执行时间 | 至 | |
| 报告负责人 | ||
| 统计口径 | 回归用例范围 | 条（变更影响面 条 + 核心链路 条） |
| 执行数 | 条 | |
| 通过数 | 条 | |
| 失败数 | 条 | |
| 阻塞数 | 条 | |
| 未执行数 | 条 | |
| 通过率 | %（分母： ） | |
| 口径例外说明 | ||
| 失败分类 | 失败项编号与用例 | |
| 归因类别 | 变更引入 / 环境或数据 / 用例失效 / 既有缺陷复现 / 待定 | |
| 判定依据与证据 | ||
| 处置状态 | 已修复待验证 / 已登记待排期 / 已关闭 / 待定 | |
| 关联缺陷或工单 | ||
| 待定项收敛时限 | ||
| 发布结论 | 准入条件逐条判定 | 通过率达标：是/否；阻塞项清零：是/否；高优先级失败已处置：是/否 |
| 结论 | 放行 / 有条件放行 / 阻断 | |
| 遗留项与责任人 | ||
| 结论签署人 | ||
| 复核人 |
统计口径字段说明：分母、范围与计算方式
统计口径的作用是让不同轮次、不同人填出的数字可以互相比较。同一指标在第二轮换一种算法，报告就失去纵向对比的意义，因此每个数量字段都要在报告中写清定义。
回归用例范围如何界定
回归范围由两部分组成：变更影响面覆盖的用例，以及核心链路的固定用例集。变更影响面依据本次版本的需求和代码改动清单推导，核心链路按业务重要性预先圈定。两部分合并后去重，得到本轮回归用例总数，这个数字是所有后续统计的基数。范围一旦确定，轮次之间只允许因新增变更而追加，不允许临时删减来抬高通过率。
各数量字段的关系
执行数、通过数、失败数、阻塞数、未执行数之间应满足：执行数 = 通过数 + 失败数，回归用例范围 = 执行数 + 阻塞数 + 未执行数。填写时先核对这两个等式，出现差额说明有状态未归类，需要补齐后再计算通过率。
通过率的分母选择
通过率默认以执行数为分母，即通过数 ÷ 执行数，反映已执行部分的稳定性。当阻塞和未执行占比较高时，仅看这个数字会高估质量，因此报告需同时给出以回归用例范围为分母的覆盖完成率。两种算法都写进报告，并注明本轮采用哪一种作为发布判定依据，避免同一版本在不同会议上出现两个通过率。
阻塞与未执行为何单列
阻塞指因环境、依赖或前置条件不具备而无法执行，未执行指排期未到或主动跳过。这两类既不算通过也不算失败，混入失败会夸大问题数量，混入通过会掩盖风险。单列之后，读者能直接看出本轮结论建立在多大的执行覆盖之上。
失败分类字段说明：归因类别与处置状态
失败分类解决的是“这条失败该由谁处理、什么时候处理”。每个失败项必须归入一个类别并附证据，归不了类的进入待定，待定项要有时限，不能长期悬置。
| 归因类别 | 判定依据 | 证据要求 | 典型处置 |
|---|---|---|---|
| 变更引入 | 失败用例落在本次变更影响面内，且变更前通过 | 变更单或提交记录、上一轮通过记录 | 登记缺陷，修复后复测 |
| 环境或数据 | 在标准环境或标准数据集下可复现通过，失败由配置、依赖版本或测试数据引起 | 环境差异对比、数据快照 | 修正环境或数据后重跑，不计入产品缺陷 |
| 用例失效 | 产品行为符合当前需求，用例断言或步骤已过时 | 需求变更记录、用例评审结论 | 更新或下线用例，记录变更 |
| 既有缺陷复现 | 失败对应已登记的历史缺陷，非本次变更引起 | 历史缺陷编号、复现步骤一致 | 关联原缺陷，按原优先级推进 |
| 待定 | 现有证据不足以归入以上四类 | 失败日志、截图、复现步骤 | 指定排查人，在收敛时限内重新归类 |
处置状态与归因类别分开填写，因为同一类别可以处于不同阶段。状态建议使用四档：已修复待验证、已登记待排期、已关闭、待定。每个失败项都要填写关联缺陷或工单编号，使报告中的失败条目能追溯到跟踪系统里的具体记录。待定项的收敛时限建议按发布节奏设定，例如在发布评审前一个工作日完成归类，超时未收敛的待定项在发布结论中按未处置的高优先级失败处理。
必填与选填：哪些字段不能空
必填字段决定报告能否作为发布判定依据，缺失时报告不能进入评审。选填字段用于补充说明，按场景填写。
| 字段 | 必填/选填 | 理由或适用场景 |
|---|---|---|
| 版本号、变更范围、回归轮次、执行时间、负责人 | 必填 | 缺少任一项，报告无法对应到具体版本和轮次 |
| 回归用例范围及两部分构成 | 必填 | 所有比例的分母来源 |
| 执行数、通过数、失败数、阻塞数、未执行数 | 必填 | 数量关系需可核对 |
| 通过率及分母说明 | 必填 | 发布判定的核心指标 |
| 每个失败项的归因类别、证据、处置状态、关联工单 | 必填 | 失败项可追溯的前提 |
| 发布结论、签署人、复核人 | 必填 | 结论需有人负责 |
| 口径例外说明 | 选填 | 存在剔除用例、替换环境等特殊情况时填写 |
| 待定项收敛时限 | 选填 | 存在待定项时必填，无待定项可空 |
| 遗留项与责任人 | 选填 | 结论为有条件放行时必填 |
必填字段缺失时，报告状态标记为“草稿—不可用于发布判定”，并在评审材料中注明缺失项和补齐时间。允许先提交草稿收集意见，但签署环节只接受必填完整的版本。
填写示例：一轮回归的完整报告
以下为演示情景，用于说明字段如何填写，数据不代表任何真实项目。
背景：版本 V3.2，变更范围为订单结算流程改造与优惠券规则调整，本轮为第一轮回归，执行时间为 3 月 10 日至 3 月 12 日，负责人为测试组李某。
| 区块 | 字段 | 填写内容 |
|---|---|---|
| 统计口径 | 回归用例范围 | 240 条（变更影响面 96 条 + 核心链路 144 条） |
| 执行数 / 通过 / 失败 / 阻塞 / 未执行 | 执行 228 条；通过 209 条；失败 19 条；阻塞 8 条；未执行 4 条 | |
| 通过率 | 91.7%（分母：执行数 228）；覆盖完成率 95.0%（分母：范围 240） | |
| 失败分类 | 变更引入 | 11 条，均有变更单与上轮通过记录，已登记缺陷 7 个，状态为已修复待验证 5 个、已登记待排期 2 个 |
| 环境或数据 | 3 条，测试库优惠券数据过期导致，修正数据后重跑通过，不计入缺陷 | |
| 用例失效 | 2 条，结算页字段顺序调整，断言过时，已更新用例 | |
| 既有缺陷复现 | 2 条，关联历史缺陷 BUG-1187、BUG-1203，按原优先级推进 | |
| 待定 | 1 条，日志不足，指定排查人，3 月 13 日前完成归类 | |
| 发布结论 | 准入判定 | 通过率达标：是（阈值 90%）；阻塞项清零：否（8 条阻塞待环境恢复）；高优先级失败已处置：是（高优先级失败均已修复待验证） |
| 结论 | 有条件放行 | |
| 遗留项与签署 | 遗留：2 个已登记待排期缺陷、1 条待定项、8 条阻塞用例；责任人：开发王某、测试李某；签署人李某，复核人测试负责人张某 |
这份示例中，阻塞项未清零但均集中在非核心链路的报表模块，且高优先级失败已全部处置，因此结论为有条件放行，遗留项逐条登记了责任人和完成时间。若阻塞项涉及核心链路，同样的通过率应判为阻断。
发布结论的判定规则与写法
发布结论由准入条件逐条判定得出，不依赖个人印象。建议固定三条准入条件，每条给出是或否，再据此选择结论。
| 结论 | 适用条件 | 写法要点 |
|---|---|---|
| 放行 | 通过率达到阈值；阻塞项清零；高优先级失败全部关闭或已验证修复 | 写明通过率数值、分母和判定依据 |
| 有条件放行 | 通过率达标，但存在不影响核心链路的阻塞项或已登记待排期的中低优先级失败 | 逐条列出遗留项、责任人和完成时间，注明放行范围 |
| 阻断 | 通过率低于阈值，或核心链路存在未处置的高优先级失败，或阻塞项导致核心链路未覆盖 | 写明阻断原因和解除条件，不写模糊表述 |
通过率阈值由团队按业务风险设定，例如核心交易类系统可设 95%，内部工具可设 85%，阈值一旦确定应写入模板并在轮次间保持一致。结论句式建议统一为：“本轮回归执行 X 条，通过率 Y%（分母 Z），准入条件 A/B/C 判定为……，结论为放行/有条件放行/阻断，遗留项 N 项，责任人……，签署人……，复核人……。”签署人与复核人应为不同角色，签署人对结论负责，复核人核对统计口径与失败归类是否一致。
报告中承载的用例执行记录、失败项和关联缺陷需要在同一处可查。ONES 测试管理支持为测试活动生成多维度测试报告并提供报告模板，失败项可一键创建并关联缺陷，缺陷可关联至迭代，便于把报告中的失败分类和遗留项直接落到跟踪记录上；具体报告维度和模板配置以实际产品为准。
模板调整与维护方法
模板需要随团队和发布节奏调整，但调整本身要有记录，否则口径会在不知不觉中漂移。
- 字段增删的判断依据：某字段连续三个轮次无人填写且不影响结论判定，可考虑删除；出现新的失败类型反复进入待定，应新增归因类别；发布节奏从月度改为双周时，可增加“距上次回归的变更积压量”字段。
- 口径变更的记录方式：通过率分母、阈值、用例范围界定方式发生变化时，在模板附带的变更记录中写明变更内容、原因和生效轮次，历史报告保留原口径，不回溯修改。
- 模板版本与归档：模板标注版本号，每轮报告归档时记录所用模板版本，便于跨轮次对比时识别口径差异。
- 与缺陷跟踪、发布流程的衔接：失败分类中的关联工单字段应与缺陷跟踪系统的编号规则一致；发布结论的签署环节嵌入发布评审流程，报告作为评审输入之一。
维护检查可按季度执行：核对必填字段是否仍被完整填写、待定项是否在时限内收敛、通过率阈值是否仍匹配当前业务风险、模板版本与归档记录是否一致。发现连续两轮出现同类口径争议，即应修订模板并记录变更。
常见问题
回归用例范围在轮次之间可以调整吗？
范围一旦确定，轮次之间只允许因新增变更而追加用例，不建议临时删减。删减会直接改变通过率的分母，使前后两轮的数字失去可比性。如果确实需要剔除某批用例，应在“口径例外说明”中写明剔除的用例、原因和影响，并保留原始范围数字，供复核人核对。
阻塞用例在发布前恢复了，报告要怎么更新？
阻塞用例恢复后应重新执行，并把结果从阻塞数移入执行数，同时更新通过数或失败数，重新核对“执行数 = 通过数 + 失败数”和“范围 = 执行数 + 阻塞数 + 未执行数”两个等式。通过率和覆盖完成率随之重算，发布结论的准入判定也要重新走一遍。建议在报告中保留更新时间和更新人，避免评审时引用旧数字。
待定项在发布评审时仍未归类，应该怎么处理？
按未处置的高优先级失败对待，在发布结论中体现。可以在评审前指定排查人并给出归类时限，但时限晚于评审时点，就不能假设它会自动解决。若该待定项涉及核心链路，倾向判为阻断；若不涉及核心链路，可在有条件放行中登记为遗留项，写明责任人和完成时间。
通过率阈值应该由谁设定，多久复核一次？
阈值由团队结合业务风险设定，核心交易类系统可以设得高一些，内部工具可以设得低一些，关键是同一系统在轮次间保持一致。建议随模板维护按季度复核一次，业务风险或发布节奏发生明显变化时提前调整。阈值变更要写入模板的变更记录，注明生效轮次，历史报告沿用原阈值，便于跨轮次对比。
报告里的失败项和缺陷跟踪系统如何对应？
每个失败项都要填写关联缺陷或工单编号，编号规则与缺陷跟踪系统保持一致，使报告中的条目能追溯到具体记录。归因类别和处置状态分开填写，因为同一类别可以处于不同阶段。ONES 测试管理支持失败项一键创建并关联缺陷，缺陷可关联至迭代，便于把报告中的失败分类和遗留项直接落到跟踪记录上；具体关联字段以实际产品配置为准。
