AI大模型+提示词工程：回归测试从3天压缩到3小时的实践

我做了十几年测试开发，说实话，回归测试一直是最让我头疼的环节之一。每次版本要发布，光跑一轮回归就得三天左右，测试人员一个个手工点页面，眼睛盯着屏幕看结果，人是真累，时间也是真不够。后来我花了几个周末，用 AI 大模型加一套完整的提示词体系，把回归测试的产出时间从 3 天压到了 3 小时，而且不是只跑一遍，是跑了两个多月、覆盖了 13 个版本。这篇文章我不聊虚的，直接把整个思路、提示词、执行流程和踩过的坑全部写出来。

先说适用范围。如果你是在做 Web 端业务系统的功能回归、接口回归，或者手头有一大批"流程相似但业务规则各有不同"的测试用例需要快速生成和执行，那这套东西大概率能帮到你。如果是纯硬件测试、强依赖真机和物理环境的场景，AI 能发挥的空间会小很多，这点后面会细说。

1. 项目背景与核心问题拆解

1.1 传统回归测试为什么这么慢

先拿我负责的项目举例：一个典型的中后台管理系统，涉及订单、用户、权限、财务、消息通知等 7 大模块，核心业务用例 68 条，每次发版前要全量跑一遍。以前是怎么做的呢？测试人员先看把需求文档和变更记录，再打开 Excel 里的测试用例表，一条条对着系统点。每一条用例平均要操作 7 到 15 个步骤，涉及多个页面跳转和数据校验。算下来一条用例耗时 15 到 40 分钟，一天跑 20 条已经是极限，三天能跑完还是因为中间不加班的乐观估计。

这里有个浪费在哪：大量时间是花在"理解用例"和"找测试数据"上的。用例表格里写了"输入非法邮箱时前端应提示错误"，但具体用什么邮箱格式、哪个项目的测试环境、需要先准备一个账号，这些信息都散落在不同文档里。测试人员每跑一条就得翻一遍资料，时间全耗在信息查找上。

更麻烦的是，传统步骤式执行有一个天然缺陷：用例的编写依赖人的经验，不同测试人员对同一条业务规则的理解可能完全不同。A 觉得"提示错误"就够了，B 会想着去验证提示文案的准确性，C 会再往前多走一步看错误状态下能否正常提交。这些差异导致回归质量直接取决于执行者水平，团队里一旦有人请假，用例就没人能跑。

1.2 AI 介入后我锁定的三个突破口

我最初也想过直接上自动化测试框架，搞一套 Selenium 或者 Playwright 脚本去替代人工。但评估完发现一个问题：这套系统的 UI 变化频率很高，产品几乎每两周就会调一次页面布局，脚本跟着页面走，改脚本的时间一点不比手工测试少。于是我把方向转向了"让 AI 去理解业务、生成测试方案和执行脚本"，同时保留必要的人工确认环节。

在做这个决定时，我给自己定了三个必须解决的突破口：

1. 用例转化为可执行脚本的速度要快。用 AI 生成 Playwright 脚本，至少要能把 68 条用例的脚本产出时间压到 1 天以内，否则整体效率提升没意义。

2. 测试数据要能自动构造。这是传统回归里最耗时的环节之一。我在提示词里要求 AI 优先使用"系统已有的真实业务数据"，同时支持独立构造边界数据，包括超长字符串、特殊字符、非法邮箱格式等。

3. 执行结果的分析要自动化和结构化。AI 跑完用例后，不能只丢一个"PASS/FAIL"结论，需要输出失败原因、疑似缺陷位置、建议修复人，这样测试人员只需要关注真正有问题的部分。

后来证明，这三个突破口全部有效。AI 生成脚本的速度远超预期，第一条用例的脚本从生成到跑通只用了 18 分钟，后面随着提示词模板稳定，单条用例脚本平均产出时间降到了 4 分钟。整体回归时间从 3 天压到 3 小时，主要不是靠脚本执行快（脚本执行本来就比人快），而是靠"省去了人工理解用例、找数据、查资料、写结论的时间"。

1.3 为什么不用现成测试平台

