人机协作测试的最佳分工

图片

一、两次判断失误，方向相反

第一次失误，是管得太多。

我们的Agent在执行接口回归时，每跑完一批用例，都要等我确认"可以继续"才能跑下一批。理由是"怕它做错决定"。结果一套两千条用例的回归，本来可以一小时跑完，因为等待我的确认，花了半天。Agent的执行速度根本发挥不出来，我自己也被打断了十几次，什么别的事都没做成。

第二次失误，是放得太松。

我让Agent全权处理一次预发环境的巡检任务，包括判断哪些异常需要阻断发布。Agent发现了一个接口响应时间比基线高了22%，判断为"性能劣化，建议阻断"，自动发送了阻断通知给整个项目组。实际上，那天预发环境在做数据迁移，性能劣化是预期内的临时现象，不影响发布。

这两次失误，方向相反，但根源相同：我没有想清楚，哪些判断应该交给Agent，哪些判断必须由人来做。

这篇文章，是把这个问题想清楚之后的总结。

二、划分的底层逻辑：判断的性质，不是任务的难度

很多人划分人机分工，是按"难度"划的——简单的给Agent，复杂的留给人。这个逻辑看起来合理，但在实践中经常出错。

有些"简单"的任务，不能给Agent：判断这个缺陷要不要阻断上线，步骤不复杂，但决策责任很重，需要人承担。

有些"复杂"的任务，完全可以给Agent：并发执行两千条接口用例，并行分析所有响应的状态码和字段完整性，逻辑复杂、工作量大，但规则完全确定，交给Agent比人工更可靠。

真正有效的划分标准，不是任务的难度，而是判断的性质：

规则完全确定的判断 → 适合Agent自主完成 执行标准可以被精确描述，结果对错有明确定义，不依赖业务背景和上下文经验。

规则大体确定但存在例外的判断 → 适合人机协作 Agent处理主干逻辑，人处理例外情况和最终确认。

依赖业务理解、经验直觉、承担责任的判断 → 必须人来把关 结果没有唯一正确答案，或者判断失误的代价高，需要人的认知和责任机制介入。

用这个框架来看，分工不是"难易题"的分配，而是"判断性质"的分配。

三、第一类：交给Agent自主完成

这一类任务的特征：执行标准完全确定，结果可验证，不需要业务经验介入。交给Agent，不只是"能做"，而是"比人做得更好"——速度更快、不会疲劳、不会遗漏。

3.1 大规模回归测试的执行

已有用例集的执行、断言、结果记录——这是Agent的主场。

并发跑两千条接口用例，每条用例的断言规则是明确的（状态码、字段存在性、数值范围）。人工执行这件事不只慢，还容易在第一千五百条用例的时候因为疲劳漏掉一个关键的断言失败。Agent不会疲劳。

可以放心交给Agent的具体操作：

• 接口用例的批量执行和结果记录
• UI回归的元素定位、操作触发、截图对比
• 性能测试的负载施压和指标采集
• 跨环境的数据一致性对比（统计层面）

边界：执行和记录可以完全交给Agent，结论的解读不行。"接口返回了502"是事实，Agent可以记录；"这个502是不是需要阻断发布"是判断，这步需要人介入。

3.2 测试数据的生成和清理

按照既定规则生成符合业务约束的测试数据，以及测试执行完成后清理测试现场——两件事的规则都是明确的，完全适合Agent处理。

可以放心交给Agent的具体操作：

• 按字段类型和约束规则生成批量测试账号、订单、商品数据
• 生成覆盖特定分布的测试数据集（如30%VIP用户、70%普通用户）
• 测试执行后的测试账号注销、测试订单取消、测试数据清除

边界：数据生成规则要由人来定义，包括哪些字段有业务约束、什么样的分布有代表性。Agent执行规则，人定义规则。

3.3 标准化文档的生成

把结构化的执行数据转化成标准格式的报告——这是有固定模板的转换工作，不需要判断，适合完全交给Agent。

可以放心交给Agent的具体操作：

• 将执行记录转化为标准缺陷报告格式
• 将多次执行结果汇总为趋势分析表格
• 将接口文档变更转化为"影响范围说明"
• 将探索测试笔记整理为结构化用例草稿（草稿，还需人工复核）

边界：文档生成Agent可以全权，但文档的最终发布（尤其是要给外部团队或管理层的文档）需要人工复核，确认描述准确、无遗漏。

四、第二类：人机协作完成

这一类任务的特征：主干逻辑规则清晰，但存在需要业务经验或上下文判断的例外情况。Agent处理大量的"常规"，人处理少量的"例外"和做最终确认。

4.1 新功能的测试用例设计

Agent可以基于需求文档生成覆盖全面的用例草稿，但草稿不能直接入库——它缺少对业务特殊约束的理解、对历史遗留问题的感知、对这个功能真实风险分布的判断。

有效的协作模式：

Agent负责：  
✓ 读取需求文档，识别所有功能点  
✓ 生成正常路径用例（格式规范、步骤完整）  
✓ 生成通用边界值和异常场景（等价类、空值、类型错误）  
✓ 按优先级排序输出草稿
人负责： 
 ✓ 识别业务特殊规则（产品文档里没写清楚的隐含约束）  
 ✓ 补充历史高发场景（基于对这个系统的经验积累）  
 ✓ 调整优先级（基于对业务风险的判断）  
 ✓ 删除不合理或重复的用例  
 ✓ 最终审核入库

