AI测试落地实战：4个场景案例详解（干货）

想象一下，你是一个测试工程师，每天面对这些场景：

产品经理在群里说“按钮换个样式，更圆润一些”，你心里咯噔一下：昨天刚跑通的50个脚本，今天又得熬夜改定位器了。这已经是本月第三次因为UI微调而批量修改脚本了。

测试一个“满100减20”的优惠券功能，需要准备10种不同金额的订单、5种优惠券类型、3种用户等级。手动造数据要半天，写SQL更是心累，数据之间的关联关系经常搞错。

凌晨CI跑挂了，报告只有一行“期望页面显示‘支付成功’，实际显示‘系统繁忙’”。你翻日志、查截图、问开发，折腾2小时才发现是测试环境的支付网关配置过期了，而测试脚本根本不会告诉你这个。

这些烦恼，本质上是因为传统自动化测试缺乏理解能力——它只会机械执行指令，无法理解页面变化背后的语义，无法构造复杂业务场景的数据，无法从错误中推理根因。

AI大模型（如GPT-4、Claude）就像是一个“懂测试的实习生”——它读过海量代码和文档，能理解自然语言，还能进行一定程度的推理。以下是它在测试领域的实际能力：

关键认知：AI不是来取代测试工程师的，而是来“干掉”那些重复、繁琐、低价值的工作，让我们把时间花在探索性测试、场景设计、质量策略上。未来测试工程师的核心竞争力，将是“懂业务 + 会编程 + 善用AI”。

痛点：人工写用例，费时又容易遗漏

一份10页的PRD，测试人员需要逐字阅读，提炼测试点，还要自己脑补边界情况。复杂模块（如优惠券、支付）往往需要2-3小时才能写出一份像样的用例清单，而且容易遗漏一些边界组合（比如“满减券+折扣券同时存在”这种场景）。

解决方案：AI读需求，人审质量

图1：AI智能用例生成流程

就像让一位资深测试阅读需求后写出用例草稿，AI负责“初稿”，人工负责“把关”。人工审核时发现遗漏的场景，可以反馈给AI，让它下次生成时更全面。经过2-3轮迭代，AI就能很好地掌握业务风格。

实操案例：优惠券功能

需求原文（电商优惠券功能，来自PRD）：

用户下单后可使用优惠券，优惠券分为满减券（满100减20）和折扣券（85折）。系统自动选择最优优惠，不可叠加使用。订单金额小于门槛时不可使用。优惠券有有效期，过期不可用。

AI生成的测试用例（GPT-4输出，经过格式整理）：

# 正常场景
场景:满减券满足门槛
假设订单金额为150元
并且用户有一张满100减20的满减券
当用户使用优惠券
那么订单金额变为130元

# 边界场景
场景:订单金额等于优惠门槛
假设订单金额为100元
并且用户有一张满100减20的满减券
当用户使用优惠券
那么订单金额变为80元

场景:订单金额刚好低于门槛
假设订单金额为99.99元
并且用户有一张满100减20的满减券
当用户使用优惠券
那么提示“不满足使用条件”

# 最优选择场景
场景:折扣券与满减券同时存在
假设订单金额为200元
并且用户有满减券(减20)和折扣券(85折)
当系统自动选择优惠
那么系统选择折扣券，订单金额变为170元

# 时间相关场景
场景:优惠券已过期
假设订单金额为150元
并且用户有一张满100减20的满减券，有效期昨天结束
当用户使用优惠券
那么 提示“优惠券已过期”

AI不仅生成了正常场景，还主动补充了边界场景（等于、低于门槛）、组合场景（两种券同时存在）、时间场景（过期）——这些都是人容易遗漏的，而AI通过训练数据中大量类似案例，天然具备这种“边界意识”。

落地细节：如何让AI生成更高质量的用例？

请根据以下业务规则生成Gherkin格式的测试用例：
- 规则1：满减券满100减20
- 规则2：折扣券85折
- 规则3：不可叠加，自动选最优
- 规则4：金额小于门槛不可用
- 规则5：有效期限制

