360 Secure SkillHub
360 安全技能中心

qa-test-estimation

面向项目经理和测试负责人,按需求复杂度、变更范围与历史数据估算测试人天。输出含测试计划、设计、执行、报告的逐阶段工作量分解,附调整系数、风险缓冲和置信度评估,并保留估算标识与覆盖率口径说明,结果仅在 workspace/ 输出、不持久化外传。

kokxi
kokxi
热度 60.16
最近更新 2026-09-29 12:31:37
分类:开发依赖:读写文件 / 内部调用大模型应用场景:任务管理 / 日程安排 / 报告撰写

安装技能

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

执行命令安装此 skill: npx secure-skills-cli add qa-test-estimation
Metadata
displayName
测试估算
name
qa-test-estimation
description
当项目经理问"这个版本多久测完"或者需要给测试排期做资源规划时使用此技能。基于需求复杂度、变更范围和历史数据系统化估算测试人天,输出包含冒烟/功能/回归/专项的逐阶段预估。不要拍脑袋——估算必须有依据(复杂度分级 + 历史基线 + 风险系数),同时标注置信度区间和风险预留。 触发场景:工作量估算、测试时间、排期、资源规划、估算工时、人天、工期、多久测完、项目计划阶段需要测试工时评估时。 Use when the user asks about: estimating test effort in person-days with complexity grading, historical baselines, risk coefficients, and confidence ranges.
license
MIT
allowed-tools
Read Grep Glob
metadata
{"slug":"qa-test-estimation","display-name":"测试估算","version":"1.8.0","when-to-use":"用户说\"工作量估算\"、\"测试时间\"、\"排期\"、\"资源规划\"、\"估算工时\"、\"人天\"、\"工期\"、\"多久测完\"、需要估算测试工作量、项目计划阶段需要测试工时评估时","related-skills":"{\"upstream\":[\"qa-req-deconstruction\",\"qa-risk-intuition\"],\"downstream\":[\"qa-test-strategy-design\",\"qa-release-risk-governance\"]}","references":"[\"references/estimation-methods.md\"]","input-format":"{\"required\":[{\"name\":\"需求范围\",\"type\":\"string\",\"description\":\"测试需求的规模和复杂度\"},{\"name\":\"测试策略\",\"type\":\"object\",\"description\":\"来自qa-test-strategy-design的测试策略\"}],\"optional\":[{\"name\":\"历史数据\",\"type\":\"object\",\"description\":\"历史估算和实际工时数据\"},{\"name\":\"团队产能\",\"type\":\"string\",\"description\":\"团队测试产能信息\"}]}","output-format":"{\"traceability\":[\"每份估算带唯一ID(EST-XXXX)\"],\"structure\":[\"覆盖率:标注口径(基于现有需求/输入文档),禁止\\\"全覆盖/100%\\\"绝对化表述;缺失模块标注\\\"未覆盖+原因\\\"\",{\"estimation_result\":\"工作量估算结果\"},{\"breakdown\":\"工作分解结构\"},{\"risk_buffer\":\"风险缓冲建议\"},{\"confidence_level\":\"置信度评估\"}]}","error-recovery-guidance":"{\"on_failure\":\"估算遗漏关键模块时回退到需求解构补充范围\",\"retry_behavior\":\"补全范围后重新估算\"}","categories":"[\"Development\",\"Testing\"]","depth-requirement":"{\"reference_value\":\"根据项目规模调整估算深度:简单×1/中等×2/复杂×3\",\"minimum\":\"至少分解到功能模块级工作量\"}"}

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

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

测试工作量估算

核心原则

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

加载时机

什么时候读 读哪个
做估算或查复杂度分级依据时,取对应方法 references/estimation-methods.md

估算方法的完整内容已下沉至 references/estimation-methods.md,避免每次触发都占用上下文。

工作量分解

测试活动分解

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

工作量分配比例

活动 占比 说明
测试计划 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

估算完成后检查:

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

检查清单

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