【IT168 技术文章】

    测试工作量的估计往往和软件开发的规模是紧密相关的.很多软件公司往往是在估计了即将要开发的软件规模后才做测试工作量的估计,然后求和得出项目的最终工作量估计.这种方法比较适用于有经验积累,测试和开发模式稳定的公司或项目,提供了一个比较准确,有参考的数字.但同时由于其完全依赖其前提-开发工作量的估计,显得比较脆弱,如果开发工作量出现较大偏差,测试工作量也就变得毫无用处.在加之代码行本身就存在着许多问题和局限,所以在选择其做为项目估算方法时需要好好了解它的原理,优缺点进而有选择性的使用.

    代码行, 是来源与英文line of code.那么代码行分析方法就是就是对软件产品的源代码的行数进行测量.但是仔细想想,可能会有以下疑问:

    是计算物理行数,还是程序的命令数量?

    空行是否计算?

    注释是否计算?

    预定义文件是否计算?

    不同版本如何计算?

    这里面是否设计到一系列的规则定义问题?

    开发过程种的配置脚本,编译脚本是否计算?

    共享文件(例如共享的开发库文件种的头部文件)如何计算?

    那么现在的一般规则是计算物理行数,不计算空行,不计算注释.对于其他选项,一般为计算源文件根目录下的所有文件.所以代码行指的是指所有的可执行的源代码行数，包括可交付的工作控制语言 (JCL ： job control language) 语句、数据定义、数据类型声明、等价声明、输入 / 输出格式声明等。常使用的单位有： SLOC(single line of code)、KLOC(thousand lines of code)、 LLOC(logical line of code)、PLOC(physical line of code)、NCLOC (non-commented line of code)、DSI(delivered source instruction)。其中SLOC和KLOC比较常用.

    代码行分析方法对技术人员是有意义的,因为它的确从某种程序上反映了软件的规模,并且是物理上可测量的.但是这种方法也存在如下诸多问题.

    在需求、计划、设计阶段因为本身没有代码行，需要靠估算来解决。总体上估算准确度不高，除非有多年的类似项目经验。估算的准确程度取决于是否有同类项目的数据和估算人员的经验。在编码、测试、实施阶段可以直接数出来。

    在满足客户的要求以及反映进度方面的能力差强人意,对于管理者意义不大.因此项目很难从整体上跟踪代码行数的指标采取行动.

    近来可视化编程工具的大量采用,以及模板库,类库的广泛采用,在程序的结果中有大量自动生成的代码或者复杂的自动配置脚本或资源文件设置,在采用这些工具的项目中,用代码行分析方法得到数值的意义已经大大降低.

    对于不同的编程语言来说,代码行也缺乏可信转换方式.

    尽管代码行方法有很多缺点,但是由于它容易使用,操作成本低(如果采用适当的支持工具),还是推荐使用代码行作为软件项目管理的参考和补充手段.