软件测试中的测试估算技术
托马斯·汉密尔顿
什么是软件测试评估？
软件测试估算 测试估算是一项管理活动，旨在大致估算测试任务所需的时间和成本。做出可靠的测试估算是一项至关重要的职责。 测试管理 因为它会影响进度安排、预算和资源配置决策。
为什么测试预估很重要
客户在签署测试合同前总会问两个问题：
对于小型项目，这些问题很容易回答。但对于大型项目——例如测试…… Guru99银行网站——你需要一种结构化的方法来捍卫你的答案。
估计什么？
- 资源： 人员、设备、设施、资金以及完成工作所需的任何其他东西。
- 时间： 任何项目中最宝贵的资源——每个版本都有截止日期。
- 人际技能： 团队的知识和经验至关重要。经验丰富的测试人员比经验不足的团队完成测试速度更快。
- 成本权衡： 项目预算——完成计划测试需要多少钱。
如何估算
常用的软件测试估算方法有：
- 工作分解结构（WBS）。
- 三点估计。
- 宽带德尔福。
- 功能点或测试点分析。
- 用例点法。
- 百分比分布。
- 临时方法。
以下四步流程结合了多种技术，最终得出可靠的估算结果。示例采用以下方法： Guru99 银行案例研究。
第一步）将整个项目分解成子任务
使用 工作分解结构 这是一种将复杂项目拆分成模块、子模块，最终细化为最小、最有意义的任务的技术。在细化到最小任务层面进行估算，比基于模糊的项目目标进行估算要可靠得多。
运用该技巧打破 Guru99号银行项目拆分为五个较小的任务：
然后，将每个任务分解成子任务，直到每一行都足够详细，可以进行估算。
| 任务 | 子任务 |
|---|---|
| 分析软件需求规格说明书 | 仔细研究需求规格说明。 |
| 采访开发人员和其他利益相关者，以了解更多关于网站的信息。 | |
| 创建测试规范 | 设计测试场景。 |
| 创建测试用例。 | |
| Rev查看并修改测试用例。 | |
| 执行测试用例 | 搭建测试环境。 |
| 执行测试用例。 | |
| Rev查看测试执行结果。 | |
| 报告缺陷 | 创建 缺陷 报告。 |
| 报告缺陷。 |
步骤二）将每项任务分配给团队成员
将每个子任务分配给最合适的负责人。
| 任务 | 所有者 |
|---|---|
| 分析软件需求规格说明书 | 所有团队成员 |
| 创建测试规范 | 测试员/测试分析师 |
| 构建测试环境 | 测试管理员 |
| 执行测试用例 | 测试员、测试管理员 |
| 报告缺陷 | 测试仪 |
步骤 3）各项任务的工作量估算
现阶段两种互补的技术都能很好地发挥作用：
- 功能点法。
- 三点估计法。
方法1）功能点方法
测试经理会估算每个任务的规模、持续时间和成本。
步骤 A）估算任务规模
以“创建测试规范”这项任务为例。其篇幅取决于被测系统的功能规模——功能越多，系统就越复杂。功能点通常分为三类：复杂、中等和简单。
根据复杂程度，测试管理器会为每个功能点分配权重：
| 团队 | 权重 |
|---|---|
| 复杂 | 5 |
| 中 | 3 |
| 简易 | 1 |
此 Guru99银行网站分为12个功能点，其复杂程度概述如下。
| # | 模块 | 适用角色 | 描述 | 权重 |
|---|---|---|---|---|
| 1 | 余额查询 | 客户经理 | 顾客： 仅查看自己账户的余额。 经理： 查看每个受监管客户的账户余额。 |
3 |
| 2 | 资金转账 | 客户经理 | 顾客： 从您自己的账户向任何目的地转账。 经理： 资金可从任何来源转账至任何目的地。 |
5 |
| 3 | 迷你声明 | 客户经理 | 账户的最近五笔交易记录。 顾客： 仅查看自己的帐户。 经理： 查看任何账户。 |
3 |
| 4 | 定制声明 | 客户经理 | 按日期或金额筛选交易记录。 顾客： 仅限本人账户。 经理： 任何账户。 |
5 |
| 5 | 修改密码 | 客户经理 | 顾客： 修改自己的密码。 经理： 更改自己的密码（而不是客户的密码）。 |
1 |
| 6 | 新客户 | 经理 | 添加和编辑客户详细信息（地址、电子邮件、电话）。 | 3 |
| 7 | 新账户 | 经理 | 储蓄账户和活期账户；客户可以持有多个储蓄账户和多个活期账户。经理可以为现有客户添加新账户。 | 5 |
| 8 | 编辑帐户 | 经理 | 编辑现有帐户的详细信息。 | 1 |
| 9 | 删除账户 | 经理 | 删除客户的现有账户。 | 1 |
| 10 | 删除客户 | 经理 | 仅当没有活跃账户时才删除客户。 | 1 |
| 11 | 存款 | 经理 | 将现金存入分行的任何账户。 | 3 |
| 12 | 提款 | 经理 | 在分行从任何账户提取现金。 | 3 |
步骤 B）估算任务所需时间
确定复杂度后，估算测试每个组所需的时间。
- 总努力： 全力测试网站的每一项功能。
- 总功能点数： 网站模块总数。
- 每个功能点的估算值： 平均每分投入；取决于团队效率。
假设团队对每个功能点的估算为 5 小时/点为……所做的总努力 Guru99银行的例子是：
| 团队 | 权重 | 功能点 | 合计 |
|---|---|---|---|
| 复杂 | 5 | 3 | 15 |
| 中 | 3 | 5 | 15 |
| 简易 | 1 | 4 | 4 |
| 功能总分 | 34 | ||
| 每点估算 | 5 | ||
| 预计总工作量（人时） | 170 | ||
完成“创建测试规范”的总工作量约为 170人时一旦确定了工作量，就可以分配资源来确定工期和成本。
步骤 C）估算任务成本
这一步骤回答了客户的第二个问题——“费用是多少？”。假设团队平均收费为 $ 5 /小时上述任务耗时170小时，因此成本为 170 × $5 = $850对每个 WBS 任务应用相同的计算方法，即可得出项目预算。
估算越准确，就越能更好地管理项目预算，确保每一分钱都能获得回报。
方法二）三点估计
三点估算法是一种结构化技术，测试经理需要为每个任务提供三个值—— 乐观的, 最有可能的和 悲观 努力程度——基于以往经验或最佳猜测。
对于“创建测试规范”，三个值可能为：
- 最佳情况： 120 人时（约 15 天），由一支实力雄厚、经验丰富的团队完成。
- 最有可能的： 使用典型团队和资源，需要 170 人时（约 21 天）。
- 最坏情况： 耗时 200 人时（约 25 天），团队经验不足，且需要额外返工。
使用 PERT 式公式计算加权平均值：
价值 E 是 加权平均 — “创建测试规范”的初步估算。
为了表达对周围的信心 E计算标准差：
如报名参加 Guru99 银行示例，估算结果为 166.6 ± 13.33 人时 — 范围为 153.33 至 179.99 人时。
步骤4）验证估计
将 WBS 中的每一项任务估算汇总起来，并将计划提交给管理委员会（CEO、项目经理、主要利益相关者）进行审查和批准。
有条不紊地向董事会解释估算过程，让他们理解其中的假设、选择的技术以及你预留的应急措施。
测试估算最佳实践
添加缓冲时间
计划往往难以经受现实的考验——团队成员会离职，测试耗时会超出预期，依赖项也会发生变化。因此，在每次估算中都应预留合理的缓冲时间，以便应对一些小的意外情况。
资源可用性计划
务必将计划休假、培训和轮班待命等因素考虑在内。忽略人员可用性的估算看起来纸面上很完美，但实际执行起来却会漏洞百出。
以过往经验为参考
来自类似项目的历史数据非常宝贵。如果您去年测试过类似的网站，请从其实际运行结果、遇到的问题以及最终解决问题的应对措施中吸取经验教训。
坚持估算——但要定期复核。
估算值并不准确trac这只是最佳猜测。 Rev在既定的里程碑节点进行跟踪，仅当需求发生重大变化或新信息改变现状时才进行调整。任何变更都应与客户进行透明的协商。
软件测试评估模板
其他估算技术
除了工作分解结构法、功能点法和三点估算法之外，还有几种其他技术被广泛使用：
- 宽带 Delphi： 由专家组进行迭代共识估计。
- 用例点法： 工作量取决于用例的数量和复杂性。
- 百分比分布： 将项目总工作量的固定百分比分配给测试。
- 临时方法： 当缺乏历史数据时，依靠专家判断。
自下而上估算与自上而下估算
从实际角度来看，估算还可以分解为两种互补的策略：
- 自下而上的估算： 基于工作分解结构 (WBS) 最底层的任务。多位利益相关者、经验丰富的员工和贡献者汇总数据，得出准确的总数。当工作内容清晰明了时，这种方法最为理想。
- 自上而下的估算： 按项目规模和复杂程度对项目进行分类，并将其与类似类型的已完成项目进行比较。此外，还使用平均工作量。 测试用例 并根据预计病例数进行缩放。在项目初期细节信息匮乏时非常有用。
大多数团队会将这两种方法结合起来——自上而下地得出主要数据，自下而上地得出信心——并在预算允许的情况下，用复杂的模型来叠加结果。
