测试技术债管理

SKILL.md

---
name: qa-tech-debt-management
slug: qa-tech-debt-management
displayName: 测试技术债管理
version: 1.7.5
description: >-
  当自动化用例频繁维护、跑一次就倒下一批、或者发现团队的测试资产维护成本越来越高时使用此技能。系统化识别测试自动化债务和测试资产技术债，评估每项债务的利息（维护成本）和本金（重写成本），给出分阶段的还款规划。不要追着 flaky test 修——技术债务管理解决的是"为什么有这么多 flaky test"的系统性问题。
  本技能属于 QA Test Skills 技能集（49 个技能之一），完整工作流体验需安装全套：npx skills add Kokxi/qa-test-skills

when_to_use: 用户说"技术债务"、"测试债务"、"自动化债务"、"重构"、"债务治理"、"维护成本"、需要管理技术债务、自动化维护成本高需要评估时
allowed-tools: Read Grep Glob Bash
related_skills:
  upstream:
    - qa-test-automation-arch    # 输入：自动化架构评估
    - qa-quality-metrics         # 输入：质量度量数据
  downstream:
    - qa-retrospective           # 输出：债务分析用于复盘
    - qa-test-strategy-design    # 输出：债务治理影响测试策略
input_format:
  required:
    - name: 测试报告
      type: object
      description: 来自qa-test-reporting的测试报告
    - name: 代码质量数据
      type: object
      description: 代码质量分析数据
  optional:
    - name: 历史基线
      type: object
      description: 历史技术债务基线
output_format:
  traceability:
    - 本技能评估债务，每个债务项沿用关联的缺陷ID或自动化架构ID
  structure:
    - 测试用例表格：固定 9 列（用例编号|测试类型|功能模块|测试标题|用例级别|预置条件|测试步骤|预期结果|风险等级）
    - 用例级别：P0≤20%（核心流程）/ P1≤40%（主要功能）/ P2≤30%（次要功能）/ P3≤10%（边缘场景）
    - 覆盖率：标注口径（基于现有需求/输入文档），禁止"全覆盖/100%"绝对化表述；缺失模块标注"未覆盖+原因"
    - debt_inventory: 技术债务清单
    - impact_analysis: 影响分析
    - repayment_plan: 偿还计划
    - prevention_strategies: 预防策略
categories: ['Development','Testing']
depth_requirement_quantification:
  reference_value: "根据债务规模调整治理深度：简单×1/中等×2/复杂×3"
  minimum: "至少完成债务识别、成本评估、治理优先级3步"
error_recovery_guidance:
  on_failure: "债务治理遗漏高优债务时回退到质量度量补充数据"
  retry_behavior: "补充数据后重新评估治理优先级"
---
> ⚠️ 本技能单独使用效果有限，建议配合完整技能集（12 步工作流）使用。安装：npx skills add Kokxi/qa-test-skills

> **⚠️ 安全警告**：本技能的示例可能涉及发布阻塞评估和线上问题影响分析。
> 实际使用时请勿直接基于评估结论阻塞发布或下线功能，先与开发和产品确认风险。
> 本技能仅在 workspace/ 输出评估文件，不持久化、不外传、不跨会话复用。

# 技术债务管理

## 核心原则

技术债务是不可避免的，关键是要识别、评估、并有计划地偿还。

## 技术债务类型

### 自动化债务

```text
债务表现：
├─ 自动化脚本不稳定
│   ├─ 频繁失败（假阳性）
│   ├─ 执行时间过长
│   └─ 维护成本高
│
├─ 自动化覆盖不足
│   ├─ 核心流程未覆盖
│   ├─ 边界场景未覆盖
│   └─ 异常场景未覆盖
│
├─ 框架问题
│   ├─ 框架版本过旧
│   ├─ 框架设计不合理
│   └─ 框架文档缺失
│
└─ 代码质量
    ├─ 代码重复
    ├─ 代码复杂度高
    └─ 代码可读性差
```

### 测试债务

```text
债务表现：
├─ 用例问题
│   ├─ 用例过时
│   ├─ 用例冗余
│   ├─ 用例覆盖不足
│   └─ 用例维护困难
│
├─ 流程问题
│   ├─ 测试流程不规范
│   ├─ 测试执行不彻底
│   ├─ 缺陷管理混乱
│   └─ 回归测试不充分
│
└─ 环境问题
    ├─ 测试环境不稳定
    ├─ 测试数据不足
    ├─ 测试工具落后
    └─ 测试基础设施薄弱
```

### 架构债务

```text
债务表现：
├─ 可测试性差
│   ├─ 接口不可Mock
│   ├─ 日志不完整
│   ├─ 配置不灵活
│   └─ 数据不可构造
│
├─ 测试架构问题
│   ├─ 分层不清晰
│   ├─ 职责不单一
│   ├─ 扩展性差
│   └─ 可维护性差
│
└─ 集成问题
    ├─ CI/CD集成不完善
    ├─ 报告不规范
    ├─ 监控不完善
    └─ 工具链不统一
```

## 债务评估

### 评估维度

