测试结果汇总要先把结论对象定清楚，再按固定口径收集执行记录和缺陷数据，归并去重后写成一页结论加一份明细，经评审确认后交付。整个过程可以拆成定口径、收数据、归并统计、写结论、评审交付五步，每一步都要有输入、负责人和完成标志，避免数据收上来后反复返工。
要点总览（TL;DR）
- 先锁定结论对象（某个测试轮次或某个版本）与纳入范围、统计字段，形成一页口径说明，再开始取数。
- 按收集数据、清洗去重、归并统计、撰写结论、评审交付五步推进，每步明确输入、动作与完成标志。
- 测试执行人保执行记录与缺陷复现信息，测试负责人做口径与结论，开发负责人确认缺陷状态，项目或产品负责人确认风险接受。
- 交付前用检查清单核对：数字可回溯、重复缺陷已合并、结论能回答能否进入下一步、遗留风险有责任人和时间。
汇总前先定口径：结论对象、范围与字段
汇总返工最常见的原因，是数据收完之后才发现口径不一致：有人按用例数统计，有人按执行次数统计；有人把已关闭缺陷算进遗留，有人没算。所以在打开表格之前，先把规则写成一页口径说明，发给所有参与人确认。
先确定结论对象
本次汇总回答的是哪个问题，决定了后面所有数据的取数范围。常见的有两种：
- 针对某个测试轮次：例如“第三轮系统测试”，结论回答这一轮测了什么、结果如何、还剩什么问题，适合轮次之间对比和决定是否进入下一轮。
- 针对某个版本：例如“V2.3版本”，结论回答这个版本整体质量是否达到交付条件，通常需要汇总该版本下所有轮次的数据。
两种对象的数据范围不同，混用会导致数字对不上。口径说明里要写明本次采用哪一种，以及对应的版本号或轮次编号。
确定纳入范围
范围要写清楚三件事：哪些模块纳入、哪些测试类型纳入、哪些环境纳入。例如“纳入订单、支付、退款三个模块的功能测试与接口测试，环境为预发布环境”。范围之外的内容即使有数据也不进本次汇总，需要时单独说明。范围写清楚，后续核对数字时才有依据。
约定统计字段与统计规则
字段名称和计算方式要统一，建议在口径说明中直接列出：
| 字段 | 统计规则 |
|---|---|
| 用例总数 | 范围内已纳入本次执行的用例数，不含范围外用例 |
| 执行数 | 本轮实际执行过的用例数，重复执行按用例计一次 |
| 通过数 / 失败数 / 阻塞数 | 以最后一次执行结果为准，阻塞指因环境或依赖问题无法执行 |
| 缺陷数 | 本轮新提交且确认有效的缺陷，重复提交合并后计数 |
| 严重程度分布 | 按团队既有分级（如致命、严重、一般、轻微）统计各等级数量 |
统计规则里最容易出分歧的是“以最后一次执行结果为准”和“重复缺陷合并计数”这两条，提前写明白，归并阶段就少一轮争论。
约定遗留缺陷和风险的记录方式
遗留项要记录四项信息：缺陷编号或风险描述、严重程度、当前状态、责任人与计划处理时间。风险项如果还没有对应缺陷，也要单独列出，写明影响范围和触发条件。记录方式统一后，结论段的遗留风险部分可以直接从这张表引用。
口径说明的完成标志是：参与人确认无异议，范围、字段、统计规则三项齐全，可以作为后续所有数字的唯一依据。
五步完成测试结果汇总
口径确定后，按下面五步执行。每步都说明输入、动作、输出和完成标志，便于对照推进。
第一步：收集执行记录与缺陷数据
输入：口径说明、测试管理工具或表格中的执行记录、缺陷跟踪系统中的缺陷列表。动作：按范围导出数据，执行记录保留用例编号、执行结果、执行时间和执行人；缺陷保留编号、标题、严重程度、状态、所属模块和处理人。输出：一份原始数据包。完成标志：数据条数与工具中的筛选结果一致，导出时间记录在案。
第二步：清洗去重，处理状态不一致
输入：原始数据包。动作：合并重复提交的缺陷，保留最早编号并注明关联编号；核对缺陷状态，已修复但未验证的单独标记；检查执行记录中结果为空或状态矛盾的条目，找执行人确认。输出：清洗后的数据集和一份清洗记录，写明合并了哪些、修正了哪些。完成标志：每条数据都有明确状态，清洗记录可追溯。
第三步：按模块和严重程度归并统计
输入：清洗后的数据集。动作：按模块汇总用例执行情况，计算执行率、通过率；按严重程度汇总缺陷分布，标出各模块的严重及以上缺陷数量；把遗留缺陷单独成表。输出：模块统计表和缺陷分布表。完成标志：各模块数字加总与总数一致，交叉核对无差异。
第四步：撰写结论
输入：统计表、遗留缺陷表、清洗记录。动作：先写通过情况，用执行率、通过率和严重缺陷数量说明整体结果；再写主要风险，指出集中在哪些模块、影响什么功能；最后写遗留问题，逐项列出责任人和计划时间。结论要能直接回答“这一轮或这个版本能不能进入下一步”。输出：一页结论加明细附表。完成标志：结论中的每个数字都能在明细表中找到出处。
第五步：评审确认并交付
输入：结论与明细。动作：组织测试、开发、项目或产品负责人评审，重点确认缺陷状态、修复计划和风险接受意见；根据评审意见修订后定稿，记录版本号、定稿时间和参与评审人。输出：定稿的汇总文档。完成标志：评审意见已处理或明确记录，文档版本和时间完整。
这五步中，数据收集和缺陷状态更新往往涉及多个人的操作。在ONES中，测试用例的执行记录和缺陷工作项可以在同一项目内关联，汇总时按轮次或版本筛选即可取到执行结果与缺陷状态，结论文档也可以与对应工作项关联，评审意见直接记录在文档上，减少在多个表格之间来回核对。
谁来做：角色分工与各自交付物
汇总如果只由测试负责人一个人完成，数据准确性依赖个人核对，进度也容易卡在等数据上。把责任拆到角色，每个人清楚自己交什么，汇总才能按时完成。
| 角色 | 主要动作 | 交付物 |
|---|---|---|
| 测试执行人 | 按口径记录执行结果，提交缺陷时写清复现步骤和环境 | 准确的执行记录、可复现的缺陷单 |
| 测试负责人 | 确认口径，组织数据收集，完成清洗归并与结论撰写 | 口径说明、统计表、结论与明细 |
| 开发负责人 | 确认缺陷状态，给出修复计划和预计完成时间 | 缺陷状态更新、修复计划 |
| 项目或产品负责人 | 评审结论，对遗留风险给出接受或处理意见 | 风险接受意见、后续安排 |
分工中有两个容易模糊的边界需要提前说清。一是缺陷状态由开发负责人确认，测试负责人只做核对，不代替开发改状态；二是风险接受由项目或产品负责人决定，测试负责人负责把风险描述清楚，不替业务方做取舍。边界清楚，评审时就不会出现“这个状态谁改的”“这个风险谁同意的”这类追问。
示例：一个版本测试结果汇总的完整过程
以下为演示情景，用于说明汇总过程，数字仅作示例。
示例背景
某版本完成第三轮系统测试，汇总对象定为“V2.3版本第三轮系统测试”，范围是订单、支付、退款三个模块的功能测试与接口测试，环境为预发布环境。
收集到的数据
按口径导出后，范围内用例共420条，执行410条，通过372条，失败31条，阻塞7条；本轮新提交缺陷46条，合并重复后为41条，其中致命1条、严重6条、一般22条、轻微12条。
归并后的模块情况
| 模块 | 用例数 | 执行数 | 通过数 | 失败数 | 阻塞数 | 严重及以上缺陷 |
|---|---|---|---|---|---|---|
| 订单 | 180 | 178 | 168 | 8 | 2 | 2 |
| 支付 | 150 | 148 | 130 | 15 | 3 | 4 |
| 退款 | 90 | 84 | 74 | 8 | 2 | 1 |
从分布看，支付模块的失败数和严重缺陷数都最高，是本次结论需要重点说明的部分；退款模块有6条用例未执行，需要在遗留项中说明原因。
形成的结论表述
结论段可以这样写：“本轮系统测试范围内用例执行率97.6%，通过率90.7%。支付模块发现严重缺陷4条，集中在退款回调和对账两个场景，其中1条致命缺陷已修复待验证，其余3条修复中，预计两个工作日内完成。退款模块6条用例因依赖的第三方沙箱环境不可用未执行，计划环境恢复后补测。综合判断：当前版本暂不具备进入验收测试的条件，建议支付模块严重缺陷关闭并完成回归后再评估。”
评审中提出的问题与处理
评审时开发负责人指出其中1条严重缺陷实际为重复提交，已在清洗阶段合并，结论中的数量需要同步修正；产品负责人对退款模块的补测时间提出要求，明确环境恢复后一个工作日内完成。修订后结论更新缺陷数量，遗留项补充补测时间，文档记录版本号和评审时间后定稿。
完成检查：汇总交付前的核对项
交付前逐项核对下面的清单，全部通过再发出。任何一项不通过，回到对应步骤处理。
- 结论对象、范围和统计字段与口径说明一致，没有中途变更未记录。
- 统计数字可以回溯到原始执行记录和缺陷单，抽查若干条能对上。
- 重复缺陷已合并，合并记录保留；缺陷状态与修复情况已由开发负责人确认更新。
- 结论明确写出通过情况、主要风险和遗留问题，能直接回答是否可进入下一步。
- 每个遗留风险都有责任人和计划处理时间，风险接受意见已由项目或产品负责人确认。
- 汇总已评审，评审意见已处理或记录，文档版本号、定稿时间和参与人完整。
这份清单同时可以作为下一轮汇总的起点：上一轮遗留项的关闭情况，就是下一轮口径说明中需要纳入跟踪的内容。
常见问题
汇总时发现工具里的执行记录和缺陷状态与实际情况不一致，应该先处理哪一边？
先处理缺陷状态，再核对执行记录。缺陷状态直接影响结论中的遗留风险判断，状态错了结论就会失真。具体做法是：把状态存疑的缺陷列出来，交给开发负责人逐条确认，已修复未验证的单独标记；执行记录中结果为空或矛盾的条目，找对应执行人确认后补录。两边都确认完再进入归并统计，避免带着错误数据往下算。
如果本次汇总只覆盖部分模块，结论里要不要提未纳入的模块？
要提，但放在范围说明里，不混进结论数字。口径说明中写明本次纳入哪些模块、哪些测试类型和环境，结论段开头重申这一范围，让读者知道结论的适用边界。未纳入的模块如果存在已知风险，可以在遗留项中单独列出并注明“本次未纳入统计”，避免读者把部分结论当成整体结论使用。
遗留缺陷的责任人和计划时间由谁填，测试负责人可以代填吗？
责任人由开发负责人确认，计划处理时间由开发负责人给出，测试负责人负责核对完整性，不代替填写。风险接受意见由项目或产品负责人给出。测试负责人代填容易出现责任落空：时间不是开发承诺的，风险不是业务方接受的。评审时逐项对照，缺责任人或缺时间的遗留项不通过。
同一版本做了多轮测试，汇总时按轮次分别出还是合并出一份？
取决于结论要回答的问题。如果目的是判断本轮测试是否达到进入下一轮的条件，按轮次单独汇总，数字只取本轮；如果目的是判断整个版本能否交付，需要合并该版本下所有轮次的数据，并在明细中注明各轮次的执行情况，便于回溯。两种口径不要混用，合并汇总时尤其要说明重复执行用例的计数规则。
汇总文档定稿后，后续缺陷状态又变了，需要重新出汇总吗？
分情况处理。如果变化影响结论判断，例如严重缺陷关闭或新增致命缺陷，应更新汇总并记录新版本号和时间，评审意见同步补充；如果只是轻微缺陷状态流转，不影响结论，可以在下一轮汇总中体现，不必单独重出。关键是文档要保留版本记录，读者能看出结论基于哪个时间点的数据。
