（一）常规的估算测试工作量的方法

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

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

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

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法的步骤是：

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

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

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

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

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

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

7. 重复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比较常用.

代码行分析方法对技术人员是有意义的,因为它的确从某种程序上反映了软件的规模,并且是物理上可测量的.但是这种方法也存在如下诸多问题.

• 在需求、计划、设计阶段因为本身没有代码行，需要靠估算来解决。总体上估算准确度不高，除非有多年的类似项目经验。估算的准确程度取决于是否有同类项目的数据和估算人员的经验。在编码、测试、实施阶段可以直接数出来。

• 在满足客户的要求以及反映进度方面的能力差强人意,对于管理者意义不大.因此项目很难从整体上跟踪代码行数的指标采取行动.

• 近来可视化编程工具的大量采用,以及模板库,类库的广泛采用,在程序的结果中有大量自动生成的代码或者复杂的自动配置脚本或资源文件设置,在采用这些工具的项目中,用代码行分析方法得到数值的意义已经大大降低.

• 对于不同的编程语言来说,代码行也缺乏可信转换方式.

尽管代码行方法有很多缺点,但是由于它容易使用,操作成本低(如果采用适当的支持工具),还是推荐使用代码行作为软件项目管理的参考和补充手段.

(三) COCOMO模型

代码行分析方法作为一种度量估计方法,在20世纪80和90年代得到非常广泛的发展,在业界开发了又许多中估算工作量和进度的参数模型,其中最著名的就COCOMO模型,它的最新版本是COCOMO II模型.

COCOMO,英文全称为constructive cost model,中文为构造性成本模型.它是一种精确、易于使用的,基于模型的成本估算方法，最早由勃姆 (Boehm) 于 1981 年提出。从本质上说是一种参数化的项目估算方法,参数建模是把下那个目的某些特征作为参数,通过建立一个数字模型预测项目成本(类似于居住面积作为参数计算的整体的住房成本).

在COCOMO模型中,工作量调整因子(Effort Adjustment Factor, EAF)代表多个参数的综合效果,这些参数使得项目可以特征化和根据COCOMO数据库中的项目规格化.每个参数可以定位很低,低,正常,高,很高.每个参数都作为乘数,其值通常在0.5到1.5之间,这些参数的乘积作为成本方程中的系数.

COCOMO用3个不同层次的模型来反映不同程度的复杂性,他们分别为

• 基本模型 (Basic Model). 是一个静态单变量模型，它用一个以已估算出来的源代码行数 (LOC) 为自变量的函数来计算软件开发工作量。

• 中间模型 (Intermediate Model). 则在用 LOC 为自变量的函数计算软件开发工作量的基础上，再用涉及产品、硬件、人员、项目等方面属性的影响因素来调整工作量的估算。

• 详细模型 (Detailed Model) 包括中间 COCOMO 模型的所有特性，但用上述各种影响因素调整工作量估算时，还要考虑对软件工程过程中分析、设计等各步骤的影响。

同时根据不同应用软件的不同应用领域,COCOMO模型划分为如下3种软件应用开发模式:

• 组织模式(Organic Mode).这种应用开发模式的主要特点是在一个熟悉稳定的环境种进行项目开发,盖项目与最近开发的其他项目有很多相似点,项目相对较小,而且并不需要许多创新.

• 嵌入式应用开发模式 (Embedded Mode).在这种应用开发模式种,项目受到接口要求的限制.接口对整个应用的开发要求非常搞,而且要求项目有很大的创新,例如开发一种全新的游戏.

• 中间应用开发模式 (Semidetached Mode).这时介于组织模式和嵌入式应用开发模式之间的类型.

COCOMO 模型具有估算精确、易于使用的特点。在该模型中使用的基本量有以下几个： (1)DSI( 源指令条数 ) ，定义为代码行数，包括除注释行以外的全部代码。若一行有两个语句，则算作一条指令。 (2)MM( 度量单位为人月 ) 表示开发工作量。 (3)TDEV( 度量单位为月 ) 表示开发进度，由工作量决定。 (4)COCOMO 模型重点考虑 15 种影响软件工作量的因素，并通过定义乘法因子，从而准确、合理地估算软件的工作量。

