软件测试过程中的计划与控制

　　软件测试过程是整个测试活动中一个至关重要的环节，对于一家企业来说，如果没有一个很好的测试流程规范，那么测试的质量就很难被控制，标准的测试流程包括五大阶段：计划与控制、分析与设计、实现与执行、评估与报告和结束活动。在测试过程中必须明白每个阶段需要完成的工作以及每个阶段需要注意的事项。本章节主要讲解：软件测试过程中的计划与控制。

　　计划与控制是测试第一个阶段的内容，后面所有的工作都是以测试计划为指导进行的，所以测试计划中时间、任务和资源的安排显得很重要。

　　1、 关键过程域

　　计划与控制主要包括以下几方面的关键过程域：

　　(1)制订一份详细的测试计划，主要包含时间安排、资源分配。

　　(2)整个测试执行过程中的风险管理。

　　(3)记录整个测试过程的结果。

　　(4)对结果进行分析和度量。

　　2、测试计划

　　制定测试计划的目的是通过确定测试任务、定义测试对象和详细的测试活动来达到组织的目标和使命。测试计划主要描述的内容是整个项目测试的阶段、每个阶段的时间安排和每天阶段需求的资源分配。

　　关于测试计划通常使用两张表来描述：一是详细的时间安排WBS(工作分解结构WorkBreakdown Structure);二是里程碑时间点，也叫关键时间点。

　　详细的时间安排即通常说的WBS 的创建方法，通常可以使用一些专业的工具(如office project工具)来创建。关于工具如何使用，在这里就不再赘述了。如图4-2 所示是一个典型测试计划的WBS 图。

　　图4-2 WBS 工作计划图

　　很多人不理解为什么有了详细的WBS 工作计划，还需要一个关键时间点的图。关键时间点的图其实本质上来说根本不如详细的WBS 工作计划，但是在测试计划的文档中，这个关键时间点的图扮演着很重要的角色。因为这个测试计划是要给领导看的，领导其实根本就没有时间看详细的测试计划，他只想看一些关键的时间点，如测试方案什么时候完成、测试用例什么时候可以完成等，也就是说，这个关键时间点主要是为了提高文档的可读性。文档的可读性比较高，那么领导会更认可你，这样加薪或升职就有戏了。所以不能只工作，还要表现出你的能力，而文档就是一方面。如图4-3 所示就是一个典型的关键时间点的图。　　

　　图4-3 关键时间点图

　　在做计划时有一个很重要的问题需要解决，就是如何估算工作时间，例如，如何估算某个版本要测试多久。这就要涉及到测试时间的估算了。在测试过程中常见的工作量估算方法包括：功能点评估法、类比法、Delphi 法、开发时间的百分比法和PERT 估计法。

　　(1)功能点评估法

　　在评估测试工作量时，使用最多的方法是功能点评估法，其步骤如下：

　　第一步：分析需求，确定本次测试的需求点。

　　第二步：根据需求点确定本次要测试的功能点。

　　这些功能点不能是复合的功能点，应该是一个原子功能点，所谓的原子功能点是指这个功能点中不再包含其他的子功能，如登录功能就是一个原子功能点，但用户管理这类功能就是复合功能，因为用户管理功能下面还包含新增用户、删除用户等。如果是升级的版本，还需要分析当前升级的这些需求有没有和以前版本中其他的一些需求是否有关联的地方，如果有相关联的地方就必须对原来老的功能点进行详细的测试。

　　第三步：评估功能点的用例数。

　　确定原子功能点后就可以估算这些功能点的用例数，在估算用例数时，可以估算一个功能的平均用例的个数。

　　第四步：确定具体的时间。

　　用例数确定后，就可以确定写用例的时间和对这些用例执行一轮所需要的时间。如估算用例数为1000 条用例，那么写这些用例的时间大约为20 天，一般的情况一天只能写50 条用例左右(不

　　计算加班时间)，一天能执行的用例数也在50 条左右。

　　(2)类比法

　　类比法也叫经验值法或历史数据法，主要是根据以前相类似项目所积累的经验和历史数据来估算工作量。既然是根据以前的经验来估算工作量，那么就一定要选择对类似的项目，一般判断两个项目是否是类似的项目或者说是否有参考价值，一般从以下三个维度来判断：

　　1)项目性质。首先相比较的两个项目应该是同一性质的，即其是一类系统，如同为银行系统。

