Playwright UI 自动化测试：用稳定定位与受控数据构建可靠回归
Playwright UI 测试指南：使用可观察状态、稳定定位器和隔离数据构建回归检查，让失败能定位到用户可见的问题。
#AI 测试
dsh-qa v0.2.0 更新：从测试看板走向可追溯的质量控制工作台
回顾 dsh-qa 从 v0.1.3 到 v0.2.0 的关键更新：双语工作台、QA Skill 生命周期，以及以来源快照、受控执行、证据包和计算型门禁组成的质量控制闭环。
缺陷上报：把“偶尔失败”变成开发可以稳定复现的问题
记录发生时间、账号状态、请求链路、实际结果和影响，把偶发故障整理成可复现、可排优先级的缺陷。
测试数据生成：系统覆盖正常、边界、异常与权限场景
围绕余额不足、租户边界、优惠券过期和日期临界值生成可复现数据，避免引入生产敏感信息。
测试报告：从测试结果到真正可执行的质量结论
把测试执行结果转成发布判断，交代覆盖范围、失败影响、剩余风险及由谁接受风险。
测试用例评审：找出覆盖缺口、模糊断言与高风险场景
检查测试用例的覆盖缺口、重复步骤、不可执行前置条件和模糊断言，并给出位置、影响和修改建议。
测试用例评审加强版：跨需求、用例与证据追踪高风险缺口
对照需求、风险清单和现有用例，追踪材料冲突与高风险覆盖缺口，让每项发现都能回到来源。
测试用例编写加强版：让需求、规则与测试用例全程可追溯
编写用例前先登记需求、接口规则和风险来源，解决版本冲突，并让每条用例都能追溯到依据。
可访问性测试：从键盘操作到完整用户体验的系统化验证
以结账流程为例检查键盘导航、焦点顺序、表单标签、错误反馈和读屏可感知状态，并将问题关联到具体控件、用户影响和可修复证据，而非只依赖自动扫描结论。
移动端测试：系统覆盖弱网、权限与应用生命周期场景
覆盖弱网恢复、权限变化、系统中断和应用重启，发现移动端状态恢复与重复请求问题。
测试用例编写：从验收标准到可执行、可验证的测试用例
从订单验收标准出发，将业务规则拆成带前置条件、数据、步骤和预期结果的测试用例；保留需求追溯，并标出缺失规则而不擅自补全。示例也说明信息不足时如何提出待确认问题。
功能测试：从业务链路出发，系统化设计测试场景
围绕下单、支付、取消与退款的订单生命周期，梳理状态转换、异常分支和恢复路径，形成可追踪、可执行的功能测试场景。示例把状态变化关联到前置条件和预期结果。