AI Coding 时代，测试工程师怎么做测试？

一、时代背景：AI 写代码快了，测试跟得上吗？

AI 编程工具的普及，让开发速度发生了质变。一个功能以前可能需要三天，现在半天出来了。迭代节奏加快了，但测试的方式还停留在原地——用例还是手写，回归还是靠人跑，联调还是拉着开发一起等。

结果就是：AI 让开发提速，测试成了新的瓶颈。

靠加人、加班追赶是追不上的。思路必须变。

— — —

二、AI 能完全替代执行测试吗？

先给结论：结构化的部分，已经可以了；非结构化的部分，还不行。

很多测试工程师的担忧是"AI 会不会取代我"，但这个问题问错了。更准确的问题是：AI 能替代测试工作里的哪些部分？

— — —

三、AI 现在能独立完成的测试

以下这些，今天就可以交给 AI：

• 单元测试生成 执行：给 AI 一段代码，它能生成覆盖边界条件和异常路径的单元测试，并自动执行
• 接口测试：给 AI 一份 OpenAPI/Swagger 文档，它能自动生成请求、发送、验证响应格式
• 回归测试自动执行：CI 流水线里，每次代码提交自动触发，无需人工介入
• 代码静态分析：扫描潜在的空指针、类型错误、安全漏洞，比人找得更全
• 性能测试脚本生成：给出场景描述，AI 能生成 k6 或 JMeter 脚本

这些工作以前占测试工程师 80% 的时间，现在应该压到 20%。

— — —

四、AI 目前做不到的四个方面

1. 判断"这个结果对不对"

AI 能跑测试，但"跑过了"不等于"正确了"。

用户注册后收到欢迎邮件，测试通过。但邮件里的称呼写的是用户 ID 而不是用户名——AI 不觉得这是 Bug，因为它不理解"用户期望看到什么"。业务正确性的判断，需要人理解用户期望。

2. 探索性测试

AI 按已知路径测，发现不了"没人想到会这样操作"的问题：

• 用户在表单里粘贴了一段 Excel 数据
• 用户同时开两个标签页下单同一件商品
• 支付页面停留了 30 分钟再提交

这些场景 AI 不会主动去想，人会。

3. 跨系统的"感觉不对"

页面加载慢了 0.8 秒，自动化测试没报错。但有经验的测试工程师打开页面就知道"这不正常"。性能退化、交互卡顿、视觉错位——这些需要人的感知。

4. 需求本身有歧义时

AI 会按字面意思测，不会质疑需求。需求写"金额四舍五入"，AI 测通了。但金融场景应该用"银行家舍入法"，这个问题 AI 不会发现。

— — —

五、更准确的边界划分

AI 能替代	AI 替代不了
重复执行	业务理解
已知场景验证	用户视角
数据生成	异常直觉
报告输出	需求质疑

— — —

六、用例要面向 AI 写，不再面向测试工程师写

这是一个容易被忽视但非常关键的转变。

传统用例是写给人看的：

text

步骤1：打开浏览器，输入网址步骤2：点击登录按钮步骤3：输入账号密码步骤4：观察页面是否跳转

这种写法描述的是"怎么操作"，AI 执行效率很低。

面向 AI 写的用例，只需要两件事：

清晰的前置条件

text

用户账号存在、余额为100元、当前未登录状态

明确的验收标准

text

支付50元后：- 余额 = 50元- 订单状态 = 已支付- 支付流水存在记录

"怎么操作"交给 AI 自己决定，人只定义"什么叫对"。

这个转变还有一个额外收益：它倒逼测试工程师真正想清楚验收标准。以前可以模糊地写"验证页面正常显示"，人看了知道啥意思。AI 不行，它需要你说清楚"什么叫正常"。很多测试工程师以前从来没真正想清楚过这个问题，面向 AI 写用例之后，这个问题必须回答。

— — —

七、正确的协作方式：先定标准，再让 AI 执行

很多团队引入 AI 测试工具后，流程变成了这样：

AI 跑完测试 → 人再看一遍结果对不对

这等于测了两遍，效率没有提升，还多了一层信任焦虑。

