AI测试结果汇总要解决的问题，是把模型生成的判断、用例执行记录和人工复核意见收敛成一份可评审、可追溯的测试结论，并让其中确认的缺陷进入统一管理流程。本文按“定口径—走流程—分角色—看示例—做检查—接工具”的顺序，给出一套可直接落地的做法，适用于版本测试结束后集中汇总的场景。ONES可作为汇总结论与缺陷工作项的承载工具，具体配置以实际环境为准。
要点总览（TL;DR）
- 汇总前先定口径：纳入AI测试结论、用例执行记录和人工复核意见三类内容，按用例为主表、模块为汇总层、缺陷单号作关联字段，避免重复计数。
- 执行按采集、清洗归并、填表、自检、提交评审五步推进，每步明确输入、输出和完成标志，证据链接必须指向可打开的原始记录。
- 角色分工写进流程说明：测试执行人提供原始结果与证据，测试负责人裁定结论分歧，缺陷管理人登记分流，研发负责人确认优先级与修复计划。
- 交付前从完整性、可追溯、一致性、闭环四个维度逐项检查，未通过时回到对应环节返工，不在汇总表上直接改结论。
- 工具承载上文档存结论、工作项管处理，两者通过用例编号或缺陷单号关联，结论变更保留版本记录并通知相关角色。
汇总口径先定：哪些结果进表、按什么粒度归并
汇总表的价值取决于口径是否统一。口径不确定，不同批次的结果无法横向比较，评审时也容易在“这条算不算问题”上反复争论。汇总开始前，测试负责人应先书面确定三件事：纳入范围、归并粒度、字段清单。
纳入范围
建议纳入三类内容：AI生成的测试结论（如风险判断、异常识别、用例通过与否的建议）、用例执行的实际记录（执行人、执行时间、实际结果）、人工复核意见（对AI结论的确认、修正或否决）。范围之外的内容，例如探索性测试中的口头反馈，若需要进入结论，应先补成正式记录再纳入，避免汇总表里出现无证据支撑的条目。
归并粒度
三种粒度各有适用条件：按用例归并适合结果条目多、需要逐条核对执行情况的场景；按模块归并适合向管理层汇报整体质量状况；按缺陷单聚合适合已进入缺陷流程、需要跟踪处理进展的阶段。一个版本测试通常以“按用例”为主表，再向上汇总到模块，缺陷单号作为关联字段挂接，避免同一问题在多个粒度上重复计数。
核心字段清单
| 字段 | 填写要求 |
|---|---|
| 用例编号 | 与用例库一致，作为归并和关联的主键 |
| 所属模块 | 按版本范围划分，便于模块级汇总 |
| AI结论 | 原样记录模型输出，不改写措辞 |
| 置信度/待复核标记 | 模型给出置信度则记录；未给出则标记“待复核” |
| 人工复核意见 | 确认、修正或否决，并写明理由 |
| 最终结论 | 通过/不通过/阻塞，由测试负责人裁定 |
| 证据链接 | 指向原始输出、日志或截图的位置 |
| 关联缺陷单号 | 已分流的填写单号，未分流的留空并说明原因 |
| 来源与时间 | 记录采集来源和采集时间，便于回溯 |
口径变更的记录方式
测试中途调整纳入范围或字段含义时，应在汇总文档中保留变更记录：变更日期、变更内容、影响到的条目范围、批准人。已经填写的条目按新口径补充或标注，不直接覆盖旧值，保证前后批次可比、争议可查。
操作步骤：从原始输出到一份可评审的汇总
口径确定后，汇总按五步执行。每一步都应有明确的输入、动作、输出和完成标志，避免流程停在“收集了一堆材料”的状态。
第一步：采集
输入是各来源的AI测试输出与执行记录。动作是按来源分类收集，为每条记录标注来源系统、采集人和采集时间。输出是一份带来源标签的原始材料清单。完成标志是纳入范围内的来源均已采集，且没有仅凭记忆补录的条目。
第二步：清洗与归并
输入是原始材料清单。动作包括：去除重复条目，对齐用例编号（编号不一致的先修正再归并），对置信度低、AI结论与执行记录矛盾、或缺少证据的条目单独标记为待复核。输出是去重对齐后的结果集和一份待复核清单。完成标志是每条结果都能对应到唯一用例编号，待复核项已单独列出。
第三步：填表
输入是清洗后的结果集。动作是按字段清单逐项写入汇总表，证据链接必须指向可打开的原始记录，不能只写“见群聊”或“见邮件”。输出是填写完成的汇总表初稿。完成标志是所有必填字段无空缺，空缺项均有说明。
第四步：自检
输入是汇总表初稿。动作是核对条数（采集条数、归并后条数、进表条数是否对得上）、核对结论与证据是否一一对应、核对待复核项是否都有处理意见。输出是自检记录。完成标志是差异项已解释或修正，自检人签字确认。
第五步：提交评审
输入是自检通过的汇总表。动作是明确提交对象（测试负责人、研发负责人、缺陷管理人）和截止时点，附上待复核清单和分歧点说明。输出是评审通知与汇总表版本。完成标志是评审人已接收并在约定时点前给出意见。
角色分工与交付物：谁采集、谁复核、谁定结论
汇总过程中的争议，多数来自职责边界不清。把每个角色的动作和交付物写进流程说明，评审时按角色找责任人，比在会上临时指派更有效。
| 角色 | 主要职责 | 交付物 | 交接时点 |
|---|---|---|---|
| 测试执行人 | 提供原始执行结果与证据，标注来源和时间 | 原始记录清单、证据链接 | 采集阶段结束前 |
| 测试负责人 | 组织复核，裁定AI结论与人工意见的分歧，确认最终结论 | 评审意见、最终结论、待复核项处理结果 | 评审会上或截止时点前 |
| 缺陷管理人 | 接收分流后的缺陷，登记缺陷单并维护状态 | 缺陷单、分流登记记录 | 评审结论确认后一个工作日内 |
| 研发负责人 | 确认缺陷优先级与修复计划，反馈修复状态 | 优先级结论、修复计划、状态更新 | 缺陷登记后约定时点 |
需要说明的是，小团队中测试负责人与缺陷管理人可能由同一人兼任，此时仍建议在流程说明中保留两个职责名称，避免“自己复核自己分流”导致缺陷遗漏无人发现。角色可以合并，职责记录不宜省略。
示例：一次版本测试的汇总表与缺陷分流
以下为演示情景，用于说明填写方式，数据为虚构。某版本迭代包含登录、订单、报表三个模块，共执行80条用例，AI对其中30条给出风险提示，人工复核后确认12条为真实问题。
汇总表填写样例
| 用例编号 | 模块 | AI结论 | 待复核标记 | 人工复核意见 | 最终结论 | 关联缺陷单号 |
|---|---|---|---|---|---|---|
| LOGIN-012 | 登录 | 疑似超时异常 | 置信度低 | 复现两次均超时，确认问题 | 不通过 | BUG-301 |
| ORDER-045 | 订单 | 金额计算异常 | — | 为测试数据构造错误，非产品缺陷 | 通过 | — |
| RPT-008 | 报表 | 导出格式不符 | 待复核 | 与需求文档比对，格式符合约定 | 通过 | — |
AI结论与人工复核不一致时的处理
以ORDER-045为例，AI判定金额计算异常，人工复核发现是测试数据构造错误。处理方式是：保留AI原始结论不改写，在复核意见中写明否决理由，最终结论记为通过，并在自检记录中登记该分歧。若复核人无法当场判定，则标记为待复核，提交测试负责人裁定，不在汇总表上直接改成“通过”了事。
缺陷分流字段对应关系
| 汇总表字段 | 缺陷单字段 | 说明 |
|---|---|---|
| 用例编号 | 关联用例 | 保持可回溯 |
| 最终结论 | 缺陷描述摘要 | 摘要需包含现象与预期 |
| 证据链接 | 附件/复现步骤 | 原始记录随缺陷单一并提交 |
| 所属模块 | 所属模块/组件 | 用于统计缺陷分布 |
| 人工复核意见 | 备注 | 保留判定依据 |
完成检查：汇总可以交付的判定条件
汇总是否完成，不取决于表格是否填满，而取决于四个维度能否逐项核对通过。建议把以下清单作为交付前的固定检查项。
- 完整性：纳入范围内的AI结论、执行记录、复核意见是否全部覆盖；采集条数与进表条数的差异是否已解释。
- 可追溯：每条最终结论能否通过证据链接回到原始记录；链接是否可打开、内容是否对应当前条目。
- 一致性：汇总表中的“不通过”条目是否都有对应缺陷单；缺陷单状态与汇总表结论是否对齐，已关闭的缺陷是否在汇总中同步更新。
- 闭环：每个缺陷是否都有负责人和处理状态；待复核项是否都有处理意见，没有悬空条目。
任一维度未通过时，返工动作是回到对应环节：完整性问题回到采集补录，可追溯问题回到填表补链接，一致性问题核对缺陷单状态，闭环问题联系责任人补齐归属。返工后重新执行自检，不在汇总表上直接修改结论掩盖问题。
把汇总接入协作工具：状态与交接的承载方式
汇总表和缺陷单分散在不同文件里，状态更新靠人工同步，是汇总流于形式的常见原因。把两者接入协作工具，关键是分清承载分工：文档存结论，工作项管处理。
文档与工作项的分工
汇总表、评审意见、口径说明和变更记录沉淀为文档，作为结论的权威版本；每条确认的缺陷创建为可跟踪的工作项，承载负责人、优先级、状态和修复进展。两者通过用例编号或缺陷单号关联，从文档能跳到工作项，从工作项能回到结论依据。
字段映射与状态流转
按上一节的对应关系，把汇总表中的用例编号、模块、结论摘要、证据链接写入缺陷工作项；工作项状态从“待确认”流转到“处理中”“待验证”“已关闭”，每次流转同步更新汇总表中的关联状态。ONES Assistant可连接ONES Project、ONES Wiki与ONES TestCase，理解项目、工作项和Wiki页面等工作上下文，并可将结果保存为工作项或Wiki页面，减少页面切换和重复录入；围绕缺陷分布等数据，还可生成进展分析与根因判断，供管理者在风险扩大前干预。具体可用范围和配置方式以实际环境为准。
复核意见与评审记录的留存
复核意见写在汇总文档对应条目旁，评审会结论单独记录为评审纪要，注明参与人、分歧点和裁定结果。这样后续追溯“为什么这条判为通过”时，能同时看到AI原始输出、复核理由和裁定人。
结论变更时的版本与通知
汇总结论发生变更时，保留文档版本记录，写明变更条目、原因和批准人，并通过工作项评论或通知告知缺陷管理人、研发负责人等相关角色。ONES基于自身权限体系进行知识问答和任务执行，输出过程可追踪、结果可审计，适合承载这类需要留痕的交接。版本记录与通知动作配套执行，避免有人按旧结论继续处理。
常见问题
AI给出的测试结论置信度低，汇总时应该直接剔除还是保留？
建议保留并单独标记，而不是直接剔除。剔除会让汇总表看起来干净，但丢失了模型曾提示过的风险线索，后续复盘时无法判断是模型误报还是漏报。
具体做法是：在汇总表中原样记录AI结论，在置信度或待复核标记字段注明“置信度低”，然后由复核人给出确认、修正或否决的意见及理由。若复核人当场无法判定，标记为待复核，提交测试负责人裁定。这样每条低置信度结论都有处理痕迹，汇总表的最终结论才有依据。
测试中途发现汇总口径需要调整，已经填好的条目怎么处理？
在汇总文档中保留变更记录，写明变更日期、变更内容、影响的条目范围和批准人，已经填写的条目按新口径补充或标注，不直接覆盖旧值。
如果变更涉及纳入范围扩大，需要回到采集环节补录遗漏的来源，并重新执行自检核对条数；如果只是字段含义调整，则逐条核对受影响条目并补充说明。保留旧值是为了让前后批次可比，也便于评审时解释差异来源。
小团队里测试负责人和缺陷管理人是同一人，流程还需要分开写吗？
角色可以合并，职责记录建议保留。流程说明中仍分别列出“组织复核并裁定结论”和“登记缺陷单并维护状态”两项职责，由同一人承担时在角色表中注明兼任。
这样做的实际作用是留出检查点：复核完成后，再按缺陷管理职责核对每条“不通过”结论是否都已登记缺陷单、是否都有负责人。两项职责写在一起时，容易在复核结束时就认为工作完成，遗漏分流登记这一步。
汇总表里的缺陷单状态和缺陷工作项状态不一致时，以哪个为准？
以缺陷工作项的状态为准，汇总表作为结论文档同步更新。工作项承载负责人、优先级和处理进展，是处理过程的实时记录；汇总表反映的是某一时点的测试结论。
一致性检查时，逐条核对汇总表中标记“不通过”的条目是否都有对应工作项，工作项状态是否已回写到汇总表。发现不一致时，先确认工作项状态是否准确，再更新汇总表，并在变更记录中注明同步时间，避免有人按旧结论继续处理。
用协作工具承载汇总结果时，哪些内容适合放文档、哪些适合建工作项？
判断标准是内容是否需要跟踪处理状态。汇总结论、口径说明、评审纪要和变更记录适合沉淀为文档，作为结论的权威版本；每条确认的缺陷适合创建为工作项，承载负责人、优先级、状态和修复进展。
两者通过用例编号或缺陷单号关联，从文档能跳到工作项，从工作项能回到结论依据。ONES Assistant可连接ONES Project、ONES Wiki与ONES TestCase，理解项目、工作项和Wiki页面等工作上下文，并可将结果保存为工作项或Wiki页面，减少页面切换和重复录入；具体可用范围和配置方式以实际环境为准。