可能会有人说，市面上不是有很多无代码测试平台吗，直接把用例拖拽成自动化脚本不就行了？我用过几款，感受如下：这类平台擅长录制和回放，但面对"业务规则变化"非常乏力。比如订单模块的"优惠券叠加使用"规则调整后，录制好的脚本根本不知道规则变了，它只会机械地点击原路径，结果整个用例直接失败，你还得从头去梳理是系统 bug 还是脚本没更新。而大模型在处理这类问题时，天然具备"理解规则变化"的优势，我可以直接把变更描述丢给它，它会自动调整测试步骤和数据预期。

当然，AI 也不是万能的。后面我会说清楚哪些环节必须保留人工，哪些环节可以让 AI 全权接管。但总体来看，对于"业务流程驱动的中后台系统回归"这个场景，大模型 + 提示词工程是性价比最高的路径。

2. 提示词设计方法论

2.1 提示词不是聊天，是配置化思维

很多教程教人写提示词，开口就说"你是一个测试专家，请帮我测试下单功能"。这种话我今天检查了三个 AI 平台，没有一次生成了能直接用的东西。原因很简单：大模型本质上是一个基于上下文的概率模型，你给它的信息越模糊，它输出的内容越虚。要知道 ChatGPT 这类大语言模型在系统设计上没有接你的数据库，也没有看到你的页面长什么样，它只能依靠你提供文字信息来猜测。

我把提示词当成"配置化思维"来处理：明确输入、明确输出、明确约束。一个合格的测试提示词应当包含：

这个表格我后来提炼成了一套模板，每次开新模块测试时只改"业务上下文"部分，其他部分保持不变。这套模板的核心逻辑很简单：提示词的质量，九成取决于你对业务的理解深度，只有一成取决于模型能力。

2.2 规则型提示词和剧本型提示词的区别

我在实践过程中把提示词分成了两类，用途完全不同：

• 规则型提示词：面向数据准备、边界值分析、断言逻辑设计。例如"生成一组包含边界值和特殊字符的邮箱地址列表，用于登录模块的非法输入测试"。这类提示词输出的是规则清单，不要求模型模拟页面操作。

• 剧本型提示词：面向端到端的流程测试。例如"模拟一个用户从注册、登录、下单、支付到查询订单的完整路径，每一步给出操作步骤和预期结果"。这类提示词需要很强的上下文连贯性，模型必须记住前面步骤产生的状态。

关键区别在于，规则型提示词的输出可以直接用于数据构造和后置断言，剧本型提示词的输出需要进一步转化为可执行脚本。我在设计整体流程时，先用规则型提示词生成测试数据和边界条件，再用剧本型提示词生成端到端脚本，最后让两条线在断言逻辑处汇合。

举个例子，我测试"订单金额计算"这条用例时，先让 AI 生成一份价格边界数据：0 元、0.01 元、负数、超大金额、小数位超长。这一步用规则型提示词很快就能完成。然后用剧本型提示词让 AI 生成"从商品列表页选择商品、加入购物车、下单、查看订单详情"的完整操作路径。最后把边界数据填入脚本的断言部分，一条高质量用例就成型了。

2.3 上下文工程比堆提示词更重要

再往后做，我发现一个很关键的经验：单纯的提示词很难覆盖完整测试场景，必须配合"上下文工程"。所谓上下文工程，就是你在提示词之前先给模型喂入足够的背景信息，让它在回答问题前先"进入状态"。这跟给一个人讲背景故事是一样的道理，模型不知道你的系统长什么样，自然给不出精确的操作指令。

我的做法是建一个项目级 context 文件，内容包含：

• 测试环境的登录地址和账号信息（脱敏后放在配置文件中引用）
• 前端页面的大致布局描述（例如"订单列表页左侧有筛选栏，筛选项包括订单号、订单状态、时间范围"）
• 核心业务对象的状态流转规则（例如"订单状态从已支付流转到已发货时，必须存在物流单号"）
• 项目中遇到的常见测试约定（例如"金额字段统一用分为单位，断言精度到整数"）

这个 context 文件约 2000 字。每次启动新一轮回归测试时，我把这个文件整体粘贴进对话上下文，然后再追加本次版本的具体变更点和测试重点。实测下来，AI 在理解业务后生成的测试方案，跟直接对着一个空对话问"帮我测订单功能"的质量差距是数量级的。

不少从业者听到"提示词工程"就觉得是写几句经典魔法句子，我用了大半年后明确感受是：提示词是一方面，上下文工程才是真正的分水岭。

3. 全流程实操：3 天到 3 小时怎么落地

