对负责功能测试、接口测试和回归测试的 QA来说，需求变化快，测试用例、缺陷报告和测试报告要反复写，边界场景还容易漏。单元测试大家都知道重要，但写起来枯燥，边界条件也容易想不全。这篇文章用一个完整的例子演示测试工程师如何借助 AI 生成单元测试：把函数代码和业务规则交给 AI，先让它列出测试场景清单，确认后再生成测试代码并运行。

使用场景

测试工程师写了一个处理“缺陷记录”数据的函数，比如按模块汇总修复耗时小时。上线前需要补测试，但时间紧，而且担心漏掉空数据、异常值这类边界情况。

推荐工具

编辑器内的编程助手（GitHub Copilot、Cursor、通义灵码、CodeGeeX 等）可以直接根据函数生成测试；也可以把代码贴给对话助手。

让 AI 生成测试后，一定要在本地运行，并检查断言是否真的验证了业务规则。

一个虚构的例子

下面这个例子是虚构的：阿美遇到的难题是“提测时间延后两天，回归时间被压缩”。为了不让它拖慢“补充登录模块的接口自动化用例”的进度，阿美决定借助 AI 生成单元测试。第一次只写了一句简单的要求，结果很空泛；第二次把对象（项目经理）、目的和限制条件都写清楚，输出就可用多了。这也是本文提示词模板要把背景写全的原因。

分步操作

  1. 提供被测函数代码和业务规则说明
  2. 让 AI 先列出测试场景：正常、边界、异常
  3. 确认场景清单，补充业务特有的情况
  4. 生成测试代码并在本地运行
  5. 检查失败的用例是代码问题还是测试问题

可复用的提示词

把方括号和括号里的内容换成你自己的信息即可：

【背景】身份：负责功能测试、接口测试和回归测试的 QA；平时主要和开发同事和项目经理打交道。
请为下面的 Python 函数编写 pytest 单元测试。

业务规则：按 category 汇总 amount；amount 为空的记录跳过；amount 为负数时抛出 ValueError。

```python
def summarize(records):
    result = {}
    for r in records:
        if r.get("amount") is None:
            continue
        if r["amount"] < 0:
            raise ValueError("amount must be non-negative")
        result[r["category"]] = result.get(r["category"], 0) + r["amount"]
    return result

要求：

  1. 先列出测试场景清单（正常、边界、异常）
  2. 再写测试代码，使用 parametrize 减少重复
  3. 每个测试函数名能看出测试意图

## 示例输出（仅供示意）

下面是演示用的输出示例，其中的人名、数字和事项均为虚构，实际使用时请以你自己的资料为准：

> **测试场景**
> 1. 正常：多条记录、多个分组
> 2. 边界：空列表；amount 为 0；amount 为 None
> 3. 异常：amount 为负数
>
> ```python
> import pytest
> from summary import summarize
>
> def test_groups_and_sums_amount():
>     data = [{"category": "登录", "amount": 10}, {"category": "登录", "amount": 5},
>             {"category": "支付", "amount": 3}]
>     assert summarize(data) == {"登录": 15, "支付": 3}
>
> @pytest.mark.parametrize("data,expected", [
>     ([], {}),
>     ([{"category": "登录", "amount": 0}], {"登录": 0}),
>     ([{"category": "登录", "amount": None}], {}),
> ])
> def test_boundary_cases(data, expected):
>     assert summarize(data) == expected
>
> def test_negative_amount_raises():
>     with pytest.raises(ValueError):
>         summarize([{"category": "登录", "amount": -1}])
> ```

拿到类似的结果后，阿美的做法是先核对事实和数字，再结合“执行支付链路回归测试”的安排调整重点，最后才对外使用。

## 实用技巧与常见坑

- 测试数据用虚构值，不要使用真实的测试账号密码、生产数据和未公开的版本信息。
- 生成的测试也要纳入代码评审。

### 给测试工程师的特别提醒

让 AI 补充“容易被忽略的场景”，再由你按业务判断取舍。还有一点很关键：AI 列出的用例只是候选清单，覆盖是否充分仍要结合需求和历史缺陷人工把关。

很多测试工程师还会这样做：把需求文档原文给 AI，让它按等价类、边界值、异常流分别列用例。

## 还可以这样用

- 补全覆盖率：把覆盖率报告中未覆盖的代码交给 AI，补充测试。
- 测试数据工厂：让 AI 写构造测试数据的辅助函数。

## 相关阅读

- [测试工程师用 AI 写技术文档：从代码生成接口文档和说明](/posts/2026-10-16-qa-engineer-tech-doc/)
- [测试工程师用 AI 写 SOP 流程文档：把经验变成可执行的标准流程](/posts/2026-10-16-qa-engineer-sop-writing/)
- [运维工程师用 AI 生成单元测试：覆盖边界条件的测试用例](/posts/2026-10-16-devops-engineer-unit-test/)
- 延伸：[AI 生成单元测试：提高覆盖率而不制造“假安全感”](/posts/2026-07-27-ai-unit-test-generation/)
- 更多场景：[AI 使用示例合集](/categories/ai-examples/)，或按标签浏览[#测试工程师](/tags/测试工程师/)、[#单元测试](/tags/单元测试/)