Coding

测试估算

Try it

当项目经理问"这个版本多久测完"或者需要给测试排期做资源规划时使用此技能。基于需求复杂度、变更范围和历史数据系统化估算测试人天,输出包含冒烟/功能/回归/专项的逐阶段预估。不要拍脑袋——估算必须有依据(复杂度分级 + 历史基线 + 风险系数),同时标注置信度区间和风险预留。 本技能属于 QA Test Skills 技能集(49 个技能之一),完整工作流体验需安装全套:npx skills add Kokxi/qa-test-skills

What it does

当项目经理问"这个版本多久测完"或者需要给测试排期做资源规划时使用此技能。基于需求复杂度、变更范围和历史数据系统化估算测试人天,输出包含冒烟/功能/回归/专项的逐阶段预估。不要拍脑袋——估算必须有依据(复杂度分级 + 历史基线 + 风险系数),同时标注置信度区间和风险预留。 本技能属于 QA Test Skills 技能集(49 个技能之一),完整工作流体验需安装全套:npx skills add Kokxi/qa-test-skills

The skill document

⚠️ 安全警告:本技能的示例可能涉及发布计划和工作量排期估算。 这些是估算参考不是直接操作;请勿未经项目经理确认即变更发布计划或排期。 本技能仅在 workspace/ 输出评估文件,不持久化、不外传、不跨会话复用。

测试工作量估算

核心原则

估算不是猜测,而是基于数据和经验的科学推断。

估算方法

1. 功能点法

原理:基于功能点数量估算

步骤

  1. 识别功能点
  2. 评估复杂度(简单/中等/复杂)
  3. 给每个功能点赋予权重
  4. 计算总工作量

功能点权重

  • 简单功能:1人时/功能点
  • 中等功能:2人时/功能点
  • 复杂功能:4人时/功能点

示例

功能点数量复杂度权重工作量
用户注册1中等22人时
用户登录1简单11人时
订单创建1复杂44人时
订单查询1中等22人时
合计4--9人时

2. 用例法

原理:基于用例数量估算

步骤:
1. 评估用例总数
2. 评估用例类型比例
3. 计算各类用例执行时间
4. 汇总总工作量

用例执行时间:
├─ 冒烟用例:5分钟/条
├─ 功能用例:10分钟/条
├─ 边界用例:15分钟/条
├─ 异常用例:20分钟/条
└─ 探索用例:30分钟/条

示例:
| 用例类型 | 数量 | 单耗 | 工作量 |
|---------|------|------|--------|
| 冒烟用例 | 20条 | 5分钟 | 100分钟 |
| 功能用例 | 100条 | 10分钟 | 1000分钟 |
| 边界用例 | 50条 | 15分钟 | 750分钟 |
| 异常用例 | 30条 | 20分钟 | 600分钟 |
| 合计 | 200条 | - | 2450分钟≈41人时 |

3. 类比法

原理:基于历史项目类比

步骤:
1. 寻找相似历史项目
2. 提取历史数据
3. 调整差异因素
4. 得出估算结果

历史数据:
├─ 项目类型:[类型]
├─ 功能规模:[功能点数]
├─ 历史工时:[实际工时]
└─ 调整系数:[差异调整]

示例:
| 历史项目 | 功能点 | 实际工时 | 本次项目 | 调整后工时 |
|---------|--------|---------|---------|-----------|
| 项目A | 100 | 80人时 | 120 | 96人时 |
| 项目B | 80 | 60人时 | 120 | 90人时 |
| 平均 | - | - | - | 93人时 |

4. 三点估算法

原理:基于乐观/悲观/最可能估算

公式:
期望值 = (乐观 + 4×最可能 + 悲观) / 6
标准差 = (悲观 - 乐观) / 6

步骤:
1. 估算乐观值(最好情况)
2. 估算最可能值(正常情况)
3. 估算悲观值(最坏情况)
4. 计算期望值和标准差

