Qa Testability Advocacy

SKILL.md

---
name: qa-testability-advocacy
version: 1.6.0
description: >-
  当测试发现"这个功能测不了"、"加个日志就能定位"、"这个模块没法 Mock"时使用此技能。从可控性（能否控制测试条件）、可观察性（能否看到内部状态）、可隔离性（能否独立测试）、自动化性和可诊断性五个维度评估系统的可测试性水平，给出具体的系统改进建议和推动策略。可测试性差的系统一定质量差——不是因为系统本身不好，是因为你根本测不透它。输出可测试性评估报告和各维度的改造建议。 ⚠️ 本技能含废弃测试清理建议，执行前请确认非关键数据。
when_to_use: 用户说"可测试性"、"难测"、"不好测"、"测试推动"、"架构改进"、"可测性评审"、需要评估可测试性、需要推动架构改进可测试性时
allowed-tools: Read Grep Glob
related_skills:
  upstream:
    - qa-quality-metrics         # 输入：质量趋势识别改进点
    - qa-execution-observation   # 输入：执行中发现的可测试性问题
  downstream:
    - qa-test-env-data           # 输出：推动环境和数据可测试性改进
    - qa-shift-left
input_format:
  required:
    - name: 测试策略
      type: object
      description: 来自qa-test-strategy-design的测试策略
    - name: 架构设计
      type: string
      description: 系统架构设计文档
  optional:
    - name: 代码库访问
      type: string
      description: 代码库路径和结构
output_format:
  traceability:
    - 每项推动建议带唯一ID（ADV-XXXX）
  structure:
    - testability_assessment: 可测试性评估报告
    - improvement_suggestions: 改进建议
    - refactoring_guide: 重构指南
    - best_practices: 可测试性最佳实践
categories: ['Development','Testing','DevOps']
depth_requirement_quantification:
  reference_value: "根据系统问题调整推动深度：简单×1/中等×2/复杂×3"
  minimum: "至少识别3个可测试性问题并提出改进建议"
error_recovery_guidance:
  on_failure: "可测试性推动遗漏问题时回退到代码评审补充"
  retry_behavior: "补充评审后重新推动改进"
---
# 可测试性推动

## 核心原则

在架构评审阶段就能识别可测试性问题，推动开发做可测试设计。

## 可测试性检查维度

### 维度1：接口层可测试性

```text
检查点：
├─ Mock点：是否有Mock接口？
│   ├─ 外部依赖是否可Mock
│   ├─ 第三方服务是否可Mock
│   └─ 数据库是否可Mock
│
├─ 测试接口：是否有测试专用接口？
│   ├─ 数据初始化接口
│   ├─ 数据清理接口
│   └─ 状态查询接口
│
├─ 接口文档：接口文档是否完整？
│   ├─ 入参/出参定义
│   ├─ 错误码定义
│   └─ 示例数据
│
└─ 接口版本：接口版本管理？
    ├─ 向后兼容
    └─ 版本切换
```

### 维度2：数据层可测试性

```text
检查点：
├─ 数据构造：测试数据能否方便构造？
│   ├─ 数据工厂模式
│   ├─ 测试数据生成器
│   └─ 批量数据导入
│
├─ 数据清理：测试数据能否方便清理？
│   ├─ 测试后自动清理
│   ├─ 按用例隔离
│   └─ 按模块隔离
│
├─ 数据隔离：测试数据能否隔离？
│   ├─ 测试环境独立
│   ├─ 测试库独立
│   └─ 测试账户独立
│
└─ 数据查询：能否方便查询数据状态？
    ├─ 数据状态查询接口
    ├─ 数据变更日志
    └─ 数据快照
```

### 维度3：日志层可测试性

```text
检查点：
├─ 关键路径日志：关键操作是否有日志？
│   ├─ 业务操作日志
│   ├─ 数据变更日志
│   └─ 异常处理日志
│
├─ 日志级别：日志级别是否合理？
│   ├─ DEBUG：调试信息
│   ├─ INFO：业务信息
│   ├─ WARN：警告信息
│   └─ ERROR：错误信息
│
├─ TraceId：是否有链路追踪？
│   ├─ 请求唯一标识
│   ├─ 跨服务追踪
│   └─ 日志关联
│
└─ 日志查询：能否方便查询日志？
    ├─ 日志平台
    ├─ 日志搜索
    └─ 日志分析
```

