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

软件开发过程 论文软件开发过程论文: 传统软件开发方法中的单元测试工作量估算 摘 要： 讨论了几种单元测试工作量估算方法各自的优缺点和对推荐方法的修正。根据实践经验，提出了一些有助于提高估算准确度的经验数据。 关键词： 单元测试；工作量估算；传统软件开发方法 1 问题提出 单元测试在软件项目开发阶段划分上不是一个独立的阶段。这一点在各种有关项目管理、软件工程的方法论中都没有异议。一般地，单元测试都是与编码合在一起考虑，即所谓的CDUT(Coding,Unit Test)或把详细设计也包括进来的DCUT(Design,Coding,Unit Test)。这是因为单元测试是由开发人员自己进行的。 软件项目的工作量估算十分重要，因为它直接关系到项目实施的成本和计划。估算方法多种多样，本质上这些方法都是基于项目应用系统最终的规模来衡量的，例如代码行数、功能点数等。关于项目的估算有很多书籍、文献都会论及。 然而，对单元测试的工作量估算却鲜有书籍、文献论及。一些项目中，要么把它混在编码里一起考虑，要么凭经验猜测其工作量或把它按编码工作量的一定比例推算。前两种方法准确度不高，后一种方法虽然有一定的准确度，但也有缺陷。因为项目的类型大体上可以分成新开发型和维护型。对于维护型的项目，单元测试工作量按编码工作量的一定比例推算，误差较大。 在此讨论的是用传统开发方法开发商业应用软件的情况下，单元测试工作量的估算。传统的开发方法大体上会按需求分析、系统分析、概要设计、详细设计、编码、单元测试、集成测试、用户验收测试、投产等阶段划分。如果采用新的开发过程，如敏捷方法论(Agile)中的测试驱动开发方法(TDD-Test Driven Development)，情况会有很大的不同。 2 估算方法 软件的测试工作量的估算方法有很多种，主要的有这样一些方法。 2.1 基于软件规模 应用这种方法的前提是需要对软件的规模作出估算。一般，在评估项目工作量的时候，都会有软件规模的估算。所以估算测试工作量的时候，这个前提是可以满足的。软件的规模通常用两种方式度量： （1）功能点数； （2）代码行数。功能点数是一种与编码语言无关的度量方法，它把对表的输入、输出按一定的规则折算成功能点，把这些功能点合计后就是应用的功能点数。而代码行数则与编码语言实现有关。有的编程语言代码行数多、有的少。估算的方式有两种： （1）编码比例法。这种方法首先统计出编码所用的时间，然后根据一定的比例计算出测试的工作量。根据笔者所看到的若干个项目组经验，单元测试的工作量是编码工作量的1.0—1.2倍。这种方法要求软件开发组织需要统计本组织历史数据，维护类似表1的基础数据。 （2）生产率计算法。这种方法要求软件开发组织有自己的测试生产率数据：单位时间内完成的测试工作量，单位是功能点或代码行/人日或人时（见表2）。软件规模除以生产率数据即可得出测试工作量。 方法（1）更常用。尤其是日本的软件开发组织更习惯于用方法（1）。日本的软件开发组织在做项目估算的时候，通常首先估算代码行数，然后根据比例，推算出概要设计（外部设计）、详细设计（内部设计）和单元测试的工作量。 通常在统计代码行数的时候，都要剔出注释行，原因是注释的工作量不能与代码相比，工作量远少于编码。根据经验、还有所看到的不同项目组的经验，代码中的注释都比所期望的少。既然工作量很少，为何程序员都不愿写注释呢？实际情况不是这样，写注释的工作量不比写代码少。大多数程序员都不愿多写注释，这不是因为不重视，而是要花很多时间。而在外包型的项目中，注释还要求用外语编写，难度更高，工作量也更大。在此建议做软件开发的组织应当在统计代码行的时候，把注释行计算在内。只有这样才能反映真实的工作量，提高程序员写注释的积极性，为今后应用的维护提供方便。初始的设计文档会随着维护的增多变得陈旧，各个组织限于资源都不会去实时更新，但代码中的注释必须是最新的。 基于软件规模的估算方法的优点是： （1）方法简单。 （2）估算本身的工作量小。这种方法的缺点是： （1）估算的依据因缺少细化的东西难以让他人，尤其是客户信服（2）估算的误差离散度大，原因是工作量与项目类型有很大关系。（3）软件开发组织需要保留和统计大量的历史数据确保上述两个表的精确度。（4）业务逻辑算法复杂度不一样。代码行数不能体现这种差别。 在维护型的项目里，单元测试工作量可能比编码要大很多。例如，在银行应用里，利息计算通常会变成一个公用模块，它集成了活期、定期、定活两便、存本取息等全部的业务利息计算方法。如果要修改这样的模块，可能改动量只有几行代码，但测试时需要把全部可能的业务都要测试一遍。虽然有上述的缺点，但在项目的早期、还缺少足够细节的情况下，这种估算方法还是有用的。另外用这种方法也可以验