代码覆盖率不够怎么补？AI写单元测试提示词与边界用例生成技巧

在日常研发交付中，很多团队都会给 CI/CD 流水线卡死一道硬指标：单测代码覆盖率必须达到 80% 甚至 85%。

很多开发者为了交差，随手把业务代码丢给大模型：“帮我给这段代码写个单元测试，用 JUnit5/pytest”。模型确实能在几秒内吐出数十行结构齐整的测试代码，但一跑 JaCoCo 或 pytest-cov，行覆盖率可能勉强到 60%，分支覆盖率（Branch Coverage）更是常常卡在 40% 左右。

其实原因很简单：大模型默认具有顺行思维偏好（Happy Path Bias），会优先生成符合业务主流程的输入参数。如果你不给它施加严密的边界约束，它根本不会主动考虑负数、空指针、并发锁竞争、网络超时以及溢出等极端条件。

要真正把覆盖率拉上去，不能靠简单催促，而要依靠严密的提示词分层结构、推理参数微调以及反向覆盖补全工作流。

一、模型选型与核心推理参数配置

不同的大模型在代码逻辑理解和单测生成上有明显的风格差异。在开始配置提示词之前，首先要选对模型，并把底层采样参数调整到适合代码工程的档位。

1. 主流大模型单测生成特性对比

2. 参数调优原则（减少幻觉断言）

代码生成不是文学创作，确定性远高于发散性。建议将调用参数调整为：

•Temperature（温度）：设置为 0.1 ～ 0.2。过高的温度会导致模型臆造被测类中不存在的方法或参数。0.1 可以强迫模型严格依据你提供的上下文和语法规则输出。

•Top-P：设置为 0.1。与低温度配合使用，将候选词锁定在高概率的核心技术语法范围内。

•Presence / Frequency Penalty：统一保持为 0。单测代码中往往需要反复使用相同的断言方法和前置配置，提高惩罚项会导致模型为了避开重复词而写出奇怪的变体代码。

二、CRBT 单测提示词框架设计

要让 AI 输出高质量、高分支覆盖率的单测，提示词不能是一句口令，必须包含四个核心区块：上下文（Context）、规则约束（Rules）、分支穷举（Branches）、输出模板（Template）。

注意看下面这套已经在企业级生产项目中验证过的标准模版：

### 角色与目标
你是一名资深软件测试专家与架构师。你的目标是为以下提供的【被测代码】编写高覆盖率、高鲁棒性的单元测试，重点补齐边界条件、异常分支与防御性逻辑。

### 1. 上下文信息 (Context)
- 开发语言与测试框架：[例如：Java 17 / JUnit 5 + Mockito / AssertJ]
- 被测类代码：

// 贴入待测类源码或核心方法

- 相关依赖类定义（DTO / 枚举 / 外部 Client）：

// 贴入出入参对象、被 Mock 的接口签名

### 2. 严苛编写规则 (Rules)
- **禁止过度 Mock**：只 Mock 外部网络、数据库 IO、第三方 RPC 及系统时间等不可控依赖。禁止 Mock 被测类自身的方法与内部私有逻辑。
- **真实断言原则**：禁止出现 `assertTrue(true)` 或仅断言 `assertNotNull(result)` 的无效校验；每一个用例必须严格验证**返回字段值**、**异常类型与错误信息**，或**依赖项的交互调用次数（如 verify）**。
- **独立性**：每个用例完全独立，不得依赖全局共享变量或特定的执行先后顺序。

### 3. 分支穷举与边界覆盖要求 (Branches)
请逐行审查被测代码，严格针对以下维度生成测试矩阵：
1. **输入等价类与边界值 (BVA)**：包括但不限于 null、空字符串、全空格、0、负数、极大值（Integer.MAX_VALUE）、精度截断、格式越界。
2. **控制流全分支覆盖**：保证 if/else 的所有路径、switch-case 的每个分支及 default、三元运算符的两个走向均有独立用例覆盖。
3. **异常处理覆盖**：显式触发所有的 try-catch 块、业务主动抛出的自定义 Exception，以及底层可能抛出的运行时异常（如 NPE、IllegalArgumentException、Timeout）。
4. **并发与状态边界**（若适用）：包含空集合、单元素集合、超额并发容量、状态机非法反向跃迁等。

