代码测试 Prompt 包：单测、参数化、E2E 与测试重构

AI 写测试，最常见的翻车不是「写不出」，而是「写了一堆没用的」--覆盖率数字漂亮，核心路径没覆盖；mock 用得太狠，测的是 mock 不是代码；边界用例靠拍脑袋，漏掉真正会出事的输入。问题不在模型，在 prompt 没把「测什么、怎么测、测到什么程度」说死。

本站已有两篇姊妹文：《通用编码 Prompt 包》(prompt-coding-pack) 管代码的生成与重构，《代码审查与 Debug Prompt 包》(prompt-code-review-debug-pack) 管审查与调试。本篇专管「写测试」一件事--代码已经能跑，要给它补测试。三者不重叠：那两篇产出的是代码或诊断，本篇产出的是测试用例、测试计划与测试策略。若你要的是「把测试生成做成自动化流水线」，另见《AI 自动化测试生成 SOP》(ai-test-generation-sop)；本篇是「人拿着 prompt 逐段补测试」的提速包。

四个 Prompt 分三级递进，外加一个速查 cheatsheet。每个都带角色、任务、约束、输出格式，变量用 {{}} 标注，复制改用即可。

一、入门级：按函数生成单测

测试翻车的起点是「让 AI 直接写测试」。它默认给你塞 5 个 happy-path，断言全是 assert result is not None，边界一个不碰。这步强制「先列签名与边界，再写用例」，把测试生成变成两段式：先对齐契约，再产出用例。

你是资深 {{语言}} 测试工程师。请为以下函数生成单元测试，分两步输出，不要一步写完。

函数代码：
{{函数代码}}

测试框架：{{pytest | jest}}

第一步--函数签名与边界清单（只写这些，等我确认后再写用例）
- 函数名、参数类型、返回类型
- 列出每个输入的合法范围与边界值（空值 / 空串 / 空数组 / 0 / 负数 / 超长 / 超大 / 非法类型）
- 列出所有需要验证的异常或错误分支（抛异常 / 返回错误码 / 返回默认值），标明触发条件
- 不要写测试用例代码

第二步--测试用例（在我确认边界清单后给出）
- 按 正常 / 边界 / 异常 三类各写 {{N}} 例，共 {{3N}} 例
- 每例写：用例名（描述被测场景）、输入、预期输出或预期异常
- 使用 {{pytest}} 的参数化（@pytest.mark.parametrize）或 {{jest}} 的 test.each，不要把每个用例写成独立 test 函数
- 只使用被测函数真实存在的接口与标准库，不要臆造任何不存在的 API 或 helper；若不确定某断言方式是否存在，标注「待确认」
- 不要写 `assert result is not None` 这种无效断言，每条断言必须锁死具体值或结构

约束：边界清单有遗漏或歧义时先问我，不要自行补；测试必须可直接运行，不留 skip 或 TODO 占位。

要点：两段式是这个 Prompt 的灵魂。AI 默认跳过边界分析直接堆 happy-path，逼它先列边界清单，你才发现它根本没考虑「空数组」这个会触发除零的输入。「每条断言锁死具体值」是另一道闸：assert result is not None 这种废话断言是 AI 测试的头号坏味道，等于没测。

二、进阶级：参数化批量用例与测试计划

单个函数的测试好补，一个模块的测试要规划。直接让 AI「给这个模块写测试」，它会挑容易的函数写一堆，真正复杂的核心路径一笔带过。这步把测试拆成「参数化用例批量生成 + 测试计划 + 依赖 mock 策略」，逼它先盘缺口再动手。

你是资深测试架构师。请为以下模块产出测试计划与参数化用例，分三部分输出。

模块代码：
{{模块代码}}

测试框架：{{pytest | jest}}
已有测试：{{已有测试文件或「无」}}

1. 测试计划
   - 列出模块内每个公开函数/方法，标注当前测试覆盖状态（已覆盖 / 部分覆盖 / 未覆盖）
   - 对每个未覆盖或部分覆盖的函数，列出需要补的用例类型（正常 / 边界 / 异常 / 并发 / 幂等）
   - 标注哪些函数是核心路径（出错影响面大），应优先补测
   - 给出覆盖率缺口清单：哪些分支、哪些错误路径、哪些边界还没被任何用例触达
2. 参数化用例
   - 对核心路径函数，用参数化方式批量生成用例（@pytest.mark.parametrize 或 test.each）
   - 每组参数化写：参数名、输入组合表（至少 5 组，含正常+边界+异常）、每组预期输出
   - 参数表要包含容易漏的组合：空集合与单元素集合、0 与负数、极大值、非法类型、边界交界处（如 off-by-one）