正确的顺序应该是：

text

人先写验收标准 ↓AI 按标准执行 ↓只有异常时人介入

AI 跑过了，就等于人跑过了，不需要重复——前提是你信任这个测试本身。

信任的来源不是"AI 跑过了"，而是：验收标准是你定的、测试场景是你审查过的、CI 环境是稳定可靠的。这三点成立，重复执行没有意义。

人工介入只有两种情况：CI 报红了，或者线上出了问题说明有测试盲区。

— — —

八、AI 执行测试的三种方式

代码层：最成熟，今天就能用

Copilot / Cursor 生成 pytest 或 Jest 测试代码，提交到仓库，GitHub Actions 自动触发执行，结果自动报告。AI 负责写代码，执行还是传统 CI 流水线。

UI 层：自然语言驱动浏览器

Playwright MCP、Midscene 等工具，AI 能直接控制浏览器：

text

"打开登录页，输入账号密码，点击登录，验证跳转到首页"→ AI 自己操作浏览器执行，不需要写一行代码

用自然语言描述操作步骤，AI 自动完成。

接口层：读文档直接发请求

给 AI 一份 OpenAPI 文档，它能自动生成请求、覆盖异常参数场景、验证响应格式，适合接口数量多、文档完整的项目。

— — —

九、复杂交互和跨业务场景，AI 执行不了怎么办

AI 测试目前有真实的边界，面对复杂场景有几种应对方式：

分层处理，不强求 AI 全跑

AI 能跑的部分自动化，跑不了的部分人工 清单化。不是所有测试都要自动化，关键是让人的时间只花在 AI 真的做不了的地方。

复杂链路：拆解后分段执行

AI 跑不了整条链路，但可以跑每一段。以电商下单为例：下单、支付、物流、退款，AI 分别测每个节点的接口和状态流转，人工测跨节点的数据一致性和异常中断后的恢复。

跨业务系统：Contract 测试替代联调

跨团队、跨系统的场景靠 AI 端到端执行不现实。用契约测试替代：每个系统定义"我提供什么、我期望收到什么"，CI 自动验证契约是否被破坏，不需要真正拉通跑一遍。

真正跑不了的：Checklist 化，逐步剥离

对于 AI 确实无法执行的场景，整理成结构化 Checklist，每次发版前人工过一遍，同时持续把其中能自动化的部分剥离出来。

— — —

十、新功能上线，人还需要再测一遍吗？

这是一个很常见的问题，答案需要区分两件事：

验证功能：不需要人再跑

用例是新的，但只要验收标准是你定的、用例是你审查过的，AI 跑过就够了。人再点一遍，发现不了 AI 没发现的问题。

验证用例有没有漏：需要探索性测试

这不是重复执行用例，而是拿着已有用例覆盖不到的地方去试。支付流程的用例写好了，但没人想到"用户在支付页面停留 30 分钟再提交"会怎样。这部分不是重复，是扩展覆盖范围。

正确的流程是：

text

AI 执行用例（验证已知场景） 人做探索性测试（发现未知场景） ↓发现新问题 → 补用例 → AI 后续自动覆盖

人工介入的价值不是重复验证，而是扩展覆盖范围。发现的每一个新问题，都应该沉淀成用例，让 AI 下次自动覆盖。

— — —

十一、测试工程师的新定位

AI 时代，测试工程师的工作从"执行测试"变成：

• 定义什么叫"正确"——验收标准的制定者，这是 AI 无法替代的
• 设计 AI 想不到的场景——探索性测试，发现真实用户的意外操作
• 判断结果是否真正代表质量——会跑不代表没问题，解读结果需要业务判断

— — —

结语

AI 是执行力极强的助手，但它不知道"为什么测"，只知道"怎么测"。

知道"为什么测"——这是测试工程师不可替代的核心价值。

转型的关键不是学会用哪个 AI 工具，而是改变对自己角色的认知：从"执行测试的人"变成"定义质量标准的人"。工具会用了，但认知没变，还是在用 AI 帮自己更快地做重复劳动——这才是大多数测试工程师现在真正卡住的地方。