软件开发过程论文软件开发过程论文：传统软件开发方法中的单元测试工作量估算.doc

软件开发过程 论文软件开发过程论文:传统软件开发方法中的单元测试工作量估算摘 要： 讨论了几种单元测试工作量估算方法各自的优缺点和对推荐方法的修正。根据实践经验，提出了一些有助于提高估算准确度的经验数据。关键词： 单元测试；工作量估算；传统软件开发方法1 问题提出单元测试在软件项目开发阶段划分上不是一个独立的阶段。这一点在各种有关项目管理、软件工程的方法论中都没有异议。一般地，单元测试都是与编码合在一起考虑，即所谓的CDUT(Coding,Unit Test)或把详细设计也包括进来的DCUT(Design,Coding,Unit Test)。这是因为单元测试是由开发人员自己进行的。软件项目的工作量估算十分重要，因为它直接关系到项目实施的成本和计划。估算方法多种多样，本质上这些方法都是基于项目应用系统最终的规模来衡量的，例如代码行数、功能点数等。关于项目的估算有很多书籍、文献都会论及。然而，对单元测试的工作量估算却鲜有书籍、文献论及。一些项目中，要么把它混在编码里一起考虑，要么凭经验猜测其工作量或把它按编码工作量的一定比例推算。前两种方法准确度不高，后一种方法虽然有一定的准确度，但也有缺陷。因为项目的类型大体上可以分成新开发型和维护型。对于维护型的项目，单元测试工作量按编码工作量的一定比例推算，误差较大。在此讨论的是用传统开发方法开发商业应用软件的情况下，单元测试工作量的估算。传统的开发方法大体上会按需求分析、系统分析、概要设计、详细设计、编码、单元测试、集成测试、用户验收测试、投产等阶段划分。如果采用新的开发过程，如敏捷方法论(Agile)中的测试驱动开发方法(TDD-Test Driven Development)，情况会有很大的不同。2 估算方法软件的测试工作量的估算方法有很多种，主要的有这样一些方法。2.1 基于软件规模应用这种方法的前提是需要对软件的规模作出估算。一般，在评估项目工作量的时候，都会有软件规模的估算。所以估算测试工作量的时候，这个前提是可以满足的。软件的规模通常用两种方式度量：（1）功能点数；（2）代码行数。功能点数是一种与编码语言无关的度量方法，它把对表的输入、输出按一定的规则折算成功能点，把这些功能点合计后就是应用的功能点数。而代码行数则与编码语言实现有关。有的编程语言代码行数多、有的少。估算的方式有两种：（1）编码比例法。这种方法首先统计出编码所用的时间，然后根据一定的比例计算出测试的工作量。根据笔者所看到的若干个项目组经验，单元测试的工作量是编码工作量的1.01.2倍。这种方法要求软件开发组织需要统计本组织历史数据，维护类似表1的基础数据。（2）生产率计算法。这种方法要求软件开发组织有自己的测试生产率数据：单位时间内完成的测试工作量，单位是功能点或代码行/人日或人时（见表2）。软件规模除以生产率数据即可得出测试工作量。方法（1）更常用。尤其是日本的软件开发组织更习惯于用方法（1）。日本的软件开发组织在做项目估算的时候，通常首先估算代码行数，然后根据比例，推算出概要设计（外部设计）、详细设计（内部设计）和单元测试的工作量。通常在统计代码行数的时候，都要剔出注释行，原因是注释的工作量不能与代码相比，工作量远少于编码。根据经验、还有所看到的不同项目组的经验，代码中的注释都比所期望的少。既然工作量很少，为何程序员都不愿写注释呢？实际情况不是这样，写注释的工作量不比写代码少。大多数程序员都不愿多写注释，这不是因为不重视，而是要花很多时间。而在外包型的项目中，注释还要求用外语编写，难度更高，工作量也更大。在此建议做软件开发的组织应当在统计代码行的时候，把注释行计算在内。只有这样才能反映真实的工作量，提高程序员写注释的积极性，为今后应用的维护提供方便。初始的设计文档会随着维护的增多变得陈旧，各个组织限于资源都不会去实时更新，但代码中的注释必须是最新的。基于软件规模的估算方法的优点是：（1）方法简单。（2）估算本身的工作量小。这种方法的缺点是：（1）估算的依据因缺少细化的东西难以让他人，尤其是客户信服（2）估算的误差离散度大，原因是工作量与项目类型有很大关系。（3）软件开发组织需要保留和统计大量的历史数据确保上述两个表的精确度。（4）业务逻辑算法复杂度不一样。代码行数不能体现这种差别。在维护型的项目里，单元测试工作量可能比编码要大很多。例如，在银行应用里，利息计算通常会变成一个公用模块，它集成了活期、定期、定活两便、存本取息等全部的业务利息计算方法。如果要修改这样的模块，可能改动量只有几行代码，但测试时需要把全部可能的业务都要测试一遍。虽然有上述的缺点，但在项目的早期、还缺少足够细节的情况下，这种估算方法还是有用的。另外用这种方法也可以验证其他估算方法的结果。2.2 基于测试案例这种方法原理是，软件开发组织内部需要有如表3的历史数据。首先开发人员针对要测试的应用或模块，设计测试案例。其次，根据测试案例数和表2的每个案例所花的时间计算出总的测试时间。为了保持组织内部数据的准确性，软件开发组织需要不断的维护表3。但这张表要比估算方法一的表简单。在单元测试的时候，测试案例已经体现了测试工作量，因而项目不再需要划分为开发或维护。另外，测试的时候，编程语言不同的影响也比编码时小很多，可以忽略。在前面举的例子中，虽然代码修改工作不多，但测试工作量大。而这个差异已经体现在了测试案例里了：测试案例会有很多。基于测试案例的估算方法的优点是：（1）通过测试案例，测试工作量可以比较准确确定，也易于被他人（包括客户）接受。（2）方法本身可以屏蔽掉实现上的技术差异，如编程语言等。（3）估算的准确性好，误差离散度小。（4）测试过程可控：根据完成的测试案例，可以方便地评估测试进展。这种方法的缺点是：（1）因为要编写测试案例，估算的成本增加。（2）测试案例本身有差异，执行所需的时间也不同。这种估算方法不能体现出这种差异。2.3 基于任务这种方法是从任务的角度评估工作量。例如，在一个典型的测试活动中，通常都会有：（1）制定测试计划。（2）设计测试案例。（3）建立测试环境。（4）根据计划和案例进行测试。（5）编写测试文档。评估时，对这些活动的工作量分别进行评估。然后把所有活动所需的工作量合计，就是总的测试工作量。很明显这种评估工作量的方法最完善，而且能够提供足够的细节让他人审核。缺点是任务很多，估算成本很大。3 应用从上面的讨论可以看出，基于软件规模评估单元测试工作量，过于粗糙，这会导致估算误差过大，从而导致进度、费用误差也会加大。一个具有CMMI5级认证的组织通常会要求进度、费用的误差不大于5%，这关系到组织的名声和项目管理的能力。一个较真的客户一般也不会接受没有细节的估算。基于任务的估算方法用于单元测试，则又过于复杂。进行单元测试的人员是开发人员自己，测试是在组件、模块一级进行的。所以不需要单独的测试计划，在概要设计书或详细设计书中作为一节列出即可。也不需要建立类似生产环境的测试环境。这种方法更适合于组织内部或者项目组内部有独立的集成测试、系统集成测试人员时的工作量估算。综上所述，单元测试的工作量估算采用基于测试案例的估算方法更适合。当然不论采用哪种方法，软件开发组织都需要积累、统计历史数据，其他组织的数据和经验只能作为参考，不能直接用于本组织。每个组织都有自己的文化、管理习惯、软件开发方法论，甚至开发人员的构成、经验都不相同，这些都会对工作量的评估有影响。软件开发组织积累、统计历史数据也是通过CMMI高级别认证的要求。4 修正在估算的时候，还可以把PERT(Program Evaluation andReview Technique)方法应用到基于软件规模的估算方法和基于测试案例的估算方法来提高估算的准确性。PERT方法的原理是，估算的时候要同时估算3个值，最可能的值；最悲观的值；最乐观的值。然后按公式（最悲观的值+4*最可能的值+最乐观的值）/6得到加权平均值。应用PERT方法能够减少估算误差的离散度。根据经验，可以首先估计一个最可能的工作量，然后下浮5%-10%作为最乐观的值，再上浮10%-20%作为最悲观的值。估算时另一个需要考虑的因素是组件、模块中的表（Table）的数量和算法复杂度的影响。程序中用到的表之间通常不是孤立的，相互间是有联系的，表和表的记录之间是有依赖关系的。往往需要根据一个表中的记录值查找另一个表中的记录。这就给单元测试验证程序功能增加了困难。一般的组件、模块中每增加一个表，总的测试工作量会增加大约1.5人时。增加5个表，几乎相当于增加一个人时。当程序里有两层甚至三层循环、IF嵌套三层以上而且嵌套部分代码很多时，也会增加测试的工作量。经验表明，有两层循环时，测试工作量会增加2人时左右，有三层以上IF嵌套时，测试工作量会增加1人时左右。需要指出的是，为了程序逻辑更加清晰，或为了增加程序的可读性，往往会把多层循环或多层IF嵌套放在不同的模块内，这种情况要识别出来。因为这种设计、编码安排不会减少总的测试工作量，可能掩盖工作量。另一个需要考虑的因素是沟通、协作的耗时。例如在应用里有异种平台数据库之间的连接或者应用了MQ等中间件与其他平台数据交换，也需要考虑人员沟通协作的成本。这主要体现在需要有等待时间。5 结语基于测试案例的估算方法能够较好地取得估算精度和估算工作量的平衡，适合用作单元测试的工作量估算。需要指出的是，测试工作量的估算方法是项目管理上的需要，不是质量管理的需要。测试案例是否完善、是否能够覆盖所有的测试点，这是另外的问题。测试工作量大并不等于测试质量高。测试工作量的估算是个实践性很强的工作，既需要有方法论的指导，也需要有实践经验。同时，软件开发组织也需要积累自己的历史数据分析调整各种估算因子。随着开发项目的增加，软件开发组织和开发人员的能力不断提高，估算精度也才能不断提高。参考文献1 Chemuturi,M.Test Effort Estimation EB/OL. http:/ whitepapers .techno logy e