但是COCOMO也存在一些很严重的缺陷,例如分析时的输入时优先的,不能处理意外的环境变换,得到的数据往往不能直接使用,需要校准,只能得到过去的情况总结,对于将来的情况无法进行校准等.

（四）功能点分析方法——原理篇

功能点分析法 (FPA：function point analysis) 是一种相对抽象的方法,是一种”人为设计”出的度量方式,主要解决如何客观,公正,可重复地对软件的规模进行度量的问题.

FPA 法由 IBM 的工程师艾伦 · 艾尔布策 (Allan Albrech) 于 20 世纪 70 年代提出，随后被国际功能点用户协会 (IFPUG：The International Function Point Users' Group) 提出的 IFPUG 方法继承，从系统的复杂性和系统的特性这两个角度来度量系统的规模，其特征是： “ 在外部式样确定的情况下可以度量系统的规模 ” ， “ 可以对从用户角度把握的系统规模进行度量 ” 。功能点可以用于 “ 需求文档 ” 、 “ 设计文档 ” 、 “ 源代码 ” 、 “ 测试用例 ” 度量，根据具体方法和编程语言的不同，功能点可以转换为代码行。经由 ISO 组织已经有多种功能点估算方法成为国际标准，如：

① 加拿大人艾伦 · 艾布恩 (Alain Abran) 等人提出的全面功能点法 (full function points) ；

② 英国软件度量协会 (UKSMA ： United Kingdom Software Metrics Association) 提出的 IFPUG 功能点法 (IFPUG function points) ；

③ 英国软件度量协会提出的 Mark II FPA 功能点法 (Mark II function points) ；

④ 荷兰功能点用户协会 (NEFPUG：Netherlands Function Point Users Group) 提出的 NESMA 功能点法，以及软件度量共同协会 (COSMIC：the Common Software Metrics Consortium) 提出的 COSMIC-FFP 方法，这些方法都属于艾尔布策功能点方法的发展和细化。

功能点分析方法具体包括两部分,一部分是测量的具体步骤和方法,通常称为功能点规模测量方法(Functional Size Measurement, FSM),另一部分则是功能点分析方法的具体应用.除非特别说明,通常的情况下并不分开讨论,而是统称为功能点分析方法(Functional Point Analysis, FPA),包括对应用软件的规模测量活动和后续应用测量结果进行适当的项目管理活动.

功能点分析方法有一些相对完整的,自成体系的概念,主要包括基础功能部件(Base Function Component, BFC), BFC类型,边界,用户,本地化,功能领域,功能规模,功能点规模测量的范围,功能点规模测量过程,功能点规模测量方法,功能性需求,质量需求,技术性需求,数值调整以及调整因子等15个关键概念.

功能点分析的基本计数就是依据标准计算出的系统 ( 或模块 ) 中所含每一种元素的数目：

① 外部输入数 (EI ： external input) ：计算每个用户输入，它们向软件提供面向应用的数据。输入应该与查询区分开来，分别计算。

② 外部输出数 (EO ： external output) ：计算每个用户输出，它们向软件提供面向应用的信息。这里，输出是指报表、屏幕、出错信息，等等。一个报表中的单个数据项不单独计算。

③ 外部查询数 (EQ ： external query) ：一个查询被定义为一次联机输入，它导致软件以联机输出的方式产生实时的响应。每一个不同的查询都要计算。

④ 内部逻辑文件 (ILF ： internal logical file) ：计算每个逻辑的主文件，如数据的一个逻辑组合，它可能是某个大型数据库的一部分或是一个独立的文件。

⑤ 外部接口文件 (EIF ： external interface file) ：计算所有机器可读的接口，如磁带或磁盘上的数据文件，利用这些接口可以将信息从一个系统传送到另一个系统。