我做了十几年测试开发说实话回归测试一直是最让我头疼的环节之一。每次版本要发布光跑一轮回归就得三天左右测试人员一个个手工点页面眼睛盯着屏幕看结果人是真累时间也是真不够。后来我花了几个周末用 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 去理解业务、生成测试方案和执行脚本同时保留必要的人工确认环节。在做这个决定时我给自己定了三个必须解决的突破口用例转化为可执行脚本的速度要快。用 AI 生成 Playwright 脚本至少要能把 68 条用例的脚本产出时间压到 1 天以内否则整体效率提升没意义。测试数据要能自动构造。这是传统回归里最耗时的环节之一。我在提示词里要求 AI 优先使用系统已有的真实业务数据同时支持独立构造边界数据包括超长字符串、特殊字符、非法邮箱格式等。执行结果的分析要自动化和结构化。AI 跑完用例后不能只丢一个PASS/FAIL结论需要输出失败原因、疑似缺陷位置、建议修复人这样测试人员只需要关注真正有问题的部分。后来证明这三个突破口全部有效。AI 生成脚本的速度远超预期第一条用例的脚本从生成到跑通只用了 18 分钟后面随着提示词模板稳定单条用例脚本平均产出时间降到了 4 分钟。整体回归时间从 3 天压到 3 小时主要不是靠脚本执行快脚本执行本来就比人快而是靠省去了人工理解用例、找数据、查资料、写结论的时间。1.3 为什么不用现成测试平台可能会有人说市面上不是有很多无代码测试平台吗直接把用例拖拽成自动化脚本不就行了我用过几款感受如下这类平台擅长录制和回放但面对业务规则变化非常乏力。比如订单模块的优惠券叠加使用规则调整后录制好的脚本根本不知道规则变了它只会机械地点击原路径结果整个用例直接失败你还得从头去梳理是系统 bug 还是脚本没更新。而大模型在处理这类问题时天然具备理解规则变化的优势我可以直接把变更描述丢给它它会自动调整测试步骤和数据预期。当然AI 也不是万能的。后面我会说清楚哪些环节必须保留人工哪些环节可以让 AI 全权接管。但总体来看对于业务流程驱动的中后台系统回归这个场景大模型 提示词工程是性价比最高的路径。2. 提示词设计方法论2.1 提示词不是聊天是配置化思维很多教程教人写提示词开口就说你是一个测试专家请帮我测试下单功能。这种话我今天检查了三个 AI 平台没有一次生成了能直接用的东西。原因很简单大模型本质上是一个基于上下文的概率模型你给它的信息越模糊它输出的内容越虚。要知道 ChatGPT 这类大语言模型在系统设计上没有接你的数据库也没有看到你的页面长什么样它只能依靠你提供文字信息来猜测。我把提示词当成配置化思维来处理明确输入、明确输出、明确约束。一个合格的测试提示词应当包含组成部分内容要求作用角色设定明确 AI 的角色、目标、背景知识限制模型输出方向业务上下文模块说明、操作流程、关键字段、预期结果让模型看见系统输入数据测试账号、测试环境 URL、基础数据特征减少模型臆测输出格式JSON/表格/脚本的具体格式让结果可直接消费边界约束什么不能做、哪些逻辑必须保留人工确认控制风险这个表格我后来提炼成了一套模板每次开新模块测试时只改业务上下文部分其他部分保持不变。这套模板的核心逻辑很简单提示词的质量九成取决于你对业务的理解深度只有一成取决于模型能力。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. 对于不确定的元素定位使用>