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日历所要的测试工作量。
2.4 测试资源需求
分析测试范围之后，所需要的测试资源就比较清楚了。测试的资源需求，包括人力资源和软、硬件资源。人力资源，侧重如何组建测试团队——项目测试组，而软、硬件资源，对于不同的项目差异很大。这里只讨论一般的操作方法，设计测试环境的建立，将在第7、第9章进行详细介绍。
如果将测试资源进行较为详细的分类，可以归纳为如图2-6所示。
1．人力资源需求
在完成了测试工作量的估算之后，软件测试项目所需的人员数目就能够基本确定了。软件测试项目所需的人员和要求在各个阶段是不同的。
（1）在初期，测试组长首先要介入进去，参与需求评审、确定测试需求和测试范围、制定测试策略和测试计划等。
（2）在测试前期，需要一些比较资深的测试设计人员、测试脚本或测试工具开发人员参与或负责软件测试需求的制定和分解、设计测试用例、开发测试脚本等工作。
（3）在测试中期，主要是测试的执行，测试需求的数量取决于测试自动化实现的程度。如果测试自动化程度高，人力的投入则不需要明显的增加；如果测试自动化程度低，对执行测试的人员要求就比较多了。
（4）在测试后期，资深的测试人员可以抽出部分时间去做新项目的准备工作。
2．测试环境资源
把建立所有必要的测试环境所需的计算机软件资源和硬件资源合称为测试环境资源。硬件提供了一个支持操作系统、应用系统和测试工具等运行的基本平台，软件资源包括操作系统、第三方软件产品、测试工具软件等，具体如下。
? 硬件：交换机、路由器、负载均衡器（Load balance）、服务器、客户端PC、摄像头、特殊的显示卡和声卡、耳机、麦克风等。
? 支撑的系统软件：Linux操作系统、Web服务器（如Apache）、中间件（如Tomcat、WebLogic）、数据库系统软件MySQL/Oracle等。
? 测试工具：JUnit、JMeter、Selenium、IBM-Rational Robot等。
2.5 测试里程碑和进度安排
软件测试贯穿软件产品开发的整个生命周期，从产品的需求分析审查到最后的验收测试，直至软件发布。从测试实际的前后过程来看，软件测试的过程是由一系列不同的测试阶段组成的，这些阶段主要有：需求分析审查、设计审查、单元测试、集成测试（组装测试）、功能测试、系统测试、验收测试、回归测试（维护）等。在软件测试项目的计划书中，需要给各个阶段制定一个明确的开始和结束时间，这就是通常所说的日程进度表（schedule）。项目进度安排，实际上取决于测试工作量和现有的人力资源。当人力资源充足时，测试周期短；当人力资源较少时，测试周期就会长。
里程碑一般是项目中完成阶段性工作的标志，即用一个结论性的标志来描述一个过程性任务明确的起止点，进度安排就是确定里程碑的起止点。一个里程碑标志着上一个阶段结束、下一个阶段开始，也就是定义当前阶段完成的标准（Entry Criteria）和下一个新阶段启动的条件或前提（Entry Criteria）。里程碑具有很强的时序性，还具有下列特征。
? 里程碑也是有层次的，在一个父里程碑的下一个层次中定义子里程碑。
? 不同类型的项目，里程碑可能不同。
? 不同规模项目的里程碑，其数量的多少不一样，里程碑可以合并或分解。
2.5.1 传统测试
在软件测试周期中，建议定义下列6个父里程碑。
（1）M1：需求分析和设计的审查。
（2）M2：测试计划和设计。
（3）M3：代码（包括单元测试）完成。
（4）M4：测试执行。
（5）M5：代码冻结。
（6）M6：测试结束。
每个里程碑再划分为子里程碑，如果项目周期很长，还可以对每个子里程碑进一步划分为更小的里程碑，以利于更有效的控制，如表2-7所示。
2.5.2 敏捷测试
在本书一开始的引言中，以Scrum为例，简要阐述了敏捷测试流程。而在敏捷测试项目中，如何明确测试的里程碑呢？万变不离其宗，敏捷测试也需要从测试计划到测试设计、再到执行，只是测试设计和执行的界限不那么分明，测试设计和执行往往交替或并列地开展。在敏捷测试中，甚至可以不需要测试用例，而是针对Use Case 或User Story直
接进行验证，并进行探索性测试。而节约出来的时间，用于开发相对稳定功能的自动化测试脚本，为后期的回归测试服务。自动化测试脚本将代替测试用例，成为软
件组织的财富。原有测试规范还要求进行两轮回归测试，在敏捷测试中，只能进行一轮回归测试。综合上述考虑，敏捷测试的实际操作流程如图2-7所示，简单有效。
在这样的流程中，大框架也没有什么不同，而且各项测试件（测试计划、需求、自动化脚本等）的评审还是需要的，只是没有明确的评审阶段，测试是一个持续的质量反馈过程，阶段性不那么突出，但还是可以设定一些控制点，即里程碑：
（1）测试任务定义；
（2）测试计划制定和评审通过；
（3）测试需求或测试点（或测试场景）列表明确和评审通过；
（4）验收测试结束。
——————本文节选自《全程软件测试（第2版）》