　　2)相同领域。相比较的两个项目应该是相同领域的，不能是跨领域的，跨领域的没有可比性。

　　3)规模。项目规模大小应该是一个级别的，也就是说不能是10 万行代码的项目与100 万代码的项目进行比较，这在项目规模上来说不是同一个级别的。在使用类比法进行估算时，通常需要先对历史项目的数据进行详细分析再进行估算，一般分析一个历史项目应该从以下维度进行详细的分析：

　　1)阶段分布：每个阶段占总工作量的百分比。

　　2)工种分布：每个工种占总工作量的百分比。

　　3)阶段工作分布：每个阶段每个工种点本阶段工作量的百分比。

　　类比法估计结果的精确度取决于历史项目数据的完整性和准确度，因此，用好类比法的前提条件之一是组织建立起较好的项目后评价与分析机制，对历史项目的数据分析是可信赖的。

　　(3)Delphi 法德尔菲法(Delphi method)，是采用背对背的通信方式征询专家小组成员的预测意见，经过几轮征询，使专家小组的预测意见趋于集中，最后做出符合市场未来发展趋势的预测结论。德尔菲法又名专家意见法或专家函询调查法，是依据系统的程序，采用匿名发表意见的方式，即团队成员之间不得互相讨论，不发生横向联系，只能与调查人员发生关系，以反复地填写问卷，以集结问卷填写人的共识及搜集各方意见，可用来构造团队沟通流程，应对复杂任务难题的管理技术。

　　Delphi 法的步骤如图4-4 所示。

　　图4-4 Delphi 法的步骤

　　第一步：准备估计内容

　　准备估计内容主要有两点需要注意：一是完备地识别被估计内容;二是尽管Delphi 法既可以对颗粒度比较大的任务进行估计，也可以对颗粒度比较小的任务进行估计，但是还是要细分任务，目的是提高估计的准确度与加快估计值收敛的速度。

　　第二步：成立估计小组。

　　成立估计小组阶段应该注意以下事项：

　　①估计小组应该由协调人、作者和3 到6 名估计专家组成。

　　②协调人负责计划和协调软件估计活动，协调人在担任此角色时不能用自己的观点去引导专家，也不能因为自己的认识或偏见而对软件估计的结果进行歪曲。

　　③协调人不能是作者，也不必作为专家。

　　④专家的数量不宜过多，否则成本比较高。

　　⑤专家必须具备两个条件：一是：有业务与技术经验的，熟悉估计的内容;二是要有估计的经验，接受过估计方法的培训，并曾经在实践中评价过自己的估计准确率。

　　第三步：召开启动会议。

　　协调人负责召开启动会议，在启动会议上主要进行以下工作：

　　①作者向专家介绍估计的内容、项目的各种假设和限制条件。

　　②专家对被估计的内容达成一致，并确认各种假设和限制条件。

　　③专家对估计结果的试题单位达成一致，如估计软件的规模时，是用行还是千行作为计量单位，代码行是否包括注释、空行、开发平台自动生成的语句等，这些都应该达成一致。

　　④对估计结束的准则达成一致。

　　第四步：专家独立估计。

　　在专家进行独立估计时，应该注意以下问题：

　　①专家的估计活动不应受外界压力的影响，协调人或作者不能给出估计结果的上下限或其他限定。

　　②各专家之间没有讨论和咨询。

　　③各专家采用的估计方法也不受限制。

　　④如果专家认为被估计的内容中存在不明确的地方，应该记录自己所做出的各种假设。

　　第五步：汇总估计结果。

　　汇总估计结果应该收集各专家的估计结果，制作本轮的估计结果表。差异率的计算方法以及接受的准则应该在活动2 或者活动3 时确定，通常的差异率的计算方法如下：

　　差异率=max(最大值-平均值，平均值-最小值)/平均值;当差异率小于25%时，平均值为最终估计结果。需要注意的是，由于颗粒比较小的任务对差异率比较敏感，所以可能需要区别定义接受准则。如果存在离群点，可以考虑删除。

　　估计结果表的格式见表4-1。　　

　　表4-1 估计结果表

　　第六步：讨论不收敛项。

　　讨论不收敛项主要需要完成以下内容：

　　①将本轮的匿名估计结果公布给各专家。

