2.3　测试工作量估算

在确定了测试需求、明确了测试范围之后，就需要明确测试任务，估算测试工作量。基于质量需求和测试的工作量、测试环境、产品发布的设想时间等要求，就可以确定测试进度和所需的测试资源，或者基于现有的测试资源来决定测试的日程表。

在传统开发模式中，测试工作量估算是测试计划的基础工作之一，但在敏捷开发中，虽然也强烈建议有一个测试计划，但其测试计划简明扼要，主要是列出测试目标、测试边界、测试点、主要的测试风险和注意事项等。其测试任务在迭代计划（如Scrum的Sprint Planning）会议中和开发任务一并考虑，可以采用Scrum估算扑克牌的方式来完成估算，这样测试工作量估算主要依赖个人经验、团队沟通等完成。即使是采用这种方式，对下面内容了解之后，有一个科学估算的基础，在敏捷开发中依旧会发挥作用。

2.3.1　工作量的估计

测试的工作量是根据测试范围、测试任务和开发阶段来确定的。测试范围和测试任务是测试工作量估算的主要依据。如何确定测试范围已在上一节做了充分的讨论，可以根据产品需求规格说明来决定。测试任务是由质量需求、测试目标来决定的，质量要求越高，越要进行更深、更充分的测试，回归测试的次数和频率也要加大，自然，测试的工作量要增大。处在不同的开发阶段，测试工作量的差异也挺大。新产品第一个版本的开发过程，相对于以后的版本来说，测试的工作量要大一些。但也不是绝对的，例如，第一个版本的功能较少，在第2、3个版本中，增加了较多的新功能，虽然新加的功能没有第一个版本的功能多，但是在第2、3个版本的测试中，不仅要完成新功能的测试，还要完成第一个版本的功能回归测试，以确保原有的功能正常。

在一般情况下，一个项目要进行2～3次回归测试。所以，假定一轮（Round）功能测试需要100个人日（man-day），则完成一个项目所有的功能测试肯定就不止100个人日，往往需要200～300多个人日。可以采用以下公式计算：

W ＝ Wo + Wo　　R1 + Wo　　R2 + Wo　　R3

●　W为总工作量，Wo为一轮测试的工作量。

●　R1，R2，R3为每轮的递减系数。受不同的代码质量、开发流程和测试周期等影响，R1、R2、R3的值是不同的。对于每一个公司来说，可以通过历史积累的数据获得经验值。

测试的工作量，还受自动化测试程度、编程质量、开发模式等多种因素影响。在这些影响的因素中，编程质量是主要的。编程质量越低，测试的重复次数（回归测试）就越多。回归测试的范围，在这3次中可能各不相同，这取决于测试结果，即测试缺陷的分布情况。缺陷多且分布很广的话，所有的测试用例都要被再执行一遍。缺陷少且分布比较集中，可以选择部分或少数的测试用例作为回归测试所要执行的范围。

在代码质量相对较低的情况下，假定R1、R2、R3的值分别为80%、60%、40%，若一轮功能测试的工作量是100个人日，则总的测试工作量为280个人日。如果代码质量高，一般只需要进行两轮的回归测试，R1、R2值也降为60%、30%，则总的测试工作量为190个人日，工作量减少了32%以上。

自动化程度越高，测试工作量就越低。由计算机运行的自动化脚本效率很高，能使执行实际测试的工作量大大降低。但是在很多情况下，测试自动化并不能大幅度降低工作量，因为测试脚本开发的工作量很大。也就是说，将总体的测试工作量前移了，从测试执行阶段移到测试脚本设计和开发的阶段，总体工作量没有明显降低。同时，由于自动化脚本可以重复使用，而且机器可以没日没夜地运行，回归测试就可以频繁进行，如每天可以执行一次，这样任何回归缺陷都可以即时发现，提高软件产品的质量。

工作量的估计是比较复杂的，针对不同的应用领域、程序设计技术、编程语言等，其估算方法是不同的。其估算可能要基于一些假定或定义。

（1）效率假设，即测试队伍的工作效率。对于功能测试，这主要依赖于应用的复杂度、窗口的个数、每个窗口中的动作数目。对于容量测试，主要依赖于建立测试所需数据的工作量大小。

（2）测试假设，目的是验证一个测试需求所需测试的动作数目，包括估计的每个测试用例所用的时间。

（3）阶段假定，指所处测试周期不同阶段（测试设计、脚本开发、测试执行等）的划分，包括时间的长短。

