返回技能市场

当项目还在需求阶段或者开发正在写代码时使用此技能——这时候介入能花最小的成本避免最多的缺陷。从需求可测试性评审(需求模糊/矛盾/不可测)、开发阶段测试设计(单元测试/接口契约/测试桩)和技术方案评审(影响面分析/风险识别)三个维度提前发现缺陷。越早发现 Bug 修复成本越低——需求阶段的 Bug 修复成本是线上阶段的 1/100。输出左移检查清单和阶段性介入记录。

版本: 1.0.1分类: 开发工具
中文

SKILL.md

⚠️ 本技能单独使用效果有限,建议配合完整技能集(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" → 启动测试左移:从需求阶段开始介入,越早发现缺陷越便宜

检查清单

测试左移实施后检查:

  • 需求评审是否参与?
  • 验收标准是否定义?
  • 可测试性是否评估?
  • 代码评审是否执行?
  • 单元测试是否支持?
  • 接口测试是否实施?

评论与讨论

0/2000

还没有评论,分享你的体验吧。