3. 依赖 mock 策略
   - 列出模块的外部依赖（数据库 / 网络 / 文件 IO / 时间 / 第三方 API）
   - 对每个依赖说明：用 mock 还是 stub 还是 fake，为什么；mock 的作用域（函数级 / 模块级）
   - 标注哪些依赖不应 mock（如纯计算函数），为什么
   - 给出 mock 最小化原则：只 mock 会产生副作用的依赖，纯函数直接用真实实现

约束：不得臆造被测模块不存在的函数或属性；mock 必须基于真实依赖接口，若依赖接口未在代码中体现，标注「待确认依赖接口」；测试不得依赖网络或真实数据库，必须本地可跑。

要点：「覆盖率缺口清单」是这个 Prompt 和入门级的关键差别--入门级管「给一个函数补用例」，进阶级管「给一个模块盘缺口」。AI 默认回避难测的函数（异步、有副作用、依赖多），逼它列出「未覆盖」状态，你才知道它偷了哪些懒。「mock 最小化原则」是反 AI 味：AI 爱把所有依赖都 mock 掉，结果测的全是 mock，真实代码一行没跑到。

三、专家级：集成/E2E 策略、覆盖率分析与测试重构

单元测试补齐了，集成测试和 E2E 还要分层。AI 在这一层最容易犯两个错：一是把集成测试写成大号单测（mock 掉所有依赖，测的还是单点）；二是测试越堆越多，冗余和重复没人清。这步强制「测试金字塔分层 + 契约测试 + 删冗余」，产出的是测试体系而不是一堆测试文件。

你是测试架构师。请对以下项目产出集成/E2E 测试策略与测试重构方案，分三部分输出。

项目概况：
{{项目结构 + 主要模块 + 已有测试情况}}

1. 集成与 E2E 测试策略
   - 按测试金字塔分层：单元层（已覆盖情况）/ 集成层 / E2E 层，标注每层应占的大致比例
   - 集成层：列出需要跨模块验证的交互点（模块 A 调用模块 B 的接口、数据流转、事件触发），每个交互点写 1-2 个验证用例
   - E2E 层：列出 3-5 条核心业务链路（从入口到最终输出的完整路径），每条写验证点
   - 契约测试：若项目有服务间调用（HTTP / 消息队列），列出需要契约测试的接口，说明用 Pact 还是自建 schema 校验
   - 标注哪些层当前缺失，应优先补哪层
2. 覆盖率缺口分析
   - 基于已有测试，列出覆盖率最薄的 3 个模块（按分支覆盖率或路径覆盖率估算，不要给编造的精确数字）
   - 对每个薄模块，说明缺口在哪（错误分支 / 边界 / 并发 / 异常恢复）
   - 给出补测优先级：按「出错影响面 × 缺口大小」排序
3. 测试重构
   - 找出冗余用例：多个用例测同一分支、参数化可合并、setup 重复可提取 fixture
   - 找出脆弱用例：依赖顺序、依赖时间、依赖网络、断言过松（只断言 not None）
   - 给出删减清单：哪些用例可删（说明为什么冗余），哪些可合并，哪些应改写
   - 标注重构后预期效果：用例数减少多少、运行时间缩短多少（给粗略估计，不要编造精确数字）

约束：不得编造覆盖率具体百分比；分层比例给区间不给精确数；契约测试方案基于项目真实依赖，若依赖未在概况中体现，标注「待确认」；测试重构不得改变被测代码行为。

要点：「不要给编造的精确数字」是这个 Prompt 的反编造闸--AI 爱自信地说「覆盖率将从 62% 提升到 87%」，这种数字没来源就是编的，逼它给区间和「粗略估计」。「删冗余」是和前两级的核心差别：入门级和进阶级都在「加测试」，专家级开始「减测试」--冗余用例是测试体系的隐性负债，跑得慢、维护贵，AI 默认只加不减，必须主动逼它列删减清单。

四、速查：5 分钟给一段代码补测试

不是所有场景都要做测试计划。修了个 bug、加了个小函数、review 时发现没测试，核心诉求是「5 分钟补几个能跑的用例」。这个 cheatsheet 逼它出「边界清单 + 参数化用例 + 一条最该测的路径」，不搞大动作。

你是测试工程师。请为以下代码在 5 分钟内补出可直接运行的最小测试集。

代码：
{{代码}}

