常规估算测试工作量有多种方法。一种是基于规模的估算，例如根据软件功能点数量来确定。先识别出系统的功能点，功能点越多，测试工作量往往越大。对于复杂功能点，测试用例设计、执行和回归测试都会耗费更多时间。另一种是经验类比法，参考以往类似项目的测试工作量。如果新项目在功能、技术复杂度等方面与已完成项目相似，就可以根据旧项目的经验来估算。还有任务分解法，将测试工作分解为测试计划制定、测试用例编写、执行测试、缺陷管理等多个任务，分别估算每个任务所需时间，最后汇总得出总的测试工作量。

    作为一个管理者，你是否被询问到某个项目要花多少时间，多少人力测试；或是作为一个普通的测试员，你是否被询问到要花多少时间来完成某个任务或是一次回归测试？我想大多数在软件行业的人或多或少都会碰到这样的关于工作量估计的询问。那么你是怎么回答的呢？你对你自己的回答有信心吗？你是否最终发现实际上花去的时间和原本估计的时间大相径庭呢？

    不同的人会使用许多不同的方法来估算及安排他们的测试工作量。不同的组织根据项目的类型，项目的内在风险，涉及的技术等而使用不同的方法。但是大多数时候测试工作量是和开发工作量合在一起的，没有一个单独的数字。（参考《建筑中文网》）

    首先让我们来看看一些常规的估算测试工作量的方法：

    1. Ad-hoc方法

    这种方法下的测试工作量不基于任何确定的期限。工作一直继续直到达到一些由管理或市场人员预先定下的时间表。或者，一直到用完了预算的经费。

    这种情况普遍存在于非常不成熟的组织，并且时常有100%的错误差数。

    2.开发时间的百分比法Percentage of development time.

    这个方法的基本前提是测试工作量依赖于开发时间/开发工作量。首先，开发工作量使用例如LOC或FP方法被估算出来，然后使用一些探索性的方法来限制测试的工作量。这种方法变化比较大而且通常基于以前的经验。

    通常预留项目的总花费时间的35%给测试。5-7%给组件和集成测试，18-20%给系统测试，10%给接收测试（或回归测试等）

    3.类比法（经验值法或历史数据法）

    根据以前或相似项目（主要在项目性质，领域，规模上有相似）所积累的经验或历史数据来估算工作量。类比法估计结果的精确度取决于历史项目数据的完整性和准确度，因此，用好类比法的前提条件之一是组织建立起较好的项目后评价与分析机制，对历史项目的数据分析是可信赖的。需要收集以下相关的历史数据：在设计和实现阶段花费的时间？测试工作的规模，例如用户需求的数量，页面数，功能点。

    4.WBS（work breakdown structure）估算法

    将项目或产品分解为具体的工作，然后分别对各个工作进行时间估算，最终求和得出项目或产品的测试工作量/时间。

    5.Delphi 法

    Delphi法是最流行的专家评估技术，在没有历史数据的情况下，这种方式可以减轻估算的偏差。Delphi法鼓励参加者就问题相互讨论。这个技术，要求有多种相关经验人的参与，互相说服对方……

    Delphi法的步骤是：

    1、协调人向各专家提供项目规格和估计表格；

    2、协调人召集小组会各专家讨论与规模相关的因素；

    3、各专家匿名填写迭代表格；

    4、协调人整理出一个估计总结，以迭代表的形式返回专家；

    5、协调人召集小组会，讨论较大的估计差异；

    6、专家复查估计总结并在迭代表上提交另一个匿名估计；

    7、重复4-6，直到达到一个最低和最高估计的一致。

    6.PERT估计法

    PERT对各个项目活动的完成时间按三种不同情况估计：一个产品的期望规模，一个最低可能估计，一个最高可能估计。用这三个估计用来得到一个产品期望规模和标准偏差的Pert 统计估计。Pert 估计可得到代码行的期望值E，和标准偏差SD。

原文网址：http://www.pipcn.com/research/200810/11975.htm