时间分配的现实参考：Agent生成草稿需要5分钟，人工审核和补充需要20–30分钟。总时间从原来的2小时（全人工设计）压缩到30–35分钟，且草稿质量的基准线更高——Agent不会漏掉等价类和边界值的基础覆盖。

4.2 探索性测试的执行

探索性测试是人最擅长的测试类型——依赖直觉、经验、好奇心，发现脚本覆盖不到的问题。但Agent可以成为探索过程中的有效辅助：

有效的协作模式：

Agent负责：  
✓ 在探索前，基于历史缺陷记录生成"重点关注区域"提示  
✓ 在探索过程中，记录操作路径（测试工程师口述，Agent结构化记录）  
✓ 探索结束后，将碎片笔记整理成结构化用例草稿  
✓ 识别探索发现和历史缺陷的相似性，提示"这里以前出过类似问题"

人负责：  
✓ 实际的探索执行（人的直觉和好奇心不可替代）  
✓ 发现的判断（这是bug还是设计如此？影响严重吗？）  
✓ 探索方向的实时调整（根据发现决定下一步往哪里探）

这个协作模式里，Agent是探索者的"副驾驶"——不开车，但帮你记路、提醒危险路段、整理发现。

4.3 缺陷优先级的初判

Agent可以基于规则给出缺陷优先级的初始建议，但初判结果需要人来确认，不能直接使用。

有效的协作模式：

Agent给出初判时，必须附上判断依据：

{  
    "issue": "POST /api/payment/confirm 返回 500",  
    "agent_priority": "P0",  
    "reasoning": "支付确认接口属于核心交易链路，500错误导致用户无法完成支付，根据历史规则，核心链路功能完全不可用定级P0",  
    "confidence": "high",  
    "requires_human_confirm": true,  
    "confirm_points": 
        ["是否只在特定条件下触发（如特定支付方式）？",    
         "是否有降级方案已启动？",    
         "是否已有线上监控告警触发？"  
        ]
 }

人看到Agent的建议和依据，快速判断"确认P0"或"调整为P1（只影响部分支付方式）"。这比人从零开始判断要快，也比Agent全权决定要准。

五、第三类：必须人来把关

这一类任务的特征：判断结果没有唯一正确答案，或判断失误的代价高，或需要人来承担决策责任。Agent可以提供信息和分析，但最终判断和行动必须由人做出。

5.1 发布阻断决策

"这个版本能不能发布"是整个测试流程最重要的判断，也是最不能外包给Agent的判断。

为什么这步必须人来做：

发布决策不是一个纯粹的技术判断，它综合了业务压力（这次发布的业务优先级）、风险偏好（团队当前能接受多大的上线风险）、上下文信息（今天有没有重大营销活动、运维是否在场、降级方案是否就绪）——这些因素没有统一的权重，需要人在具体情境下做出综合判断。

Agent能帮你做的：把所有质量数据汇总成一份结构化的"发布前质量画像"，明确列出通过的指标和有风险的指标。判断和决策，是人的事。

5.2 需求中的质量风险识别

在需求评审阶段识别质量风险，需要对业务逻辑的深度理解，对系统历史问题的积累，以及对"这类需求容易在哪里出问题"的经验直觉。

Agent可以帮你检查需求文档的完整性（是否有未定义的边界条件），但它识别不了"这个需求的逻辑和三个月前的那次改动有潜在冲突"——因为它不知道三个月前发生了什么，也感受不到业务团队在推进这个需求时的隐含假设。

需求阶段的质量把关，是测试工程师最有价值、也是最难被替代的工作，必须人来做。

5.3 跨团队的质量沟通和协商

当测试结论需要被传达给开发、产品、管理层，当需要就"这个缺陷要不要修"进行协商，当需要解释"为什么这次回归比上次多发现了15个缺陷"——这些沟通需要人来完成。

不只是因为人际沟通的复杂性，更因为这些沟通背后承载的是责任和信任。"Agent说这个缺陷可以接受"，没有人会信服；"测试工程师判断这个缺陷在当前业务优先级下可以接受，理由是……"，才是能推动决策的有效沟通。

六、一张可以直接用的分工参考表

七、结尾：最好的分工，是让每一方做它最擅长的事

这张分工表，不是一份固定的规范，而是一个起点。

你的系统有它的特殊性，你的团队有它的工作方式，你的业务有它的风险分布。分工的边界，应该在实践中持续校准——某个环节Agent判断失误太多，往回拉，加一层人工确认；某个环节人工确认每次都是橡皮图章，往前推，让Agent直接自主完成。

分工不是一次性设计好的架构，是在实践中不断调整的协议。

我在开头说的两次失误——管得太多和放得太松——都是因为没有想清楚分工的底层原则，而是凭感觉画的边界。有了"判断性质"这个框架，边界的调整就有了依据，不只是靠感觉。

Agent最擅长的：在规则清晰的空间里，以极高的速度和一致性执行。

人最擅长的：在规则模糊的边界上，用经验和判断力做取舍，并为结果负责。

这两件事，合在一起，才是一个完整的测试体系应有的样子。