请以以下格式输出：
【场景名称】
前置条件：...
操作步骤：...
预期结果：...

效率数据

痛点：写脚本费时，定位器容易失效

一个登录功能的脚本，看似简单，但要考虑等待、断言、异常处理，新手可能要写半小时。更头疼的是，定位器（如#username）一旦被开发改了，脚本就挂了。

解决方案：AI理解意图，自动生成稳定脚本

图2：自然语言到自动化脚本的转换

就像对助理说“帮我订个外卖”，AI自动完成下单、支付、跟踪。你说“测试登录”，AI自动生成包含定位、输入、点击、断言的完整代码。

实操案例：用GitHub Copilot生成登录脚本

你在代码中写下注释（支持自然语言）：

// 测试登录功能：访问登录页，输入用户名test@example.com，密码123456，点击登录，验证跳转到首页并显示用户名

Copilot自动补全（按Tab接受）：

test('登录功能', async ({ page }) => {
  await page.goto('https://example.com/login');
  await page.fill('#username', 'test@example.com');
  await page.fill('#password', '123456');
  await page.click('button[type="submit"]');
  await expect(page).toHaveURL('https://example.com/dashboard');
  await expect(page.locator('.user-name')).toHaveText('test@example.com');
});

AI不仅生成了代码，还自动添加了等待（fill内部已含等待）和断言，比很多新手写的还规范。

进阶：让AI推荐稳定的定位器

当元素属性经常变化时，告诉AI你的困境：

输入：需要定位“提交订单”按钮，id和class经常变，但页面有唯一文本“提交订单”，请推荐最稳定的定位方式

AI会输出：

// 推荐方案1:基于角色和名称(最稳定)
await page.getByRole('button', { name: '提交订单' }).click();
// 推荐方案2:基于文本(次稳定)
await page.getByText('提交订单').click();
// 不推荐:基于CSS选择器(易失效)
await page.locator('#submit-btn').click();

对比说明：

落地细节：如何让AI生成高质量的脚本？

await expect(page.locator('.result')).toHaveText('成功', { timeout: 10000 });

效率数据：

痛点：测试数据是“隐形成本”

一个支付功能测试，需要准备：

· 正常金额（100元、200元...）

· 边界金额（0.01元、100.00元、9999.99元）

· 异常金额（负数、非数字、超长）

· 特殊场景（组合支付、优惠券抵扣、分期支付）

手动构造这些数据，往往需要编写SQL脚本或调用API，还要保证数据之间的关联关系（如用户、订单、优惠券）。这个过程比写测试用例还花时间，而且容易遗漏边界。

解决方案：AI根据业务规则生成结构化数据

提示词模板（可以设计成可复用的）：

请生成10条用户注册测试数据，包含以下字段：- 用户名：6-12位字母数字，不能以数字开头- 邮箱：有效格式，支持常见域名（@example.com, @test.com）- 手机号：中国大陆手机号，11位数字，以1开头
- 密码：至少8位，包含大小写字母和数字，允许特殊字符
同时生成3条边界数据：- 用户名超长（>12位）- 邮箱无@符号- 手机号包含字母

以JSON格式输出，分为normal和boundary两个数组。

AI输出（部分）：

{  "normal": [    {      "username": "alice123",      "email": "alice@example.com",      "phone": "13812345678",      "password": "Alice@2025",      "description": "正常用户"    },    {      "username": "bob_test",      "email": "bob@test.com",      "phone": "15987654321",      "password": "Bob#1234",      "description": "正常用户"    }  ],  "boundary": [    {      "username": "thisisaverylongusernamethatexceeds12chars",      "email": "invalid",      "phone": "abcd12345",      "password": "short",      "description": "边界：用户名超长，邮箱无效，手机号含字母，密码过短"    }  ]}

AI不仅生成了正常数据，还自动准备了边界异常数据，覆盖了测试人员容易遗漏的场景。

集成到测试框架：数据驱动测试

落地细节：如何让AI生成符合业务规则的数据？

效率数据：