AI测试结果汇总的关键是先定口径再动手：明确汇总哪些测试任务、哪些AI产出、按什么粒度统计，然后按采集、去重、分类、出视图、转缺陷、跟踪六步执行，最终交付一份能追溯到原始用例与日志的汇总表。本文给出可直接套用的字段清单、角色分工、填写示例和验收检查项，并说明汇总结论如何进入缺陷闭环；ONES在其中的作用是承载汇总文档、缺陷工作项与评审记录。
要点总览（TL;DR）
- 先固定汇总口径：明确汇总对象（AI生成的用例、执行结果、失败日志、缺陷建议）、汇总粒度（按轮次、模块或用例集）和必填字段，再开始采集。
- 按采集、去重合并、分类分级、生成汇总视图、转缺陷、跟踪更新六步执行，每步明确输入、动作、输出和完成标志。
- 采集、判定、汇总、复核分给不同角色，复核人与汇总责任人分开，汇总结果才具备评审基础。
- 只有判定为产品缺陷的结果才建单，AI误报和环境问题记录在汇总表中并注明处理方式，避免污染缺陷库。
- 用字段完整性、可追溯性、统计一致性、缺陷闭环、口径稳定五项检查判断汇总是否可用，全部通过再提交评审。
先定汇总口径：汇总什么、按什么粒度汇总
汇总做得好不好，很大程度上在开始采集前就决定了。同一轮测试里，AI可能生成了用例建议、执行结果、失败日志摘要和缺陷建议，这些产出的格式、可信度、归属都不同。如果不先固定范围，汇总表会出现有的模块统计了AI建议、有的没统计，上一轮按用例集统计、这一轮按模块统计的情况，结论无法横向比较。
汇总对象建议限定为四类：AI辅助生成的测试用例、测试执行结果、失败日志、AI给出的缺陷建议。范围之外的内容，例如探索性测试的手工记录，可以单独归档，不混入同一张表。汇总粒度三选一或组合使用：按测试轮次（适合版本验收）、按模块（适合定位质量问题集中区）、按用例集（适合跟踪某类功能的回归情况）。粒度一旦确定，本轮内不再变更。
必填字段直接决定汇总表能否支撑后续追溯和转缺陷，建议按下表作为表头：
| 字段 | 填写要求 | 作用 |
|---|---|---|
| 用例编号 | 与测试管理系统中的编号一致 | 追溯原始用例 |
| 执行时间 | 精确到日期，必要时到时分 | 区分轮次与重跑 |
| 环境 | 测试环境标识，如预发布、灰度 | 排除环境导致的假失败 |
| AI产出类型 | 用例建议／执行结果／日志摘要／缺陷建议 | 区分AI参与环节 |
| 结果状态 | 通过／失败／阻塞／未执行 | 统计通过率 |
| 失败原因分类 | 按预先定义的字典填写 | 失败分布分析 |
| 关联缺陷号 | 已建单的填写缺陷编号，未建单留空并注明原因 | 闭环追溯 |
口径需要有人拍板。建议由测试负责人确认字段清单、失败原因字典和严重程度标准，确认时点放在本轮测试执行开始前，确认结果记录在汇总文档的首页或版本说明中。中途新增字段要标注生效轮次，避免历史数据被追溯修改。
六步操作流程：从原始结果到汇总表
口径确定后，汇总按固定顺序推进。每一步都有明确的输入、动作、输出和完成标志，做完一步再进入下一步，可以减少返工。
第一步：采集原始结果
输入是测试执行记录和AI工具导出的结果文件。动作是把执行结果、失败日志、AI建议原文按用例编号归集，原始日志单独留存，不删改。输出是一份未加工的原始结果集。完成标志是每个执行过的用例都能找到对应记录，缺失的记录标注原因。
第二步：去重合并
同一用例多次执行会产生多条记录，重复的AI建议也会出现。合并规则提前定好：同一用例多次执行，取最新一次结果；若最新为通过而此前失败，保留失败记录并在备注中说明修复情况；同一问题的多条AI建议按描述相似度合并为一条，保留最早出处和全部关联用例。输出是去重后的结果清单，完成标志是清单中不存在同一用例同一环境的重复行。
第三步：分类分级
按失败原因字典归类，常见分类包括环境问题、测试数据问题、用例本身缺陷、产品缺陷、AI误报。再按影响范围定严重程度，例如阻塞主流程、影响部分功能、提示性问题。分类由测试执行人初判，测试负责人确认。输出是带分类和级别的结果清单，完成标志是每条失败记录都有分类，无“待定”项遗留。
第四步：生成汇总视图
在分类结果基础上统计：总体通过率、按模块的失败分布、按失败类型的占比、AI建议的采纳数量与采纳率。输出是汇总统计区和明细表，完成标志是统计数字能由明细行加总得出，抽查任意一个统计值都能对上明细。
第五步：转缺陷
并非所有失败都进入缺陷库。判定为产品缺陷的记录，由测试负责人确认后建单，填写复现步骤、关联用例编号和日志位置；AI误报和环境问题记录在汇总表中并注明处理方式，不建单。输出是缺陷清单和汇总表中的关联缺陷号，完成标志是每条应转缺陷的记录都有对应缺陷编号和负责人。
第六步：跟踪与更新
缺陷状态变化后，按固定节奏刷新汇总表，例如每日站会前或每轮测试结束时。更新内容包括缺陷状态、修复验证结果和新增失败。输出是最新的汇总表版本，完成标志是汇总表中的缺陷状态与缺陷库一致，且表头标注了最后更新时间。
角色分工与各环节交付物
汇总变成单人拼表，通常是因为职责没有分开。把采集、判定、汇总、复核分给不同角色，既能提高准确性，也让汇总结果具备评审基础。
| 角色 | 主要动作 | 交付物 |
|---|---|---|
| 测试执行人 | 执行用例，记录结果，保存失败日志，初判失败类型 | 原始执行记录与日志 |
| 测试负责人 | 确认失败分类与严重程度，判定哪些结果转缺陷 | 确认后的分类结果与转缺陷决定 |
| 开发负责人 | 确认缺陷归属模块与修复责任人，更新修复状态 | 缺陷归属与状态更新 |
| 汇总责任人 | 维护汇总表结构，执行去重合并与统计，按节奏刷新 | 汇总表及统计视图 |
| 复核人 | 按比例抽查汇总行与原始记录的一致性 | 抽查记录与复核结论 |
小团队里角色可以兼任，但复核人与汇总责任人建议分开，否则一致性检查容易流于形式。复核比例可按轮次风险设定，例如高风险模块全查、一般模块抽查两成。
示例：一轮AI辅助测试的汇总表与缺陷清单
以下为演示情景，用于说明填写方式，数据为虚构。背景：某模块进行一轮回归测试，共执行20条用例，其中8条由AI辅助生成，AI另给出5条缺陷建议。
汇总表节选：
| 用例编号 | 执行时间 | 环境 | AI产出类型 | 结果状态 | 失败原因分类 | 关联缺陷号 |
|---|---|---|---|---|---|---|
| TC-101 | 3月10日 | 预发布 | 用例建议 | 通过 | — | — |
| TC-104 | 3月10日 | 预发布 | 执行结果 | 失败 | 产品缺陷 | BUG-231 |
| TC-107 | 3月10日 | 预发布 | 执行结果 | 失败 | 测试数据问题 | — |
| TC-112 | 3月10日 | 预发布 | 缺陷建议 | 失败 | 产品缺陷 | BUG-232 |
| TC-115 | 3月10日 | 预发布 | 缺陷建议 | 通过 | AI误报 | — |
统计结果：执行20条，通过14条，失败5条，阻塞1条，通过率70%；失败中产品缺陷2条、测试数据问题1条、环境问题1条、AI误报1条；AI建议5条中采纳2条，采纳率40%。
由汇总结果转出的缺陷条目示例：BUG-231，标题为“订单提交后状态未刷新”，关联用例TC-104，复现步骤引用执行日志第12行，严重程度为影响部分功能，负责人为开发A。BUG-232来自AI缺陷建议，经测试负责人确认后建单，备注中保留AI建议原文链接。
追溯关系在表中体现为一条链：汇总行TC-104指向原始用例与执行日志，日志对应缺陷BUG-231，缺陷状态回写到汇总表。复核时从任意一行出发，都能走完这条链。
汇总结果如何进入缺陷管理与协作流程
汇总表本身只是中间产物，价值在于把结论交给缺陷跟踪和评审。交接对象包括开发负责人（缺陷归属与修复）、测试负责人（验证结论）和项目管理者（质量趋势判断）。评审时点建议放在每轮测试结束、汇总表刷新完成后，评审内容是失败分布、缺陷清单和AI建议采纳情况。
缺陷状态与汇总表的同步靠固定节奏维持：缺陷从待处理变为已修复、已验证，汇总表对应行的关联缺陷号和状态列随之更新，避免出现汇总表显示失败、缺陷库已关闭的脱节情况。AI建议采纳情况单独记录，包括建议总数、采纳数、误报数和不采纳原因，用于下一轮调整AI辅助的使用方式。
这套流程需要文档与工作项共同承载。汇总表、口径说明和评审记录适合放在文档中，缺陷和修复任务适合作为工作项跟踪。ONES Assistant可连接ONES Project、ONES Wiki与ONES TestCase，理解项目、工作项和Wiki页面的上下文，把自然语言指令转化为可追踪的工作，并将结果保存为工作项或Wiki页面，减少汇总表与缺陷库之间的重复录入。围绕缺陷分布，它可生成进展分析和根因判断，帮助评审时快速定位问题集中区域；相关操作基于ONES权限体系执行，输出过程可追踪、结果可审计。具体配置方式以团队实际环境为准。
完成检查：汇总是否可用的验收项
汇总做完不等于做得对。以下清单可逐项核对，全部通过再提交评审。
| 检查项 | 通过标准 |
|---|---|
| 字段完整性 | 必填字段无空缺；留空项均注明原因 |
| 可追溯性 | 随机抽取汇总行，能回到原始用例、执行日志和缺陷号 |
| 统计一致性 | 通过率、失败分布等统计值与明细行加总一致，抽查无偏差 |
| 缺陷闭环 | 应转缺陷的结果均已建单，每条缺陷有负责人和当前状态 |
| 口径稳定 | 字段、分类字典与上一轮一致；有变更的标注生效轮次 |
| AI建议记录 | 建议总数、采纳数、误报数齐全，误报有简要原因 |
检查中发现不一致，先修正再提交，不带着已知偏差进入评审。连续几轮保持口径稳定后，汇总数据才能用于跨轮次的质量趋势比较。
常见问题
AI给出的缺陷建议可以直接建成缺陷单吗？
不建议直接建单。AI缺陷建议需要经过测试负责人确认，判定为产品缺陷后再建单，并在缺陷备注中保留AI建议原文和关联用例编号。判定为误报或环境问题的建议，记录在汇总表中并注明处理方式，不进入缺陷库。这样既保留了AI建议的线索，也避免误报拉低缺陷库的可用性。
同一用例多次执行、结果不一致时，汇总表里保留哪一条？
合并规则要在采集前定好。常见做法是取最新一次执行结果；如果最新为通过而此前失败，保留失败记录并在备注中说明修复情况，便于回溯问题是否真正解决。同一用例同一环境在汇总表中只保留一行，历史执行记录留在原始日志中备查。规则一旦确定，本轮内所有模块按同一标准执行。
汇总表多久刷新一次比较合适？
刷新节奏与缺陷状态变化挂钩，常见选择是每日站会前刷新一次，或在每轮测试结束时统一刷新。刷新内容包括缺陷状态、修复验证结果和新增失败记录。关键是保持固定节奏，并在表头标注最后更新时间，避免出现汇总表显示失败、缺陷库已关闭的脱节情况。
小团队人手有限，角色可以合并吗？
可以兼任，但复核人与汇总责任人建议分开。汇总责任人负责维护表结构和统计，复核人按比例抽查汇总行与原始记录的一致性；同一人兼任时，一致性检查容易流于形式。复核比例可按风险设定，高风险模块全查，一般模块抽查两成左右。
上一轮的汇总口径和这一轮不一致，还能比较吗？
口径变更后，跨轮次数据不能直接比较。新增字段或调整分类字典时，在汇总文档中标注生效轮次，历史数据保持原样，不做追溯修改。需要对比趋势时，只比较口径一致的轮次，或在评审中说明差异来源。连续几轮保持口径稳定后，汇总数据才适合用于质量趋势判断。
