> ⚠️ 本技能单独使用效果有限，建议配合完整技能集（12 步工作流）使用。安装：npx skills add Kokxi/qa-test-skills

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

技术债务管理

核心原则

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

技术债务类型

自动化债务

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

测试债务

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

架构债务

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

债务评估

评估维度

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

评估矩阵

加载时机

> 债务治理的完整内容已下沉至 references/debt-governance.md，避免每次触发都占用上下文。

债务预防

预防措施

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

债务看板

## 技术债务看板

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

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

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

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

输出示例

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

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

检查清单

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