Qa Shift Left

SKILL.md

---
name: qa-shift-left
description: >-
  测试左移实践，将测试活动提前到需求分析和开发阶段。当用户需要实施测试左移、提前测试或评估需求可测试性时自动触发。
  也适用于：项目早期需要介入测试，或开发阶段需要测试指导时。
   关键词：测试左移、提前测试、需求可测试性、开发测试、需求评审、代码评审、单元测试、静态分析、缺陷预防。
when_to_use: 用户说"测试左移"、"左移"、"提前测试"、"需求可测试性"、"需求评审"、"开发阶段测"、需要将测试提前、项目早期需要介入测试时
allowed-tools: Read Grep Glob Bash
related_skills:
  upstream:
    - qa-req-deconstruction      # 输入：需求分析
    - qa-testability-advocacy    # 输入：可测试性推动
  downstream:
    - qa-code-review-for-test    # 输出：左移实践支持代码评审
    - qa-test-automation-arch    # 输出：左移实践影响自动化架构
input_format: 需求分析 + 可测试性评估
output_format: 测试左移方案（需求评审+代码评审+单元测试支持）
---

# 测试左移实践

## Overview

你是一位测试左移专家，擅长将测试活动提前到开发阶段。
**核心原则**：测试左移——越早发现缺陷，修复成本越低。
本技能覆盖需求阶段→设计阶段→开发阶段的左移实践和可测试性推动。

## 左移阶段

### 阶段1：需求阶段

```
测试活动：
├─ 需求评审
│   ├─ 参与需求评审会议
│   ├─ 从测试角度提出问题
│   ├─ 识别需求不清晰/矛盾点
│   └─ 评估需求可测试性
│
├─ 验收标准
│   ├─ 协助定义验收标准（AC）
│   ├─ 确保AC可测试、可自动化
│   ├─ 明确输入/输出/边界
│   └─ 识别隐含需求
│
└─ 可测试性评估
    ├─ 评估接口是否可Mock
    ├─ 评估日志是否可追踪
    ├─ 评估配置是否可动态
    └─ 评估数据是否可构造
```

### 阶段2：设计阶段

```
测试活动：
├─ 架构评审
│   ├─ 评估系统架构可测试性
│   ├─ 识别测试难点
│   ├─ 建议可测试设计
│   └─ 评估依赖服务Mock方案
│
├─ 接口设计评审
│   ├─ 评估接口设计合理性
│   ├─ 确认接口文档完整性
│   ├─ 评估错误码设计
│   └─ 评估版本兼容性
│
└─ 数据库设计评审
    ├─ 评估表结构设计
    ├─ 评估索引设计
    ├─ 评估数据迁移方案
    └─ 评估数据一致性
```

### 阶段3：开发阶段

```
测试活动：
├─ 代码评审
│   ├─ 从测试角度Review代码
│   ├─ 识别潜在Bug模式
│   ├─ 评估异常处理
│   └─ 评估日志记录
│
├─ 单元测试支持
│   ├─ 协助开发设计测试用例
│   ├─ 提供测试数据建议
│   ├─ 验证单元测试覆盖
│   └─ 评审单元测试质量
│
└─ 接口测试
    ├─ 编写接口测试用例
    ├─ 验证接口契约
    ├─ 测试接口边界条件
    └─ 执行接口自动化测试
```

## 需求可测试性

### 验收标准模板

```markdown
## 验收标准（AC）

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

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

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

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

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

### 可测试性检查清单

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

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

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

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

## 代码评审检查点

### 测试视角的CR

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

## 单元测试支持

### 单元测试检查清单

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

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

## Examples

**团队在需求评审阶段参与不足，导致上线后频繁需求变更**
→ 左移实践：
  - 需求阶段：参与需求评审，定义验收标准（AC），推动可测试性检查
  - 设计阶段：测试视角参与技术方案评审，识别设计缺陷
  - 开发阶段：推动单元测试覆盖率，执行测试视角代码评审

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

## Guidelines

测试左移实施后检查：
- [ ] 需求评审是否参与？
- [ ] 验收标准是否定义？
- [ ] 可测试性是否评估？
- [ ] 代码评审是否执行？
- [ ] 单元测试是否支持？
- [ ] 接口测试是否实施？