技能提升网“测试通过”这四个字缺了什么
它没有说明测了哪个版本、走了哪条路径、使用什么账号、预期看见什么，也没有告诉上线负责人哪些情况根本没测。等到生产环境出现问题，团队只能重新猜测当时的测试范围。
一条可以支持上线决定的验收结论，至少要回答：验证对象是什么，操作步骤是什么，预期与实际是否一致，证据放在哪里，仍有哪些例外，由谁接受这些风险。结论可能仍然是“通过”，但过程必须能够回放。
验收条件从需求文档里长出来
测试开始前，把需求中的行为描述改成可观察条件。例如，“用户可以修改联系方式”仍然太宽。需要继续写明入口、账号状态、允许修改的字段、校验规则、保存后的反馈，以及刷新页面后数据是否保留。
Doc Co-Authoring Skill 适合协作整理这类验收文档。先收集用户目标、版本范围、依赖、权限和例外，再逐段明确规则。内容接近完成时，用缺少项目背景的读者视角检查：仅凭文档能否知道怎么操作，失败时该看哪里，谁有权决定放行。
| 验收字段 | 应记录的内容 |
|---|---|
| 版本与环境 | 构建版本、访问地址、依赖服务状态 |
| 前置条件 | 账号类型、已有数据、权限和开关状态 |
| 用户动作 | 按真实顺序记录点击、输入和跳转 |
| 预期结果 | 页面、数据、消息或权限应发生的变化 |
| 实际证据 | 截图、页面状态、日志和问题编号 |
| 例外处理 | 未覆盖路径、已知问题、接受人与期限 |
浏览器测试负责复现，不负责替产品做决定
在本地或隔离测试环境中，Webapp Testing Skill 可以使用 Playwright 驱动真实浏览器，验证表单、按钮、跳转、动态内容和控制台信息。它强调先观察页面结构与实际状态，再选择稳定定位方式，避免凭猜测使用容易变化的层级或临时类名。
一条测试尽量只验证一个清楚行为，并在关键节点保存证据。失败时记录停在哪一步、页面显示什么、控制台是否报错、是否可以重复出现。涉及付款、删除、发消息或真实用户数据的路径，应放在隔离环境中使用测试账号，不能把自动化直接指向生产数据。
自动化通过不等于体验合格。文案是否让人理解、手机上的触控感受、异常提示是否具有帮助，仍要人工检查。性能、安全和跨设备兼容也不能由这套基础网页验收完全覆盖。
把例外写在上线决定之前
验收记录最容易漏掉的是“没有测什么”。第三方服务不可用、旧账号数据不足、某个浏览器暂未覆盖，这些都应列入例外。负责人需要判断它们是否阻塞上线、是否可带风险发布，或者必须缩小上线范围。
放行决定应包含版本、时间、负责人、通过项、阻塞项、已接受风险、回滚条件和监控对象。若要求变化，先更新验收条件再补测试，不要事后修改文字让原结果看起来符合新标准。
不同对象需要不同的上线通知
开发需要知道版本和未解决问题，客服关注用户会遇到什么变化及如何处理异常，业务团队则关心生效时间与影响范围。Internal Comms Skill 可以把同一份已确认记录整理成项目更新、FAQ 或领导层摘要，但不能为了通知完整补写未验证事实。
通知中把内容分为已经确认、暂定判断和后续行动。对外承诺与内部测试结果之间若有差异，应在发布前解决，不能让客服在用户反馈后才发现功能边界。
验收提示可以按这个顺序写
根据指定版本的需求文档，列出每条可观察的验收条件、前置状态、操作步骤和预期结果。暂时不要执行测试；先标出缺少版本、权限、数据或例外说明的条目。
在隔离环境中执行已经确认的路径。每条路径记录实际结果、关键截图、控制台异常和可重复条件。不要触发真实付款、删除或消息发送；遇到未授权操作立即停止。
依据已批准的验收记录准备上线通知，分别说明生效范围、用户可见变化、已知限制、异常处理入口和负责人。未确认信息保留为待定，不写成正式承诺。
上线前最后核对
- 版本、环境和账号条件清楚，测试证据不会与其他构建混淆。
- 验收项来自已确认需求，每项都有可观察结果。
- 自动化记录了路径、实际状态、截图或日志。
- 未覆盖路径和已知问题进入放行决定。
- 高风险操作只在隔离环境和测试数据上执行。
- 面向开发、客服与业务的通知事实一致。
- 回滚条件和上线后观察对象已经指定负责人。
上线负责人需要的不是一句肯定，而是一份可追溯的判断材料。需求说明边界，浏览器测试留下证据，沟通材料把已经确认的变化送到需要行动的人手里。任何一段缺失，“通过”都只是状态标签。
