Tester Kit：智能体执行测试，人做决定

问题

测试团队 100% 手工测试。多数成员技术背景不强，无法用传统方式编写自动化脚本。每人每天最多只能完成 3 到 4 个任务，没有足够时间重跑旧用例，而开发团队已经用上 AI，功能交付的速度超过了测试的速度。

Tester Kit 之前没人来得及重跑旧用例，旧缺陷反复出现

• 重复缺陷
• 新缺陷

• 一个模块的缺陷约 30% 是重复出现的缺陷

  3070

背景与角色

• 测试团队四人，同时支持多个项目。
• 测试用例保存在电子表格中，许多用例在各次发布之间重复。
• 我负责设计流程、搭建 skill、培训并跟进落地情况，同时兼任 BA。
• 约束：测试人员不写代码；智能体不得自行判定通过或失败；所有结果必须附证据。

第 1 步：对测试用例分类

并非所有用例都适合交给智能体。

分类哪些用例交给智能体，哪些手工测试

	示例	交给智能体	人做什么
API 与数据检查	接口返回正确的状态码，数据库状态正确	是	验证报告
重复且稳定的界面流程	登录、创建记录、筛选列表	是	验证证据
多步骤且含计算的业务流程	部分付款后检查应收款	是	逐步验证并核对数据
界面观感与体验	布局、颜色、提示文案	否	手工测试
第三方集成、真实支付	Webhook、支付网关	否	受控的手工测试
探索性测试	发现脚本之外的缺陷	否	有专业经验的测试人员

第 2 步：设计 Tester Kit

这套工具包含 8 个 skill，封装后测试人员只需安装到 IDE 中即可运行自动化用例，无需编写代码。代表性的 skill 串成一条链：

Tester Kit每个 skill 做一件事，每件事一个产出

1. 1生成测试用例根据 story、验收标准、业务规则
2. 2执行前检查环境、样例数据、测试账号
3. 3执行用例集在 staging 上执行，截图，保存日志
4. 4回归测试按刚变更的模块重跑旧用例
5. 5起草缺陷复现步骤、预期、实际
6. 6汇总证据可附到工单的文件夹

规则适用于所有 skill

• 智能体只给出初步结果：疑似通过、疑似失败或不确定。
• 每个结果都必须附证据：截图、日志、实际值。
• 不触碰生产数据。只使用测试账号。
• 通过或失败的最终判定由测试人员做出。

第 3 步：并行执行

每位测试人员打开 10 到 15 个 IDE 智能体标签页（Claude Code、Codex、Antigravity），每个会话执行一组用例。智能体先执行，测试人员跟踪汇总表。

测试人员的一天

• 测试人员
• 智能体

1. 1测试人员划分用例组
2. 2智能体并行执行每个会话一组用例10–15
3. 3智能体初步结果附证据
4. 4测试人员核查证据
5. 5测试人员手工测试失败用例、无法自动化的用例
6. ?测试人员QA 决定

第 4 步：“看起来通过”的情况

下面的模拟示例说明了为什么仍然需要人来验证。用例：为 3,000,000 越南盾的账单登记 1,000,000 越南盾，应收款应恰好减少 1,000,000 越南盾。

第 5 步：测试人员的新角色

测试人员从事事手工操作的人，变成验证 AI 工作结果的人。

新角色

1. 1设计测试用例由 AI 生成草稿
2. 2选择交给智能体的用例
3. 3调度智能体会话跟踪汇总表
4. 4核查证据对失败用例、不确定用例做手工测试
5. ?判定通过或失败
6. 6附证据的缺陷报告

结果

根据内部统计：

• 之前
• 之后

• 同一模块的重复缺陷✓ 30% → 5%

  30%
  5%

在美国客户项目上，统计自项目文档库：

工具包已交付给测试人员（包括 Ubuntu 用户），并附面向非技术人员的指南。

我学到的

• 不写代码的人同样可以驾驭自动化测试，只要工具说的是他们的语言：测试用例和证据。
• 智能体不是判定通过或失败的人。测试人员仍然对测试结果的验证负责。
• 自动化最大的价值在于把时间腾给需要人来做的工作：疑难用例和探索性测试。