自动化测试结果汇总要解决的问题，是把分散在各流水线、各测试框架里的执行结果，收敛成一份口径统一、可追溯的记录。落地时先确定汇总对象与字段，再固定采集与归并动作，随后按角色完成核对、分发与复盘。本文按这四步展开，并给出一份演示批次的汇总示例和完成检查清单，供团队按自身工具链调整后使用。
要点总览（TL;DR）
- 汇总以“执行批次”为主对象，批次下挂用例级结果，必填字段缺失的批次不能作为发布判断依据。
- 采集靠流水线在测试阶段后自动产出统一格式结果并上报，按批次ID加用例标识归并去重，缺失与解析失败项进入待补录清单。
- 测试执行人、测试负责人、开发责任人、发布把关人各有明确输入与交付物，失败项闭环的标志是每个失败项都有责任人和处理状态。
- 发布结论只引用已归类的失败项，环境异常与脚本问题修复后重跑，真实缺陷与阻塞项未闭环时阻断发布。
- 检查通过后按批次归档，重跑使用新批次ID并保留原批次记录，保证结论可回溯到原始执行记录。
汇总什么：先定对象、字段与口径
汇总前先确定记录对象和字段，后续采集、归并、检查才有统一标准。建议以“一次执行批次”为汇总主对象：一个批次对应一次构建版本在特定环境下的完整测试执行，批次下挂用例级结果。这样既能看整体通过情况，也能下钻到单条失败用例。
字段分必填与选填两类。必填字段缺失时该批次不能作为发布判断依据；选填字段用于分析和复盘，缺失不影响汇总成立。状态口径要在团队内统一，避免同一结果在不同框架里被记成不同含义。
| 字段名 | 含义 | 必填 | 取值来源 |
|---|---|---|---|
| 批次ID | 一次执行的唯一标识，通常由流水线运行号生成 | 必填 | 流水线运行记录 |
| 构建版本 | 被测代码的提交号或构建号 | 必填 | 代码仓库/构建系统 |
| 执行环境 | 测试运行的环境，如测试环境、预发环境 | 必填 | 流水线配置 |
| 用例标识 | 用例的唯一编号，跨批次保持稳定 | 必填 | 测试框架用例定义 |
| 结果状态 | 通过、失败、跳过、阻塞之一 | 必填 | 测试框架结果文件 |
| 失败原因 | 断言失败、环境异常、超时等归类 | 失败时必填 | 日志与执行人判定 |
| 关联需求 | 用例覆盖的需求编号 | 必填 | 用例与需求的关联关系 |
| 关联缺陷 | 失败项对应的缺陷单号 | 失败时必填 | 缺陷跟踪系统 |
| 执行时间 | 用例开始与结束时间 | 选填 | 测试框架结果文件 |
| 耗时 | 单条用例执行时长 | 选填 | 测试框架结果文件 |
状态口径需要提前约定：通过指断言全部成立；失败指断言不成立或执行异常；跳过指按条件主动不执行，需注明跳过原因；阻塞指因环境、依赖或前置用例失败而无法执行。跳过和阻塞都不计入通过率分子，但要在汇总中单独列出数量，避免被误读为通过。
用例标识与需求、缺陷的关联键是追溯的基础。用例标识应稳定不变，需求编号和缺陷单号使用团队现有系统的编号规则，汇总记录中保存编号而非标题，防止标题修改后关联断裂。
结果怎么进来：采集、归并与去重步骤
采集的目标是让每次流水线执行后自动产出结构化结果并上报，减少人工整理。各测试框架的输出格式不同，先约定一种统一中间格式，再由上报环节转换，汇总侧只处理这一种格式。
统一格式至少包含批次ID、构建版本、环境、用例标识、状态、失败原因、开始结束时间和关联需求。转换脚本放在流水线中执行，测试框架升级时只调整转换逻辑，汇总侧不受影响。
| 步骤 | 输入 | 动作 | 输出 | 完成标志 |
|---|---|---|---|---|
| 1. 生成结果文件 | 测试框架执行输出 | 流水线在测试阶段结束后调用转换脚本 | 统一格式的结果文件 | 文件生成且字段齐全 |
| 2. 自动上报 | 结果文件 | 流水线在测试阶段成功后触发上报任务 | 汇总系统中的批次记录 | 上报任务返回成功 |
| 3. 归并去重 | 同一批次的多份上报 | 按批次ID加用例标识判重，保留最新一次结果 | 批次内唯一的用例结果集 | 用例数等于计划执行数 |
| 4. 异常标记 | 缺失或解析失败的结果 | 标记为待补录并通知执行人 | 待补录清单 | 清单清零或注明原因 |
重复上报常见于流水线重试或分片执行。归并规则建议以批次ID加用例标识为唯一键，同一键多次出现时保留最后一次执行结果，并在记录中保留上报次数，便于发现异常重试。分片执行时各分片使用同一批次ID，归并后合并为完整用例集。
解析失败或结果缺失时，不要直接丢弃。将这类记录标记为待补录，附上原始日志位置，由执行人确认是环境问题还是脚本问题，补录后重新归并。待补录清单是汇总完成检查的输入之一。
谁来汇总：角色分工与交付物
汇总容易变成测试负责人的单人兜底，原因是各角色的输入和输出没有约定。把职责按“谁产生数据、谁判定原因、谁做发布判断”拆开，汇总就变成一条有交接点的流程。
| 角色 | 在汇总中的动作 | 输入 | 交付物 |
|---|---|---|---|
| 测试执行人 | 维护用例标识与需求关联，处理待补录项 | 测试框架结果、执行日志 | 完整的结果文件与补录说明 |
| 测试负责人 | 核对批次覆盖与字段完整性，归并失败原因 | 批次记录、待补录清单 | 汇总记录与失败项清单 |
| 开发责任人 | 确认失败原因归属，提交修复或标注非缺陷 | 失败项清单与日志 | 缺陷单或原因说明 |
| 发布/质量把关人 | 依据汇总结论做发布判断 | 汇总记录与失败项处理状态 | 发布结论与遗留风险说明 |
失败项分派的责任归属要明确到人：测试负责人完成原因初判后，将失败项分派给对应开发责任人；开发责任人确认后关联缺陷单或标注为环境、用例问题；测试负责人在下一批次验证修复结果并更新状态。闭环的标志是每个失败项都有责任人和处理状态，而不是只有一条备注。
汇总记录的归档与查阅由测试负责人负责，按批次保存，保留原始结果文件的位置索引。发布把关人和后续复盘人员按批次查阅，避免用最新批次覆盖历史记录。
当团队使用 ONES 承载研发过程时，可以把失败项作为工作项关联到需求与缺陷，测试记录与流水线结果在项目内集中查看。ONES DevOps 解决方案提供项目管理、测试管理、效能管理、流水线集成等模块组合，并支持集中可视化展现 CI/CD 全过程，适合把汇总后的失败项跟踪与发布判断放在同一处管理。具体的结果导入格式与字段映射，需要按团队实际使用的模块配置确认。
一份可用的汇总示例
以下为演示情景，用于说明汇总记录的填写方式，数据不代表任何真实项目。
批次 B-20240612-03，构建版本 commit a1b2c3，执行环境为预发环境，计划执行用例 120 条。汇总结果：通过 108 条，失败 8 条，跳过 3 条，阻塞 1 条。跳过项注明为“依赖服务未就绪，按条件跳过”，阻塞项注明为“前置用例 TC-045 失败导致无法执行”。
| 用例标识 | 状态 | 失败原因归类 | 关联需求 | 责任人 | 处理状态 |
|---|---|---|---|---|---|
| TC-045 | 失败 | 断言失败，接口返回字段缺失 | REQ-210 | 开发A | 已提缺陷 BUG-88，修复中 |
| TC-052 | 失败 | 环境异常，数据库连接超时 | REQ-215 | 测试B | 环境已恢复，待重跑 |
| TC-067 | 失败 | 用例脚本问题，选择器失效 | REQ-210 | 测试B | 脚本已修正，下批次验证 |
| TC-071 | 阻塞 | 前置用例 TC-045 失败 | REQ-210 | 开发A | 随 BUG-88 修复后重跑 |
该批次的发布判断为“暂不发布”：失败项中有 1 条为真实缺陷且影响核心需求 REQ-210，另有 1 条阻塞项依赖同一缺陷。环境异常和脚本问题两类失败在修复后重跑，不构成发布阻断。汇总结论中写明阻断原因和待验证项，发布把关人据此决定是否等待下一批次。
这个示例体现的规律可以迁移：失败原因先归类再分派，环境与脚本问题由测试侧处理，真实缺陷由开发侧处理；阻塞项跟随其前置失败项一起闭环；发布结论只引用已归类的失败项，不笼统写“存在失败”。
汇总完成后怎么检查
汇总记录是否可用，用一组可逐项核对的检查项判断。检查不通过时，汇总不能作为发布依据。
| 检查项 | 通过标准 | 阻断条件 |
|---|---|---|
| 批次覆盖 | 计划执行的用例均有结果记录，待补录清单清零或已注明原因 | 存在未说明的缺失用例 |
| 字段完整性 | 必填字段缺失率为零，失败项均有失败原因 | 必填字段缺失且影响判断 |
| 失败项闭环 | 每个失败项有责任人和处理状态 | 存在无责任人的失败项 |
| 可回溯性 | 汇总结论能定位到批次与原始结果文件 | 结论无法对应到具体执行记录 |
| 状态口径 | 跳过与阻塞项单独列示并注明原因 | 跳过或阻塞被计入通过 |
应阻断发布的情况包括：核心需求关联用例失败且未修复；存在阻塞项且前置失败未闭环；必填字段大面积缺失导致通过率不可信。要求重跑的情况包括：环境异常导致的失败在环境恢复后未验证；脚本问题修正后未在新批次确认。重跑使用新批次ID，保留原批次记录，便于对比。
检查通过后，汇总记录按批次归档，失败项处理状态在后续批次中持续更新，直到全部闭环。这样每一份汇总结论都能回溯到原始执行记录，发布判断也有据可查。
常见问题
流水线重试或分片执行导致同一批次结果重复上报，应该怎么处理？
以批次ID加用例标识作为唯一键判重，同一键多次出现时保留最后一次执行结果，同时在记录中保留上报次数，便于识别异常重试。分片执行时各分片共用同一批次ID，归并后合并为完整用例集，再用“用例数等于计划执行数”作为归并完成的标志。
失败用例的原因一时判断不了，汇总还能继续往下走吗？
可以继续，但要把这类失败项单独标记为“原因待定”，并指定初判责任人。测试负责人先按日志做初步归类，分派给对应开发责任人确认；确认前该失败项不计入已闭环，发布判断时按未闭环处理。原因待定项积压过多，说明日志留存或分派规则需要调整。
跳过和阻塞的用例要不要计入通过率？
不计入通过率分子，但要在汇总中单独列出数量并注明原因。跳过需写明按什么条件主动不执行，阻塞需写明前置失败项或环境依赖。把跳过和阻塞混入通过统计，会让通过率虚高，发布把关人也就失去了判断依据。
环境异常导致的失败，修复环境后应该重跑还是直接沿用原结果？
应重跑。环境恢复后用新批次ID重新执行，保留原批次记录用于对比，确认原失败项在新批次中转为通过。直接沿用原结果或手工改状态，会让汇总记录与原始执行记录脱节，后续复盘时无法还原当时情况。
团队已经在用 ONES 管理研发过程，汇总后的失败项怎么衔接跟踪？
可以把失败项作为工作项关联到对应需求与缺陷，测试记录与流水线结果在项目内集中查看。ONES DevOps 解决方案提供项目管理、测试管理、效能管理、流水线集成等模块组合，并支持集中可视化展现 CI/CD 全过程，适合把失败项跟踪与发布判断放在同一处管理。具体的结果导入格式与字段映射，需按团队实际启用的模块配置确认。
