上篇文章聊了用 AI 写 96 个 E2E 测试用例的实战经验，写完之后我自己也在想：效率提升的关键到底是工具，还是我跟 AI 对话的方式？
今天把我日常积累的 15 个 Prompt 模板全部公开，按 6 个测试场景分类，覆盖了从需求分析到脚本维护的完整链路。
直接拿走用，不用改。
为什么需要 Prompt 库
先说一个真实感受：同样用 AI，有人 5 分钟出一个完整脚本，有人折腾半小时还在调。
差距不在工具，在于你怎么提问。
一个好的 Prompt 和一个差的 Prompt，效果天差地别：
| 提问方式 | 效果 |
|---|---|
| "帮我写个测试脚本" | AI 给一个通用模板，基本不能用 |
| "帮我测试登录功能，用 Playwright" | 好一点，但选择器全靠猜 |
| "测试 InfluxDB 数据接入，操作流程 1234，页面用 Ant Design，Playwright CommonJS 格式，优先用 waitForResponse" | 80%+ 代码直接可用 |
区别就在于：上下文、约束、格式要求。
我把这些经验固化成了模板，下次遇到类似场景，复制 → 填空 → 发给 AI，30 秒搞定一个高质量提问。
六大场景，15 个模板
场景一：从需求生成测试用例
这是测试工作的起点。以前看完 PRD 自己列用例，容易遗漏；现在让 AI 先出一版，我来审核补充。
模板 1：需求 → 用例清单
以下是功能需求描述：
[贴需求/PRD 内容]
请帮我生成测试用例，要求：
1. 按 Happy Path / 边界条件 / 异常场景 分类
2. 每个用例包含：用例名称、前置条件、操作步骤、预期结果
3. 优先级标注（P0/P1/P2）
4. 重点关注数据边界和权限校验
为什么好用：分类要求让 AI 不会只给你 Happy Path；优先级标注帮你快速筛选回归范围。
模板 2：补充遗漏场景
以下是我已有的测试用例：
[贴已有用例列表]
请站在"线上事故"视角，帮我补充：
1. 我可能遗漏的边界条件
2. 容易被忽略的异常场景
3. 并发/性能相关的测试点
不要重复已有用例，只补充新的
为什么好用："线上事故视角"这个约束很关键，让 AI 不是在补充"正确但无用"的场景，而是真正高风险的。
模板 3：接口测试用例
以下是接口文档：
[贴接口信息：URL、方法、参数、返回值]
请生成接口测试用例，覆盖：
1. 正常请求（各参数组合）
2. 参数校验（缺失、类型错误、边界值、特殊字符）
3. 权限校验（未登录、无权限、跨租户）
4. 幂等性和并发场景
每个用例给出请求示例和预期响应
场景二：生成 Playwright 脚本
这是我用得最多的场景，几乎每天都用。
模板 4：操作流程 → 脚本
我需要测试 [功能名称]，页面 URL 是 [xxx]
操作流程：
1. xxx
2. xxx
3. xxx
验证点：xxx
技术要求：
- Playwright + CommonJS 模块格式
- 页面使用 Ant Design 组件
- 需要处理异步加载（优先用 waitForResponse，避免 waitForTimeout）
- 断言用 expect + toBeVisible/toHaveText
关键技巧：最后的"技术要求"是精华。不加这段，AI 会用各种随机写法；加了之后，风格统一，质量稳定。
模板 5：表单操作
页面有一个表单，字段如下：
[列出字段名、类型、可选值]
请生成 Playwright 脚本：
1. 填写所有字段
2. 下拉框用 click + 选项定位（Ant Design Select）
3. 提交表单
4. 验证提交成功提示
5. 处理可能的异步等待
模板 6：列表/表格操作
页面有一个 Ant Design Table，需要：
1. 等待表格数据加载完成
2. 在表格中找到包含 [关键词] 的行
3. 点击该行的 [操作按钮]
4. 处理确认弹窗
5. 验证操作成功
请生成 Playwright 脚本，注意处理表格数据动态加载
场景三：选择器定位
做 UI 自动化最头疼的部分，AI 在这个环节能帮大忙。
模板 7：组件定位
页面上有一个 Ant Design 的 [组件类型，如 Select/Cascader/Modal]
我需要 [具体操作，如"选择某个选项"]
当前 DOM 结构大致是：[贴关键 DOM 片段，可选]
请给我 3 种定位策略（CSS/XPath/Role-based），并说明哪种最稳定
模板 8：动态元素
这个元素有以下特征：
- [文本内容/位置/class 名/层级关系]
- 问题：[为什么现有选择器不稳定]
请给出更稳定的定位方案，优先考虑：
1. getByRole / getByText（语义化）
2. data-testid（如果有）
3. 稳定的 CSS 选择器
4. 最后才考虑 XPath
模板 9：选择器优化
这个选择器不稳定：[贴选择器]
失败现象：[超时/定位到错误元素/偶尔找不到]
页面使用 [UI 框架名]
请分析不稳定的原因，并给出优化方案
要求：不要用 nth() 硬编码索引，不要依赖动态 class 名
场景四：调试与修复
模板 10：分析测试失败
这个测试用例报错了：
[贴完整报错信息]
测试代码是：
[贴相关代码片段，15行以内]
请分析：
1. 最可能的失败原因
2. 修复方案
3. 如何避免这类问题再次出现
关键技巧：一定要贴完整报错，不要只描述现象。"点不到按钮"和完整的 TimeoutError 信息，AI 给出的答案质量完全不同。
模板 11：修复 Flaky Test
这个测试用例偶尔失败（大约 10 次中失败 2-3 次）：
[贴代码片段]
失败时的报错：[贴报错]
成功时正常通过
请分析时序/竞态问题，给出稳定化方案
要求：不要简单加 waitForTimeout，用更可靠的等待策略
模板 12：异步加载处理
页面有一个 [列表/图表/弹窗]，数据通过接口异步加载
当前代码用 waitForTimeout(3000) 等待，但不稳定
接口信息（如果知道）：[URL 或描述]
请给出更可靠的等待策略
场景五：架构设计
模板 13：Page Object 设计
这个页面的主要功能是：[描述]
页面包含以下区域/组件：
1. xxx
2. xxx
请帮我设计 Page Object Model：
- 每个区域的关键元素定位
- 常用操作封装为方法
- 使用 Playwright CommonJS 格式
模板 14：测试数据管理
我的测试需要以下数据：[描述]
当前问题：[数据冲突/清理困难/环境依赖]
请建议测试数据管理方案：
1. 数据创建策略（每次新建 vs 固定数据）
2. 数据清理策略
3. 环境隔离方案
场景六：代码审查
模板 15：测试代码 Review
请 review 以下测试代码：
[贴代码]
重点关注：
1. 选择器稳定性
2. 等待策略是否合理
3. 断言是否充分
4. 是否有潜在的 flaky 风险
5. 代码可读性和维护性
用好 Prompt 的 5 个技巧
光有模板还不够，分享几个实战中总结的技巧：
1. 给上下文
告诉 AI 你用什么框架、什么 UI 库、什么模块格式。"用 Playwright 测试 Ant Design 页面"比"写个测试"好 10 倍。
2. 给约束
明确说不要什么。"不要用 waitForTimeout"、"不要用 nth() 硬编码"——负面约束往往比正面要求更有效。
3. 给示例
贴一小段现有代码，让 AI 保持风格一致。否则每次生成的代码风格都不一样，维护成本很高。
4. 贴完整报错
调试时一定贴完整的错误信息，不要只描述现象。AI 能从 stack trace 中提取很多你注意不到的线索。
5. 分步来
复杂需求拆成多次对话。先生成脚本 → 再优化选择器 → 再处理等待策略。一次塞太多，AI 容易顾此失彼。
什么时候该用 / 不该用 AI
最后再强调一次这个边界，避免大家过度依赖：
| 场景 | 用 AI | 自己来 |
|---|---|---|
| 生成脚本初稿 | ✅ | |
| 选择器定位策略 | ✅ | |
| 分析报错日志 | ✅ | |
| 生成用例清单 | ✅ | |
| 代码 Review | ✅ | |
| 决定测试范围和优先级 | ✅ | |
| 理解业务逻辑 | ✅ | |
| 最终稳定性验证 | ✅ | |
| 认证/权限处理 | ✅ |
Prompt 再好，也只是工具。判断力才是你的核心竞争力。
总结
| 指标 | 数据 |
|---|---|
| Prompt 模板 | 6 大场景，15 个 |
| 覆盖环节 | 需求→脚本→定位→调试→架构→审查 |
| 提问效率 | 30 秒完成一个高质量提问 |
| 脚本可用率 | 从 ~50% 提升到 80%+ |
这 15 个模板是我在实际项目中反复打磨出来的，不是拍脑袋想的。后续还会持续更新。
如果你觉得有用，建议收藏这篇文章，下次写测试的时候打开直接复制。
写在最后
很多人觉得用 AI 就是"问一下就行了"，但实际上，提问的质量决定了回答的质量。
一套好的 Prompt 库，本质上是把你的测试经验编码成了可复用的模板。AI 提供算力，你提供判断力，两者结合才是最大化效率的方式。
这是「测试进化论」的第二篇文章。下一篇聊聊怎么用 Claude Code 做一个监控配置质检工具——一条命令自动检查配置健康状况，输出带评分的诊断报告。
关注「测试进化论」—— 测试不会消失，只会进化。
