技能提升网首页打开正常，菜单也能点，网站看上去已经可以上线。真正容易出问题的地方却藏在下一步：表单提示没有出现，登录成功后仍停在原页，退出账号以后还能返回受保护页面。只看几个静态页面，这些问题很容易漏过去。
上线前的检查应该围绕用户要完成的事情来安排。一轮检查不用覆盖整站，先选出会影响咨询、注册和后台访问的关键路径，然后把每个结果写成可以判断对错的条件。
先画出两条不能断的路径
第一条从访客进入页面开始，经过填写表单、触发校验、提交数据，最后看到明确结果。第二条覆盖登录、进入受保护页面和退出账号。页面数量可能不多，但每一步都应有可观察的结果。
先写路径还有一个好处：团队能提前决定哪些操作不能碰生产数据。发送通知、创建订单、删除记录等动作应放在隔离环境，用测试账号和测试数据完成。若只能检查生产站，至少要避开有真实副作用的提交动作。
表单检查不能停在成功提交
正常填写只是最顺的一种情况。建议先提交空表单，观察必填项是否在对应位置给出提示；再输入格式错误的邮箱、超长文本或前后带空格的内容，确认页面没有静默吞掉错误。按钮连续点击时，还要看请求是否重复发送，提交过程中是否有明确状态。
检查结果不要写成“表单正常”。更有用的记录会指出输入、动作和预期结果，例如：邮箱格式错误时不发送请求，字段下方出现可读提示；提交成功后页面显示确认信息，刷新页面不会再次创建记录。这样一旦失败，开发者知道应从前端校验、接口响应还是页面状态更新开始排查。
登录流程要把会话前后都走完
输入正确账号并进入后台，只完成了一半。错误密码应留下清楚的失败提示，登录后的目标页应真正可访问，退出后再次打开受保护地址则应回到登录入口。还要确认刷新页面和浏览器前进、后退不会绕过访问限制。
如果网站有不同角色，至少选择一个普通账号检查权限边界。管理员能看到的按钮不该自动出现在普通账号页面。这里的判断仍然需要项目负责人参与，因为测试工具可以看到页面状态，却不知道某个角色在业务上究竟应有什么权限。
让脚本先观察页面，再开始操作
Webapp Testing Skill 面向本地网页应用，使用 Python Playwright 驱动浏览器。它的官方说明建议区分静态页面与动态应用：静态 HTML 可以先读源码找定位线索；动态页面则先启动服务、等待页面渲染，再通过截图或 DOM 观察实际状态，之后执行点击和输入。
这套顺序能减少一种常见误判。页面还在加载时，按钮可能尚未出现，或者已经出现但不能接收点击。Playwright 会在执行动作前检查元素是否可见、稳定、可用并能接收事件；定位器每次使用时也会重新查找当前 DOM 中的元素。脚本仍应选择稳定的目标，优先使用角色、标签文字或项目约定的测试标识，少依赖容易变化的层级和临时类名。
官方 Skill 还提供服务管理脚本，用来在测试前启动一个或多个本地服务。使用前应先运行帮助命令，确认端口、启动方式和依赖，再把 Playwright 逻辑放进独立脚本。测试结束后关闭浏览器和服务，避免下一轮检查受到残留进程影响。
失败以后，先保存现场
自动化检查最怕只留下一个红色的“失败”。表单提交没有成功时，至少保存当时的页面截图、浏览器控制台信息和相关请求线索。Playwright 的 Trace Viewer 还能按操作查看 DOM 快照、定位器、日志、网络请求和前后状态，适合追查失败发生在哪一步。
证据文件要和测试步骤放在一起。只截最终错误页，往往看不到前面的输入和跳转；只保存控制台日志，又可能缺少用户实际看到的提示。修复以后用相同输入重新执行原步骤，并保留新的结果。这样才能确认问题已经解决，而不是刚好换了一条路径避开了它。
上线检查记录可以这样收口
- 关键路径有明确起点、操作、预期结果和结束状态。
- 表单覆盖空值、错误格式、重复提交和服务端失败后的页面反馈。
- 登录覆盖错误凭据、会话保持、受保护页面与退出后的访问。
- 定位方式不依赖脆弱的页面层级，等待条件对应真实页面状态。
- 失败时保存截图、控制台和请求线索，修复后用原步骤复测。
Webapp Testing Skill 适合把这些检查整理成可重复执行的浏览器流程，也能帮助查看 DOM、截图和浏览器日志。它不会替代性能压测、安全审计、真实设备体验或业务权限判断。上线决定仍应由负责人根据失败严重程度、影响范围和剩余风险作出。
最后一次执行时，把脚本版本、测试环境和失败证据一并归档。下一次网站改版后，同一组关键路径就能直接拿来做回归检查。
