回归结果分析是把一轮回归测试的执行记录整理成可复算的指标，再结合变更范围、用例覆盖和缺陷分布解释结果。口径统一是结论可信的前提：同一批记录，分母定义不同，算出的通过率可能相差很大。本文给出指标清单、取数规则、计算步骤和一个完整算例，并说明哪些结论不能从指标直接得出。
要点总览（TL;DR）
- 回归结果分析服务于一个具体决策：本轮回归是否支撑发布。结论要落到可执行的判断上，并说明依据。
- 先定口径再算数：执行率、通过率、阻塞率、缺陷发现密度、遗留缺陷数各有分母定义，阻塞、未执行、跳过计入执行率分母但不计入通过率分母。
- 计算按五步走：锁定数据快照、状态归类清洗、逐指标计算、结合变更范围解释、记录依据与待确认项，每步保留输入输出便于复核。
- 200条用例的算例显示，88.2%的通过率需要结合未执行与阻塞用例的分布、遗留严重缺陷来判断，单一指标不足以支撑发布结论。
- 解读有边界：通过率高不等于变更风险低，跨轮次数字不可直接比较，未覆盖部分要单独说明，回归结果是发布判断的输入之一。
回归结果分析要回答什么问题
回归结果分析服务于一个具体决策：本轮回归是否支撑发布，还是需要继续修复后再验。围绕这个决策，分析要回答三件事——既有能力是否被变更破坏、破坏的程度和分布如何、未验证的部分还剩多少风险。结论应当能落到“可以发布”“有条件发布（附已知遗留）”“暂不发布”这类可执行的判断上，而不是停留在“整体情况良好”的描述。
评估对象需要事先写清楚：哪一轮回归、哪个版本的用例集、覆盖哪些模块或需求、执行记录取自哪个时间窗。这三项构成分析的数据边界，后续所有指标都在这个边界内计算。边界不清，指标就失去可比性。
本文聚焦变更后既有能力的验证结果分析。测试策略与测试计划的制定属于测试计划范畴，单个缺陷的复测与修复验证跟踪属于缺陷跟踪范畴，两者不在本文展开。分析开始前可以先写一份评估目标说明，包含：本轮回归支撑的发布决策、评估对象（用例集版本、轮次、模块范围）、结论的交付对象与时间要求。
指标与统计范围：选哪些指标、圈多大范围
指标不是越多越好。回归结果分析常用的六个指标已经能覆盖发布判断和质量趋势两类用途，再增加指标往往只是换角度重复同一信息。选择时先明确每个指标服务哪个判断，再决定是否纳入。
| 指标 | 用途 | 统计范围 |
|---|---|---|
| 执行率 | 判断本轮回归是否按计划跑完，识别未验证部分 | 本轮纳入回归的用例集版本，统计时间窗内的执行记录 |
| 通过率 | 判断已执行部分中既有能力保持正常的比例 | 已执行用例（分母口径见下一节） |
| 失败率 | 与通过率互补，定位失败集中度 | 同上 |
| 阻塞率 | 判断环境、依赖等外部因素对验证完整性的影响 | 本轮全部应执行用例 |
| 缺陷发现密度 | 衡量单位用例或单位模块暴露的缺陷数量，用于质量趋势对比 | 本轮回归执行期间提交的缺陷，按模块或按用例数折算 |
| 遗留缺陷数 | 判断发布时仍带在身上的已知问题规模 | 本轮回归发现且截至结论时点未关闭的缺陷 |
用途上可以分两组：执行率、通过率、阻塞率和遗留缺陷数直接参与发布判断；失败率和缺陷发现密度更多用于趋势观察和定位问题集中区域。趋势类指标需要多轮数据才有意义，单轮数值只能作为参考。
统计范围由四个要素圈定：用例集版本（哪一版用例被纳入）、回归轮次（第几轮，是否包含冒烟轮）、统计时间窗（执行记录从何时到何时）、模块或需求范围（全量回归还是变更影响范围内的回归）。范围一旦确定，本轮分析内不再调整；确需调整时，应在结论中注明并说明对指标的影响。
数据口径：分子分母、状态归类与缺失值处理
口径说明要写到别人拿着同一批原始记录能算出同样数字的程度。每个指标至少写清公式、分子、分母、单位和统计时间窗。下表给出常用口径，实际使用时按团队状态定义替换名称，但归类逻辑保持一致。
| 指标 | 公式 | 分母定义 | 单位 |
|---|---|---|---|
| 执行率 | 已执行用例数 ÷ 应执行用例数 | 本轮纳入回归的全部用例，含阻塞、未执行、跳过 | % |
| 通过率 | 通过用例数 ÷ 已执行用例数 | 已执行用例，即通过 + 失败（不含阻塞、未执行、跳过） | % |
| 失败率 | 失败用例数 ÷ 已执行用例数 | 同上 | % |
| 阻塞率 | 阻塞用例数 ÷ 应执行用例数 | 本轮纳入回归的全部用例 | % |
| 缺陷发现密度 | 本轮提交缺陷数 ÷ 已执行用例数（或按模块折算） | 已执行用例数或模块用例数，需在报告中注明采用哪种 | 个/百条用例 |
| 遗留缺陷数 | 本轮发现且未关闭的缺陷计数 | 不涉及分母，按严重级别分组呈现 | 个 |
状态归类是口径中最容易出分歧的部分。建议明确以下规则：通过指实际结果与预期一致；失败指实际结果与预期不一致且已提交缺陷或确认问题；阻塞指因环境、依赖、数据等原因无法执行；未执行指本轮计划内但尚未开始；跳过指经评审确认本轮不适用。阻塞、未执行、跳过计入执行率的分母，但不计入通过率的分母——通过率回答的是“跑了的里面有多少是好的”，把没跑成的算进去会掩盖问题。
缺失值和异常记录按以下方式处理：无执行记录的用例按未执行计入分母；同一用例在同一轮次内重复执行，以最后一次有效执行结果为准，并在原始记录中保留重复痕迹；因环境中断导致整批记录不可信的，该批次不计入本轮统计，在结论中单独说明受影响范围。分母为零时，指标记为“不适用”并注明原因，不能写成 0% 或 100%——例如本轮没有执行任何用例，通过率没有意义，此时应直接报告执行率为 0 并说明原因。
计算与评估步骤：从原始记录到结论
分析过程要能被他人按同样步骤重算，关键是每一步都留下输入和输出。以下五步可以作为固定流程。
- 锁定数据快照。确定用例集版本号、回归轮次和执行记录的时间窗，导出一份不再变动的记录副本。输出：带版本标识的原始数据集。
- 清洗与状态归类。按上一节规则把每条记录归入通过、失败、阻塞、未执行、跳过，标记重复执行和异常中断记录。输出：带归类字段的明细表，以及一份异常记录清单。
- 逐指标计算。按口径表计算六个指标，保留分子、分母和中间结果，便于复核。输出：指标计算表，每个数字可追溯到明细。
- 结合变更范围解释。把失败和阻塞用例映射到变更涉及的模块，检查变更影响范围内的用例覆盖是否充分，再形成发布判断。输出：结论段落，含判断和主要依据。
- 记录依据与待确认项。列出结论依赖的关键数字、口径选择、未覆盖范围和需要他人确认的问题。输出：分析记录，随结论一并归档。
这五步中，第二步和第四步最容易被跳过。状态归类不做，指标就建立在模糊的记录上；变更范围不映射，高通过率可能只是跑了一堆与变更无关的用例。执行记录、用例状态和缺陷数据分散在不同工具里时，汇总和复核的成本会明显上升。ONES 的测试管理可以按用例集和轮次组织执行记录，缺陷以工作项形式与用例关联，分析时在同一处取数并保留状态变更痕迹，便于按上述步骤复算和交接评审。
一个算例：200条用例的回归结果怎么读
以下为演示情景，数字为构造数据，用于说明计算过程。某轮回归纳入 200 条用例，统计时间窗为两天，变更涉及订单和支付两个模块。执行记录归类后：通过 150 条，失败 20 条，阻塞 10 条，未执行 18 条，跳过 2 条。本轮提交缺陷 26 个，截至结论时点关闭 14 个，遗留 12 个，其中严重级别 3 个。
计算过程：应执行用例数为 200；已执行用例数为通过加失败，即 170。执行率 = 170 ÷ 200 = 85.0%；通过率 = 150 ÷ 170 ≈ 88.2%；失败率 = 20 ÷ 170 ≈ 11.8%；阻塞率 = 10 ÷ 200 = 5.0%；缺陷发现密度 = 26 ÷ 170 ≈ 15.3 个/百条用例；遗留缺陷 12 个，其中严重 3 个。
单看 88.2% 的通过率似乎不错，但结合覆盖情况解读会得到不同判断。未执行的 18 条和阻塞的 10 条合计 28 条，占应执行用例的 14%，需要检查这些用例是否落在变更影响范围内。若订单模块的核心路径用例恰好在未执行之列，则通过率只反映了已跑部分，不能支撑“变更风险可控”的结论。反之，若未执行用例集中在与本次变更无关的模块，且变更范围内用例全部执行且通过，结论强度会明显提高。
遗留缺陷同样影响结论。12 个遗留缺陷中有 3 个严重级别，需要逐个确认是否影响发布路径；若严重缺陷集中在支付模块且未修复，即使通过率较高，也应给出“暂不发布”或“有条件发布并附已知问题清单”的判断。这个算例说明：发布判断由执行率、覆盖情况、遗留缺陷严重级别共同决定，任何单一指标都不足以支撑结论。
结果解读与限制：哪些结论不能从指标直接得出
指标反映的是已执行部分的状况，解读时需要守住几条边界。
- 通过率高不等于变更风险低。结论强度取决于覆盖范围：变更涉及的模块是否都有用例覆盖、用例本身是否有效。用例陈旧或断言过弱时，通过率高可能只是没测到问题。判断覆盖是否充分，需要把变更点与用例映射逐一核对。
- 跨轮次、跨用例集版本的数字不可直接比较。用例集增删、状态定义调整、统计时间窗变化都会改变分母。需要对比趋势时，先确认两轮的用例集版本和口径一致；不一致时应分别报告，或按共同子集重算后再比较。
- 未覆盖部分要单独说明。未执行、阻塞、跳过的用例不进入通过率分母，但它们代表未验证的风险。结论中应列出这部分用例的数量和分布，不能因为指标好看就略过。
- 回归结果是发布判断的输入之一。发布决策还需要结合代码评审、其他测试类型的结果、线上监控和业务影响评估。把回归通过率当作质量保证的全部依据，会低估未覆盖区域和未发现缺陷的风险。
- 指标不用于个人绩效结论。执行率和通过率受任务分配、环境状况和用例设计影响，直接对应到个人考核会扭曲记录行为，例如把失败用例改为跳过。分析结论应指向版本质量和流程改进。
把这些限制写进分析记录，和指标一起交付，结论才经得起追问。一份合格的回归结果分析，读者能从中看到数字怎么来的、覆盖了什么、没覆盖什么，以及为什么得出这个发布判断。
常见问题
本轮回归没有跑完，执行率只有六成，还能做结果分析吗？
可以分析，但结论的性质要改。执行率不足时，通过率只反映已执行部分，分析重点应转向未执行和阻塞用例的分布：它们是否落在变更影响范围内、阻塞原因是否可解除、剩余用例预计何时能跑完。此时给出的判断通常是“暂不发布”或“有条件发布”，并附上未验证范围清单。把执行率、未执行用例清单和阻塞原因一并交付，比只报一个通过率更有决策价值。
两轮回归的通过率一个85%、一个92%，能直接说质量变好了吗？
不能直接比较。先核对两轮的用例集版本、状态定义和统计时间窗是否一致。用例集增删会改变分母，状态归类调整会改变分子，时间窗不同则纳入的执行记录范围不同。口径一致时可以直接对比；不一致时，建议按两轮共同的用例子集重算后再比较，或分别报告并注明差异。趋势判断至少需要多轮同口径数据，单轮之间的差值容易受用例调整影响。
阻塞用例算失败还是算未执行？对指标影响大吗？
阻塞应单独归类，既不算通过也不算失败。它计入执行率的分母（因为属于应执行用例），但不计入通过率的分母。这样处理的原因是：阻塞反映的是环境、依赖、数据等外部因素导致的无法验证，与用例本身是否暴露问题无关。如果把阻塞算作失败，会拉低通过率并掩盖真实缺陷分布；如果算作通过，则会高估验证完整性。阻塞率单独作为一个指标呈现，正好用来判断验证完整性的缺口。
缺陷发现密度按用例数折算还是按模块折算，怎么选？
两种都可以，关键是同一份报告内保持一致并在口径说明中注明。按已执行用例数折算（如每百条用例的缺陷数）适合跨轮次、跨团队做趋势对比，因为分母标准化了规模差异；按模块折算适合定位问题集中区域，能直接看出哪个模块缺陷密度偏高。如果两个用途都要，可以同时给出两组数字，但不要混用同一列做比较。缺陷计数口径也要固定：按提交时间归属本轮，还是按发现轮次归属，需事先约定。
回归结论需要和哪些其他证据一起看，才能支撑发布决策？
回归结果回答的是“变更后既有能力是否被破坏”，它不覆盖新功能验证、性能与安全等专项测试、代码评审发现的问题，也不反映线上监控数据。发布决策通常需要把这些证据放在一起：回归的执行率与覆盖情况、遗留缺陷的严重级别与影响路径、专项测试结论、变更本身的评审意见。回归分析记录中列出结论依赖的关键数字和待确认项，评审时其他人可以据此追问和复核，结论才站得住。
