回归测试反复耗时？掌握AI自动化测试脚本提示词快速生成E2E用例与断言代码

在软件迭代周期中，每次发版前的大规模回归测试往往是整个研发链条中最耗时的环节。很多团队虽然搭建了自动化测试框架，但在实际维护时却陷入两难：手动编写 Playwright 或 Cypress 脚本耗时费力，业务 UI 稍有变动就会大面积报错；而随手在聊天窗口丢给大模型一句“帮我写个登录页面的 E2E 测试”，生成的代码往往充斥着硬编码等待、脆弱的绝对 XPath 选择器，以及毫无业务约束的浅层断言，根本无法直接合并到 CI/CD 流水线。

其实，编写高可用自动化测试脚本的核心并非复杂的语法，而是如何向大模型输入精准的页面上下文、严格的定位策略以及严谨的断言逻辑。只要建立一套结构化的提示词工程规范，大模型就能在几秒钟内输出结构严密、开箱即用的端到端（E2E）用例代码。

一、 为什么常规提示词生成的 E2E 脚本总是跑不通？

日常与很多同行交流时，大家最普遍的抱怨是“大模型生成的测试脚本看着很漂亮，一跑全是红”。拆解这类失败用例后，可以归纳出三个致命问题：

1.幻觉元素定位（Hallucinated Locators）：只给大模型提业务需求（如“测试加入购物车”），却不提供真实的 DOM 结构或可访问性树（Accessibility Tree）。大模型只能凭空猜测元素名字，生成的 `page.click(‘#add-to-cart-btn’)` 在实际页面上根本不存在。

2.滥用硬编码等待（Hard Waits）：大模型极其喜欢生成 `page.waitForTimeout(5000)`。这种代码在本地偶尔能跑通，但在并发 CI 环境中不是超时报失败，就是将整个构建时间拉长数倍。

3.无效断言（Shallow Assertions）：多数生成代码仅仅断言“页面没有报错”或“URL 发生了跳转”，却忽略了网络请求状态、按钮禁用态切换、服务端返回 Toast 消息以及局部数据更新等深层业务断言。

想要让大模型稳定输出生产级测试代码，必须将软件测试工程规范转化为提示词硬性约束。

二、 核心大模型选型对比与采样参数配置

不同基础模型在代码逻辑、上下文长度和遵循约束指令的表现上各有侧重。编写自动化测试脚本时，模型的选择与参数控制直接决定代码的可用度：

必须锁定的采样参数（Inference Parameters）

在调用模型 API 或在 Web 端工作台配置生成任务时，必须将参数调到高度收敛的确定性状态：

•Temperature（采样温度）：严格设定在 0.1 至 0.2 之间。自动化测试属于精密工程任务，不需要天马行空的创意。过高的温度会导致选择器命名飘移、异步等待语法错误。

•Top-P（核采样）：建议锁定在 0.1 至 0.3。将候选词范围压缩至概率最高的一小簇，确保代码语法与断言方法的纯正性。

•Max Tokens：设置不低于 4096，防止大模型在输出包含多分支断言的长测试文件时中途截断。

三、 生产级 E2E 提示词工程架构：RTCA 框架

为了避免大模型随意发挥，我们采用专门针对测试脚本设计的 RTCA 框架（Role – Task – Context – Assertions/Constraints）：

1.Role（角色）：设定为精通 Playwright/Cypress 最佳实践的高级自动化测试工程师，要求编写符合生产环境规范的代码。

2.Context（上下文注入）：绝不喂冗余的整页无用标签，仅传入无障碍辅助树（Accessibility Tree）或带有 `data-testid` 的最小 DOM 片段，外加接口契约文档。

3.Constraints（硬性约束）：强制禁止静态等待、强制要求元素可见性先决条件、严格限定定位器优先级（`getByRole` > `getByLabel` > `getByTestId` > 严禁绝对 CSS/XPath）。