### 4. 输出格式与模板 (Template)
- 遵循命名规范：`test_[方法名]_[测试场景条件]_[预期行为或结果]`。
- 采用 AAA（Arrange-Act-Assert）结构分段并用注释标明。
- 在给出代码前，先输出一个清晰的 Markdown 表格，列出本次覆盖的所有场景分支及对应的输入预期。

三、攻克极端边界的提示词实战技巧

在实际业务中，很多代码覆盖率上不去，是因为深层嵌套的分支难以触发。通过以下三个专项技巧，可以把分支覆盖率从 60% 稳步拉到 90% 以上。

1. 两阶段生成法：先出用例矩阵，再写测试代码

不要让模型在一次推理中同时完成“寻找逻辑漏洞”和“编写严谨代码”两项高负荷任务。分两步走，效果会好很多。

•阶段一提示词（逻辑推演与分支挖掘）：

“请通读上述代码，忽略具体语法实现，仅列出所有能导致代码走向不同逻辑分支的输入组合与边界条件。请使用表格输出：分支编号、代码所在行号、输入参数条件、预期执行分支、抛出异常或返回结果。”

•阶段二提示词（代码落地）：

“请依据你刚才分析出的用例矩阵，逐一为每一个用例编写严格的 [测试框架名] 代码。确保每一个边界分支都有至少一个独立的测试方法进行断言校验。”

这种做法先迫使模型调用其推理链梳理逻辑分支，生成代码时就有章可循，几乎不会漏掉边缘的分支判定。

2. 反向补全法：基于覆盖率报告（Diff Driven Testing）精准补刀

如果你的项目已经跑过测试，但测试报告（如 JaCoCo 的 HTML 报告）显示某几行始终处于标红（Uncovered）或标黄（Partially Covered）状态，直接把未覆盖信息作为反向线索喂给 AI。

### 补齐未覆盖分支指令
我们的单测覆盖率检测显示，以下代码行处于【未覆盖】或【分支未完全走通】状态：

- 第 42 行：`if (order.getAmount() <= 0 || order.getUser() == null)`（当前仅覆盖了 amount > 0 的情况，未覆盖 amount <= 0 以及 user 为 null 的分支）
- 第 58-63 行：catch (PaymentGatewayException ex) 异常降级分支

被测方法完整逻辑如下：
[贴入方法代码]

任务要求：
请不要重复编写已有的正常用例。请**仅针对上述标红未覆盖的行与分支**，反向推导所需的测试入参和 Mock 条件，编写 2-3 个精准的高效用例，把这几行的覆盖率补齐。

3. 常见复杂场景专项注入语句

针对特定技术栈中的“覆盖率死角”，可以直接在提示词中附加针对性的约束模块：

•针对集合与分页边界：

“请务必覆盖：集合为 null、集合为空（size=0）、集合仅有 1 个元素、集合刚好达到分页大小上限（size=PageSize）、以及超额（size=PageSize+1）五种状态。”

•针对外部 RPC 异常与超时边界：

“请使用 Mockito 为外部依赖注入模拟异常：`when(client.call(any())).thenThrow(new SocketTimeoutException())`，并断言被测类的熔断、重试或包装异常逻辑是否完全执行。”

•针对高精度计算（BigDecimal/浮点）：

“被测代码包含金额计算，请提供：精度舍入边界（如四舍五入在 0.005 的情况）、除以 0 的计算输入、正负极大金额相加导致的溢出检验用例。”

四、落地工作流 SOP：从 50% 冲到 90% 的四步闭环

把 AI 辅助单测引入日常开发，不应是一次性的复制粘贴，而要建立一套标准作业程序（SOP）：

[步骤 1: 提炼契约] 提取目标类、核心依赖接口、入参出参对象
        │
        ▼
