---
name: test
description: 用户要求测试、E2E、回归、复现缺陷，或要判断一个功能、修复、迁移能不能交付时使用。先写测试计划，再从真实入口走到结果真正生效的地方执行，最后按计划逐项报告。写代码过程中跑一下单测、编译这类顺手检查不用；判断代码写得好不好用 review。
---

# test

测试是想办法证明它是错的，而不是替实现找通过的理由。一路测到结果真正生效、或被真实使用方看到的地方：请求成功、命令退出 0、页面提示完成、单测变绿，都只证明它们自己那一层。

## 先写计划

计划从这些来源长出来：`.agents/tasks/<任务>/shape.md` 的目标和验收标准（如果有）、原始缺陷、实际 diff、公共接口，以及受影响的调用方和消费者。不从通用检查清单长出来。

先写清被测的对象和环境：哪个版本或构建、哪个环境、用什么身份和数据、在哪里观察结果。每个关键场景一个用例，写到另一个人不用现场补细节就能执行：

- 为什么测，失败会影响谁；
- 具体的输入、请求或操作步骤；
- 期望的结果，以及系统最终应处于什么状态；
- 在哪里、用什么确认这个最终状态；
- 测试会改动哪些数据，怎样清理。

执行前反过来检查计划：如果产品其实是错的，这些用例有没有可能全部通过？常见的漏洞是只验证了操作被触发、没验证最终状态，或者漏了旧的调用方、权限、异步消费者和失败恢复路径。

非平凡的测试先把计划给用户看一眼，然后开始执行；执行中发现计划没覆盖的风险，补进计划，已有用例不删。

## 执行

先确认实际测到的是预期的版本、进程、数据和环境。按承诺对应的入口来测：承诺的是界面行为，就亲自走界面；API、数据库、日志和下游系统用来确认最终状态，不能代替界面上的操作。

每个用例先记下实际做了什么、看到了什么，再给结论。失败和重跑都保留，不用后来的通过覆盖先前的失败，也不根据计划或记忆补写没发生过的步骤。发现产品问题时先留下可以复现的证据；只有用户要求或授权了修复才去修，修完按受影响范围重测。某个条件不满足时，只暂停依赖它的用例，其余继续。测试中创建的数据、进程和配置，清理后确认已经清掉，保留的写明。

## 报告

计划里的每个用例在报告中都有且只有一个结果：

- **通过**：直接证据支持全部预期；
- **失败**：实际行为和预期不符；
- **未完成**：没能完整执行或确认，写明原因，例如环境不可用、被其他失败挡住、主动跳过或缺少最终状态的证据。

总体结论只看关键用例的证据，不看通过率：给出能不能交付，列出失败项、未完成项和因此还不能证明的范围，以及测试留下的数据或进程。

## 保存

简单改动、一个检查就能完整证明的，直接在对话里报告测了什么、结果如何、还有什么没证明。需要计划的测试写到 `.agents/tasks/<任务>/test.md`，先写"计划"一节，执行后在同一文件补"报告"一节；截图、日志、请求和响应等原始材料放在同目录的 `evidence/` 下，正文说明它们证明了什么。

一次性的测试脚本属于这次测试的证据；要把自动化测试长期加进产品代码，属于实现工作，按当前授权处理。