测试工作量估算是整个测试过程中不可忽视的环节，关乎项目整体的交付计划及时间工期安排。预估的越准确，对项目整体节奏的把握更有利。
我们首先要强调，估算估算，本身就带有预测性质，其准确程度是要受到多方面因素制约的，尤其是信息的充分性。
越是大型的复杂项目，对于估算的要求就越高；反之，小规模“短频快”的项目则对于估算要求不那么高。
1. 估算办法
如何得出对于测试时间的准确估算，可以从三种思路去保证：
- 参照以往项目的经验
- 依靠专家经验进行估算
- 使用专业的估算算法
项目中常见的估算形式有自上而下式的，也有自下而上式的。
自上而下式：
- 先整体，再拆解
- 先宏观，再细节
- 管理人员主导，基层人员落实
自下而上式：
- 先拆解，再整合
- 先细节，再整体
- 基层人员估算，管理人员核算
自上而下和自下而上式的估算方法都有其适合的应用场景，这取决于项目的特性，组织的风格等。
例如，对于一个严格约定了交付时间的定制性开发项目而言，其项目的整体时间框架是固定的，开发和测试工作时间都需要在相应的时间框架内进行工作量的细化和编排；而对于一个典型的Scrum式敏捷项目而言，工作项时间的估算通常都来自于工作人员自己个人的估算，然后再由项目统筹汇总。
一个典型的估算思路如下图所示：
2. 常见的估算方式
类比估算
根据以前类似项目的实际工作量，凭经验来推测当前项目的工作量。
例如，系统迭代周期内，曾经新增一个功能模块，实际开发和测试工作量是15人天。参照历史经验，当我们再次新增类似规模的功能模块时，我们推测当前的任务工作量也为15天。
为了准确的使用类比方法，要求组织内部简历比较完善的经验库，同时也要求参与估算人员有较丰富的同类项目经验。
类比估算的方法并不适合用于大型复杂和变动可能性高的项目。
用开发时间的百分比估算
这种估算方法在一些项目里是比较常见的，其成立前提在于，测试工作量依赖于软件的规模，而软件的规模又决定了开发编码的工作量。
这个方法的基本前提是测试工作量依赖于开发时间/开发工作量。首先，开发工作量使用例如LOC或FP方法被估算出来，然后根据项目以往测试花费时间的经验总结，按一定比例得出测试时间/工作量。
比如预留开发时间的50%给测试工作，是一种常见的做法。
这种方法的风险也比较大，并且不适用于复杂情况。
WBS估算法
WBS全称（work breakdown structure），即工作内容分解。严格来说他不是一种估算方法，而是项目管理方法，并且可以应用在大多数场景。其理念在于将复杂的工作内容分解成足够的颗粒度，对这些细粒度的内容逐一估算，继而累加得出整体结果。
WBS是一种典型的自底向上的方法。
我们使用WBS法对测试任务进行细化，对每项测试任务进行分解，然后根据分解后的子任务进行估算。
通常来说，分解的粒度越小，估算精度越高。可以再加上10%～15%的浮动幅度，来确定实际所需的测试工作量。
Delphi估算法
典型的专家判断法，是由许多专家运用结构化的方法来做出主观判断。
简单来说就是背对背评估、偏差不超过一定数值（比如10%）有效。德尔菲估算法一般进行4~6轮，使大家的意见逐渐趋于一致。
专家的选择方面，在测试领域内通常没有严格要求，任务的相关人员一般都做为专家参与Delphi估算。
PERT估算法
又称三点估算法，是指估算三种可能的工期，然后加权平均，得出活动的平均工期和标准偏差。
PERT对各个项目活动的完成时间按三种不同情况估计：一个产品的期望工期，一个最低可能估计，一个最高可能估计。
用这三个估计用来得到一个产品期望工期和标准偏差的Pert 统计估计。Pert 估计可得到工期的期望值E，和标准偏差SD。
T(E)期望值=
SD标准偏差=
软件规模估算法
对于软件规模，业界有两种广泛应用的估算方式：
- 代码行估算LOC（Line Of Code）
- 功能点估算FPA（Functional Point Analysis）
软件规模估算更多的是用于预估软件开发工作量，但测试工作量依赖于软件的规模，因此通过规模与测试工作量之间的对应关系推算测试工作量，是具有可行性的。
这种方法对于项目成员缺乏相关经验，或者系统功能、结构比较复杂的情况下有一定的使用价值。
而相较于代码行估算，功能点（换言之可以对应到测试点）估算对于测试工作而言具有更高的相关性。
软件规模估算可能会用到一些科学的算法，例如对于MVC模型比较有效的MarkII方法，其计算公式为：
功能点＝输入DET×0.58＋实体类型×1.66＋输出DET×0.26
注意以上的估算方法都有其应用价值，而且页并非割裂的存在。在实际项目种应用时，往往会多种方法结合使用。
3.估算实践
下面我们通过一个案例来分析各种估算方法结合使用的实例。
以如下项目为例：
X&X COTS Commercial
- 该项目为一个COTS产品的定制性二次开发项目
- 项目周期计划为4个月
- 采用持续集成，高速迭代的研发方式
3.1.工作量框架确定
首先在项目立项阶段，项目工期已被确定为4个月。在这样的背景下，项目经理与架构师进行了软件规模整体估算，并得出了所需开发人员人数为7人。
测试经理通过百分比类比预估，凭借自己的经验，以开发人员人数为基础，提出了3人测试的人员需求。
3.2.测试任务拆解
立项阶段结束后，商务分析人员/产品人员开始逐步确定系统需求，架构师给出系统架构概要。测试经理通过手头可以确定和预计存在任务情况，开始做WBS任务分解。
通过将测试计划、分析、设计、实施、执行、评估、报告等工作进行逐一分解，得到如下任务列表：
3.3.估算会议
在人员基本到位后，项目经理召集项目全员，启动项目工作量估算会议。
会议上，基于WBS拆解的任务项，逐项任务展开Delphi专家估算。
专家的挑选并不采用严格的形式，而是由项目经理主持选定单项任务的执行人、协力者和审批者参与估算。估算最小精度被确定为0.25人/天。
每一项任务进行具体估算时，估算人员进行实名投票（举牌），管理人员统筹投票结果的偏离度，如果单个估算人员的估算偏差超出平均（比如20%），则需要阐述自己的理由。
阐述完毕后，重新开始投票，重复上述过程，直到所有人员的投票值收敛于一定偏差值之内，用其平均值做为最终估算值。
3.4.MarkII功能点估算应用
在Delphi估算的过程中，出现了专家普遍认为对于某功能模块经验不足，无法准确估算的情况。因此采用功能点估算法推算相应工作量，步骤如下：
① 选取一个已知（已估）工作量大小的模块，拆解其功能点。（如用户管理模块的用户注册功能点）已知功能点对应测试任务为1.5/人天。
② 按照MarkII方法，拆解该功能点的输入、输出与关联实体。如：
用户注册事务
-
输入DET “用户名称”、“用户密码”、“用户条款”等约15项
-
输出DET “注册成功”、“密码不符合规范”、“用户已注册”等10项
-
关联实体 用户记录，地址簿记录，地址详情记录，支付卡记录等5项
根据公式计算得出：15×0.58+5×1.66+10×0.26=19.6。
这里得出的数字是一个指数，推论的具体含义可以这么理解：一个大小为19.6的事务（功能点），对应所需测试活动工作量为1.5人/天。
③ 拆解待估算模块功能点，进而同样对于功能点使用Mark II估算：
订单创建事务
-
输入DET “收货地址”、“支付方式”、“配送方式”等约20项
-
输出DET “下单成功”、“支付失败”、“库存不足”等20项
-
关联实体 订单记录，库存记录，支付记录，物流记录等5项
计算得出其规模指数为：20×0.58+5×1.66+20×0.26=25.1。
结合上一步的结论，大小为25.1的事务，对应所需测试工作量推算为：
25.1×（2.5/19.6）= 1.92（人/天）≈ 2（人/天）
④ 对于其他待测功能点重复第3步，直至整体模块估算完成。
结语
需要指出的是，虽然更为准确的测试工作量估算是理想的效果，但是由于测试工作对于其他部门产出的依赖，往往在实际工作中，影响到计划的测试进度安排的变量非常多而且难以预期。
估算结果是随着工作迭代，一步步精确的一个过程。
测试管理人员需要密切关注测试真实进度，实际工作量与预估工作量之间的偏离，并及时调整估算结果，同时也总结估算偏离的原因，为自己和项目的后续估算工作累积经验。