[步骤 2: 矩阵推演] 运行 CRBT 提示词生成《分支等价类与边界矩阵》
        │
        ▼
[步骤 3: 代码装配] 生成测试代码并在本地执行编译与测试
        │
        ▼
[步骤 4: 报告反哺] 读取本地覆盖率未达标行，输入反向指令精准攻坚

1.代码提炼：不要把几千行的无关业务文件全部粘进去。只提取被测类本身，以及与被测逻辑直接相关的接口签名、实体定义。如果上下文杂音太多，模型对边界的专注度会显著下降。

2.矩阵推演：先让模型交出《用例矩阵》。技术负责人或开发者花 30 秒扫一眼表格，确认边界是否找全（比如是否漏了空指针、负数或特殊状态）。

3.代码装配与执行：将 AI 吐出的测试代码贴入本地项目运行。此时重点看两个结果：编译是否报错、测试是否一次性通过。

4.报告反哺：打开本地生成的覆盖率可视化页面，找到依然标红的逻辑块，使用本文第三节的“反向补全法”喂回给 AI，通常一轮对话即可将死角代码彻底覆盖。

五、避坑指南：AI 生成单测的高频翻车点

借助大模型编写测试代码能够大幅节省敲键盘的时间，但也伴随着特定的技术风险。实际操作中必须时刻提防以下四个常见陷阱：

1. 虚假断言（Assertion Roulette / Hallucination）

这是 AI 写单测最隐蔽的问题。模型常常生成只执行方法却不校验实质结果的假测试。例如：

// 错误示范：AI 生成的代码表面上跑通了，但什么都没测到
OrderResult result = orderService.process(order);
assertNotNull(result); // 仅断言非空，完全没断言状态码、计算金额是否正确

应对策略：在提示词中死磕规则，明确要求：“必须断言具体业务字段的值，每个测试用例必须包含对关键状态的精确对比”。

2. 过度 Mock（Mock 了一切，导致测试失去意义）

有时为了让测试能跑通，AI 会把被测类内部的依赖、甚至是私有逻辑全给 Mock 掉，导致真实执行的代码只剩下一行接口壳子，覆盖率数据虚高，但代码一到线上就崩溃。

应对策略：严格遵循规则限制：只允许对外部 IO、数据库与网络服务做 Mock，纯内存计算与领域模型逻辑必须用真实对象运行。

3. 强测私有方法

初学者常让 AI 为 `private` 方法单独编写单测，导致模型使用大量 Java 反射（ReflectionTestUtils）去强行调用私有逻辑。这破坏了面向对象的封装性，一旦后续代码重构，单测将大面积失效。

应对策略：单测应当面向公共契约（Public API）测试。私有逻辑的覆盖率，必须通过传入特定的公有方法参数，间接穿透并覆盖到私有逻辑中。

4. 测试用例之间的数据污染

AI 生成测试时，偶现共用一个全局静态 List 或数据库预置 ID，导致单个运行通过，整组运行相互影响报错。

应对策略：要求模型严格遵循 `@BeforeEach` 或独立的 `setUp` 隔离原则，每个用例都必须在干净的状态下初始化上下文。

总结行动清单

把代码覆盖率真正做扎实，核心不在于花哨的概念，而在于将模糊的指令转变为确定的逻辑约束。

今天就可以直接按照以下步骤优化你的单测流程：

1.调参：在你的开发环境或 Copilot/IDE 插件中，把代码补全和生成模型的温度降到 0.1；

2.定模版：把本文第二节的 CRBT 框架 保存为团队通用的提示词模版；

3.两步走：遇到高圈复杂度（Cyclomatic Complexity）的棘手函数，先让模型列出边界矩阵，再让它下笔写代码；

4.抓死角：拿覆盖率报告中没走通的行，进行反向靶向补全。

把单测从单纯应付流水线指标的苦差事，变成梳理业务逻辑漏洞的过程，团队的代码健壮性自然会迈上一个扎实的台阶。