让 Claude Code 设计测试策略

补测试前不要先写代码。让 Claude Code 先识别测试框架、风险点、边界场景和最小验证方式，再决定补单元测试、集成测试还是人工验收。

测试不是“让 CC 随便补几个用例”。真正有用的测试，应该覆盖本次改动最容易出问题的地方。

如果项目有测试体系，可以让 CC 帮忙补测试；如果没有，也可以让它设计最小验证方式。关键是先做测试策略，而不是直接写测试文件。

先识别项目测试方式

不要一上来就说“补测试”。先让 CC 看项目怎么测。

请先只读分析当前项目测试方式，不要新增测试。

请告诉我：
1. 项目使用什么测试框架。
2. 测试文件通常放在哪里。
3. 测试命名风格是什么。
4. 现有测试偏单元、集成还是端到端。
5. 当前任务最适合补哪类测试。

如果项目没有测试体系，也要明确说出来。

测试应该围绕风险设计。

请基于本次改动列出风险点。

格式：
| 风险点 | 可能出错的原因 | 推荐验证方式 |

要求：
1. 不要为了补测试而补测试。
2. 只关注本次改动可能影响的行为。
3. 如果人工验收更合适，也请说明。

风险点比测试数量更重要。

不同任务适合不同测试：

不要所有任务都硬写单元测试。

测试策略不是越多越好，而是用最少的测试覆盖最高风险。

可以按这个顺序选：

1. 先覆盖本次改动直接影响的主路径。
2. 再覆盖最容易出错的边界条件。
3. 再覆盖历史上出过问题的回归路径。
4. 最后才考虑可选的维护性测试。

让 CC 帮忙收敛：

请给出本次改动的最小测试集。

要求：
1. 不追求测试数量。
2. 每个测试都对应一个明确风险。
3. 如果某个风险人工验收更合适，请说明。
4. 标出哪些测试可以后续再补。

请先给测试计划，不要写测试代码。

请输出：
1. 本次最需要验证的行为。
2. 推荐补哪些测试。
3. 每个测试覆盖什么风险。
4. 哪些风险不适合自动化测试，需要人工验收。
5. 最小测试集是什么。

确认后再让它写测试。

测试应该尽量验证行为，而不是绑死实现。

不好的测试：

更好的测试：

可以这样要求：

请优先测试用户可观察行为，不要过度绑定实现细节。

如果必须 mock，请说明 mock 的原因和边界。

如果项目没有测试体系，不要让 CC 直接引入一堆依赖。

如果当前项目没有测试体系，请不要新增测试框架。

请给出最小验证方案：
1. 应该运行什么检查。
2. 应该打开哪些页面。
3. 应该测试哪些输入。
4. 应该观察哪些结果。
5. 是否建议后续单独建立测试体系。

建立测试体系本身应该是独立任务。

测试不是写完就完了。让 CC 说明覆盖范围：

请解释新增测试：
1. 每个测试覆盖什么风险。
2. 为什么这些测试足够支撑本次改动。
3. 哪些风险还没有覆盖。
4. 如何运行这些测试。
5. 测试失败时应该先看哪里。

这样用户才知道测试是否真的有价值。

有些测试看起来通过了，但价值很低：

可以要求 CC 自查：

请检查新增测试是否存在假覆盖。

重点看：
1. 是否真的覆盖本次改动风险。
2. 是否只测试了无关实现细节。
3. mock 是否掩盖真实问题。
4. 是否遗漏关键失败路径。

测试失败不一定说明业务代码错了，也可能是测试写错、mock 不合理、环境缺失或断言过度。

可以让 CC 先分类：

测试失败了，请先不要修改业务代码。

请判断失败原因属于哪类：
1. 业务逻辑确实有问题。
2. 测试断言不合理。
3. mock 或测试数据不对。
4. 环境或依赖问题。
5. 之前已有历史失败。

请说明依据，再给出最小修复建议。

这样能避免为了让测试通过而改坏业务。

请为本次测试策略收尾。

请输出：
1. 本次改动的主要风险点。
2. 已覆盖的自动化测试。
3. 已覆盖的人工验收。
4. 未覆盖风险及原因。
5. 是否建议后续补更完整测试体系。

测试策略的最终目标，是让交付结果更可信，而不是让测试数量看起来更多。