我用AI把回归测试从3天压到3小时，提示词全公开

去年双十一大促前，我们发了一个版本。回归测试跑了整整三天。

第三天凌晨两点，办公室里只剩我和另一个同事，对着CI上一片红，谁都不想说话。不是没测完，是测完了不敢信——失败列表里一半是环境问题，一半是脚本挂了，还有几个是真正的bug。要一条条筛，一条条确认，一条条提单。

那段时间我一直在想：回归测试这件事，到底卡在哪？

后来我想明白了。卡的不是执行，执行有自动化。卡的是前面写用例、中间维护脚本、后面分析失败。这三块全是人肉堆出来的。而人肉，就会慢，就会错，就会累。

再后来，我开始把AI拉进这个流程。不是当许愿池，是当实习生。你给它清晰的指令，它给你能用的草稿，你来审核和修正。

效果是：同样一个版本的回归测试，从3天压到了3小时。

先说清楚，不是AI一键跑完，也不是完全无人值守。3小时里包含了人工审核、修复和确认。但相比之前，已经是另一个世界了。

下面我把整个流程拆开，每个环节用的提示词全部公开。你直接复制就能用，但记得把里面的项目信息换成你自己的。

一、以前为什么慢？

我们之前的回归流程大概是这样：

需求评审完，测试同学根据PRD和过往经验，手工写用例。一个中等版本，新增+修改的用例大概80到120条。写用例本身就要大半天。

然后是把新用例转成自动化脚本。Playwright也好，Selenium也好，写脚本、调定位器、调等待，又一天。

跑起来之后，失败分析最要命。CI上几十条失败，你得挨个看日志、看截图、看视频，判断是产品bug、脚本问题、环境问题还是数据问题。有时候一条失败查半小时，查到最后发现是测试账号被锁了。

最后写报告，汇总数据，给上线建议。又是小半天。

三天，就这么没了。

我们试过加机器、并行跑、只跑核心用例。有用，但治标不治本。因为写用例、维护脚本、分析失败这三件事，还是靠人。

二、转折：把AI当实习生，而不是许愿池

我一开始也试过让AI“帮我写回归测试用例”。结果它给我吐了一堆看起来很像、但根本跑不通的东西。接口名是编的，字段是猜的，业务规则是它自己想象的。

后来我换了个思路。

我不再让它“写用例”，而是让它做具体环节里的具体事。比如：根据代码变更分析影响面，根据影响面推荐回归范围，根据手工用例转脚本，根据失败日志给根因排序。

而且我给它喂上下文。不是只丢一句“帮我写用例”，而是把接口文档、数据库表结构、历史bug列表、项目目录结构一起给它。它不知道业务，我就告诉它业务。

这个思路转变之后，效率完全不一样了。

三、具体怎么做：五个环节，五个提示词

环节1：影响面分析——别上来就写用例

以前我们写回归用例，靠的是“感觉这次改了啥”。但代码变更那么多，靠人看PR根本看不过来。

现在我会先把这次发版的PR列表、commit记录、变更文件路径拉出来，整理成一段摘要，丢给AI做影响面分析。

提示词如下：

你是一个资深测试架构师，有10年电商业务测试经验。

以下是一次发版的代码变更摘要：
[粘贴PR标题、commit message、变更文件路径、关键diff片段]

请分析：
1. 这次变更可能影响哪些业务模块、接口、页面？
2. 每个影响点按优先级分类：P0（必须回归）、P1（建议回归）、P2（可选回归）。
3. 给出判断理由。
4. 推荐需要重点回归的测试点类型（正常流、异常流、边界值、权限、兼容性等）。

输出格式：
模块 | 影响点 | 优先级 | 理由 | 建议回归类型

注意：
- 如果信息不足，请列出你需要我补充的信息，不要编造。
- 不要输出具体的测试用例，只做影响面分析。

这个提示词的关键是最后那句“不要编造”。一开始我没加，它就会自己脑补出根本不存在的接口。加了之后，它会老老实实说“我需要知道这个接口的入参和出参定义”。

拿到影响面分析之后，回归范围就从“全量”变成了“P0+P1”。我们统计过，通常能砍掉60%到70%的无关用例。

环节2：用例生成——喂上下文，别让它瞎猜

影响面确定之后，接下来是生成或补充测试用例。

这里我吃过亏。如果你只给一句“根据以下需求生成测试用例”，AI会给你一堆正确的废话。什么“验证登录成功”、“验证登录失败”，你看了想打人。

提示词如下：

你是一个有8年经验的测试工程师，熟悉电商交易链路。

背景信息：
- 项目名称：[项目名]
- 本次变更内容：[粘贴影响面分析结果]
- 相关接口文档：[粘贴接口定义]
- 数据库表结构：[粘贴关键表结构]
- 历史高频bug：[粘贴近3个月相关模块的bug列表]
- 已有用例库：[粘贴已有用例标题，避免重复]

请生成回归测试用例，要求：
1. 覆盖正常流、异常流、边界值、权限、数据一致性。
2. 每条用例包含：用例标题、前置条件、操作步骤、预期结果、优先级。
3. 优先覆盖历史bug对应的场景。
4. 不要生成与已有用例重复的用例。
5. 如果某个场景需要具体数据但信息不足，标注“需补充数据”，不要编造。

输出格式：Markdown表格。

这个提示词里，“历史高频bug”是最有价值的部分。AI会根据历史bug反推测试场景，这比凭空想要准得多。

生成之后，我会人工过一遍，删掉重复的、不合理的，补充它没想到的。大概能省掉70%的写用例时间。

环节3：脚本转换——手工用例到Playwright

用例有了，接下来是转自动化脚本。

