qa-shift-left

该技能面向测试左移实践，说明如何在需求、设计、开发阶段提前介入以降低缺陷修复成本；包含验收标准模板、接口/数据/日志/配置四层可测试性清单、测试视角代码评审检查点、单元测试质量清单，以及左移实施后的核对项；阶段细节放在引用文档中按需加载。

kokxi

热度 59.59

最近更新 2026-09-29 12:30:02

分类：开发依赖：读写文件 / 代码执行应用场景：代码审查 / 工作流 / 模板 / 研究

安装技能

复制下面的话术发给你的 Agent，它会通过 secure-skills 检索并安装该技能。

执行命令安装此 skill： npx secure-skills-cli add qa-shift-left

Metadata

displayName: 测试左移
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: {"slug":"qa-shift-left","display-name":"测试左移","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，避免每次触发都占用上下文。

需求可测试性

验收标准模板

## 验收标准（AC）

### 功能描述
[功能的简要描述]

### 验收条件
- [ ] 条件1：[具体条件]
- [ ] 条件2：[具体条件]
- [ ] 条件3：[具体条件]

### 输入
- 正常输入：[示例]
- 异常输入：[示例]
- 边界输入：[示例]

### 输出
- 正常输出：[预期结果]
- 异常输出：[错误信息]
- 边界输出：[边界处理]

### 验证方法
- [ ] 手动测试
- [ ] 自动化测试
- [ ] 接口测试

可测试性检查清单

接口层：
├─ [ ] 接口是否可Mock？
├─ [ ] 接口是否有测试接口？
├─ [ ] 接口文档是否完整？
└─ [ ] 接口版本是否管理？

数据层：
├─ [ ] 数据是否可构造？
├─ [ ] 数据是否可清理？
├─ [ ] 数据是否可查询？
└─ [ ] 数据是否可隔离？

日志层：
├─ [ ] 关键路径是否有日志？
├─ [ ] 日志级别是否合理？
├─ [ ] 是否有TraceId？
└─ [ ] 日志是否可查询？

配置层：
├─ [ ] 功能开关是否支持？
├─ [ ] 配置是否可动态修改？
├─ [ ] 测试配置是否独立？
└─ [ ] 配置变更是否有记录？

代码评审检查点

测试视角的CR

检查点：
├─ 业务逻辑
│   ├─ 条件判断是否正确？
│   ├─ 边界条件是否处理？
│   ├─ 异常情况是否考虑？
│   └─ 数据校验是否完整？
│
├─ 异常处理
│   ├─ 异常是否捕获？
│   ├─ 异常信息是否明确？
│   ├─ 异常恢复是否实现？
│   └─ 异常日志是否记录？
│
├─ 日志记录
│   ├─ 关键操作是否有日志？
│   ├─ 日志级别是否合理？
│   ├─ 敏感信息是否脱敏？
│   └─ TraceId是否传递？
│
└─ 性能影响
    ├─ 是否有N+1查询？
    ├─ 是否有内存泄漏风险？
    ├─ 是否有并发问题？
    └─ 是否有性能瓶颈？

单元测试支持

单元测试检查清单

覆盖率：
├─ [ ] 核心逻辑覆盖？
├─ [ ] 分支覆盖？
├─ [ ] 边界覆盖？
└─ [ ] 异常覆盖？

质量：
├─ [ ] 测试命名清晰？
├─ [ ] 测试职责单一？
├─ [ ] 测试独立运行？
├─ [ ] 测试快速执行？
└─ [ ] 测试可维护？

输出示例

团队在需求评审阶段参与不足，导致上线后频繁需求变更 → 左移实践：

需求阶段：参与需求评审，定义验收标准（AC），推动可测试性检查
设计阶段：测试视角参与技术方案评审，识别设计缺陷
开发阶段：推动单元测试覆盖率，执行测试视角代码评审

用户说"怎么减少线上Bug" → 启动测试左移：从需求阶段开始介入，越早发现缺陷越便宜

检查清单

测试左移实施后检查：