当 AI Agent 开始接手浏览器自动化，很多团队已经能让它完成登录、搜索、下单等常规操作。但线上最难复现的缺陷，往往出现在正常流程之外。
订单接口返回 503，页面一直转圈；网络突然断开，用户连续点击提交；服务恢复后，页面却没有重新加载数据。
这些问题很难靠反复执行正常用例发现。测试工程师需要主动制造异常，并且保留足够的执行证据。
Playwright CLI 配合 Skills，可以把网络异常注入、浏览器交互、Trace 记录和故障分析串成一套工作流程。
目录
一、正常流程通过，不代表异常处理可靠
二、网络 Mock 改变了异常场景的构造方式
三、Mock、Trace 与 Skills 如何协同
四、用订单接口复现一次故障
五、从故障复现走向工程化测试
六、AI Agent 能接手哪些测试工作
一、正常流程通过，不代表异常处理可靠
常规 Web 自动化主要验证业务流程能否完成。例如，进入订单页面、查询订单、检查列表数据。
但接口返回异常时，前端可能出现另一套问题：错误提示没有展示、加载状态无法结束、重试按钮失效，甚至重复提交订单。
手工构造这些故障，通常需要开发人员配合修改服务，或者临时调整测试环境。故障越依赖环境状态，复现成本越高。
异常测试的价值，在于让故障可重复、结果可判定、证据可回放。
二、网络 Mock 改变了异常场景的构造方式
Playwright CLI 提供网络请求拦截能力。测试人员可以针对指定接口，模拟不同的响应状态，也可以控制浏览器的联网状态。
常见场景包括：
HTTP 503：验证服务不可用时的页面反馈。
延迟响应：验证加载状态和业务超时处理。
网络断开：验证离线提示与恢复流程。
异常响应体：验证前端对缺失字段、格式错误数据的处理。
需要区分的是，HTTP 504 是服务返回的状态码，真正的网络超时则可能表现为请求长时间没有完成或被客户端取消。两者的处理路径并不相同。
三、Mock、Trace 与 Skills 如何协同
三者承担不同职责。
Playwright CLI：执行浏览器操作、拦截请求、检查页面和网络状态。
Skills：向编程 Agent 提供命令说明、操作流程及相关参考文档。
Trace：记录浏览器操作、页面快照、截图、网络活动和控制台信息，帮助还原故障发生的过程。
整体流程如下。
mermaid-diagram_9
Skills 不会自动保证测试正确。Agent 仍然需要按照业务预期执行检查，并根据实际证据判断结果。
四、用订单接口复现一次故障
假设订单页面依赖 /api/orders 接口。我们需要验证接口返回 503 时，页面是否展示错误信息，以及故障解除后能否恢复。
先安装 CLI 并初始化 Skills：
npm install -g @playwright/cli@latest
playwright-cli install --skills
启动本地测试应用后，执行以下命令：
打开订单页面
playwright-cli open http://localhost:3000/orders
开始记录 Trace
playwright-cli tracing-start
模拟订单接口返回 503
playwright-cli route "**/api/orders" --status=503 --body='{"message":"service unavailable"}' --content-type=application/json
重新加载，触发请求
playwright-cli reload
检查页面、请求和控制台
playwright-cli snapshot
playwright-cli requests --filter="/api/orders"
playwright-cli console error
这里要核对三个结果：请求是否命中 Mock、页面是否出现预期错误提示、加载状态是否正确结束。
如果需要验证网络断开，可以单独执行：
playwright-cli network-state-set offline
playwright-cli reload
playwright-cli snapshot
恢复联网
playwright-cli network-state-set online
playwright-cli reload
完成异常检查后，撤销路由并验证恢复：
playwright-cli unroute "**/api/orders"
playwright-cli reload
playwright-cli snapshot
停止记录并保存 Trace
playwright-cli tracing-stop
撤销 Mock 后，需要确认实际后端可用，否则无法判断恢复失败是业务问题还是测试环境问题。
CLI 会输出 Trace 文件路径。使用下面的命令打开对应文件：
npx playwright show-trace <实际的trace文件路径>
Trace Viewer 可以帮助我们沿着执行时间线查看页面状态、请求响应和控制台信息。
例如，接口已经返回 503，但页面仍然显示加载中，就可以进一步检查前端错误处理和状态更新逻辑。
Trace 能还原浏览器观察到了什么，但不能单独证明后端故障的根因。
五、从故障复现走向工程化测试
单次 Mock 只能覆盖一个条件。团队需要围绕核心业务建立异常场景矩阵。
测试场景
重点检查
HTTP 500/503
错误提示、加载状态、重试入口
延迟响应
超时处理、重复点击、页面响应
网络断开
离线提示、恢复后的数据刷新
异常响应体
数据校验、空状态、异常处理
写请求失败
重复提交、订单状态一致性
落地时还有三个细节容易被忽略。
第一，Mock 规则要尽量精确。拦截范围过大，可能影响页面的其他接口，制造与目标场景无关的失败。
第二，执行结束后必须清理路由。否则后续用例可能继续命中 Mock，造成测试污染。如果项目使用 Service Worker，还需要检查它是否接管了请求，导致拦截规则没有生效。
第三，Trace 不是测试断言。它提供分析证据，但测试仍然需要明确的预期结果，例如错误提示是否可见、加载状态是否结束、重试后数据是否更新。Trace 和请求日志也可能包含敏感信息，需要控制访问权限和保留时间。
稳定的异常用例可以进一步沉淀为 Playwright Test 自动化脚本，加入持续集成流程。CLI 则适合让 Agent 探索页面、复现问题和收集证据。
六、AI Agent 能接手哪些测试工作
过去，测试工程师需要手工配置异常、重复执行操作，再从截图和日志中寻找线索。
现在，Agent 可以根据 Skills 了解可用命令，按照场景配置 Mock，检查页面变化，收集 Trace，并依据测试规则整理故障证据。
但测试预期仍然需要明确。例如，订单提交失败后是否允许重试、重试前是否需要查询订单状态，都属于业务规则，不能只根据页面截图推断。
后续的工程实践可以围绕三个方向展开：建立可复用的异常场景库，把故障证据纳入自动化报告，再将稳定的检查规则沉淀进持续集成。
对于测试开发工程师来说，浏览器操作只是执行层。如何设计异常场景、定义判定条件、分析证据并验证恢复，才是这套能力能否用于真实项目的关键。
如果让 AI Agent 独立测试你负责的订单系统，你会要求它只提交执行结果，还是必须同时提交可复现的故障步骤、Trace 证据和恢复验证结果？
本文部分内容参考了霍格沃兹测试开发学社整理的相关技术资料，主要涉及软件测试、自动化测试、测试开发及 AI 测试等内容，侧重测试实践、工具应用与工程经验整理。
