负责服务器、发布流水线、监控告警和故障处理的运维或 SRE，日常工作里告警多、脚本杂、变更文档和故障复盘写起来费时，夜间排障时更需要快速理清思路。单元测试大家都知道重要，但写起来枯燥，边界条件也容易想不全。下面以运维工程师的真实场景为例，演示用 AI 生成单元测试的完整流程：把函数代码和业务规则交给 AI，先让它列出测试场景清单，确认后再生成测试代码并运行。

使用场景

运维工程师写了一个处理“告警记录”数据的函数，比如按主机组汇总持续分钟。上线前需要补测试，但时间紧，而且担心漏掉空数据、异常值这类边界情况。现实中，运维工程师还得兼顾“更新 Nginx 配置模板”等日常事务，所以更需要一套拿来就能用的方法。

工具选择

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

一个虚构的例子

先看一个虚构但很典型的例子。小吴是一位负责服务器、发布流水线、监控告警和故障处理的运维或 SRE，这周手头的事情包括“处理 2 起磁盘告警和 1 起证书过期隐患”和“清理无主的云资源”，偏偏这时又需要生成单元测试。小吴没有从空白页开始，而是先花几分钟把相关材料整理好，按下面的提示词交给 AI，拿到初稿后对照原始资料逐条核对，再补上自己的判断。整个过程中，小吴特别留意不把服务器 IP、账号口令、证书私钥和内部拓扑放进对话里。

操作步骤

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

可复用的提示词

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

【背景】当前的难点是：机房网络计划维护，可能影响夜间批处理任务。
请为下面的 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. 每个测试函数名能看出测试意图

## AI 输出示例（示意）

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

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

拿到类似的结果后，小吴的做法是先核对事实和数字，再结合“清理无主的云资源”的安排调整重点，最后才对外使用。

## 避坑指南

- AI 有时会根据代码的现有行为写断言，如果代码本身有 bug，测试也会“通过”。
- 先确认场景清单再生成代码，比直接要测试代码更可靠。
- 生成的测试也要纳入代码评审。

### 给运维工程师的特别提醒

让 AI 写的命令先在测试环境执行，并要求它说明每个参数的作用。还有一点很关键：涉及删除、重启、改权限的命令，必须先确认影响范围并做好回滚准备，不能照抄执行。

## 举一反三

- 补全覆盖率：把覆盖率报告中未覆盖的代码交给 AI，补充测试。
- 接口测试：根据接口文档生成请求用例和断言。

## 相关阅读

- [运维工程师用 AI 写技术文档：提示词与文档示例](/posts/2026-10-16-devops-engineer-tech-doc/)
- [运维工程师用 AI 写 SOP 流程文档：把经验变成可执行的标准流程](/posts/2026-10-16-devops-engineer-sop-writing/)
- [数据分析师用 AI 生成单元测试：提示词与 pytest 示例](/posts/2026-10-16-data-analyst-unit-test/)
- 延伸：[编码 Agent 工作流：从需求拆解到合并请求的人机协作模式](/posts/2026-07-18-coding-agent-workflow/)
- 更多场景：[AI 使用示例合集](/categories/ai-examples/)，或按标签浏览[#运维工程师](/tags/运维工程师/)、[#单元测试](/tags/单元测试/)