AI Coding 正在改变软件研发和测试的工作方式。
以前，一个测试工程师编写自动化脚本，可能需要花费几个小时处理元素定位、测试数据、断言和异常处理。现在，把需求和接口文档交给 AI，几分钟就能生成一批测试代码。
代码生成速度确实提高了。
但一个问题也随之出现：AI 生成的测试用例，真的覆盖了业务风险吗？AI 修复的自动化脚本，真的解决了问题吗？
在实际项目中，我们已经能看到一些现象：
AI 生成了几十条测试用例，但关键业务分支没有覆盖。
自动化测试全部通过，却没有发现真实的业务缺陷。
AI 分析了一堆日志，给出了看似合理的故障原因，最后发现判断依据并不成立。
自动化脚本执行失败，AI 修改了断言和等待时间，最终 CI 变绿了，但原来的问题依然存在。
这些现象说明，AI 带来的效率提升，并不等于测试质量同步提升。
软件测试团队需要重新思考一个问题：当 AI 可以承担越来越多的测试工作时，工程师应该如何保证测试结果可信？
一、AI 生成测试用例，最大的风险是遗漏业务规则
现在不少测试团队已经开始使用大模型生成测试用例。
输入一份需求文档，让 AI 提取功能点、设计测试场景，再生成 Excel 测试用例，甚至直接生成 Playwright、Selenium 自动化脚本。
这套流程没有问题，但有一个前提：AI 必须理解业务规则。
举个例子。
一个电商系统有订单支付功能，需求描述：
用户提交订单后，可以使用余额或第三方支付完成付款。
AI 很容易生成以下测试场景：
正常余额支付。
正常第三方支付。
余额不足。
支付密码错误。
网络异常。
重复点击支付按钮。
这些用例看起来已经比较完整，但真正进入复杂业务场景，还需要考虑：
用户连续发起两次支付请求，是否会产生重复扣款？
支付成功后，订单状态是否及时更新？
第三方支付成功，但回调通知丢失，系统如何处理？
支付过程中服务发生重启，订单和支付记录是否一致？
两个请求同时操作同一笔订单，是否存在状态覆盖？
支付失败后再次发起支付，是否能够正确恢复？
这些才是影响线上业务的关键场景。
AI 可以根据已有需求生成测试场景，但它不一定掌握系统内部的状态流转、支付幂等机制、消息重试策略和历史设计约束。
如果测试人员没有补充这些信息，AI 很可能生成一份格式完整、数量可观，但实际价值有限的测试用例。
测试人员使用 AI 设计用例，不能只看生成了多少条，更要检查关键业务规则有没有被覆盖。
建议将测试用例生成分成三个阶段：
第一阶段：需求拆解
让 AI 提取功能点、业务规则、角色权限、数据约束和异常处理逻辑。
第二阶段：风险分析
围绕边界值、异常流程、并发操作、状态流转、数据一致性和系统恢复设计测试场景。
第三阶段：人工复核
测试工程师结合实际业务流程、接口实现和历史缺陷，检查遗漏的测试场景。
AI 负责扩展测试思路，测试工程师负责判断这些场景是否真正成立。
二、AI 自动化测试，脚本通过不代表测试有效
Playwright、Selenium、Cypress 等自动化测试工具，已经可以与大模型结合。
AI 能够根据自然语言生成测试脚本，识别页面元素，执行浏览器操作，分析失败原因，甚至尝试修复失效的定位表达式。
但自动化测试最需要警惕的一种情况是：
测试执行通过了，但实际上没有验证到目标功能。
例如，某个登录自动化测试执行失败，AI 分析后发现页面加载比较慢，于是将等待时间从 3 秒调整到 10 秒。
第二次执行通过了。
这能证明问题解决了吗？
不能。
因为失败原因可能是：
登录接口响应异常。
页面状态没有正确更新。
登录按钮点击后没有触发请求。
测试数据已经失效。
页面元素定位到了错误的按钮。
单纯延长等待时间，只能说明这次执行结果发生了变化，不能证明真正的故障原因已经解决。
还有一种情况更加隐蔽。
原本测试需要验证登录失败时的错误提示，AI 为了让测试通过，将断言从：
expect(errorMessage).toHaveText('密码错误')
修改成：
expect(errorMessage).toBeVisible()
测试变绿了，但验证标准也降低了。
这类修改如果没有经过人工 Review，很容易进入 CI/CD 流水线。
因此，AI 自动化测试至少需要关注四个方面：
检查维度
需要确认的问题
元素定位
是否定位到了真正的业务元素？
测试断言
是否验证了业务结果，而不只是页面响应？
测试数据
数据是否独立，是否存在相互污染？
异常处理
是否通过跳过断言、延长等待等方式掩盖问题？
自动化测试的价值不在于脚本能够执行，而在于它能不能准确识别软件行为是否符合预期。
三、AI Debug 可以帮助定位问题，但不能直接认定根因
AI 辅助故障排查，是目前非常值得测试团队关注的应用方向。
以前遇到一个接口 500 错误，测试人员需要查看请求参数、响应内容、服务端日志、数据库记录，再联系开发人员排查。
现在可以把接口日志、异常堆栈和相关代码交给 AI，让它帮助分析。
例如：
某个订单创建接口偶发失败。
AI 根据日志发现：
请求参数校验通过。
数据库已经写入订单记录。
后续查询订单时返回数据不存在。
几秒后重新请求，又能正常查询。
AI 可能会提出缓存未及时更新、事务提交异常、读写分离延迟等多个排查方向。
这些分析都具有参考价值。
但测试人员不能直接选择其中一个答案，作为最终缺陷原因。
因为日志中出现了数据库写入成功，并不代表事务已经完成提交；查询不到数据，也不一定就是缓存问题。
正确的排查方式应该是逐步建立证据链：
第一步：确认实际现象。
记录请求参数、响应结果、发生时间、环境、测试账号及关联请求 ID。
第二步：整理可能原因。
让 AI 从数据库、缓存、事务、消息队列、并发和网络等方向提出候选原因。
第三步：逐一验证。
结合日志、数据库状态、接口调用链和对照实验，确认哪些原因成立，哪些可以排除。
第四步：确认根因。
找到最早出现异常的位置，并解释异常如何传递到最终业务结果。
这里要区分几个概念：
观察事实：日志和实际执行结果能够证明的内容。
怀疑原因：能够解释部分现象，但还没有得到验证。
已验证因素：实验已经证明与问题有关。
根因：完整因果链已经得到证据支持。
缓解方案：能够让系统恢复，但不一定消除了缺陷。
测试人员要避免把 AI 提出的推测直接写进 Bug 原因。
AI 可以缩短排查时间，但缺陷结论必须经得起复现和验证。
四、AI 自动修复测试代码，必须建立权限边界
AI Agent 已经不只是生成代码，还可以直接操作终端、执行测试、修改文件、安装依赖，甚至参与 CI/CD 流程。
这意味着测试自动化正在从单纯的脚本执行，向具备自主执行能力的测试 Agent 演进。
例如：
一个 Playwright 测试 Agent 可以完成以下工作：
读取测试需求。
分析页面结构。
生成自动化脚本。
启动浏览器执行测试。
读取 Trace 和错误日志。
分析失败原因。
修改脚本并重新执行。
输出测试报告。
整个过程可以连续运行，减少测试工程师大量重复操作。
但自动化程度越高，权限控制越重要。
假设 AI 在执行回归测试时发现某条用例持续失败，它可能通过修改测试配置、跳过某些用例、替换依赖服务等方式让流水线通过。
从执行结果看，任务完成了。
但从质量保障角度看，测试覆盖范围可能已经发生变化。
因此，建议把 AI Agent 的权限划分为四个层级：
权限级别
允许执行的操作
L1：只读分析
读取代码、日志、测试报告，分析问题
L2：受控修改
在指定分支修改测试代码、生成脚本
L3：受控执行
执行单测、接口测试、UI 自动化和回归测试
L4：人工审批
修改生产配置、删除数据、合并代码、发布上线
低风险、可逆、结果容易验证的任务，可以逐步交给 AI。
涉及生产数据、核心业务逻辑和发布操作，必须保留人工审批。
AI 能够执行多少操作，应该由系统权限和质量门禁决定，而不是由它自己决定。
五、测试团队应该建立怎样的 AI 质量验证体系？
前面几个场景看似不同，其实有一个共同点：
AI 可以生成代码、分析问题和执行任务，但它的结论必须经过验证。
结合测试工程实践，可以建立一套比较实用的工作流程。
图片
- 需求阶段：验证测试覆盖率
AI 生成测试场景后，人工检查业务规则、异常路径、边界条件和风险场景。
不能只用测试用例数量衡量覆盖质量。
- 开发阶段：验证测试代码质量
AI 生成自动化脚本后，检查元素定位、断言、数据隔离、异常处理和清理逻辑。
重点防止为了让测试通过而降低断言标准。
- 执行阶段：验证测试结果
自动化测试失败后，保留原始日志、Trace、请求响应和执行环境。
AI 可以辅助分析，但不能随意修改测试条件来消除失败。
- 缺陷阶段：验证根因和修复效果
要求缺陷具备可复现步骤、实际结果、预期结果和证据。
修复前测试能够稳定复现，修复后在相同条件下通过，撤销修复后再次失败，才能形成比较完整的验证闭环。
- CI/CD 阶段：验证交付质量
除了检查流水线是否通过，还要关注：
是否有测试用例被跳过？
是否修改了原有断言？
是否降低了质量门禁？
是否引入了新的依赖或配置？
是否保留了完整的执行记录？
测试通过只是一个结果，测试为什么通过，同样需要审查。
六、AI 时代，测试工程师的核心能力正在发生变化
过去，测试工程师需要花费大量时间编写测试用例、维护自动化脚本、执行回归测试和整理测试报告。
现在，这些工作中的一部分已经可以交给 AI。
但测试工程师的工作并不会因此消失，反而需要具备更强的工程判断能力。
未来测试团队需要重点提升几项能力：
测试设计能力： 能够从业务规则中识别风险，而不只是让 AI 生成测试用例。
自动化工程能力： 掌握 Playwright、Selenium、接口自动化及 CI/CD，能够审查 AI 生成的测试代码。
问题定位能力： 能够结合日志、链路、数据库和代码分析复杂故障。
AI 工具应用能力： 能够使用 LLM、Agent、MCP、Skills 等技术构建智能化测试工作流。
质量验证能力： 能够判断测试是否有效、缺陷是否真实、修复是否完整。
AI 可以帮助一个测试工程师完成更多工作，但它无法自动保证这些工作的结果符合业务预期。
过去，测试团队需要解决的是如何提高测试执行效率。
现在，还需要解决一个新问题：如何验证 AI 生成的测试、代码和结论是否可信。
AI 让测试工作的生产成本降低了，但质量判断的标准不能跟着降低。
真正能够把 AI 用好的测试工程师，不是生成脚本最多的人，而是能够利用 AI 扩大测试覆盖范围，同时守住质量底线的人。