（4）复杂度假定，应用的复杂度指标和需求变化的影响程度决定了测试需求的维数。测试需求的维数越多，工作量就越大。

（5）风险假定。一般考虑各种因素影响下所存在的风险，将这些风险带来的工作量设定为估算工作量之外的10%～20%。

2.3.2　工作分解结构表方法

要做好测试工作量的估算，需要对测试任务进行细化，对每项测试任务进行分解，然后根据分解后的子任务进行估算。通常来说，分解的粒度越小，估算精度越高。可以再加上10%～15%的浮动幅度，来确定实际所需的测试工作量。比较专业的方法是工作分解结构表（WBS），它按以下3个步骤来完成。

（1）列出本项目需要完成的各项任务，如测试计划、需求和设计评审、测试设计、脚本开发、测试执行等。

（2）对每个任务进一步细分，可进行多层次的细分，直到不能细分为止。如针对测试计划，首先可细分为：

●　确定测试目标；

●　确定测试范围；

●　确定测试资源和进度；

●　测试计划写作；

●　测试计划评审。

“ 确定测试范围 ”还可再细分为功能性测试范围和非功能性测试范围的分析。“ 测试计划评审 ”可以再分为测试组内评审、项目组评审、公司质量保证小组评审和最终批准。

（3）列出需要完成的所有任务之后，根据任务的层次给任务进行编号，就形成了完整的工作分解结构表（如表2-5所示）。

WBS除了用表格的方式表达之外，还可以采用结构图的方式，那样会更直观、方便，如图2-5所示。

当WBS完成之后，就拥有了制定日程安排、资源分配和预算编制的基础信息，这样不仅可获得总体的测试工作量，还包括各个阶段或各个任务的工作量，有利于资源分配和日程安排。所以，WBS方法不仅适合工作量的估算，还适合日程安排、资源分配等计划工作。

2.3.3　工作量估计的实例

结合Google日历的功能点可以看出，测试工作量与测试用例的数量成比例。根据全面且细化的测试用例，可以更准确地估计测试周期各阶段的时间安排。根据Google日历的功能计算，测试用例数为6×60 = 360例（以平均每个大模块60个用例来算）。除了测试用例数，还要考虑以下因素。

●　根据测试团队和项目的具体情况来算，如2.3.3节中的几个假定：效率假设、测试假设和应用的维数等。

●　测试平台、环境的不同组合，包括操作系统、浏览器、通信协议、防火墙、代理服务器等的组合。

●　回归测试频率和重复次数。

●　自动化测试的水平。

●　其他特定的因素，增加10%～20%的余量。

在Google日历的测试中，做如下假定和分析。

●　所有人员为中级软件测试工程师的水平。

●　每个测试用例设计时间为20分钟，包括评审、输入到用例管理数据库中等所用的时间。所以测试用例设计的时间为120小时，即15个人日。

●　70%的测试用例可以进行自动化测试，30%为手工测试。即自动化测试用例数为252例，手工测试用例数为108例。

●　每位工程师每天可开发10个测试用例的测试脚本，包括调试。所以测试脚本开发的工作量为26个人日。

●　要进行两次的回归测试，R1、R2值为70%、40%，则单平台下手工运行的测试用例数为108×(1＋70%＋40%) ＝ 227例。

●　对操作系统没有影响，而且不考虑SSL的支持，只考虑浏览器IE6.0、IE7.0、Firefox1.5、Firefox2.0和代理服务器的影响。作为交叉组合，共设为4种。

●　也没有必要在4种组合上运行所有的测试用例，两种主要组合运行100%的手工测试用例，另外两种组合运行50%的手工测试用例，即测试用例数为原来的3倍，所以手工运行的测试用例数为227 × 3 ＝ 681例。

●　假定每个测试工程师每天可以运行60个测试用例，即每个测试用例的执行要用5分钟，运行测试用例要用5个小时，另外3个小时用于处理缺陷报告和邮件、与开发人员沟通等。所以手工测试用例执行的时间为12个人日。

●　自动化测试的运行都在晚上进行，工程师需要时间分析测试结果、修改脚本适应新的变化、做缺陷报告等，估计要5个人日。

这样就估算出了功能测试的基本工作量，即15＋26+12+5=58个人日。

对系统测试的工作量，可以按照同样的方法进行，所不同的是系统测试几乎是由测试工具完成的，工作量主要集中在环境构建、测试数据准备和结果分析等上面。表2-6给出了Google日历所要的测试工作量。