10 AI 辅助测试

狂师2026/8/25...大约 8 分钟

10 AI 辅助测试

用 AI 提高测试效率，但不交出判断权。AI 生成候选，人负责验证和把关。

为什么重要

AI 对测试效率的改变已经真实发生：写 20 条用例从半小时变成「AI 出初稿 + 10 分钟审查」。但两个现实要认清：

只会说「帮我写测试用例」的人，拿到的是平均水平的产出，且无法判断质量。
会把任务拆细、给足上下文、带着验证清单去审查的人，效率是前者的数倍。

这一章讲的就是后者的工作方式。它不依赖任何特定工具，Claude Code、Cursor、ChatGPT、通义、DeepSeek 都适用。

知识清单

AI 辅助的正确姿势【必须掌握】

核心原则：让 AI 做候选生成和辅助审查，人做判断和把关。

把任务拆细，给足上下文（需求文档、接口定义、代码、日志原文），明确输出格式和约束，最后用清单验证。一个提示词的四个组成部分：

角色与目标：你是测试工程师，要产出什么。
上下文：需求 / 接口文档 / 代码原文直接贴上，不要让 AI 猜。
输出要求：格式、分类维度、每条的必填字段。
约束：不许编造、不确定的要标注、区分正常 / 异常路径。

提示词模板库【必须掌握】

四个高频场景的模板，直接可用：

模板一：测试点生成

请根据下面的需求说明，输出测试点。
要求：
1. 按功能、接口、权限、安全、兼容性、性能、异常场景分类；
2. 每个测试点写出前置条件、操作步骤、预期结果；
3. 单独列出你不确定、需要产品确认的点；
4. 不要编造需求里没有出现的业务规则。

需求说明：
<贴需求原文>

模板二：接口自动化脚本生成

请根据这份 OpenAPI 文档生成 pytest 接口测试用例初稿。
要求：
1. 区分正常路径和异常路径；
2. 每个用例都要有明确断言；
3. 不要只断言 HTTP 200，业务字段和数据库校验位置用注释标出；
4. 标出需要人工补充测试数据的地方；
5. 使用项目现有结构：请求封装在 client.py，conftest 提供 token fixture。

接口文档：
<贴 OpenAPI/Swagger JSON>

模板三：失败日志分析

请分析下面这次 CI 失败日志。
要求：
1. 先判断失败发生在环境、测试数据、断言、接口还是业务代码；
2. 给出最可能的 3 个原因，按可能性排序；
3. 给出下一步排查命令或需要查看的日志；
4. 不要直接下结论，缺证据的地方标注「不确定」。

日志原文：
<贴日志>

模板四：测试代码审查

请以测试架构师身份审查下面这份自动化代码。
检查项：
1. 是否有硬编码的环境地址、账号、魔法值；
2. 用例之间是否互相依赖；
3. 断言是否太弱（只断言 200 / 只断言非空）；
4. 失败重试是否可能掩盖真实问题；
5. 数据清理是否完整；
按严重程度输出问题清单和修改建议。

代码：
<贴代码>

这类 Prompt 的价值在于让 AI 把候选空间列出来。真正的判断仍然来自日志、数据、代码和业务规则。

AI 编程工具写测试的工作流【必须掌握】

用 Claude Code / Cursor 这类 AI 编程工具做测试开发时，推荐的工作流：

先立规矩再开工：把项目规范写进 CLAUDE.md / .cursorrules（目录结构、命名、断言要求、禁止 sleep 等），AI 生成的代码才会符合工程规范而不是一次性脚本。
小步快跑：一次让它做一个用例模块或一个页面对象，不要「把整个系统自动化了」。生成一段、review 一段、跑一段。
让 AI 先读后写：先让它读你现有的框架代码和 conftest，再基于现有模式写新用例，保持一致性。
AI 写测试，谁来测 AI：AI 生成的测试代码也要被验证——故意改坏一个断言、造一个错误响应，确认用例真的会红。测试代码本身不可信，测试就是假的。

