人工测试和自动化测试的结果常常分散在两处：手工结果记在用例表或缺陷系统里，自动化结果留在流水线日志和测试报告里，统计时靠人再对一遍。要统一汇总，先统一用例标识、执行状态和缺陷关联这三处口径，再让两类结果进入同一入口，按版本或迭代生成一张执行视图。下文给出四步流程、角色分工、迭代示例和完成检查，并说明这类汇总视图如何由测试管理工具承载，以ONES为例交代范围。
要点总览（TL;DR）
- 统一汇总的前提是先把用例标识、执行状态、缺陷关联三处口径对齐，再让两类结果进入同一入口。
- 操作上分四步：建立统一用例编号并映射脚本、定义状态字典与映射、约定自动化回传格式与人工录入入口、按版本或迭代生成汇总视图并核对差异。
- 角色按“定规则、供数据、用结果”划分：测试负责人定口径，自动化工程师维护回传，手工测试人员录入结果，测试经理评审汇总。
- 汇总视图提交评审前要过字段完整性、状态映射一致性、用例覆盖对账、缺陷关联完整性、差异核对五项检查，失败项无归属或差异无结论即阻断。
- ONES DevOps 解决方案包含测试管理模块，可用于承载用例、执行记录与缺陷关联的管理，具体回传格式与合并视图配置需结合团队环境确认。
统一汇总先解决哪三个口径问题
汇总做不下去，多数时候原因在口径，不在工具。人工与自动化结果分散在不同工具或表格中，典型表现有三种：同一用例在手工用例库叫“登录失败锁定”，在自动化脚本里叫 test_login_lock，两边按名称对不上；人工记录写“失败”，自动化报告写“FAILED”，统计时被当成两种状态；人工失败挂了缺陷单，自动化失败只留在日志里，缺陷数量与失败数量对不上。这三类问题分别对应用例标识、执行状态、缺陷关联，需要先逐项统一。
三类口径的统一原则
- 用例标识：为每条测试用例分配唯一编号，人工执行记录和自动化脚本都引用同一编号。脚本名、用例标题只作说明，不参与对账。一个自动化脚本覆盖多条用例时，按用例编号分别记录结果，避免一条脚本结果只算一次执行。
- 执行状态：定义一份状态字典，例如通过、失败、阻塞、未执行、跳过，并写明自动化框架的原始状态如何映射到字典。映射规则随流程一起维护，新增框架或状态时同步更新。
- 缺陷关联：约定失败结果与缺陷的关联规则，例如失败用例必须关联缺陷单号或标注“已知问题、暂不修复”，并说明人工失败与自动化失败采用同一套关联要求。
汇总视图的最小字段
口径统一后，汇总视图至少要能回答“哪条用例、在哪个版本、由谁执行、结果是什么、失败是否已挂缺陷”。最小字段如下表。
| 字段 | 说明 | 人工来源 | 自动化来源 |
|---|---|---|---|
| 用例编号 | 唯一标识，两类执行共用 | 用例库编号 | 脚本中引用的同一编号 |
| 用例标题 | 便于阅读，不用于对账 | 用例库 | 脚本注释或映射表 |
| 执行方式 | 人工或自动化 | 录入时选择 | 回传时标记 |
| 执行状态 | 取自统一状态字典 | 录入时选择 | 按映射规则转换 |
| 执行时间 | 用于按迭代窗口汇总 | 录入时间 | 回传时间 |
| 执行人/执行环境 | 人工填执行人，自动化填环境或任务标识 | 执行人 | 流水线任务与环境 |
| 缺陷单号 | 失败项关联的缺陷或已知问题标记 | 手工关联 | 回传字段或人工补录 |
| 版本/迭代 | 汇总维度 | 录入时选择 | 回传时携带 |
字段不必一次求全，但用例编号、执行状态、缺陷单号、版本这四项缺失时，汇总结果无法核对，应作为必填项固定下来。
统一汇总的操作步骤
四步流程按顺序推进，前一步的输出是后一步的输入。每步都给出完成标志，便于判断是否可以进入下一步。
第一步：建立统一用例编号并映射两类执行
输入：现有手工用例库、自动化脚本清单。动作：为每条用例分配唯一编号，在自动化脚本或脚本与用例的映射表中标注对应编号；一个脚本覆盖多条用例的，逐条列出。输出：用例编号清单与脚本—用例映射表。完成标志：抽查任意一条自动化结果，都能找到对应用例编号；不存在只有脚本名、没有用例编号的执行记录。
第二步：定义执行状态字典与状态映射
输入：自动化框架的原始状态列表、人工记录中使用的状态写法。动作：确定统一状态字典，逐项写明自动化原始状态到字典的映射，例如超时、断言失败统一映射为失败，环境不可用映射为阻塞；人工录入时只允许从字典中选择。输出：状态字典与映射表。完成标志：两类来源的状态都能落到字典内，没有字典外的自由文本状态。
第三步：约定自动化结果回传格式与人工结果录入入口
输入：状态字典、最小字段表。动作：约定自动化结果以结构化格式回传，字段覆盖用例编号、状态、执行时间、环境、缺陷单号等；人工结果通过同一入口录入，字段与回传格式一致。回传失败时保留原始报告，由自动化工程师补录，避免结果丢失。输出：回传格式说明与录入入口配置。完成标志：两类结果写入同一张执行记录表，字段可对齐。
第四步：按版本或迭代生成汇总视图并核对差异
输入：同一时间窗口内的执行记录。动作：按版本或迭代筛选，生成包含通过率、失败项、阻塞项、未执行项的汇总视图；对同一用例人工与自动化结果不一致的条目逐条核对，注明原因，例如环境差异、用例版本不同步、自动化脚本未更新。输出：迭代汇总视图与差异说明。完成标志：每条差异都有结论，汇总数据与执行记录可对账。
这套动作在测试管理工具中承载时，用例编号、执行记录与缺陷关联可以放在同一处管理。ONES DevOps 解决方案包含测试管理模块，并强调打通项目管理与工程实践、集中呈现交付过程；具体的结果回传格式与合并视图配置，需要结合团队实际环境确认。
角色分工与各环节交付物
汇总流程涉及四类角色，职责边界按“定规则、供数据、用结果”划分。团队规模较小时可一人兼多角，但交付物仍需明确到人。
| 角色 | 职责边界 | 交付物 | 交接时点与评审方式 |
|---|---|---|---|
| 测试负责人 | 定义用例编号规则、状态字典、缺陷关联规则与汇总字段 | 口径清单、状态字典与映射表、最小字段表 | 迭代开始前发布，变更时通知全员 |
| 自动化工程师 | 维护脚本—用例映射，按约定格式回传结果，处理回传异常 | 脚本—用例映射表、结构化结果文件、回传异常说明 | 每次自动化执行后回传，异常当日说明 |
| 手工测试人员 | 按统一入口录入执行结果，失败项关联缺陷或标注已知问题 | 人工执行记录、缺陷关联记录 | 执行完成后当日录入，不积压到迭代末 |
| 开发人员 | 处理失败项对应的缺陷，反馈修复状态 | 缺陷修复记录与状态更新 | 缺陷关闭时同步更新关联结果 |
| 测试经理 | 评审汇总视图，确认差异说明，判断是否可交付 | 迭代汇总视图、差异核对结论、评审记录 | 迭代结束前评审，阻断项当场定责与期限 |
交接的关键在两处：自动化结果回传后由自动化工程师确认字段完整，人工记录录入后由测试负责人抽查状态是否取自字典。评审以汇总视图和差异说明为材料，重点看失败项是否都有缺陷或已知问题标记，避免只报通过率、不交代失败去向。
一个迭代内的汇总示例
以下为演示情景，用于说明汇总方式，数据为示例值。某迭代共 120 条用例，其中 80 条由人工执行，40 条由自动化覆盖，两类执行都引用同一用例编号。
用例编号与状态映射
用例编号按模块加序号编排，例如 LOGIN-001、ORDER-014。自动化框架的原始状态按映射表转换：断言失败与超时映射为失败，环境不可用映射为阻塞，主动跳过映射为跳过。人工录入时只从字典中选择状态。
合并后的汇总视图
| 执行方式 | 用例数 | 通过 | 失败 | 阻塞 | 未执行 | 通过率 |
|---|---|---|---|---|---|---|
| 人工 | 80 | 68 | 7 | 3 | 2 | 85% |
| 自动化 | 40 | 33 | 5 | 1 | 1 | 82.5% |
| 合计 | 120 | 101 | 12 | 4 | 3 | 84.2% |
差异与失败项处理
核对时发现两条用例人工通过、自动化失败，例如 ORDER-014 在人工环境通过，自动化环境因测试数据未清理而失败。处理方式是标注差异原因，由自动化工程师修正数据准备逻辑后重跑，重跑结果覆盖原记录并保留说明。12 条失败项中，9 条已关联缺陷单，2 条标注为已知问题、本迭代不修复，1 条待确认归属。4 条阻塞项注明阻塞原因与解除时间，3 条未执行项说明是排期原因还是环境原因。差异逐条有结论后，汇总视图才提交评审。
汇总结果的完成检查
汇总视图提交评审前，按以下清单逐项核对。任一关键项不通过，视为阻断，需返工后重新提交。
| 检查项 | 核对内容 | 通过标准 | 不通过时的处理 |
|---|---|---|---|
| 字段完整性 | 用例编号、执行状态、执行时间、版本、缺陷单号是否齐全 | 必填字段无空缺，缺失项有说明 | 退回补录，补齐后再汇总 |
| 状态映射一致性 | 是否存在字典外状态，自动化状态是否按映射表转换 | 全部状态落在字典内 | 修正映射规则或录入数据 |
| 用例覆盖对账 | 计划执行用例数与实际执行记录数是否一致 | 差额均有未执行或阻塞说明 | 查明遗漏用例并补执行或补说明 |
| 缺陷关联完整性 | 失败项是否都关联缺陷或标注已知问题 | 失败项无“无归属”状态 | 逐条确认归属后更新 |
| 差异核对 | 同一用例两类结果不一致的条目是否逐条说明 | 每条差异有原因与结论 | 补充核对，未结论项列为阻断 |
阻断条件建议固定为三条：必填字段缺失且无说明、失败项无缺陷归属、差异条目无结论。出现任一情况，汇总视图不进入交付评审。返工由对应角色在约定时间内完成，测试经理复核后重新提交。汇总流程稳定运行后，可把检查项固化为迭代结束前的固定动作，减少每次临时对账的成本。
常见问题
自动化脚本一条覆盖多条用例时，汇总时怎么计数？
按用例编号分别记录结果，一条脚本覆盖几条用例就产生几条执行记录，每条记录引用各自的用例编号。脚本名只作说明，不参与对账。这样汇总时通过率按用例数计算，不会因为脚本数量少而低估覆盖范围。如果脚本内部某条用例被跳过，也要单独记录为跳过状态，并在差异说明中注明原因。
人工和自动化对同一用例结果不一致，以哪个为准？
不预设哪一方为准，先核对差异原因再定结论。常见原因包括执行环境不同、测试数据未清理、用例版本与脚本未同步。核对后由对应角色修正并重跑，重跑结果覆盖原记录，同时保留差异说明。若差异暂时无法解释，该条目列为阻断项，汇总视图不进入交付评审。
团队规模小、没有专职自动化工程师，流程怎么简化？
角色可以合并，但交付物不能省。测试负责人可同时承担口径定义与汇总评审，手工测试人员兼做自动化结果回传确认。关键是保留三样东西：脚本与用例的映射表、状态字典与映射规则、失败项的缺陷归属。检查项可先保留字段完整性和缺陷关联两项，流程稳定后再补齐其余检查。
自动化结果回传失败或字段缺失时怎么处理？
保留原始测试报告，由负责回传的人员在约定时间内补录，补录记录标注来源为原始报告。字段缺失的条目在汇总视图中标记为待补，不计入通过率统计，避免用不完整数据得出偏高的结论。补录完成后重新生成汇总视图，并在差异说明中记录这次异常。
汇总视图多久生成一次比较合适？
跟随团队的迭代节奏，在迭代结束前生成一次作为交付评审材料；迭代周期较长时可在中途增加一次，用于发现阻塞项和失败项归属问题。时间窗口要与执行记录的版本或迭代字段一致，避免把不同迭代的结果混在一起统计。频率确定后固定下来，减少每次临时对账的成本。