示例:
| 任务 | 乐观 | 最可能 | 悲观 | 期望值 | 标准差 |
|------|------|--------|------|--------|--------|
| 需求分析 | 4 | 6 | 10 | 6.3 | 1.0 |
| 用例设计 | 8 | 12 | 20 | 12.7 | 2.0 |
| 测试执行 | 16 | 24 | 40 | 25.3 | 4.0 |
| 回归测试 | 8 | 12 | 20 | 12.7 | 2.0 |
| 合计 | 36 | 54 | 90 | 57.0 | 9.0 |

工作量分解

测试活动分解

├─ 测试计划
│   ├─ 制定测试策略
│   ├─ 编写测试计划
│   └─ 评审测试计划
│
├─ 测试设计
│   ├─ 分析需求文档
│   ├─ 设计测试用例
│   ├─ 评审测试用例
│   └─ 准备测试数据
│
├─ 测试执行
│   ├─ 环境搭建
│   ├─ 用例执行
│   ├─ 缺陷提交
│   ├─ 回归测试
│   └─ 冒烟测试
│
├─ 测试报告
│   ├─ 编写测试报告
│   ├─ 评审测试报告
│   └─ 总结经验教训
│
└─ 其他活动
    ├─ 沟通协调
    ├─ 问题解决
    └─ 文档维护

工作量分配比例

活动占比说明
测试计划10%策略制定、计划编写
测试设计25%用例设计、数据准备
测试执行50%用例执行、缺陷管理
测试报告10%报告编写、总结
其他活动5%沟通、协调、文档

影响因素

调整系数

├─ 需求稳定性
│   ├─ 稳定:0.9
│   ├─ 一般:1.0
│   └─ 变更频繁:1.2
│
├─ 技术复杂度
│   ├─ 简单:0.8
│   ├─ 中等:1.0
│   └─ 复杂:1.3
│
├─ 团队经验
│   ├─ 资深:0.8
│   ├─ 中等:1.0
│   └─ 新人:1.3
│
├─ 自动化程度
│   ├─ 高:0.7
│   ├─ 中等:1.0
│   └─ 低:1.2
│
└─ 历史缺陷
    ├─ 少:0.9
    ├─ 一般:1.0
    └─ 多:1.2

综合估算公式

总工作量 = 基础工作量 × 调整系数1 × 调整系数2 × ...

示例:
基础工作量:100人时
需求稳定性:1.1(变更频繁)
技术复杂度:1.2(复杂)
团队经验:1.0(中等)
自动化程度:0.9(中等偏高)

总工作量 = 100 × 1.1 × 1.2 × 1.0 × 0.9 = 118.8人时

估算报告模板

# 测试工作量估算报告

## 项目信息
- 项目名称:[名称]
- 迭代版本:[版本]
- 估算日期:[日期]
- 估算人:[姓名]

## 估算方法
[功能点法/用例法/类比法/三点估算法]

## 估算结果
| 活动 | 工作量(人时) | 工作量(人天) | 负责人 |
|------|-------------|-------------|--------|
| 测试计划 | XX | XX | [姓名] |
| 测试设计 | XX | XX | [姓名] |
| 测试执行 | XX | XX | [姓名] |
| 测试报告 | XX | XX | [姓名] |
| 合计 | XX | XX | - |

## 调整因素
| 因素 | 系数 | 说明 |
|------|------|------|
| 需求稳定性 | 1.1 | 需求变更频繁 |
| 技术复杂度 | 1.2 | 技术实现复杂 |
| 团队经验 | 1.0 | 团队经验丰富 |
| 自动化程度 | 0.9 | 有自动化支持 |

## 最终估算
- 总工作量:XX人时
- 总工作量:XX人天
- 建议工期:XX天
- 资源需求:XX人

## 风险提示
- [风险1]
- [风险2]
- [风险3]

Examples

新功能上线,PM问"需要多久测完" → 功能点法:登录(3个功能点)× 3人时 = 9人时 → 用例法:25条用例 × 0.5人时/条 = 12.5人时 → 类比法:类似功能上次用了10人时,这次稍微复杂,估算12人时 → 三点估算法:乐观9h/最可能12h/悲观18h → (9+4×12+18)/6 = 12.5h

一个迭代的测试工作量估算 → 活动分解:需求评审(2人天)→用例设计(5人天)→执行(8人天)→报告(1人天) → 调整系数:团队新成员需1.2×,加0.2测试环境不稳定系数 = 1.4 → 最终估算:(2+5+8+1) × 1.4 = 22.4人天