以前这一步最烦。手工用例写的是“点击登录按钮”，脚本里要写定位器、等待、断言。一条用例转成脚本，熟练工也要十分钟。

现在我把手工用例和项目现有的Page Object代码一起丢给AI。

提示词如下：

你是一个Playwright自动化专家，熟悉TypeScript和Page Object模式。

以下是我们项目的Page Object代码结构：
[粘贴Page Object类名和方法名]

以下是一条手工测试用例：
[粘贴用例内容]

请把它转成Playwright测试脚本，要求：
1. 使用TypeScript。
2. 使用Page Object模式，调用已有方法。
3. 定位器优先使用getByRole、getByLabel、getByTestId，不要用XPath。
4. 使用expect断言，不要用console.log。
5. 如果用例中提到的元素在Page Object中不存在，列出需要新增的方法，不要直接写定位器。
6. 如果信息不足，列出需要补充的信息。

输出格式：完整的测试文件代码。

关键点：不要让它直接写定位器。让它调用Page Object。这样脚本的维护成本会低很多。如果Page Object里没有对应方法，它会告诉你需要新增什么，而不是瞎编一个选择器。

转出来的脚本，我大概改10%到20%就能跑。比以前快太多了。

环节4：失败分析——Trace和日志丢给AI

这是我最喜欢的环节，也是省时间最多的环节。

以前失败分析靠人看日志，一条条翻。现在我把Playwright的失败日志、Trace摘要、网络请求记录、控制台错误一起整理成一段文本，丢给AI。

提示词如下：

你是一个测试排障专家，熟悉Playwright和前端后端联调。

以下是测试失败信息：
- 测试用例名称：[用例名]
- 失败步骤：[第几步失败]
- 错误日志：[粘贴错误堆栈]
- Trace摘要：[粘贴关键操作和网络请求]
- 控制台日志：[粘贴浏览器console错误]
- 环境信息：[CI/本地、浏览器版本、测试账号]

请分析：
1. 最可能的根因是什么？按可能性从高到低排序。
2. 每条根因给出证据。
3. 判断问题类型：产品bug、脚本问题、环境问题、数据问题。
4. 给出修复建议。
5. 如果无法判断，列出需要进一步排查的方向。

输出格式：
根因 | 可能性 | 证据 | 问题类型 | 修复建议

注意：不要直接下结论说“一定是产品bug”，要给出判断依据。

这个提示词最实用的地方是“问题类型”分类。以前我们最怕的就是把脚本问题当成产品bug提给开发，开发一看不是，打回来，来回扯皮。现在AI先分个类，人工再确认，扯皮少了很多。

我们统计过，失败分析的时间从平均每条20分钟降到了5分钟左右。

环节5：报告汇总——让AI写第一版

最后是测试报告。

以前写报告，要汇总通过率、失败列表、风险点、上线建议。数据是有的，但组织成文字要花时间。

提示词如下：

你是一个测试经理，需要向上级汇报回归测试结果。

测试数据：
- 总用例数：[数字]
- 通过：[数字]
- 失败：[数字]
- 跳过：[数字]
- 失败用例列表：[粘贴失败用例及分析结果]
- 本次回归范围：[粘贴影响面分析]
- 已知风险：[粘贴未修复问题]

请生成一份回归测试报告，包括：
1. 测试范围概述。
2. 执行结果统计。
3. 失败分析摘要（按问题类型分组）。
4. 风险提示（哪些问题可能影响上线）。
5. 上线建议（可以上线/有条件上线/不建议上线）。

要求：语言简洁，面向开发和产品，不要堆砌形容词。

AI写的报告，我改一改就能发。省了至少半小时。

四、效果对比

我们拿最近一个中等版本做了对比：

注意，这里面已经包含了人工审核和修正的时间。AI不是替代人，是让人从重复劳动里抽出来，专注在判断和决策上。

稳定性方面，因为回归范围更精准了，跑的全是相关用例，误报也少了很多。以前全量跑三天，很多失败是无关用例的环境问题。现在只跑P0+P1，失败列表干净多了。

五、踩过的坑

坑1：上下文给太少。 一开始我只丢一句“帮我写用例”，结果全是废话。后来我把接口文档、表结构、历史bug都喂进去，质量立刻上来了。AI不知道你的业务，你得告诉它。

坑2：没有约束“不要编造”。 AI会一本正经地编接口名、编字段、编业务规则。后来我在每个提示词里都加了“如果信息不足，列出需要补充的信息，不要编造”。这个约束非常关键。

坑3：一次让AI做太多。 我试过让AI“分析影响面并生成用例并转成脚本”，结果它哪一步都做得不精。后来拆成五个环节，每个环节单独给提示词，效果好得多。

坑4：不审核直接用。 AI生成的用例和脚本，一定有人工审核。它不是100%准确，但能帮你完成80%的草稿。剩下20%，才是你的价值所在。

坑5：提示词不迭代。 我现在的提示词是改了十几版之后的。每次发现AI输出不对，我就回去改提示词。建议你建一个自己的提示词库，用Git管理起来，慢慢迭代。

六、最后说两句

从3天到3小时，核心不是AI有多神，而是把回归测试拆成了AI能帮上忙的环节。

以前我们总想着“AI能不能自动测”，结果发现不行。但如果你换个思路，让AI做影响面分析、做用例草稿、做脚本转换、做失败初筛、做报告初稿，你会发现它每个环节都能帮上忙。

提示词我都放在上面了。你可以直接拿去用，但更重要的是理解这个思路：AI是实习生，不是许愿池。你给它清晰的指令和足够的上下文，它才能给你能用的结果。

如果你也在跟回归测试的周期较劲，不妨从影响面分析那一步开始试。就那一步，就能帮你省掉半天。

去用，别只收藏。