测试框架：{{pytest | jest}}

输出三部分，紧凑不啰嗦：
1. 边界清单：列出 5 个最容易出事的输入（空 / 单元素 / 越界 / 非法类型 / 极值），每条一句话
2. 参数化用例：用 @pytest.mark.parametrize 或 test.each 写一组参数化测试，含正常 2 例 + 边界 3 例，每例写明预期输出
3. 最该测的一条路径：指出这段代码最容易在生产翻车的一条执行路径，写一条针对它的断言用例

约束：只用代码里真实存在的接口；断言锁死具体值，禁用 assert not None；拿不准的接口标「待确认」，不要臆造。

要点：「最该测的一条路径」是这个 cheatsheet 的灵魂。AI 默认均匀撒用例，但真实代码总有「最脆的那条路径」--可能是边界交界、可能是异常恢复分支。逼它指出哪条最该测，比堆 10 个 happy-path 有用。「禁用 assert not None」是去 AI 味的硬规则，无效断言是测试债务的源头。

四条通用约束

上面四个 Prompt 共享四条硬约束，是「AI 写的测试能不能用」的底线：

1. 可运行 + 边界处理：产出的测试必须能直接跑通，不留 skip 或 TODO；边界（空值、空数组、超大输入、并发）必须有显式用例，不能只在注释里写「假设输入合法」。
2. 不臆造 API：AI 测试翻车的头号原因。它会自信写出 assertUserEquals()、mockDatabase.flush() 这种看似合理但根本不存在的断言或 mock 方法。只许用测试框架标准 API 或被测代码真实存在的接口，拿不准的标「待确认」。
3. AI 草稿需人审：每个 Prompt 产出都是草稿，不是成品。AI 生成的测试尤其要人工核对「断言是否锁死了正确的东西」--AI 常写「断言通过但根本没测到点」的伪测试。Prompt 要求附「边界清单」和「预期输出」是给人审的抓手。
4. 去 AI 味：禁无效断言（assert not None、assert True）；禁废话注释（「这里测试正常情况」）；用参数化合并重复用例，不要一个 test 函数只测一个输入。AI 味重的测试看着数量多，实则信息密度低。

怎么用

四个 Prompt 按场景取用：

• 给单个函数补单测：用入门级。先出签名和边界清单，你确认后再参数化用例。
• 给整个模块盘测试：用进阶级。先出测试计划和覆盖率缺口，再批量参数化用例，mock 策略单独定。
• 搭测试体系或清理测试债：用专家级。先分层（金字塔 + 契约），再分析覆盖率缺口，最后列删冗余清单。
• 临时补几个用例：用速查 cheatsheet。5 分钟出边界清单 + 参数化 + 一条最该测的路径。

模型选择上，入门级和速查 cheatsheet 主流模型都能胜任，DeepSeek 性价比高、适合批量补测；进阶级测试计划和专家级分层策略偏推理，Claude Opus / GPT-5 / Codex 这类编码向模型更稳，Claude 长上下文适合把整个模块的代码和已有测试一次喂进去做缺口分析；一句话：日常补测选 DeepSeek，测试体系设计和重构选 Claude / GPT-5。

踩坑

1. 让 AI 一步出全部测试：它直接堆 happy-path，边界一个不碰。解法：入门级 Prompt 强制两段式，先边界清单后用例。
2. 无效断言泛滥：AI 爱 assert result is not None，看似覆盖了其实没测到点。解法：硬约束「断言锁死具体值」，禁用 not None 类断言。
3. mock 用过头：AI 把所有依赖都 mock 掉，测的是 mock 不是代码。解法：进阶级 Prompt 强制「mock 最小化原则」，只 mock 有副作用的依赖，纯函数用真实实现。
4. AI 编造覆盖率数字：它自信地说「覆盖率从 62% 升到 87%」，数字没来源。解法：专家级 Prompt 硬约束「不得编造精确百分比」，只给区间和粗略估计。
5. 只加测试不删冗余：测试越堆越多，跑得慢维护贵，没人清。解法：专家级 Prompt 强制列「删减清单」，主动逼 AI 找冗余和脆弱用例。

参考来源

• Anthropic《Prompt engineering》：docs.anthropic.com/en/docs/build-with-claude/prompt-engineering/overview
• OpenAI《Prompt engineering guide》：platform.openai.com/docs/guides/prompt-engineering
• Martin Fowler《TestPyramid》：martinfowler.com/bliki/TestPyramid.html
• Pact《Contract testing》：pact.io