　　②讨论不收敛的估计项。

　　③为了达成一致的理解，此时可能需要重新细化估计内容或确定估计假设。

　　第七步：新一轮估计。

　　新一轮估计主要是对上一轮估计结果未被接受的估计项，执行活动4 的步骤，如此不断反复，直至满足以下任何一项条件：完成多轮估计(如5 轮)，该条件已经在结束准则中确定了;所有的估计结果收敛于一个可以接受的范围;所有专家拒绝对各自的估计结果进行修改。

　　第八步：讨论未收敛的估计项。

　　对于结束了多轮估计后，仍然未收敛的估计项，可以采用如下方法确定最终估计结果：按照少数服从多数的原则，忽略少数与其他估计结果差异很大的估计结果;采用“掐头去尾求平均值”的方法;由各专家进行讨论，形成一个一致的意见。当然，也不限于采用其他方法来确定最终的估计结果。

　　第九步：总结本次估计。

　　总结本次估计主要需要完成以下内容：

　　①估计小组对最后汇总的估计结果进行审核，并对结果达成一致。

　　②估计小组可以对Delphi 法进行思考，提出改进措施，以使将来的估计活动更加有效。

　　(4)开发时间百分比法

　　使用开发时间百分比法评估的前提是开发时间和开发工作量，也就是说，这种方法评估的准确性很大程度依赖于开发时间和开发工作量的评估。其步骤如下：

• 　　第一步：使用LOC 或FP 的方法，先估算出开发工作量。

• 　　第二步：使用一些探索性的方法来限制测试的工作量，通常遵守以下原则：

　　测试总花费的时间占整个项目的35%;

　　5%～7%给组件和集成测试;

　　18%～20%给系统测试;

　　10%给接收测试(或回归测试等)。

　　这种估算方法存在很大的不确定性，因为这个更多的是依靠经验来制定，不像其他的方法计算比较精确。

　　(5)PERT 法

　　PERT(Program Evaluation an Review Technique，计划评审技术)主要用来估算软件项目时间成本。PERT 估计方法需要评估最佳的、可能的、悲观的三种情况下的估计值，假设最佳的、可能的、悲观的估计值分别计为a、m、b，之后再按照以下公式来计算估计值：

• 　　E=(a+4×m+b)/4

• 　　E 的值则为计算出来的期望值。

　　在该公式中，包含了如下两个原理：

　　原理一：对上式进行变换，引入一个中间结果c，c 的值为a+2×m+b，那么期望值E 的结果为E=(m+c)/2。

　　原理二：从上面的公式也可以看出，在计算E 的公式中，m 的权重为4，而a 和b 的权重都是1，也就是说，该方法强调了中间值的重要性，而极值的重要性并不大。

　　该方法在实际使用过程中，需要注意以下问题：

　　第一：当只有一个人参与估算时，则需要估算人估算三个数值：

       悲观的值、可能的值、乐观的值，然后再使用公式来计算就可以。

　　第二：当2 个人参与估算时，则需要2 个估算人分别估算三个数值：

       悲观的值、可能的值、乐观的值，然后分别计算这3 个数据的平均值，再将计算出来的悲观的平均值、可能的平均值、乐观的平均值这三个值使用公式来计算就可以。

　　第三：当3 个人参与估算时，有以下2 种方法：

　　类似第二种情况的处理方法，此时3 个人估计得到9 个值;

　　每个人只估计一个数，取最大值、最小值作为悲观值和乐观值，取中间的数据作为可能值，再使用公式计算就可以。

　　第四：当N 个人(N>3)参与估算时，有以下2 种方法：

　　类似第二种情况的处理方法，此时N 个人估计得到3×N 个值;

　　每个人只估计一个数，取最大值、最小值作为悲观值和乐观值，对中间的N-2 个数值取平均值，再使用公式计算就可以。

　　一般PERT 方法适用于少于6 人参与估算的项目。

　　以上详细地描述了功能点评估法、类比法、Delphi 法、开发时间的百分比法和PERT 估计法，但在实际工作中，我们使用最多的方法还是按功能点来评估，这样更直接，其他的方法更适合整个项目工期的评估。

　　最后，给大家推荐一个软件测试自学群，识别下方二维码，免费领取学习课件、视频哦。　

　　附：川石信息全国校区最新开班时间，课程资料获取13691729932(微信同号)。