自动化测试的价值，是在行为被破坏时提供可信反馈，而不只是生成一批能运行的文件。本文以虚构的社区维修课堂预约功能为例：同一用户不能重复占用同场名额，取消后名额释放，网络失败不能显示预约成功。我们从用例与覆盖设计、执行与失败诊断、跨框架维护与 CI 三个场景，串起可审阅的证据链。本文不声称已运行案例或扫描读者项目。
把产品规则写成独立的验收依据
先列用户、场次、容量、状态与幂等约定。相同用户、相同场次的第二次请求应返回已有预约或明确冲突，具体选择由产品与接口契约确定；不能让生成测试的 Agent 按当前代码猜正确行为。取消后能否重新预约、截止时间、管理员操作和并发规则也要明确，未知项先作为设计问题，不写成假定。
给测试任务提供验收条件、接口或函数、现有框架、fixture、允许环境、禁止依赖和成功命令。保留代码与契约版本，使设计、执行与诊断都用同一份规则。单测、集成、API 与 E2E 分层承担风险，覆盖率是线索，不能代替行为质量。
开始前检索 GitHub 的成熟开源方案，参考 Microsoft Playwright 的 CI、trace 和浏览器测试方法。它适合关键页面路径与失败证据，采用前核对当前版本、许可、浏览器依赖、运行环境和数据范围。不为所有单元逻辑引入浏览器，也不因框架文档有示例就声称项目已经可用。本文不安装依赖或执行测试。
场景一：从风险映射到合适层级
纯规则如截止时间计算、状态转换和输入校验优先单元测试，固定时钟、时区与边界值。数据持久化、唯一约束与事务适合使用隔离数据库的集成检查；API 层验证响应、身份与契约；浏览器层保留少量关键用户路径。最低成本且能暴露目标错误的层级，通常比把每条规则都点击一遍更易维护。
建立风险表，逐项写输入、预期、失败含义与层级。正常预约验证保存及用户反馈；重复请求验证无第二次占用；容量边界包含剩余一席与已满；取消验证状态与名额；未登录和他人预约验证权限；超时验证未知或失败提示。并发最后一席需要真实约束检查，不能只用两个先后浏览器操作冒充同时竞争。
fixture 使用虚构用户、独立场次与可清理状态，隔离数据库与通知替身。测试账号、邮件、支付、生产 API 都不能默认继承开发者真实凭据。对外部服务只在明确授权和预算内做必要集成验证，其余用可解释替身，并标明替身覆盖范围，不能把 mock 通过写成真实服务通过。
测试从契约与设计出发，读现有实现帮助定位，不逐行镜像实现细节。断言应核对真实结果，如预约记录 ID、占用数、状态与可见消息，不能仅断言函数被调用或页面出现“成功”字样。快照需要人工理解变化；一次自动更新所有快照可能让错误变成新的预期。
用受控变更检验假绿：暂时破坏重复预约保护，确认相关测试失败；恢复后再次通过。只在隔离副本或可恢复环境做这类验证，保留变更与恢复证据，不损坏真实数据。还应确认失败原因正是目标规则，而不是测试启动不了。能变红、能解释红，再谈进入长期套件。
场景二：执行前固定环境，红灯后先定性
记录命令、工作目录、提交或版本、依赖锁定、环境变量名称、数据库初始化、浏览器与系统信息。敏感值不进入报告。确认服务就绪使用可观察状态而非固定等待；浏览器测试观察真实 DOM 后选择稳定定位，避免脆弱的全页 CSS 序号。每个用例独立构造与清理状态，不依赖另一个用例先运行。
执行保留退出码、用例数量、通过失败跳过、耗时、日志和必要截图或 trace。总数应能对账，零用例或全部跳过不能叫通过。工具断开、日志截断或超时结果未知时先查进程与产物，不直接重复有副作用的测试。报告区分已计划、已执行和已验证。
红灯分类至少四种：产品缺陷、测试实现错误、不稳定依赖和环境问题。产品缺陷用实际状态与契约定位；测试错误看错误定位、数据假设和断言；flaky 看时序、共享状态、随机、时钟和外部服务；环境问题看启动、依赖、浏览器与配置。分类可以待确认，不为尽快绿灯随意修改业务规则。
在同一失败上保留第一次证据，再决定针对性重跑。重跑通过仍是一次不稳定观察，不能抹掉初次失败。记录尝试数与失败频率，禁止无限重试。必要时短期隔离用例，附负责人、原因、补救措施和到期时间，关键路径仍需替代验证，不能永久静音。
修复产品或用例后先跑相关集合，再按变更影响范围做必要回归；新失败与未解决疑点决定是否扩大检查，不机械反复全跑。不可通过删有效断言、扩大时间上限到失去意义或把错误吞掉来获得绿灯。维护者应能从报告重现，并看懂实际与预期的差异。
本地浏览器阶段可用的 Skill
Webapp Testing适用于本地预约界面的交互检查、截图、日志和重现记录。已核对其 SkillPI 公开详情、Anthropic 固定来源与 Apache-2.0 许可记录。前提包括 Python、Playwright、对应浏览器二进制、启动命令与端口，以及获准的虚构数据。
把它放在关键页面回归步骤：先观察渲染 DOM，再操作预约、重复提交、取消与失败提示，并保存断言和证据。它不是数据库并发正确、API 权限完整、安全审计或所有设备兼容的认证。这里核对的是来源和用途，不表示已替读者跑过测试；也不将原文八个名称直接当作本平台已核验记录。
场景三：跨框架维护与 CI 关卡
已有项目用什么框架就优先复用什么，单测、API 与浏览器工具各自保持清晰职责。迁移框架前列功能差异、数据构造、mock 行为、断言和报告格式，先迁少量已知用例做等价检查，不把新框架绿灯直接当旧覆盖全搬过去。维护成本与团队能力比工具数量更重要。
CI 明确依赖安装、测试数据、服务启动、执行命令、超时、并发和产物保留。浏览器版本与库版本匹配，外部依赖受控，失败时保留有用证据。先用稳定低并发建立基线，再扩分片或并发；按实际资源观察，不能把本地快速参数直接复制到资源较小的 runner。
每个并发任务使用独立数据与端口，避免共享场次互相抢名额。覆盖率报告区分未执行路径和已测行为，不能靠同一层重复测试堆数字。执行时间预算应让高价值检查先反馈，较慢完整验证可按风险安排，但发布所需关卡不能无解释跳过。
日志、HTML 报告和 trace 可能包含测试账号、令牌或页面数据，存到获准产物位置并控制访问与保留，不自动公开报告。关闭某种共享选项不代表所有依赖都不会出站，检查实际配置。失败通知也只发给明确授权对象，不能把私人记录当公共附件。
为每组测试指定维护人，记录 fixture、外部依赖、重跑策略、已知缺口与退役条件。接口、规则、框架或浏览器更新后复测相关样本。测试过时可以重写或移除，但依据是规则与风险变化，不能仅因为它经常变红。清理产物与数据同样保留可追溯范围。
如何发现并比较更多测试方法
检索时给出技术栈、验收规则、测试层级、现有框架、禁止生产账号或外部服务等限制。候选核对公开详情、固定来源、许可、依赖和准确用途。生成用例、解释失败和维护 CI 是不同职责，组合时共用同一验收与 fixture，避免各自猜预期。
一次试一个候选，与基线比较断言质量、失败信息、稳定性、执行时间和维护难度。发现工具的推荐不是运行权限，也不保证最优；下载量和统一安全宣传不作为证据。随着 SkillPI 新增可验证条目，再按具体步骤刷新关联，保留旧决定与新试用结果。
一次可审阅的实施请求
可要求 Agent：“依据这份预约契约，先交风险到层级的映射；复用已有框架与虚构用户；只在指定测试环境执行，保留首次失败，不改生产配置。”评审时核对每个用例是否对应明确规则、数据能否独立重建、清理是否影响其他任务。若测试初始化失败，必须作为环境错误报告，不能跳过全部用例后称通过。
FAQ 与最终验收
先补单测还是 E2E？按风险与反馈速度选择，业务规则通常先在低层验证，关键用户旅程再用浏览器。需要什么材料？至少明确行为、输入预期、边界、框架、fixture、限制和成功命令。多个 Skill 能否组合？可以，但职责、数据与接受标准统一，不能让一个生成者自己改变标准然后宣布通过。
怎样识别假绿？让目标行为受控破坏时确实失败，恢复后检查正确通过，并确认用例真的执行。CI flaky 怎么办？保留证据，分析时序与隔离，有限重试与临时隔离必须有责任人与期限。覆盖高是否够？不，断言、边界、失败解释和维护才决定反馈价值。
交付验收矩阵、用例与 fixture、命令和环境、第一次失败与修复证据、实际结果、CI 配置和维护说明。标明本地、mock、集成与目标环境各验证到哪里，不将一层成功扩大为全系统通过。本文是实施方法，未替读者生成、运行或提交测试。
来源
本文按中英文原文的设计覆盖、执行诊断、跨框架 CI 三场景，以原创维修课堂预约案例重写。浏览器与 CI 方法参考 Playwright 官方 CI 文档源码和trace 说明，Skill 范围依据上方固定来源记录，不沿用未核实的安装量与全库安全保证。