4.Assertions & Task（断言规则与目标任务）：明确区分正向核心流程、负向异常分支，并详细罗列界面层、数据层与网络层的三维断言清单。

四、 可直接复制的实战提示词模板

下面这套结构化提示词模板经过大量业务用例验证，能够直接导入 Cursor、Claude Projects 或定制 GPTs 中使用：

# Role
你是一名资深自动化测试架构师，深谙 Playwright（TypeScript）与 Web-First 断言最佳实践。

# Task
为给定的用户操作流程编写一套生产级 E2E 自动化测试用例，覆盖正向路径（Happy Path）与边界异常路径（Edge Cases）。

# Context
1. 目标功能：电商订单结算页支付流程
2. 基础配置：Playwright + TypeScript，baseURL 已在配置文件中定义为 "https://staging.mall.internal"
3. 状态前置：用户认证状态已由 global-setup 写入 "storageState.json"，当前无需通过 UI 重复执行登录
4. 真实页面 DOM/可访问性树片段：

# Constraints (严格执行)
1. 定位器策略：优先使用 getByRole、getByLabel 和 getByTestId。严禁使用脆弱的绝对 XPath（如 //div[2]/form/button）或动态生成的 CSS 类名。
2. 异步处理：严禁使用 page.waitForTimeout()！必须依托 Playwright 自带的 Auto-waiting 机制，或使用 expect(locator).toBeVisible()、page.waitForResponse() 进行网络级显式等待。
3. 用例独立性：每个 test 块必须互相独立，禁止依赖上一条测试产生的遗留数据。
4. 断言深度：必须包含三层断言：
   - 视图交互层：按钮状态转变（如加载中的 disabled 态）。
   - 网络拦截层：使用 page.waitForResponse 校验 POST /api/order/create 响应码为 200。
   - 业务结果层：页面成功跳转至 /order/success 且页面展示对应订单编号。

# Output Format
仅输出可运行的 TypeScript 测试代码文件，遵循 Page Object 模式或结构清晰的 test.describe 组织方式，无需多余闲聊。

五、 输出代码质量实测对比

输入相同的测试需求，对比随意提示与精准约束提示下的代码生成质量：

优化前（典型反面教材：随口一问生成的脚本）

// 脆弱、不可靠、充斥着隐患
import { test, expect } from '@playwright/test';

test('test order payment', async ({ page }) => {
  await page.goto('https://staging.mall.internal/checkout');
  await page.waitForTimeout(3000); // 隐患：盲目等待，拖慢执行且容易偶发超时

  // 隐患：绝对类名与脆弱选择器，前端打包哈希一变立即崩溃
  await page.click('.coupon-section > button'); 
  await page.fill('#coupon-code', 'INVALID888');
  await page.click('button[name="submit-order"]');

  // 隐患：浅层断言，仅判断页面包含某些文字，无法捕捉真实业务阻断
  await page.waitForTimeout(2000);
  const content = await page.textContent('body');
  expect(content).toContain('支付');
});

优化后（应用本工程方法生成的规范脚本）

import { test, expect } from '@playwright/test';