```text
├─ 影响度
│   ├─ 对测试效率的影响
│   ├─ 对测试质量的影响
│   ├─ 对团队士气的影响
│   └─ 对交付速度的影响
│
├─ 紧迫度
│   ├─ 是否阻塞当前工作
│   ├─ 是否影响发布
│   ├─ 是否导致线上问题
│   └─ 是否影响团队效率
│
├─ 解决成本
│   ├─ 人力成本
│   ├─ 时间成本
│   ├─ 风险成本
│   └─ 机会成本
│
└─ 解决收益
    ├─ 效率提升
    ├─ 质量提升
    ├─ 成本降低
    └─ 风险降低
```

### 评估矩阵

| 债务类型 | 影响度 | 紧迫度 | 解决成本 | 解决收益 | 优先级 |
|---------|--------|--------|---------|---------|--------|
| 自动化不稳定 | 高 | 高 | 中 | 高 | P0 |
| 用例过时 | 中 | 中 | 低 | 中 | P1 |
| 框架版本旧 | 中 | 低 | 高 | 中 | P2 |
| 文档缺失 | 低 | 低 | 低 | 低 | P3 |

## 债务治理

### 治理策略

```text
├─ 立即解决（P0）
│   ├─ 阻塞性问题
│   ├─ 线上问题
│   └─ 效率严重下降
│
├─ 计划解决（P1）
│   ├─ 影响当前迭代
│   ├─ 影响团队效率
│   └─ 风险较高
│
├─ 逐步解决（P2）
│   ├─ 不影响当前工作
│   ├─ 可以规划解决
│   └─ 成本较高
│
└─ 持续监控（P3）
    ├─ 影响较小
    ├─ 成本较高
    └─ 可以接受
```

### 治理方法

```text
自动化债务治理：
├─ 脚本稳定化
│   ├─ 修复假阳性
│   ├─ 优化等待策略
│   ├─ 增加重试机制
│   └─ 改进错误处理
│
├─ 覆盖提升
│   ├─ 补充核心流程
│   ├─ 补充边界场景
│   ├─ 补充异常场景
│   └─ 优化测试数据
│
└─ 框架升级
    ├─ 版本升级
    ├─ 架构优化
    ├─ 文档完善
    └─ 工具统一

测试债务治理：
├─ 用例优化
│   ├─ 清理过时用例
│   ├─ 合并冗余用例
│   ├─ 补充覆盖不足
│   └─ 改进可维护性
│
├─ 流程改进
│   ├─ 规范测试流程
│   ├─ 完善执行标准
│   ├─ 改进缺陷管理
│   └─ 优化回归策略
│
└─ 环境改善
    ├─ 稳定测试环境
    ├─ 补充测试数据
    ├─ 升级测试工具
    └─ 完善基础设施

架构债务治理：
├─ 可测试性改进
│   ├─ 接口Mock化
│   ├─ 日志完善
│   ├─ 配置动态化
│   └─ 数据构造化
│
├─ 架构优化
│   ├─ 分层清晰化
│   ├─ 职责单一化
│   ├─ 扩展性提升
│   └─ 可维护性提升
│
└─ 集成完善
    ├─ CI/CD完善
    ├─ 报告规范化
    ├─ 监控完善
    └─ 工具链统一
```

## 债务预防

### 预防措施

```text
├─ 代码质量
│   ├─ 代码评审
│   ├─ 静态分析
│   ├─ 测试覆盖
│   └─ 重构习惯
│
├─ 流程规范
│   ├─ 流程文档化
│   ├─ 执行标准化
│   ├─ 定期Review
│   └─ 持续改进
│
├─ 团队能力
│   ├─ 培训提升
│   ├─ 知识共享
│   ├─ 经验沉淀
│   └─ 最佳实践
│
└─ 工具支持
    ├─ 工具自动化
    ├─ 工具标准化
    ├─ 工具维护
    └─ 工具升级
```

## 债务看板

```markdown
## 技术债务看板

### P0（立即解决）
- [ ] 自动化脚本频繁失败
- [ ] 测试环境不稳定

### P1（计划解决）
- [ ] 核心流程自动化覆盖不足
- [ ] 用例过时需要更新

### P2（逐步解决）
- [ ] 框架版本需要升级
- [ ] 测试数据管理需要改进

### P3（持续监控）
- [ ] 测试文档需要完善
- [ ] 工具链需要统一
```

## 输出示例

**测试团队的UI自动化用例维护成本越来越高（每次迭代要改30%的用例）**
→ 技术债务识别：自动化债务（页面元素频繁变化→定位策略脆弱）
→ 评估：维护成本=每次2人天，预估治理后降低到0.5人天
→ 治理：重构定位策略（CSS→自定义属性），统一Page Object模式
→ 预防：制定自动化规范，新增功能必须添加自定义属性

**代码覆盖率从80%降到了60%**
→ 识别测试债务：增量代码缺乏单元测试覆盖
→ 排期治理：每迭代拿出20%容量偿还测试债务

## 检查清单

技术债务管理完成后检查：
- [ ] 债务是否识别完整？
- [ ] 债务评估是否准确？
- [ ] 治理策略是否制定？
- [ ] 治理计划是否执行？
- [ ] 预防措施是否实施？
- [ ] 债务看板是否维护？