原创内容未获授权禁止转载、转发、抄袭。上一篇讲了 AI 如何辅助需求拆解和用例设计。这一篇继续往下走怎么把测试用例变成真正能跑、能维护、能接入 CI 的自动化脚本。很多同学用 AI 生成脚本时最常见的问题是脚本看起来能跑但跑几次就不稳定本机能跑换个环境就失败页面提示成功了但数据到底对不对没人知道。所以这一篇不只讲“生成脚本”重点讲脚本怎么写得更像一个可靠的测试资产。一、AI 生成脚本只是初稿以订单提交流程为例AI 很容易生成下面这种 Playwright 脚本。import{test,expect}fromplaywright/test;test(订单提交成功 - 正常库存和有效地址,async({page}){awaitpage.goto(https://your-test-env.example.com);awaitpage.getByRole(textbox,{name:账号}).fill(test_user);awaitpage.getByRole(textbox,{name:密码}).fill(123456);awaitpage.getByRole(button,{name:登录}).click();awaitpage.getByText(测试商品).click();awaitpage.getByRole(button,{name:加入购物车}).click();awaitpage.getByRole(button,{name:去结算}).click();awaitpage.getByText(默认收货地址).click();awaitpage.getByRole(button,{name:提交订单}).click();awaitexpect(page.getByText(订单提交成功)).toBeVisible();awaitexpect(page.getByText(待支付)).toBeVisible();});这段代码作为初稿没问题但还不能直接当稳定自动化资产。它至少有几个问题问题影响测试环境写死换环境就要改代码账号密码写死不安全也不方便维护商品数据依赖页面已有数据数据变了脚本就失败只断言页面文案业务数据不一定正确没有清理测试数据多次执行可能互相影响二、把环境变量抽出来测试脚本不要写死环境地址、账号、密码。建议改成constbaseUrlprocess.env.TEST_BASE_URL;constusernameprocess.env.TEST_USERNAME;constpasswordprocess.env.TEST_PASSWORD;使用时awaitpage.goto(baseUrl);awaitpage.getByRole(textbox,{name:账号}).fill(username);awaitpage.getByRole(textbox,{name:密码}).fill(password);这样做的好处是测试环境可以随时切换敏感信息不写进代码方便接入 CI/CD多套环境可以复用同一套脚本三、准备稳定的测试数据很多自动化失败不是脚本写得差而是测试数据太乱。订单提交流程至少需要数据类型示例正常用户可登录、有默认地址异常用户禁用、未认证、权限不足正常商品有库存、可购买异常商品库存不足、下架、限购优惠券有效、过期、已使用、不满足门槛地址数据默认地址、空地址、无效地址更推荐的方式是四、断言不要只看页面提示UI 提示“提交成功”不代表业务真的成功。订单类场景至少要补三类断言断言类型示例页面断言页面出现“订单提交成功”接口断言查询订单接口返回状态为待支付数据断言库存扣减正确订单金额正确示例constresponseawaitpage.request.get(${baseUrl}/api/order/latest,{headers:{Authorization:Bearer${token}}});expect(response.status()).toBe(200);constorderawaitresponse.json();expect(order.status).toBe(WAIT_PAY);expect(order.totalAmount).toBe(99.00);expect(order.productCount).toBe(1);这样脚本才不是只测了“页面有没有提示”而是真正测到了业务结果。五、推荐的测试工程目录结构如果只写几条脚本文件随便放也能跑。但只要用例开始变多就一定要做工程化拆分。可以参考下面这种结构tests/ order/ submit-order.spec.js cancel-order.spec.js fixtures/ auth.fixture.js test-data.fixture.js pages/ login.page.js product.page.js cart.page.js order.page.js utils/ api-client.js >六、把重复动作封装起来如果每个用例都写一遍登录、搜索商品、加入购物车后面维护会很痛苦。可以先做简单封装asyncfunctionlogin(page,username,password){awaitpage.getByRole(textbox,{name:账号}).fill(username);awaitpage.getByRole(textbox,{name:密码}).fill(password);awaitpage.getByRole(button,{name:登录}).click();}asyncfunctionaddProductToCart(page,productName){awaitpage.getByText(productName).click();awaitpage.getByRole(button,{name:加入购物车}).click();}用例里就变成awaitlogin(page,username,password);awaitaddProductToCart(page,测试商品);后面页面变化时只需要改公共方法不需要到处找脚本。七、自然语言 UI 自动化适合放在哪像 Midscene.js 这类工具比较适合做两类事情。第一类是探索性测试。比如快速验证页面主要流程是否能走通。第二类是低频维护脚本。比如后台管理系统、内部工具、运营配置页这些页面变化多但测试频率没有核心交易链路那么高。示例思路import{test}fromplaywright/test;import{PlaywrightAgent}frommidscene/web/playwright;test(使用自然语言完成登录检查,async({page}){awaitpage.goto(https://your-test-env.example.com);constainewPlaywrightAgent(page);awaitai.aiAct(输入账号 test_user);awaitai.aiAct(输入密码 123456);awaitai.aiAct(点击登录按钮);awaitai.aiAssert(页面右上角出现用户头像或用户名);});不建议一上来就把支付、资金、库存扣减这类核心链路完全交给自然语言脚本。核心链路还是要有稳定的接口校验和确定性断言。八、AI 生成脚本时参考提示词你是一名资深测试开发工程师请根据下面测试用例生成 Playwright 自动化脚本。 要求 1. 使用 playwright/test 2. 优先使用 getByRole、getByText 等稳定定位方式 3. 不要使用脆弱的 XPath 4. 环境地址、账号、密码从环境变量读取 5. 登录、加购、提交订单封装成公共方法 6. 提交订单后增加接口断言 7. 输出完整代码 测试用例 粘贴测试用例内容如果生成出来的脚本不稳定可以继续追问请检查上面的 Playwright 脚本是否存在稳定性问题。 重点检查 1. 是否存在固定等待 2. 是否存在脆弱定位 3. 是否缺少断言 4. 是否依赖脏数据 5. 是否适合接入 CI九、总结这一期主要讲从用例到脚本的落地。几个关键点AI 生成的脚本只是初稿环境、账号、密码不要写死测试数据要可控最好通过接口准备UI 断言不够核心场景要补接口或数据校验测试工程要做目录拆分避免脚本越写越乱自然语言 UI 自动化适合从低频场景试点下一期继续讲自动化执行后怎么让 AI 分析失败原因并接入质量门禁。