作为一个管理者，你是否被询问到某个项目要花多少时间，多少人力测试；或是作为一个普通的测试员，你是否被询问到要花多少时间来完成某个任务或是一次回归测试？我想大多数在软件行业的人或多或少都会碰到这样的关于工作量估计的询问。那么你是怎么回答的呢？你对你自己的回答有信心吗？你是否最终发现实际上花去的时间和原本估计的时间大相径庭呢？
不同的人会使用许多不同的方法来估算及安排他们的测试工作量。不同的组织根据项目的类型，项目的内在风险，涉及的技术等而使用不同的方法。但是大多数时候测试工作量是和开发工作量合在一起的，没有一个单独的数字。
首先让我们来看看一些常规的估算测试工作量的方法：
1. Ad-hoc方法
这种方法下的测试工作量不基于任何确定的期限。工作一直继续直到达到一些由管理或市场人员预先定下的时间表。或者，一直到用完了预算的经费。
这种情况普遍存在于非常不成熟的组织，并且时常有100％的错误差数。
2. 开发时间的百分比法Percentage of development time
这个方法的基本前提是测试工作量依赖于开发时间/开发工作量。首先，开发工作量使用例如LOC或FP方法被估算出来，然后使用一些探索性的方法来限制测试的工作量。这种方法变化比较大而且通常基于以前的经验。
通常预留项目的总花费时间的35％给测试。
● 5-7%给组件和集成测试
● 18-20%给系统测试
● 10%给接收测试（或回归测试等）
3. 类比法（经验值法或历史数据法）
根据以前或相似项目（主要在项目性质，领域，规模上有相似）所积累的经验或历史数据来估算工作量。类比法估计结果的精确度取决于历史项目数据的完整性和准确度，因此，用好类比法的前提条件之一是组织建立起较好的项目后评价与分析机制，对历史项目的数据分析是可信赖的。需要收集以下相关的历史数据：
● 在设计和实现阶段花费的时间
● 测试工作的规模，例如用户需求的数量，页面数，功能点
● 数据样式，例如实体，字段的数量
● 屏幕或字段数量
● 测试对象的规模，例如KLOC
4. WBS（work breakdown structure）估算法
将项目或产品分解为具体的工作，然后分别对各个工作进行时间估算，最终求和得出项目或产品的测试工作量/时间。
5. Delphi 法
Delphi法是最流行的专家评估技术，在没有历史数据的情况下，这种方式可以减轻估算的偏差。Delphi法鼓励参加者就问题相互讨论。这个技术，要求有多种相关经验人的参与，互相说服对方。。
Delphi法的步骤是：
① 协调人向各专家提供项目规格和估计表格；
② 协调人召集小组会各专家讨论与规模相关的因素；
③ 各专家匿名填写迭代表格；
④ 协调人整理出一个估计总结，以迭代表的形式返回专家；
⑤ 协调人召集小组会，讨论较大的估计差异；
⑥ 专家复查估计总结并在迭代表上提交另一个匿名估计；
⑦ 重复4-6， 直到达到一个最低和最高估计的一致。
6. PERT估计法
PERT对各个项目活动的完成时间按三种不同情况估计：一个产品的期望规模，一个最低可能估计，一个最高可能估计。用这三个估计用来得到一个产品期望规模和标准偏差的Pert 统计估计。Pert 估计可得到代码行的期望值E，和标准偏差SD。
测试工作量的估计往往和软件开发的规模是紧密相关的。很多软件公司往往是在估计了即将要开发的软件规模后才做测试工作量的估计，然后求和得出项目的最终工作量估计。这种方法比较适用于有经验积累，测试和开发模式稳定的公司或项目，提供了一个比较准确，有参考的数字。但同时由于其完全依赖其前提-开发工作量的估计，显得比较脆弱，如果开发工作量出现较大偏差，测试工作量也就变得毫无用处。在加之代码行本身就存在着许多问题和局限，所以在选择其做为项目估算方法时需要好好了解它的原理，优缺点进而有选择性的使用。
代码行，是来源与英文line of code。那么代码行分析方法就是对软件产品的源代码的行数进行测量。但是仔细想想，可能会有以下疑问：
● 是计算物理行数，还是程序的命令数量？
● 空行是否计算？
● 注释是否计算？
● 预定义文件是否计算？
● 不同版本如何计算？
● 这里面是否设计到一系列的规则定义问题？
● 开发过程种的配置脚本，编译脚本是否计算？
● 共享文件（例如共享的开发库文件种的头部文件）如何计算？
那么现在的一般规则是计算物理行数，不计算空行，不计算注释。对于其他选项，一般为计算源文件根目录下的所有文件。所以代码行指的是指所有的可执行的源代码行数，包括可交付的工作控制语言 （JCL ： job control language） 语句、数据定义、数据类型声明、等价声明、输入 / 输出格式声明等。常使用的单位有： SLOC（single line of code）、KLOC（thousand lines of code）、 LLOC（logical line of code）、PLOC（physical line of code）、NCLOC （non-commented line of code）、DSI（delivered source instruction）。其中SLOC和KLOC比较常用。
代码行分析方法对技术人员是有意义的，因为它的确从某种程序上反映了软件的规模，并且是物理上可测量的。但是这种方法也存在如下诸多问题。
● 在需求、计划、设计阶段因为本身没有代码行，需要靠估算来解决。总体上估算准确度不高，除非有多年的类似项目经验。估算的准确程度取决于是否有同类项目的数据和估算人员的经验。在编码、测试、实施阶段可以直接数出来。
● 在满足客户的要求以及反映进度方面的能力差强人意，对于管理者意义不大。因此项目很难从整体上跟踪代码行数的指标采取行动。
● 近来可视化编程工具的大量采用，以及模板库，类库的广泛采用，在程序的结果中有大量自动生成的代码或者复杂的自动配置脚本或资源文件设置，在采用这些工具的项目中，用代码行分析方法得到数值的意义已经大大降低。
● 对于不同的编程语言来说，代码行也缺乏可信转换方式。
尽管代码行方法有很多缺点，但是由于它容易使用，操作成本低（如果采用适当的支持工具），还是推荐使用代码行作为软件项目管理的参考和补充手段。
