你有没有想过:写测试比写功能还累,能不能让 AI 先帮你把测试草稿一口气写完,你只负责审?2026 年,AI 已经能根据函数、模块甚至一句话需求,生成单元测试、集成测试乃至端到端(E2E)测试。本教程教你把 AI 当「测试搭档」,既提速又不养出「假绿」的测试。
🧪 本教程适合:想补测试但不想从零手写的开发者。你会用 Cursor / Claude / ChatGPT 等任意能读代码的 AI,以及 pytest 之类的测试框架。
先搞懂:AI 写测试,到底写什么?
用一句话理解:测试就是「给代码出题,验证它答得对」。AI 擅长把你的函数拆成各种边界情况,自动出题。三类最常见:
| 类型 | 测什么 | 工具举例 |
|---|---|---|
| 单元测试 | 单一函数 / 类的行为 | pytest、unittest |
| 集成测试 | 多个模块协同 | pytest + 测试库 |
| 端到端 E2E | 真实用户操作流程 | Playwright、Selenium |
AI 先写,你来审:让 AI 直接跑测试或改生产代码风险高。正确姿势是「AI 起草 → 你读一遍 → 再运行」。
Step 1:给 AI 足够的上下文
1 别只丢一句「帮我写测试」
AI 生成测试的质量,取决于你给的上下文。至少给三样:被测代码、使用的框架、你关心的边界。
提示词示例:
「这是我的函数(贴代码)。请用 pytest 写单元测试,
覆盖:正常输入、负值、0、空值、超大数。
用 assert 表达预期,不要引入额外依赖。」
💡 在 Cursor / Claude Code 这类能读工程的工具里,直接框选文件说「给这个函数写测试」,它会自动带上上下文,最省事。
Step 2:审测试,重点看「是不是在真测」
2 提防「假绿测试」
AI 有时会写出「永远通过」的测试——比如把期望值直接写成函数返回值,或者用例太弱没覆盖分支。你重点查三处:
· 有没有 assert 真正的预期结果(而非 `assert result is not None` 了事)
· 边界值是否齐了(负、零、空、极大)
· Mock(桩)是否过度,导致根本没测到真实逻辑
「全绿」不等于「测好了」:故意改错一行源码,看测试会不会变红。会变红,才是真在测。
Step 3:跑起来,看覆盖率
3 用工具量化「测了多少」
写好测试就运行,并用覆盖率工具看看漏了哪些行:
# 运行测试
pytest tests/ -q
# 看覆盖率(需装 pytest-cov)
pytest tests/ --cov=src --cov-report=term-missing
🚀 覆盖率高不代表质量高,但覆盖率低一定有大片没测到。先追求「关键路径 80%+」,再逐步补。
Step 4:让 AI 写 E2E,验证「真能跑通」
4 从「单元」走到「用户视角」
单元测试保证零件好,E2E 保证整车能开。让 AI 基于你的页面结构生成 Playwright 脚本:
# 让 AI 生成类似这样的脚本
from playwright.sync_api import sync_playwright
def test_login_flow():
with sync_playwright() as p:
b = p.chromium.launch()
page = b.new_page()
page.goto("https://example.com/login")
page.fill("#user", "test")
page.fill("#pass", "123456")
page.click("#submit")
assert page.locator(".welcome").is_visible()
b.close()
E2E 慢且易碎:界面一改就可能红。把它留给「核心流程」(登录、下单、支付),别什么都自动化。
Step 5:把测试固化进开发习惯
5 提交前跑一遍,省下日后返工
测试的价值在「每次改动都自动验一遍」。两个落地动作:
| 动作 | 收益 |
|---|---|
| 提交前本地跑 pytest | 把 Bug 拦在出门前 |
| 接入 CI 自动跑 | 每次合并都验证,团队不踩彼此的坑 |
🔑 铁律:AI 生成的测试要先读懂再入库。看不懂的测试,留着也是隐患。
常见问题速查
| 现象 | 原因 & 解决 |
|---|---|
| 测试全绿但 Bug 还在 | 用例太弱 / 被 Mock 架空,补边界与断言 |
| AI 写的测试跑不通 | 环境 / 依赖没说清,把报错贴回给 AI 修 |
| E2E 经常随机失败 | 加了隐式等待 / 选择器太脆,改用稳定定位 |