最近在搞一个基于 Nuxt.js (前端) 和 Spring Boot (后端) 的客户项目（一个复杂的酒店与旅行预订管理后台）。为了保证微服务迭代时的稳定性，我们引入了 Playwright 框架来跑 E2E（端到端）测试。
理想很丰满，以为有了 E2E 脚本就能高枕无忧；现实却很骨感，每天看着控制台里莫名其妙标红的测试用例，简直让人抓狂。这几天连续排查了几个极其狡猾的报错，今天就来复盘一下，帮大家避避坑。
坑一：“假装是前端 Bug”的脏数据陷阱
某天，一个本来跑得很稳的取消政策测试用例（cxl-policy.spec.ts）突然挂了。看 Playwright 的报错提示，一直卡在某个页面的等待上，第一反应是：是不是前端同学又乱改 UI DOM 结构，导致定位器（Locator）失效了？
顺着这个思路去查前端代码，发现根本没动过！没办法，只能打开 Playwright 的 trace viewer 逐帧回放，同时打开开发者工具看 Network 请求。
💡 破案与解决：
结果发现，这根本不是前端的问题！由于底层的内部微服务做过更新，旧的测试数据状态发生了冲突（也就是典型的“脏数据残留”）。当脚本跑到特定步骤时，后端 API 悄悄返回了一个 HTTP 500 错误，导致前端页面白屏或卡死，Playwright 自然也就找不到后续的 DOM 元素了。
- 教训： E2E 测试报错时，永远不要盲目相信“找不到元素”的表象。
- 解决动作： 彻底清理并更新了测试数据库中的初始状态（Fixture Data），再次运行脚本，直接绿灯通过。
坑二：神秘消失的“邮件地址”输入框
刚解决完脏数据，另一个涉及“修改订单与追加行程”的复杂测试用例（cxl-mix.spec.ts）又超时报错了。
这次的报错日志非常明确：脚本在尝试填写“代表者”信息时，死活找不到 邮件地址 这个输入框（Timeout error）。
💡 排查思路：
这种“幽灵输入框”通常有以下几种可能：
1. 异步加载没完成： 前端 Nuxt 渲染太慢，输入框还没挂载到 DOM 上，Playwright 就急着去操作了。
2. 动态渲染逻辑改变： 是不是前置条件没触发？比如只有勾选了“需要发送确认信”，这个邮箱输入框才会出现？
3. 微服务通信延迟： 页面可能在等待后端某个微服务返回客户的基础信息字典，导致该区块一直处于 Loading 状态。
对于这种问题，最有效的排查手段就是使用 Playwright 的 page.pause() 进行断点调试，或者强行加上 await page.waitForSelector('.email-input-class') 看看究竟是元素压根没渲染，还是被其他图层遮挡了。
总结：E2E 测试的“脆弱性”到底来自哪里？
经过这几天的折腾，我对 E2E 测试有了更深的感悟：它绝对不是单纯的前端测试，而是整个系统健康状态的最高级集成测试。
很多时候 E2E 脚本挂了，并不是你的测试代码写得烂，而是它在帮你“吹哨”：
* 可能是微服务的 API 契约发生了改变。
* 可能是数据库里的基础状态数据被其他同事污染了。
* 可能是前端加了某个骚气的过渡动画，导致原来的测试时序完全错乱。
因此，维护一套高质量的 E2E 测试，需要我们对 Nuxt 前端、Spring Boot 后端乃至数据库状态都有全局的掌控力。
コメント