qa-shift-left

--- name: qa-shift-left description: >- 当项目还在需求阶段或者开发正在写代码时使用此技能——这时候介入能花最小的成本避免最多的缺陷。从需求可测试性评审（需求模糊/矛盾/不可测）、开发阶段测试设计（单元测试/接口契约/测试桩）和技术方案评审（影响面分析/风险识别）三个维度提前发现缺陷。越早发现 Bug 修复成本越低——需求阶段的 Bug 修复成本是线上阶段的 1/100。输出左移检查清单和阶段性介入记录。 触发场景：测试左移、左移、提前测试、需求可测试性（左移阶段）、需求评审（左移介入）、开发阶段测、项目早期需要介入测试时。 Use when the user asks about: shifting testing left into requirements and development — requirement testability review, test design during development, and technical design review. license: MIT allowed-tools: Read Grep Glob Bash metadata: display-name: "Shift Left" version: "1.8.0" when-to-use: "用户说\"测试左移\"、\"左移\"、\"提前测试\"、\"需求可测试性（左移阶段）\"、\"需求评审（左移介入）\"、\"开发阶段测\"、需要将测试提前、项目早期需要介入测试时" related-skills: "{\"upstream\":[\"qa-req-deconstruction\",\"qa-testability-advocacy\"],\"downstream\":[\"qa-code-review-for-test\",\"qa-test-automation-arch\"]}" references: "[\"references/shift-left-stages.md\"]" input-format: "{\"required\":[{\"name\":\"项目计划\",\"type\":\"string\",\"description\":\"项目时间线和阶段规划\"},{\"name\":\"质量目标\",\"type\":\"string\",\"description\":\"项目质量目标和标准\"}],\"optional\":[{\"name\":\"团队能力\",\"type\":\"string\",\"description\":\"团队测试技能评估\"}]}" output-format: "{\"traceability\":[\"本技能规划左移，不产出唯一ID；可溯源到需求评审ID\"],\"structure\":[{\"shift_left_plan\":\"左移测试计划\"},{\"early_activities\":\"早期介入活动清单\"},{\"quality_gates_early\":\"前置质量门禁\"},{\"team_enablement\":\"团队赋能计划\"}]}" error-recovery-guidance: "{\"on_failure\":\"左移介入遗漏可测试性问题时回退到需求评审补充\",\"retry_behavior\":\"补充评审后重新评估左移点\"}" categories: "[\"Development\",\"Testing\",\"DevOps\"]" depth-requirement: "{\"reference_value\":\"根据介入阶段调整左移深度：简单×1/中等×2/复杂×3\",\"minimum\":\"至少覆盖需求可测试性评审、开发阶段测试2个介入点\"}" --- > ⚠️ 本技能单独使用效果有限，建议配合完整技能集（12 步工作流）使用。安装：npx skills add Kokxi/qa-test-skills # 测试左移实践 ## 核心原则 测试左移——越早发现缺陷，修复成本越低。 ## 加载时机 | 什么时候读 | 读哪个 | |-----------|--------| | 介入需求/设计/开发阶段时 | [`references/shift-left-stages.md`](references/shift-left-stages.md) | > `左移阶段`的完整内容已下沉至 `references/shift-left-stages.md`，避免每次触发都占用上下文。 ## 需求可测试性 ### 验收标准模板 ```markdown ## 验收标准（AC） ### 功能描述 [功能的简要描述] ### 验收条件 - [ ] 条件1：[具体条件] - [ ] 条件2：[具体条件] - [ ] 条件3：[具体条件] ### 输入 - 正常输入：[示例] - 异常输入：[示例] - 边界输入：[示例] ### 输出 - 正常输出：[预期结果] - 异常输出：[错误信息] - 边界输出：[边界处理] ### 验证方法 - [ ] 手动测试 - [ ] 自动化测试 - [ ] 接口测试 ``` ### 可测试性检查清单 ```text 接口层： ├─ [ ] 接口是否可Mock？ ├─ [ ] 接口是否有测试接口？ ├─ [ ] 接口文档是否完整？ └─ [ ] 接口版本是否管理？ 数据层： ├─ [ ] 数据是否可构造？ ├─ [ ] 数据是否可清理？ ├─ [ ] 数据是否可查询？ └─ [ ] 数据是否可隔离？ 日志层： ├─ [ ] 关键路径是否有日志？ ├─ [ ] 日志级别是否合理？ ├─ [ ] 是否有TraceId？ └─ [ ] 日志是否可查询？ 配置层： ├─ [ ] 功能开关是否支持？ ├─ [ ] 配置是否可动态修改？ ├─ [ ] 测试配置是否独立？ └─ [ ] 配置变更是否有记录？ ``` ## 代码评审检查点 ### 测试视角的CR ```text 检查点： ├─ 业务逻辑 │ ├─ 条件判断是否正确？ │ ├─ 边界条件是否处理？ │ ├─ 异常情况是否考虑？ │ └─ 数据校验是否完整？ │ ├─ 异常处理 │ ├─ 异常是否捕获？ │ ├─ 异常信息是否明确？ │ ├─ 异常恢复是否实现？ │ └─ 异常日志是否记录？ │ ├─ 日志记录 │ ├─ 关键操作是否有日志？ │ ├─ 日志级别是否合理？ │ ├─ 敏感信息是否脱敏？ │ └─ TraceId是否传递？ │ └─ 性能影响 ├─ 是否有N+1查询？ ├─ 是否有内存泄漏风险？ ├─ 是否有并发问题？ └─ 是否有性能瓶颈？ ``` ## 单元测试支持 ### 单元测试检查清单 ```text 覆盖率： ├─ [ ] 核心逻辑覆盖？ ├─ [ ] 分支覆盖？ ├─ [ ] 边界覆盖？ └─ [ ] 异常覆盖？ 质量： ├─ [ ] 测试命名清晰？ ├─ [ ] 测试职责单一？ ├─ [ ] 测试独立运行？ ├─ [ ] 测试快速执行？ └─ [ ] 测试可维护？ ``` ## 输出示例 **团队在需求评审阶段参与不足，导致上线后频繁需求变更** → 左移实践： - 需求阶段：参与需求评审，定义验收标准（AC），推动可测试性检查 - 设计阶段：测试视角参与技术方案评审，识别设计缺陷 - 开发阶段：推动单元测试覆盖率，执行测试视角代码评审 **用户说"怎么减少线上Bug"** → 启动测试左移：从需求阶段开始介入，越早发现缺陷越便宜 ## 检查清单 测试左移实施后检查： - [ ] 需求评审是否参与？ - [ ] 验收标准是否定义？ - [ ] 可测试性是否评估？ - [ ] 代码评审是否执行？ - [ ] 单元测试是否支持？ - [ ] 接口测试是否实施？

存档时间线

版本索引永久保留；内容副本只保留最新 1 份，更早版本仅留索引与哈希（存档时间线的证据链不会因此断裂）。

下载存档内容副本

相关资产