test.describe('订单结算结算链路回归套件', () => {
  test.beforeEach(async ({ page }) => {
    // 页面跳转并确保基础网络空闲
    await page.goto('/checkout');
    await expect(page.getByRole('form', { name: '订单结算表单' })).toBeVisible();
  });

  test('正向链路：选定收货地址并提交订单，成功进入支付结果页', async ({ page }) => {
    const submitButton = page.getByRole('button', { name: '提交订单并支付' });

    // 监听底层核心下单接口
    const orderResponsePromise = page.waitForResponse(
      response => response.url().includes('/api/order/create') && response.status() === 200
    );

    // 交互操作
    await submitButton.click();

    // 校验接口响应与界面跳转双重断言
    await orderResponsePromise;
    await expect(page).toHaveURL(//order/success/);
    await expect(page.getByRole('heading', { name: '订单提交成功' })).toBeVisible();
  });

  test('负向分支：输入非法优惠券应展示警告信息，且阻止订单提交', async ({ page }) => {
    const couponInput = page.getByLabel('优惠券代码输入框');
    const applyCouponButton = page.getByRole('button', { name: '兑换' });
    const alertMessage = page.getByRole('alert');

    // 填入非法优惠码并触发兑换
    await couponInput.fill('EXPIRED_999');
    await applyCouponButton.click();

    // 检验局部业务告警状态
    await expect(alertMessage).toBeVisible();
    await expect(alertMessage).toHaveText('优惠券已失效或不存在');

    // 验证总金额未被恶意篡改
    await expect(page.getByTestId('total-amount')).toHaveText('¥299.00');
  });
});

六、 从原型到流水线：三步落地实操 SOP

在日常团队协作中，为了将这套方法变成稳定的工程习惯，建议遵循以下标准执行流程：

第一步：精准提取 DOM 上下文（拒绝污染 Token）

不要把整个 HTML 源码全部丢给大模型。可以在 Chrome DevTools 控制台执行一行脚本，提取仅包含无障碍可访问属性和关键数据标识的轻量级 DOM：

// 控制台快速过滤核心交互树
copy(
  Array.from(document.querySelectorAll('button, input, SELECT, form, [role], [data-testid]'))
    .map(el => el.outerHTML)
    .join('n')
);

将剪贴板中清洗过的内容塞入提示词的 `Context` 区域，既节约输入成本，又能彻底消除无关样式的干扰。

第二步：驱动大模型构建“断言矩阵”

在要求编写执行脚本之前，先让模型列出用例覆盖清单：

“根据上述 DOM 结构，先列出 3 条主干路径用例与 4 条边界异常路径的测试点矩阵（含前置操作、操作步骤、预期断言），等我确认后再开始编写 TypeScript 代码。”

这一步能有效拦截大模型在业务理解上的偏差，确保写出来的每一行代码都打在关键逻辑点上。

第三步：失败用例的自动化闭环修正

当 CI 运行报错时，不要手动逐行排查。直接将 Playwright Trace 的控制台报错日志与原测试脚本原封不动反向喂给大模型：

# 任务
测试用例运行失败，请分析错误日志并修复 TypeScript 脚本。

# 错误日志
Error: Timed out 5000ms waiting for expect(locator).toBeVisible()
Locator: getByRole('heading', { name: '订单提交成功' })
Received: <element(s) not found>

# 当前测试代码
[贴入刚才生成的测试代码]

# 补充现场信息
经排查，后端返回需要经过 3 秒轮询支付网关。请将静态可见断言重构为针对支付接口轮询结束的显式响应等待。

大模型接收到具体的异常类型与真实运行时现场后，修复准确率通常超过 90%，大幅缩短测试脚本的维护耗时。

七、 避坑自查清单

在把大模型生成的测试脚本正式合并进团队主干前，务必对着这份核对表自查：

1.是否存在硬编码等待？ 全局搜索 `waitForTimeout`，一旦出现坚决替换为基于元素状态或网络响应的等待。

2.选择器是否过度耦合样式？ 检查代码中是否存在类似 `.btn-blue`、`.flex-row > div:nth-child(3)` 的选择器，若有，强制要求模型改用语义化属性重写。

3.测试数据是否自闭环？ 确保测试所需的用户信息、商品 ID 均通过 API 前置构建或具备唯一伪随机后缀，严禁直接依赖测试数据库中的已有固定数据。

4.认证状态是否复用？ 检查每个测试文件是否都在重复走一遍 UI 登录流程，如果是，果断拆分出独立的 Auth Setup 模块，通过会话状态缓存跳过无意义的重复步骤。

把提示词当做严格的工程接口来约束，把上下文当做精细的输入数据来清洗。通过这套标准流程，原本耗时两三天的回归测试脚本搭建工作，完全可以压缩到半天内高质量交付。