一、我把测试扔给了 AI
前两篇里我说过，这个项目我第一次有了完整的测试链路——用例、脚本、截图、报告，一样不缺。但这里有一个没展开的真相：
这些测试，一开始不是 AI 认真写的，是 AI 偷懒偷出来的。
项目刚开始的时候，我天真地以为：测试交给 AI 就解放了。反正它比我快，让它生成用例、写脚本、跑报告，我验收就行。
结果第一份测试报告就让我醒了。
那是一份"看起来完美"的报告：通过率 100%，所有用例全绿，格式工整。但我仔细一看，发现问题了——
- 用例只有 3 条，而规范要求 6 条
- 每条用例的步骤就一句话："打开页面，看到列表正常"
- 函数体两三行，一个字段断言都没有
- 报告里没有"发现问题"这个章节
这哪是测试，这是糊弄。但妙就妙在——它糊弄得很工整。通过率 100%，表格排版漂亮，你不逐条看，根本发现不了它在偷懒。
那一刻我明白了：AI 写测试的真正风险，不是它不会，是它会偷懒——而且偷懒的方式特别"合理"。
二、AI 是怎么偷懒的
跟 AI 打交道这段时间，我总结出它偷懒的几种典型姿势：
2.1 用例数缩水
要求一个模块 6 条用例，它给你 3 条；树形模块要求 7 条，它给 4 条。凑够"看起来测过了"，但关键的边界场景一个没有。
2.2 函数体只有两三行
测试脚本的函数要求：请求参数、预期状态码、预期响应 code、至少 1 个字段断言。AI 偷懒的时候，函数就是：
function testPageLoad() {
const res = await get('/xxx/getList');
assert(res.status === 200); // 就这？就这？
}
只检查 HTTP 200，不检查返回数据对不对、字段有没有。这种测试等于没测。
2.3 只测正常路径，不测边界
空值提交、重复编码、删除不存在的记录——这些最该测的边界，AI 全跳过了。只测"正常填数据 → 提交成功"这种阳光路径。
2.4 用"和上一个模块类似"当借口
这是最气人的一种：让它给新模块写测试，它说"这个模块和之前那个类似，不用重复写了，用例参考那个就行"。
每！个！模！块！都！要！独！立！测！ 不然改了这个模块的 bug，你根本不知道。
三、我给它画的红线
发现 AI 会偷懒之后，我干了一件事：写了一份《测试规范》，把"什么是合格的测试"钉死。核心是四条最低标准和一系列红线。
3.1 最低数量要求
| 模块类型 | 最少用例数 |
|---|---|
| 标准CRUD（表格+抽屉表单） | 6个 |
| 树形CRUD（组织/菜单等） | 7个 |
| 含子表/关联的模块 | 6个 |
| 纯查询/看板类 | 5个 |
截图也有对应数量，标准 CRUD 最少 5 张，树形 6 张。
3.2 必须覆盖的场景
- 页面加载 — 列表正常渲染、列头和数据正确
- 新增 — 打开抽屉 → 必填校验 → 填写 → 提交 → 列表刷新
- 编辑 — 数据回填正确 → 修改 → 提交
- 删除 — 确认弹窗 → 确定 → 列表刷新
- 删除校验（有外键的模块）— 有关联数据时提示错误不可删
- 状态切换 — 启用/禁用 → 列表状态更新
- 查询筛选 — 关键字搜索、下拉筛选、分页
3.3 红线（缺一不可）
- 新增用例没测"空值提交校验" → 不合格
- 编辑用例没测"数据回填正确性" → 不合格
- 有子节点的树形模块没测"删除校验" → 不合格
- 列表模块没测分页或搜索 → 不合格
- 测试脚本函数体小于 5 行 → 不合格
- 无字段断言 → 不合格
- 通过率 100% 但无边界测试覆盖 → 怀疑偷懒，要求补测
- 测试报告没有"发现问题"章节 → 不合格（全通过也要写"无问题"）
这套规范写下去之后，AI 的测试产出质量肉眼可见地上来了。因为每一条红线都是它可以执行的规则，它不用猜"这样算不算合格"。
四、定完规矩，新的坑又来了
我以为画完红线就万事大吉。结果 AI 开始"在规矩之内偷懒"——每条红线都满足，但依然出各种幺蛾子。
4.1 三向一致性：四个数字对不上
测试用例合计 13 条，测试报告概况写 12，脚本实际输出 11，执行结果表里只有 10 行。
用例数、概况数、脚本输出数、结果行数——这四个数字必须一致。 不一致 = 一定有问题，必须查根因，不能只改数字。
AI 偷懒的经典操作：报告里的数字随便填，反正没人核对。
4.2 边界测试归类混乱
边界测试（比如"删除不存在的记录"）属于 API 测试组，但 AI 会把它塞进浏览器交互组。移动之后，两个分组的标题、用例条数、统计数字全都对不上了。
4.3 报告表格断裂
报告执行结果表中间出现空行、边界测试行和上方行断开了、批量替换的时候把"### 第交互组"的标题截成了"第交互"。
这些不是技术问题，是复制粘贴和批量替换的脏活——AI 干的时候不留心，你验收的时候看着难受。
4.4 截图管理混乱
重跑脚本之后，旧截图不删，目录里躺着 8 张图报告里只引用了 5 张；截图命名重复，01-xxx.png 有两个不同内容。
报告的截图索引必须和目录里实际存在的文件一一对应。 不然验收的人对着报告找不到图。
4.5 样式测试的坑（这是前端特有的）
getComputedStyle(el).backgroundColor对渐变按钮返回rgba(0,0,0,0)——因为按钮是linear-gradient，背景色取不到，得同时查backgroundImage- 页面 body 背景是白色，但视觉上明明是深色——因为有个全屏子 div 盖住了 body，检查 body 没用，要看实际可见的容器
- 深色背景上文字显示成黑色——Element UI 默认文字色
rgba(0,0,0,0.65)没被覆盖，表格、表单这些子组件的文字色要重点查
这些都是"代码看起来对、跑起来也绿，但测的是错的"的典型。
4.6 修改顺序混乱
改了一个模块之后，正确顺序应该是：① 改测试用例 → ② 改脚本 → ③ 跑脚本 → ④ 更新报告。四者联动。
但 AI 会跳过用例直接改脚本，或者跑完脚本只改报告不改用例。最后用例和报告对不上，你根本不知道这个模块到底测了什么。
五、质量是验收出来的，不是生成出来的
把测试交给 AI 这半年，我最深的体会是：
AI 让"没人写测试"变成了"每个模块都有完整测试链路"——这是实打实的价值。 以前改代码靠人肉点，现在每个模块有用例、脚本、截图、报告，出了问题能追溯。
但"让 AI 写测试"从来不是解放，是把体力活换成了管理活。 你省下了写用例、跑脚本的时间，但多了两件事：
- 给 AI 立规矩——把"什么叫合格"用可执行的规则写死（数量、场景、红线）
- 验收 AI 的产出——四个数字对不对得上、截图全不全、是不是又在规矩边缘糊弄
AI 偷懒的姿势永远比你的规则多一步。今天你堵住"用例数缩水"，它明天就在"报告数字造假"上糊弄你。
所以别再问"能不能让 AI 自己写测试"了。能，但——
测试的质量，永远靠验收，不靠生成。 这跟代码一样：AI 负责干，你负责"干得行不行"。而"干得行不行"这件事，AI 自己永远判断不了。
下一篇预告：写文档这件最烦的事，AI 顺手替我干了
