QA
建立视觉回归测试
针对关键界面状态的稳定截图检查，能抓到有意义的视觉变化，又不过度嘈杂。
流程
按这个顺序做。
- 选择关键页面和组件状态，包括响应断点、错误、空状态和交互状态。
- 通过固定浏览器、视口、字体、区域、时间、动画行为、数据和网络依赖，使渲染环境确定。
- 用稳定定位器实现截图断言，并遮罩或替换真正动态的区域。
- 在与持续比较相同的环境中生成基线，并人工审阅每张基线图。
- 反复运行比较以识别不稳定像素；调整就绪等待或窄而有据的容差，而不是大面积隐藏。
- 把套件和图像产物加入 CI，定义明确的基线更新审阅流程，并测试故意视觉变更会被捕获。
先准备
猫会向你要的输入。
- 可运行界面与关键状态
- 支持的浏览器与视口矩阵
- CI 环境
- 基线存储策略
路由器 + 一份 playbook
先路由。只选一份。
Cat Paw 每次任务只加载一份 playbook，不合并多份。先走这个路由器；其余路径是此 workflow 可检查的候选。
- 路由器：
engineering-pack skills/engineering/alirezarezvani/senior-qa/SKILL.mdskills/product/pm-execution/test-scenarios/SKILL.md
界限
界限跟着提示一起走。
- 未经人工审阅，绝不自动批准变更后的基线。
- 保持阈值和遮罩窄且有记录。
- 从截图排除密钥和个人数据。
完成代表
一个可核对的终点。
关键状态有已审阅基线，重复运行在 CI 中稳定，受控视觉变异会导致预期测试失败和差异产物。
来源
这个流程从哪来。
- playwright.dev/docs/test-snapshots
- learn.microsoft.com/en-us/azure/app-testing/playwright-workspaces/how-to-configure-visual-comparisons
来源确立 workflow 的模式。如有 Reddit 或社区帖子，视为实务轶事，不是普遍事实。