Guidelines

估算完成后检查:

  • 估算方法是否选择合适?
  • 基础数据是否准确?
  • 调整系数是否合理?
  • 工作量分解是否完整?
  • 风险提示是否识别?
  • 估算结果是否可信?

检查清单

  • 工作量是否分解到模块级?
  • 历史数据是否参考?
  • 风险缓冲是否预留?
  • 估算依据是否充分?
  • 排期是否可执行?

Related skills

当新项目启动需要制定测试方案、或者迭代开始前需要确定"这期怎么测"时使用此技能。根据项目特征(新项目/迭代/重构/紧急修复)、风险分布和资源约束设计分层测试策略,明确测试范围、测试手段、准入准出标准和工具选型。一个好的测试策略让团队知道"测什么、不测什么、为什么"。输出包含风险矩阵、分级测试方案的测试策略文档。 本技能属于 QA Test Skills 技能集(49 个技能之一),完整工作流体验需安装全套:npx skills add Kokxi/qa-test-skills

3 installs

当需要管理测试团队、制定团队目标和绩效标准、或者团队扩招需要面试标准时使用此技能。覆盖测试团队管理(目标设定/KPI 制定/人员成长)、绩效评估(能力模型/360 评估)、招聘面试(面试流程/技术评估标准)和组织建设。不要只管进度不管成长——一个稳定的测试团队靠的是每个人都在不断学习和进步。 本技能属于 QA Test Skills 技能集(49 个技能之一),完整工作流体验需安装全套:npx skills add Kokxi/qa-test-skills

3 installs

当管理层问"质量到底怎么样"、需要量化质量数据来做决策、或者想建立质量看板来跟踪趋势时使用此技能。从过程质量(需求评审通过率/用例覆盖度)、结果质量(Bug 密度/线上事故数)、效率(测试周期/回归耗时)和健康度(自动化通过率/环境稳定性)四个维度设计度量指标。⚠️ 度量的目的不是打分,是发现问题趋势——如果只报喜不报忧,度量就没用了。 本技能属于 QA Test Skills 技能集(49 个技能之一),完整工作流体验需安装全套:npx skills add Kokxi/qa-test-skills

1 installs

当团队要选测试工具(自动化框架/性能工具/管理平台)、现有工具不能满足需求需要替换、或者公司要求做技术评估时使用此技能。通过多维度对比评估(功能覆盖/学习成本/社区活跃度/维护成本/扩展性)输出推荐方案和迁移实施建议。不要只看 Gartner 象限或者技术网红推荐——工具好不好取决于你的团队能力、技术栈和实际场景。每个推荐方案附带 POC 验证计划和风险提示。 本技能属于 QA Test Skills 技能集(49 个技能之一),完整工作流体验需安装全套:npx skills add Kokxi/qa-test-skills

1 installs

当团队里有测试新人需要带、想提升团队整体测试水平、或者需要把个人经验转化为团队能力时使用此技能。通过 Pair 测试、经验分享、checklist 沉淀、模板建设和培训材料等方式赋能团队。不要等着新人犯错再教——好的赋能是提前给工具和方法论,让新人在第一次做之前就知道"正确的做法是什么"。 本技能属于 QA Test Skills 技能集(49 个技能之一),完整工作流体验需安装全套:npx skills add Kokxi/qa-test-skills

1 installs

当测试发现"这个功能测不了"、"加个日志就能定位"、"这个模块没法 Mock"时使用此技能。从可控性(能否控制测试条件)、可观察性(能否看到内部状态)、可隔离性(能否独立测试)、自动化性和可诊断性五个维度评估系统的可测试性水平,给出具体的系统改进建议和推动策略。可测试性差的系统一定质量差——不是因为系统本身不好,是因为你根本测不透它。输出可测试性评估报告和各维度的改造建议。 ⚠️ 本技能含废弃测试清理建议,执行前请确认非关键数据。 本技能属于 QA Test Skills 技能集(49 个技能之一),完整工作流体验需安装全套:npx skills add Kokxi/qa-test-skills

3 installs