回归自动化不以点过多少按钮为目标，而是回答这次变更影响什么、哪些检查真执行了、剩余风险谁处理。本文用虚构的城市摄影展票务页面升级，覆盖回归套件规划、UI 定位修复和报告验收。我们要验证日期筛选与取消入口，保留已知风险，不声称已跑过案例，也不以全部自动化作为成功标准。
先建立变更与验收的对应关系
输入包含变更差异、产品规则、现有测试、环境与历史缺陷。把日期筛选、新增取消入口、共享导航与预约 API 分别标注，列可能影响的用户路径。代码修改位置不是完整影响范围，公共组件、缓存和权限也可能关联；不确定项写待分析，不能凭文件名决定不用测。
开始前检索 GitHub 的开源方案，参考 Playwright 对重试、trace 与报告的处理。其区分首轮通过、重试后通过与持续失败，适合避免把 flaky 抹成普通绿灯。采用前核对版本、许可、浏览器和依赖，本文不安装或执行工具，不把框架能力写成读者项目已经通过。
场景一：按风险维护回归包
建立规则到用例的矩阵，记录覆盖、部分覆盖和缺失的依据。发现测试文件不等于行为覆盖；核对断言、fixture 和执行层级。例如日期筛选只检查按钮可点击，是部分覆盖，不能证明结果日期正确。取消入口需确认权限、状态变化和失败提示，而不只看图标存在。
回归分为冒烟、定向与必要的广泛回归。冒烟验证基本入口与关键依赖；定向覆盖本次规则与关联历史缺陷；跨系统或高影响变更再扩大。自动化候选看稳定接口、频率、风险与维护成本，低频复杂场景可用人工探索补充。登录或付款即使常见，也不意味着任何团队都应无条件全自动操作真实账户。
每个用例有责任人、测试数据、环境、预期、产物与运行策略。隔离生产账号与真实票务，使用虚构展览、独立预约和通知替身。哪些是 mock、哪些是真实测试环境要标清，不能把替身结果扩大为支付或库存生产验证。范围缩减附理由和补救，不默默跳过缺失覆盖。
给 Agent 的请求可以是：“依据日期筛选变更与现有断言，先交覆盖矩阵；列冒烟、定向和待人工探索项，说明不自动化的理由。只使用指定测试环境与虚构数据。”规划结果先审行为与风险，再决定哪些脚本值得维护。
场景二：定位失败先检查页面状态
本地通过、CI 失败时，先记录代码、框架、浏览器、操作系统、视口、语言、时区、数据与网络差异。确认应用已就绪、账户有权限、目标页面与状态正确。按钮找不到可能是产品没显示、数据不足、权限错误或测试定位不稳，不能默认自动换选择器就算修复。
先看源码理解语义与可访问名称，再观察实际 DOM，优先稳定且唯一的用户可识别控件或约定测试标识。定位后仍要核对控件用途，避免从“取消预约”误选到“取消筛选”。重复文字应限定容器，不随意 first() 掩盖歧义。动态列表按稳定记录 ID 或可解释条件选择，不依赖第几个元素。
等待应对应状态，例如筛选请求完成后的结果可见、保存状态确认或按钮可用，不用固定睡眠掩盖时序。增大超时前查等待条件是否正确。保留失败截图、日志和 trace，核对页面动作与网络；产品错误就修产品，测试假设错就修用例，不能为了通过删断言。
小程序 WXML 快照与浏览器 DOM 是不同环境，需要对应运行器、快照与定位 API。一个 Playwright 方法不自动支持小程序元素修复。原文特定修复器没有可验证匹配记录前，不用同名推断兼容。
修复后运行目标用例与关联回归，保留第一次失败。有限重试可以采集不稳定信息，但重试后通过仍需标 flaky。隔离问题用例要有负责人、原因与期限，关键路径有替代验证；无限重跑或永久忽略会让报告失去判断价值。
本地 UI 回归的可核验 Skill
Webapp Testing适用于本地票务页面交互、截图、日志与可重现发现。已核对 SkillPI 详情、Anthropic 固定来源和 Apache-2.0 许可记录。需要 Python、Playwright、对应浏览器二进制、启动命令与端口，以及获准的虚构数据。
将其用于实际 DOM 观察与关键流程检查，不把它当完整回归策略、WXML 修复器、安全扫描或所有浏览器兼容认证。来源核验与实际运行分开，本文没有替读者执行测试。新候选进入目录后，按规划、定位或报告职责核对前提再更新关联。
场景三：从运行产物到可决策报告
解析 JUnit、Jest、Pytest、Allure 或其他结果前，确认格式版本、运行 ID、提交、时间、分片与环境。不同格式对失败、错误、跳过和重试定义可能不同，不能将字段名相近就直接合并。保留解析失败，缺产物与空套件不是零失败，更不是通过。
报告区分唯一用例与尝试次数，首轮通过与重试后通过。计算通过率必须说明分母，跳过与未执行单列，覆盖率区分代码覆盖与需求覆盖。分片合并按稳定用例标识去重，同一测试不同浏览器或参数可能是不同配置，不能误删；重跑也不能虚增总用例数量。
失败分析列用例、预期实际、分类、证据位置、影响和负责人。趋势比较使用相同范围与环境；套件缩小或新增大量简单用例时，通过率变化不能直接解释为质量改善。HTML 或表格只是展示，关键结论必须能回查原始结果，报告生成成功不等于数据解析完整。
产物可能含账号、令牌、页面数据或私有代码，保存到获准位置，限制访问与保留，不默认公开分享。定时任务还要验证调度是否真的触发、运行是否完成、报告是否新鲜，缺失与陈旧结果应有明确状态，不能每天重复展示上次绿灯。
验收决定与维护
输出可接受、需补验证或阻塞的决定，说明依据、范围、已知缺口与承担者。总分不能覆盖关键失败，关键用例未跑也不能写全量通过。发布权限与验收建议分开，测试通过不自动授权部署。对未知结果先查实际状态，不盲目重复外部动作。
维护矩阵、数据构造、依赖、重试和退役条件。规则变化时更新测试依据，不仅修改快照；框架更新后复测定位与报告解析。淘汰冗余项前核对独特风险，保留恢复路径。自动化比例由风险和维护决定，不宣传统一百分比。
FAQ
先修定位还是规划？先明确本次范围与预期，再定位失败根因，两者可以迭代但不能互相替代。能自动出报告吗？可以从结构化结果生成，但需验证总数、语义和证据链接。为什么本地绿而 CI 红？逐项比环境与数据，保留首次证据，不默认测试有错。
技能免费是否就没成本？还需框架、模型、runner 与维护，许可和服务费分别核对。怎样开始？先用一个变更、覆盖矩阵和一组虚构数据形成完整闭环，再扩规模，不先安装一堆名字相近工具。
来源
本文按中英文原文的规划、定位修复与报告验收，以原创摄影展票务案例重写，不沿用用户引语、下载量和统一安全保证。方法参考 Playwright 重试文档与trace 说明。