测试覆盖缺口分析

问题：测试清单越拉越长，缺口却没人说得清

功能一多，最常见的困境不是“不写测试”，而是没人能回答：这个页面测过吗？那条支付链路有回归用例吗？ 团队可能积累了上百个 *.spec.ts，但覆盖面是靠记忆维持的——接手的人只能靠猜，回归测试里漏掉 checkout 关键路径的事时有发生。事后补测往往意味着更高的修复成本。

coverage 这个技能就是为了把这件事讲清楚：先给应用做一次全量体检，再告诉你哪里是真空地带。

它如何工作

整个流程分为四个阶段：

• 盘点应用表面：借助 Explore subagent 扫描路由配置（app/、React Router 或 Vue Router）、组件树和 API 控制器，列出所有页面路径、交互组件与端点方法，并标注关键用户流程，比如登录、下单。
• 归集现有测试：解析全部 *.spec.ts / *.spec.js，根据 page.goto()、定位器用法和接口 mock 情况，推断每段代码背后有多少用例在支撑。
• 生成覆盖矩阵：把应用表面和已有测试对齐，按区域统计用例密度，得出粗略的覆盖率百分比。
• 排定优先级并出计划：按业务影响把缺口分为 Critical（认证、支付）、High（CRUD、搜索）、Medium（设置、偏好）和 Low（静态页），每个缺口给出建议的用例数量、模板推荐和工作量预估（quick / medium / complex），最后可选择调用 /pw:generate 自动生成前 N 个缺口的测试。

适用边界与注意点

• 它是只读分析，不是测试框架：技能本身只输出矩阵、缺口清单和预估，真正的测试代码要交给 /pw:generate 或人工完成。
• 路由识别依赖约定：框架层面的特殊配置，比如动态段或自定义路由守卫，可能不会被完整枚举，结果需要人工复核。
• 模板质量决定自动生成的效果：templates/ 目录中的样板如果和你的工程栈不匹配，生成出来的用例多半要返工。
• 优先依赖 source map 和符号信息：如果原作者只用 E2E 覆盖了表层路径，深层逻辑（如状态管理、工具函数）的缺口不会被自动暴露，这类盲区要靠单元测试补齐。

简单说，它适合在写新功能前做一次覆盖面盘点，或者在重构前帮你圈出风险最高的无测区域；但指望它替代完整的测试策略，那还远远不够。