浏览器自动化测试与采集合规实践

先回答两个具体问题

UI 自动化用例为什么总在页面重构后批量失效？网页数据采集又为什么可能从「写个脚本」变成合规事故？前者多半是选择器脆弱、等待策略粗放和用例互相污染；后者通常源于没有先判断数据性质、站点意愿和使用强度。这个技能把这两件事拆开讲，而不是丢给你一套通用模板。

技能如何组织实践

• 采集前先过合规三问：数据是否完全公开、是否需要登录或付费；robots.txt、用户协议、官方 API 怎么影响选择；是自用分析还是商用转售，请求频率会不会影响对方服务。结论很直接：有 API 就用 API，不绕过登录验证、验证码或技术防护。
• 用反脆弱思路写 UI 自动化：选择器按 data-testid、语义角色加可见文本、稳定 id/name、CSS 类名到 XPath 长路径的顺序取舍；等待条件而不是固定 sleep，并用全局超时加局部超时兜底。
• 让用例可重跑：每个用例自建数据、不依赖执行顺序，数据用后清理；失败时自动截图并保留页面快照。自动重试可以接受一次，但靠三次重试才绿的用例应回到根因修复。
• 把 E2E 放在正确位置：只有挂掉会直接损失收入或用户的流程才值得写端到端测试，其余逻辑尽量下沉到接口测试或单元测试。
• 跑在服务器上也要能活下来：容器补齐字体和依赖库，中文页面装中文字体；限制无头浏览器并发实例数，定期回收实例，设置页面级超时与兜底 kill。

适用边界

它不提供绕过登录验证、破解验证码、伪造身份、抓取个人信息或明确禁止抓取内容的手段。采集是否合法还要结合具体站点条款、数据性质和司法辖区判断，重大商用采集应先咨询法务。