qa-test-estimation
Skill31 starsChanged 48 days agoMITView on GitHub
当项目经理问"这个版本多久测完"或者需要给测试排期做资源规划时使用此技能。基于需求复杂度、变更范围和历史数据系统化估算测试人天,输出包含冒烟/功能/回归/专项的逐阶段预估。不要拍脑袋——估算必须有依据(复杂度分级 + 历史基线 + 风险系数),同时标注置信度区间和风险预留。 触发场景:工作量估算、测试时间、排期、资源规划、估算工时、人天、工期、多久测完、项目计划阶段需要测试工时评估时。 Use when the user asks about: estimating test effort in person-days with complexity grading, historical baselines, risk coefficients, and confidence ranges.
In this repository50 other files it gives its agents.
- AGENTS.mdAGENTS.md
- CLAUDE.mdCLAUDE.md
- qa-agent-testingSkill
- qa-ai-blindspot-compensationSkill
- qa-ai-context-engineeringSkill
- qa-ai-output-critiqueSkill
- qa-ai-prompt-strategySkill
- qa-api-testingSkill
- qa-boundary-deep-diveSkill
- qa-bug-lifecycleSkill
- qa-bug-reportingSkill
- qa-bug-root-cause-analysisSkill
- qa-ci-cd-testingSkill
- qa-code-review-for-testSkill
- qa-combination-strategySkill
- qa-critical-thinkingSkill
- qa-domain-modelingSkill
- qa-execution-observationSkill
- qa-expert-reviewSkill
- qa-exploratory-testingSkill
- qa-heuristic-checklistSkill
- qa-input-validationSkill
- qa-mobile-testingSkill
- qa-output-validationSkill
- qa-quality-metricsSkill
- qa-question-frameworkSkill
- qa-regression-testingSkill
- qa-release-risk-governanceSkill
- qa-req-deconstructionSkill
- qa-requirement-reviewSkill
- qa-retrospectiveSkill
- qa-risk-intuitionSkill
- qa-scenario-treeSkill
- qa-shift-leftSkill
- qa-shift-rightSkill
- qa-specialized-testingSkill
- qa-stakeholder-communicationSkill
- qa-state-transitionSkill
- qa-team-coachingSkill
- qa-tech-debt-managementSkill
- qa-tech-selectionSkill
- qa-testability-advocacySkill
- qa-test-automation-archSkill
- qa-test-case-designSkill
- qa-test-data-engineeringSkill
- qa-test-env-dataSkill
- qa-test-leadershipSkill
- qa-test-reportingSkill
- qa-test-skillsSkill
- qa-test-strategy-designSkill
The file
Files
⚠️ 本技能单独使用效果有限,建议配合完整技能集(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
估算完成后检查:
- 估算方法是否选择合适?
- 基础数据是否准确?
- 调整系数是否合理?
- 工作量分解是否完整?
- 风险提示是否识别?
- 估算结果是否可信?
检查清单
- 工作量是否分解到模块级?
- 历史数据是否参考?
- 风险缓冲是否预留?
- 估算依据是否充分?
- 排期是否可执行?
Does it work?
Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.
No reviews yet
People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.
- It worked
- Partly
- It didn't
Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.
Your trail
Files you open will collect here, so you can find them again.
Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.
Now do this for your own.
Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.

