AI测试管理的落地重点，是把AI用在用例草拟、用例评审、测试结果汇总、缺陷分类与摘要这些可以复核的环节，并为每个环节设定输入、人工复核动作和通过标准。本文按“划定边界—分步流程—角色分工—迭代示例—完成检查”展开，说明测试负责人、用例评审人和缺陷处理人如何协作，也说明ONES在其中的承载方式。
要点总览（TL;DR）
- AI测试管理适合放在用例草拟、用例评审、测试结果汇总、缺陷分类与摘要这些可逐条检查的环节，测试执行脚本、模型训练和常规自动化测试协同不纳入本篇。
- 落地流程分五步：用例草拟、用例评审、测试结果汇总、缺陷分类与摘要、人工复核，每步都要写清输入、动作、输出和完成标志。
- 测试负责人定边界与复核规则，用例评审人确认或退回候选用例，缺陷处理人确认分类与摘要后流转，复核记录要留痕。
- 机制是否可用，看复核规则是否覆盖全部AI输出、抽样复核问题比例、用例退回率和缺陷分类人工修正比例，未通过时按问题类型调整规则再验证。
- ONES Assistant 可把自然语言指令转化为创建缺陷、更新状态并通知负责人等可追踪操作，结果保存为工作项或 Wiki 页面，便于复核和追溯。
AI测试管理先划清哪些环节交给AI
引入AI辅助测试管理，第一步是确定哪些动作由AI生成候选结果、哪些动作必须由人确认。判断标准可以归纳为两条：该动作的产出是否便于人工逐条检查；该动作出错时是否能在流转前被拦截。满足这两条的环节适合引入AI，反之应留在人工流程中。
适合纳入AI辅助的环节包括：根据需求描述或验收条件草拟候选用例；在评审前对用例做完整性、重复性方面的初步检查；把执行记录整理成测试结果摘要；根据缺陷描述给出分类建议和摘要。这些环节的共同点是产出为文本或结构化建议，评审人可以逐条确认、退回或修改。
不纳入本篇范围的环节包括测试执行脚本的编写、模型训练与调优、常规自动化测试的协同管理。这些工作涉及代码资产、算法配置或持续集成链路，管理方式与本文讨论的“AI输出加人工复核”流程不同，应另行设计。
无论哪个环节，人工复核都是必要动作。AI输出在流程中一律视为候选结果，只有经过指定角色确认后，才能进入用例库、测试报告或缺陷流转。这条规则需要在流程设计时就写清楚，而不是等到出现问题再补。
| 环节 | 是否纳入AI辅助 | 人工复核动作 |
|---|---|---|
| 用例草拟 | 纳入 | 评审人逐条确认、修改或退回 |
| 用例评审 | 纳入（AI做初步检查，人做结论） | 评审人给出通过或退回结论 |
| 测试结果汇总 | 纳入 | 测试负责人核对摘要与执行记录是否一致 |
| 缺陷分类与摘要 | 纳入 | 缺陷处理人确认分类、修正摘要后流转 |
| 测试执行脚本编写 | 不纳入 | — |
| 模型训练与调优 | 不纳入 | — |
| 常规自动化测试协同 | 不纳入 | — |
从用例草拟到缺陷复核的操作步骤
边界确定后，可以把流程拆成五个步骤。每一步都需要明确输入、动作、输出和完成标志，这样执行人才知道什么时候算做完，复核人也有据可依。
第一步：用例草拟
输入是需求描述、验收条件或用户故事。动作是把这些材料交给AI生成候选用例，要求覆盖正常流程、边界条件和异常场景。输出是一组候选用例，标注来源需求。完成标志是候选用例覆盖了该需求的主要场景，且每条用例都能追溯到具体验收条件。草拟阶段不追求用例数量，重点是场景覆盖是否完整。
第二步：用例评审
输入是候选用例和对应的需求材料。动作是评审人逐条阅读，判断用例的步骤是否可执行、预期结果是否明确、是否与已有用例重复。评审人可以确认、修改或退回，退回时需写明原因。输出是评审结论：通过、修改后通过或退回重拟。完成标志是每条候选用例都有明确的评审结论，没有悬而未决的条目。
第三步：测试结果汇总
输入是本轮的执行记录，包括通过、失败、阻塞的用例及对应版本。动作是让AI把执行记录整理成摘要，说明整体通过情况、失败集中在哪些模块、阻塞项的原因分布。输出是一份测试结果摘要。完成标志是摘要中的数字与执行记录一致，测试负责人核对后可以用于迭代评审。
第四步：缺陷分类与摘要
输入是测试人员提交的缺陷描述。动作是AI根据描述给出分类建议（如功能缺陷、界面问题、性能问题）和一段简明摘要。输出是带分类建议和摘要的缺陷候选记录。完成标志是每条缺陷都有分类建议和摘要，等待缺陷处理人确认。
第五步：人工复核
输入是前四步产生的全部AI输出。动作是各环节责任人确认或修正：评审人确认用例，测试负责人核对摘要，缺陷处理人确认分类与摘要。输出是可流转的最终记录，包括进入用例库的用例、定稿的测试摘要和进入缺陷跟踪流程的缺陷。完成标志是所有AI输出都经过对应责任人确认，且确认记录可查。
| 步骤 | 输入 | 动作 | 输出 | 完成标志 |
|---|---|---|---|---|
| 用例草拟 | 需求描述、验收条件 | AI生成候选用例 | 候选用例清单 | 覆盖主要场景并可追溯需求 |
| 用例评审 | 候选用例、需求材料 | 评审人逐条确认、修改或退回 | 评审结论 | 每条用例均有明确结论 |
| 测试结果汇总 | 执行记录 | AI整理摘要 | 测试结果摘要 | 摘要数字与执行记录一致 |
| 缺陷分类与摘要 | 缺陷描述 | AI给出分类建议与摘要 | 缺陷候选记录 | 每条缺陷均有建议与摘要 |
| 人工复核 | 各环节AI输出 | 责任人确认或修正 | 可流转的最终记录 | 全部输出经确认且留痕 |
这五步在工具中需要有承载位置：候选用例、评审结论、测试摘要和缺陷记录都应保存为可追踪的对象，而不是散落在聊天记录或临时文档里。ONES Assistant 连接 ONES Project、ONES Wiki 与 ONES TestCase，可以把自然语言指令转化为 ONES 中可追踪的工作，例如创建缺陷、更新状态并通知负责人，结果保存为工作项或 Wiki 页面，便于后续复核和追溯。
角色分工与各环节交付物
流程能否稳定运行，取决于每个环节是否有人对结果负责。建议至少明确三类角色：测试负责人、用例评审人、缺陷处理人。角色可以由同一人兼任，但职责要分开写清楚。
测试负责人负责制定适用边界与复核规则，包括哪些环节引入AI、AI输出需要谁确认、退回后如何处理。测试负责人还要在每轮结束后查看复核记录，判断规则是否需要调整。交付物是书面的适用边界说明和复核规则。
用例评审人对AI草拟的用例做确认与退回。评审时需要对照需求材料判断覆盖是否完整，对不合格的用例写明退回原因。交付物是带评审结论的用例清单，退回原因要具体到缺失的场景或表述不清的步骤。
缺陷处理人负责确认AI给出的分类与摘要，修正后再流转给开发。如果分类建议与实际不符，处理人应修改并记录修正原因，这些记录是后续评估AI输出质量的依据。交付物是分类准确、摘要清晰的缺陷记录。
复核记录与留痕要求需要提前约定：谁在什么时间确认了哪条输出、做了哪些修改、退回原因是什么。留痕的目的不是追责，而是让规则调整有数据支撑。ONES 的 AI 能力基于 ONES 权限体系进行知识问答和任务执行，输出过程可追踪、结果可审计，可以作为复核留痕的承载方式之一。
| 角色 | 负责环节 | 主要职责 | 交付物 |
|---|---|---|---|
| 测试负责人 | 全流程 | 制定适用边界与复核规则，查看复核记录并调整规则 | 适用边界说明、复核规则、规则调整记录 |
| 用例评审人 | 用例草拟、用例评审 | 逐条确认、修改或退回候选用例，写明退回原因 | 带评审结论的用例清单 |
| 缺陷处理人 | 缺陷分类与摘要、人工复核 | 确认或修正分类与摘要，记录修正原因 | 可流转的缺陷记录及修正记录 |
| 测试负责人（兼核对） | 测试结果汇总 | 核对摘要与执行记录是否一致 | 定稿的测试结果摘要 |
一个迭代内的AI测试管理示例
以下是一个演示情景，用于说明流程如何在一个迭代中衔接，不代表任何具体项目的实测结果。
迭代开始后，产品经理在需求文档中写清了三条验收条件。测试负责人把需求描述交给AI草拟用例，得到十二条候选用例，覆盖正常下单、库存不足和重复提交三种场景。用例评审人逐条检查，发现库存不足场景只写了一条用例，退回要求补充并发情况下的库存扣减场景。补充后再次评审通过，用例进入用例库。
开发提测后，测试人员执行用例并记录结果。本轮共执行十二条用例，九条通过，两条失败，一条阻塞。测试负责人让AI根据执行记录生成摘要，摘要指出失败集中在订单状态同步模块，阻塞项是因为测试环境缺少支付回调配置。核对数字无误后，摘要用于迭代评审会。
两条失败用例对应提交了两个缺陷。AI根据缺陷描述给出分类建议：一条归为功能缺陷，一条归为接口问题，并各生成一段摘要。缺陷处理人确认第一条分类正确，第二条实际是数据问题而非接口问题，修改分类并记录原因后流转给开发。
迭代复盘时，测试负责人查看复核记录，发现用例退回集中在边界场景覆盖不足，缺陷分类修正集中在数据类问题。下一轮调整时，在草拟环节的输入中补充边界场景清单，并在缺陷分类规则中增加数据问题的判断说明。这样，复核发现的问题回流到流程规则中，形成闭环。
上线前的完成检查与效果验证
机制是否可用，可以用一组检查项逐条判断。检查不通过时，先调整规则再扩大使用范围，避免在规则不完整的情况下铺开。
- 复核规则是否覆盖全部AI输出环节：逐项核对用例草拟、用例评审、测试结果汇总、缺陷分类与摘要是否都有指定的复核人和确认动作，没有遗漏环节。
- 每条AI输出是否都有留痕：抽查若干条记录，确认能查到谁在何时确认、修改了什么、退回原因是什么。
- 抽样复核结果是否稳定：由测试负责人定期抽取一定比例的已确认输出做二次检查，观察二次检查中发现问题的比例。比例持续偏高，说明复核动作流于形式或AI输入质量不足。
- 用例退回率是否在可接受范围：统计每轮候选用例被退回的比例及退回原因分布。退回原因集中在某一类场景，说明草拟输入需要补充该类材料。
- 缺陷分类被人工修正的比例：统计缺陷处理人修改AI分类建议的次数占比。修正比例高，说明分类规则或缺陷描述模板需要调整。
- 测试结果摘要是否与执行记录一致：核对摘要中的关键数字，出现偏差时检查汇总环节的输入是否完整。
未通过时的调整方向可以按问题类型区分：复核覆盖不全，补充规则和责任人；退回率过高，回到草拟环节改进入口材料；分类修正比例高，细化分类口径并在缺陷模板中增加必填信息；摘要偏差，检查执行记录是否及时更新。调整后重新抽样验证，确认信号改善再进入下一轮。
当这些检查项连续若干轮通过，且抽样复核、退回率和分类修正比例处于团队可接受的水平，可以认为这套AI测试管理流程已经可以稳定运行。此后仍需保留定期抽样，因为需求类型和缺陷分布会随项目阶段变化，复核规则也需要随之更新。
常见问题
团队刚开始引入AI辅助测试，应该从哪个环节先试？
建议从用例草拟或缺陷分类与摘要中选一个环节先试。这两个环节的产出都是文本，评审人可以逐条检查，出错也容易在流转前拦截。先在一个迭代内跑通“AI生成候选结果—指定角色确认—记录复核结论”的完整链路，再逐步扩展到其他环节。一次铺开全部环节，复核规则往往来不及细化，退回原因也难以归因。
AI给出的缺陷分类建议经常被修正，应该怎么处理？
先统计修正集中在哪些类别，再判断是分类口径不清还是缺陷描述信息不足。常见做法是细化分类说明，并在缺陷提交模板中增加必填信息，例如复现步骤、影响范围和发生环境。调整后重新抽样，观察修正比例是否下降。修正记录本身也是评估AI输出质量的依据，建议保留修正原因，便于后续复盘。
人工复核会不会让流程变慢，如何控制复核成本？
复核成本取决于复核粒度和抽样方式。用例评审可以逐条确认，测试结果摘要由负责人核对关键数字即可，不必逐字重读。稳定运行若干轮后，可以对低风险环节改为按比例抽样复核，同时保留全量留痕。抽样比例和复核方式应写入复核规则，并根据抽样发现问题的比例动态调整。
复核记录需要保留哪些内容，保留多久？
至少保留四项：谁确认了哪条输出、确认时间、做了哪些修改、退回原因。这些记录用于判断规则是否需要调整，也用于回答“这条用例或缺陷为什么是现在这个状态”。保留期限可以结合团队的迭代周期和审计要求约定，关键是保证在复盘和追溯时能查到。
ONES 在这套流程里能承载哪些环节？
ONES Assistant 连接 ONES Project、ONES Wiki 与 ONES TestCase，可以把自然语言指令转化为 ONES 中可追踪的工作，例如创建缺陷、更新状态并通知负责人，结果保存为工作项或 Wiki 页面。ONES 的 AI 能力基于 ONES 权限体系进行知识问答和任务执行，输出过程可追踪、结果可审计，适合作为复核留痕的承载方式之一。具体环节的可用范围建议以实际环境确认。