3.1 第一步：用 AI 分析版本变更并圈定回归范围

回归测试不是 68 条用例全跑一遍，那是"全量重测"，不是"回归"。真正的回归测试要想清楚一个核心问题：这次版本动了什么，哪些功能可能被连带影响。

以前这一步靠测试经理开评审会，以经验和记忆判断影响范围。现在我让 AI 来做初版分析。我给它输入：

• 本次版本的产品需求文档摘要
• 变更涉及的代码模块列表（从 Git 提交信息里直接拉）
• 历史缺陷记录（比如之前哪个模块经常出 bug）
• 模块间依赖关系描述

提示词大致长这样（核心逻辑公开，实际使用时替换你项目的具体描述）：

你是资深测试架构师。以下是我提供的版本变更信息、代码提交记录和模块依赖说明。 请完成三件事： 1. 列出本次变更影响的全部功能模块和核心业务用例编号； 2. 评估每个用例的回归风险等级（高/中/低），高风险用例必须具备数据关联和状态流转分析； 3. 输出一份被圈定的回归范围清单，格式为 JSON，包含用例ID、用例名称、所属模块、风险等级、影响原因。 注意：只根据我提供的变更信息分析，不要臆测未提及的功能。如果某项分析依赖系统内部数据或历史测试报告，请明确标注出缺失信息，不要生成空洞结论。

这一步输出的 JSON 大概包含 30 到 46 条待回归用例，排除了十几个明显不受影响的模块。后续测试人员只需要对这个清单做二次确认，而不是从 68 条里逐条判断。

3.2 第二步：把回归用例转化为结构化测试场景

拿到圈定范围后，下一步是让 AI 把每条用例扩展为"结构化场景描述"。这一步的关键是补齐操作路径和数据预期。

还是以订单金额计算为例。原始用例表格里只写了一句"验证订单金额计算正确"。AI 扩展后的结构化场景包含：

• 前置条件：已登录用户、商品库存充足、用户账号包含有效优惠券
• 操作步骤：搜索商品 → 选择商品加入购物车 → 进入购物车页面核对金额 → 提交订单 → 进入支付页面
• 预期结果：订单金额 = 商品单价 × 数量 − 优惠金额，运费规则按满 99 元包邮计算
• 边界条件：商品数量为 1、价格正好等于满减门槛、优惠券金额超过订单金额

这一步的提示词核心模板：

将以下测试用例扩展为结构化场景描述。要求： 1. 每个场景必须包含前置条件、操作步骤、预期结果、数据需求； 2. 预期结果必须可校验，写出具体判断逻辑，不能只写"正常"或"不报错"； 3. 如果用例涉及金额计算，必须给出计算公式； 4. 输出格式为 Markdown 表格，每行一个场景。 用例原文： [在此粘贴用例原文]

当时我用 68 条用例跑这个流程，生成的质量总体可用。大约 80% 的场景描述可以直接进入脚本生成阶段，剩下 20% 集中在"涉及特殊权限""依赖历史数据"的用例上，需要测试人员手动补充。

3.3 第三步：提示词驱动的自动化脚本批量生成

这是整个方案里最核心、也最容易被忽略的一步。很多人让 AI 写自动化脚本，失败了就觉得 AI 不行，其实大概率是前面两步没做扎实——上下文没喂够、场景描述太简陋、预期结果不可校验，脚本自然不可能写对。

当你已经有了高质量的场景描述表，再让 AI 转成 Playwright 脚本就非常顺。我给 AI 的转换提示词如下（这是完整可用的版本，替换掉 {占位符} 就能用到你的项目里）：

你是一名熟练的 Playwright 测试工程师。请根据下面的场景描述和约束生成端到端测试脚本。 项目说明： - 目标系统：{中后台管理系统} - 测试环境 URL：{测试环境地址} - 登录方式：{账号密码登录，验证码已关闭} - 关键数据前置：使用场景描述中提供的测试账号；如果账号不存在，脚本中不要写"登录失败重新申请账号"，直接标记为数据待补充并由外部脚本处理。 场景描述： {粘贴上一步生成的场景表格} 脚本要求： 1. 使用 @playwright/test 语法，结构化组织 test.describe 和 test； 2. 每个断言必须包含明确预期值，禁止只断言元素存在，必须断言内容/金额/状态文本； 3. 对于不确定的元素定位，使用>