AI 代码审查与质量左移【了解即可】

更进一步，可以把 AI 固化为流水线里的一环：PR 提交时自动让 AI 按模板四审查，输出评论。这在 GitHub Actions 生态已有成熟方案（搜 "AI code review action"）。价值在于把人从「逐行看 diff」升级为「确认 AI 标记的风险点」。

MCP 与 Skill 工具生态【了解即可】

MCP（Model Context Protocol）：让 AI 调用外部工具的协议标准。测试领域的想象空间：AI 直接调你的测试平台 API 触发执行、读 Allure 结果、查数据库造数。2026 年主流 AI 编程工具都已支持，值得关注但不必焦虑。
Skill（技能包）：把反复打磨的提示词、工作流程和配套资产（脚本模板、检查清单、规范文档）打包成 AI 随时可调用的能力单元。「接口用例生成」「失败日志诊断」「测试报告生成」这类高频流程，沉淀成 Skill 后一次封装、团队复用，新人拿到手的就是你踩完坑之后的最佳版本。
一句话区分：MCP 给 AI 接上手（能调用什么工具），Skill 给 AI 传承经验（按什么套路干活）。测试团队的资产沉淀方式，正在从「内部 wiki + 口口相传」转向「提示词库 + Skill 库」。

AI 输出的验证纪律【必须掌握】

不管 AI 多强，三条纪律不能破：

AI 生成的用例必须对照六维框架审（功能流程 / 数据边界 / 权限安全 / 兼容性 / 性能稳定 / 可观测性，见第 05 章）。它经常漏风控、频率限制、账号锁定、Token 续期、并发登录这类「业务深水区」。
AI 生成的断言必须人工确认有效：跑一遍「故意破坏测试」（改坏数据、mock 错误响应），断言会红的才是真断言。
AI 给的结论必须有证据链：日志分析说「数据库超时」，要能指出日志里哪一行支持的。标注「不确定」的地方就是你要去补证据的地方。

学习建议与常见误区

每天用一个真实任务练：本周写的用例初稿、这周的一次失败日志、上个月的一段烂脚本，都可以套模板跑一遍。一个月后你对「AI 能干什么、经常错什么」会有体感。
建立自己的提示词库：把有效的模板存下来（本仓库也欢迎贡献），按场景组织。提示词是测开的新工具箱，沉淀多了就封装成 Skill（见 MCP 与 Skill 工具生态），从「自己用」升级为「团队用」。
误区一：AI 生成的用例直接入库。 没审过的用例 = 没测过的功能。AI 用例的正确路径是「AI 初稿 → 人工审查补漏 → 评审入库」。
误区二：让 AI 一把梭整个框架。 生成的框架看起来完整，跑不起来或风格混乱。框架骨架自己搭，填充类工作交给 AI。
误区三：把 AI 当答案机而不是候选机。 「AI 说接口失败是环境问题」——它可能对，但你要它给出日志证据，否则就是用一个新的不可靠判断替换了自己的判断。
误区四：敏感数据直接贴给外部 AI。 生产日志、真实账号、内部接口文档进外部服务前先脱敏，这是纪律问题。

自查清单

一个合格的测试提示词有哪四个组成部分？
用模板一生成登录页测试点，找出 AI 遗漏的至少 5 个点（提示：风控、锁定、Token、并发登录、审计）。
怎么验证 AI 生成的断言是有效的？（破坏性测试法）
AI 编程工具写测试时，为什么要把规范写进 CLAUDE.md / .cursorrules？
AI 日志分析给出结论后，你的下一步动作是什么？
哪些数据不能直接贴给外部 AI 服务？脱敏的基本做法？
MCP 和 Skill 分别解决什么问题？把你团队的一个高频测试流程设计成 Skill，你会往里放哪些内容？