qa-tech-debt-management

面向 QA 团队的技术债管理方法论技能，帮助识别自动化债务、测试债务与架构债务，从影响度、紧迫度、解决成本与收益四个维度评估并划分 P0 至 P3 优先级，给出分阶段偿还计划、预防措施与债务看板。完整治理内容下沉至引用文件，正文提供分类框架与检查清单，未附带可执行脚本，评估结论需与开发和产品确认风险。

kokxi

热度 59.94

最近更新 2026-09-29 12:30:49

分类：数据依赖：读写文件 / 代码执行应用场景：报告撰写 / 工作流 / 任务管理 / 自动化脚本

安装技能

复制下面的话术发给你的 Agent，它会通过 secure-skills 检索并安装该技能。

执行命令安装此 skill： npx secure-skills-cli add qa-tech-debt-management

Metadata

displayName: 测试技术债管理
name: qa-tech-debt-management
description: 当自动化用例频繁维护、跑一次就倒下一批、或者发现团队的测试资产维护成本越来越高时使用此技能。系统化识别测试自动化债务和测试资产技术债，评估每项债务的利息（维护成本）和本金（重写成本），给出分阶段的还款规划。不要追着 flaky test 修——技术债务管理解决的是"为什么有这么多 flaky test"的系统性问题。触发场景：技术债务、测试债务、自动化债务、重构、债务治理、维护成本、自动化维护成本高需要评估时。 Use when the user asks about: test automation and test asset technical debt — interest versus principal, flaky test triage, and staged repayment plans.
license: MIT
allowed-tools: Read Grep Glob Bash
metadata: {"slug":"qa-tech-debt-management","display-name":"测试技术债管理","version":"1.8.0","when-to-use":"用户说\"技术债务\"、\"测试债务\"、\"自动化债务\"、\"重构\"、\"债务治理\"、\"维护成本\"、需要管理技术债务、自动化维护成本高需要评估时","related-skills":"{\"upstream\":[\"qa-test-automation-arch\",\"qa-quality-metrics\"],\"downstream\":[\"qa-retrospective\",\"qa-test-strategy-design\"]}","references":"[\"references/debt-governance.md\"]","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\":[\"覆盖率：标注口径（基于现有需求/输入文档），禁止\\\"全覆盖/100%\\\"绝对化表述；缺失模块标注\\\"未覆盖+原因\\\"\",{\"debt_inventory\":\"技术债务清单\"},{\"impact_analysis\":\"影响分析\"},{\"repayment_plan\":\"偿还计划\"},{\"prevention_strategies\":\"预防策略\"}]}","error-recovery-guidance":"{\"on_failure\":\"债务治理遗漏高优债务时回退到质量度量补充数据\",\"retry_behavior\":\"补充数据后重新评估治理优先级\"}","categories":"[\"Development\",\"Testing\"]","depth-requirement":"{\"reference_value\":\"根据债务规模调整治理深度：简单×1/中等×2/复杂×3\",\"minimum\":\"至少完成债务识别、成本评估、治理优先级3步\"}"}

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

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

技术债务管理

核心原则

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

技术债务类型

自动化债务

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

测试债务

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

架构债务

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

债务评估

评估维度

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

评估矩阵

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

加载时机

什么时候读	读哪个
识别/评估/偿还测试债时	`references/debt-governance.md`

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

债务预防

预防措施

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

债务看板

## 技术债务看板

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

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

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

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

输出示例

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

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

检查清单

技术债务管理完成后检查：