### 维度4：配置层可测试性

```text
检查点：
├─ 功能开关：是否有功能开关？
│   ├─ 新功能开关
│   ├─ 实验功能开关
│   └─ 灰度开关
│
├─ 配置动态化：配置能否动态修改？
│   ├─ 运行时配置
│   ├─ 热更新配置
│   └─ 配置回滚
│
├─ 测试配置：是否有测试专用配置？
│   ├─ 测试环境配置
│   ├─ Mock配置
│   └─ 超时配置
│
└─ 配置文档：配置项文档是否完整？
    ├─ 配置项说明
    ├─ 默认值说明
    └─ 影响范围说明
```

### 维度5：依赖层可测试性

```text
检查点：
├─ 外部依赖：外部依赖能否Mock？
│   ├─ 第三方接口Mock
│   ├─ 消息队列Mock
│   └─ 缓存服务Mock
│
├─ 服务依赖：服务依赖能否隔离？
│   ├─ 服务虚拟化
│   ├─ 契约测试
│   └─ 集成测试环境
│
├─ 数据库依赖：数据库依赖能否Mock？
│   ├─ 内存数据库
│   ├─ 测试数据库
│   └─ 数据库快照
│
└─ 降级方案：依赖异常时能否降级？
    ├─ 熔断机制
    ├─ 降级策略
    └─ 容错处理
```

## 可测试性评估表

| 维度 | 检查点 | 现状 | 目标 | 差距 | 改进措施 |
|------|--------|------|------|------|---------|
| 接口层 | Mock点 | 无 | 有 | 大 | 开发Mock接口 |
| 数据层 | 数据构造 | 手动 | 自动 | 中 | 开发数据工厂 |
| 日志层 | TraceId | 无 | 有 | 大 | 接入链路追踪 |
| 配置层 | 功能开关 | 无 | 有 | 中 | 开发开关平台 |
| 依赖层 | 服务Mock | 无 | 有 | 大 | 开发服务虚拟化 |

## 可测试性改进建议

### 短期改进（1-2周）
```text
├─ 接口层：添加测试接口
├─ 数据层：编写数据构造脚本
├─ 日志层：添加关键路径日志
├─ 配置层：添加测试配置项
└─ 依赖层：配置Mock数据
```

### 中期改进（1-2月）
```text
├─ 接口层：开发Mock平台
├─ 数据层：开发数据工厂
├─ 日志层：接入链路追踪
├─ 配置层：开发开关平台
└─ 依赖层：开发服务虚拟化
```

### 长期改进（3-6月）
```text
├─ 接口层：契约测试平台
├─ 数据层：测试数据管理平台
├─ 日志层：日志分析平台
├─ 配置层：配置中心
└─ 依赖层：服务治理平台
```

## 应用场景

**评审订单系统的架构设计**
→ 接口层可测试性：订单接口是否支持Mock？是否有测试桩？
→ 数据层可测试性：数据库是否支持事务回滚？测试数据隔离？
→ 日志层可测试性：关键操作是否打印日志？日志级别是否可配置？
→ 配置层可测试性：功能开关是否支持动态配置？第三方服务地址是否可配置？
→ 依赖层可测试性：依赖服务是否有Mock方案？是否支持降级？

**开发说"这个不好测"**
→ 启动可测试性评估，逐维度分析，给出具体改进建议和沟通话术

## 自检清单

可测试性评估完成后检查：
- [ ] 是否评估了五个维度？
- [ ] 是否识别了差距？
- [ ] 是否制定了改进计划？
- [ ] 改进措施是否可行？
- [ ] 是否有时间计划？


## 检查清单

- [ ] 可测试性问题是否识别？
- [ ] 影响面是否评估？
- [ ] 改进建议是否可行？
- [ ] 优先级是否标注？
- [ ] 推动策略是否制定？