E2E测试怎么做才稳定不掉链子

前端改完，怎么确认它真的还能用

前端改一处，影响往往不止一处：页面能不能正常加载、关键按钮点下去有没有反应、表单提交流程是否还通、控制台有没有悄悄报错、弹窗会不会遮住该填的输入框——这些"看起来对不对"的问题，光看代码 diff 判断不了，得真的在浏览器里跑一遍。而手动开浏览器、点一遍、截个图、翻控制台，既慢又容易漏，改动一多就懒得每次都验，回归问题就这么溜进去了。

这个技能能帮你验什么

它用 Python Playwright 把"在浏览器里跑一遍"变成可重复的脚本流程。第一步是区分页面类型：静态 HTML 直接读取文件、识别选择器；动态应用则要先启动服务、等渲染完成再侦察。服务管理上，它用 with_server.py 管理单个或多个本地服务的生命周期，避免手动起停。检查能力上，它会等 networkidle（网络空闲）后再检查 DOM、截图、查看按钮和输入控件、读取控制台日志。操作能力上，它编写同步 Playwright 脚本执行点击、输入和断言。它强调一个固定顺序：先启动、等空闲、侦察清楚，再动手操作，而不是页面还没好就盲点。

"先侦察后行动"这条顺序是这套测试可靠的核心：页面没渲染完就去点按钮、查元素，得到的结论是假的；等到网络空闲、DOM 稳定再操作，截图和断言才反映真实状态。

怎么用它

用法是把本地页面地址或服务、要验证的行为，以及必要的启动命令用自然语言交给它，由它按顺序起服务、侦察、操作并给出结论。例如可以这样对它说：

它适合这些场景：前端改动后要验证页面能否正常加载并完成关键交互；动态应用渲染异常，需要截图、DOM 和控制台日志辅助定位；本地项目需要先启动开发服务器再自动执行浏览器测试；静态 HTML 工具需要直接读取选择器并做简单自动化检查。适合前端工程师、全栈开发者、QA 测试人员，以及要验证本地 Web 应用功能、视觉状态或交互流程的产品技术团队。

大家常问

端到端（E2E）测试到底是什么意思？为什么前端改完光看代码 diff 判断不了页面还正不正常？

E2E 测试是在真实浏览器里按用户视角跑完整流程（登录、点击、提交）并断言结果。代码 diff 只能看出"代码改成了什么样"，看不到样式渲染、异步数据时序、DOM 就绪、网络响应这些真正决定页面是否正常的维度，所以要在浏览器里真跑一遍。

单元测试和端到端（E2E）测试有什么区别？分别适合在什么场景用？

单元测试在无浏览器环境验证单个函数或组件的逻辑，毫秒级、数量最多，适合细粒度逻辑与边界条件；E2E 在真实浏览器跑完整用户路径，慢但最接近生产，数量最少，只覆盖关键业务流。原则是别用 E2E 替代单元测试。

为什么自动化测试会时而通过、时而失败（flaky）？这种不稳定的根因通常是什么？

flaky 多发在 E2E 层，根因是引入了太多不可控时序：异步渲染竞态（元素还没出现就去操作）、测试间状态污染（Cookie/缓存残留）、动画导致点击落空、波动的网络与接口、易变的选择器。越靠测试金字塔顶端，不稳定概率越高。

做网页自动化测试时，为什么要先等页面加载完、网络空闲再去检查元素和断言？

现代页面的 DOM 是异步填充的：路由切换先出骨架屏，再靠请求拉真实数据。不等网络空闲就定位元素、点按钮，等于在一个不可预测的 DOM 快照上做决策，结果无法复现，断言时对时错。等渲染稳定再侦察，截图和断言才反映真实状态。