丈量软件质量

对比十年前，虽然软件开发采用的语言进步了，开发工具更先进了，国家的投入也多了，但国产软件的质量仍然没有一个跨越性的提升。不坚实的软件质量带来了严重的后果，例如：

 

1．  国内用户形成思维定势，不认可国产软件的质量，导致用户倾向采购更为昂贵但质量更好的国外软件，近而导致国产软件无法在市场上成为主流，特别是在基础平台软件领域。

2．  国内开发人员潜意识中认可国外软件厂商的领先性和标准性，满足于跟踪学习，削弱了创新挑战的意识，进而更加深第一点。

3．  大量的软件项目拖延导致软件开发成本急剧增加，导致软件企业利润微薄，无法完成资本积累走上良性发展的道路。

4．  国产软件不能在质量，先进性和用户数上和国外产品较量，进而无法获得参与国际标准制定的门票，继续滞后。

 

ISO9001, CMM的推动都是希望能通过流程控制来保证软件质量，但具体如何保证，软件质量到底如何，仍然没有一个具体的方法和客观的衡量标准，而完全依赖开发人员自己的主观猜测（ 注: ISO9001的文档化管理已经被证明不适用于软件开发， CMM只是规定了需要做到的功能点，但没有规定如何做）。

 

同样的问题也困扰着西方的软件产业，从90年代末起，西方软件业兴起了敏捷开发的热潮，很多“新”的软件开发方法和概念被引入到商业软件开发中，例如测试先行的开发(Test-driven Development)，自动回归测试( Auto-Regression Test )，持久集成测试( Continuous Integration )，共享代码( Celebrative Code Ownership )等。同时开源运动的发展也更近一步推动了敏捷开发的潮流（最著名的单元测试工具Junit就是开源产品），使这些由民间程序员自行总结和发起的敏捷开发方法迅速超越以往的CMM, RUP成为西方软件业的主流开发方法。IBM的RUP和微软最新的.NET Framework都提供了用于敏捷开发的工具和支持。而印度的外包软件企业也开始提供敏捷外包业务。

 

这些”新”方法的引入，使得保证软件质量有了切实的手段，更重要的是使软件质量的测量有了基础。是的！软件质量是可以被丈量的！

 

之所以在”新”的上使用引号, 是因为这些开发方法都是早就在被采用，软件质量的丈量也早就被研究和运用，但真正在商业应用中被广泛应用还是在java语言和敏捷开发方法普及之后。

 

而在软件质量保证，软件质量丈量方面的研究和应用，走的最前的是美国的国防，军事情报等部门。甚至在java/敏捷开发方法普及以前，在C, C++，Fortune , Ada语言的时代，软件测试和软件质量的量化丈量等概念就已经在美国军事部门的软件开发过程中被研究和运用。在IEEE协会的很多论文当中，关于软件质量丈量的很多论文都是美国军事部门的工程师提交的。他们通过对数年内软件项目中软件的代码数量，测试手段，测试覆盖，代码分析，错误率等进行了大量的统计分析，发展了完善的软件测试方法，工具和软件质量衡量的指标体系。

 

软件质量保证（ Quality Assurance ）一个重要的概念就是软件质量应该是可以丈量的。一个软件是否能够通过验收，是否达到发布到生产环境的标准应该是可以通过量化的指标来衡量，而不是依靠主观的判断。目前国内的软件开发项目通过验收，基本上是靠人工做功能点测试。根据功能点测试存在两个问题：

 

1．    从使用角度进行的功能测试经常无法覆盖所有的可能性，是一种粗放型黑盒测试。

2．    无法衡量软件代码的质量。

 

而同样的，软件开发商对问题“你们的软件质量如何?”往往也无法拿出数据进行证明自己软件的质量。就是说，软件质量变成了一个象征性的名词，我们知道需要重视软件质量，但如何保证软件质量，特别是如何量化软件质量，衡量软件质量却没有方法和手段。对用户来说，他无法明确知道开发商提交的软件是否质量优良。对软件开发商来说，他也无法明确知道自己开发的软件的质量和对用户证明。因此量化软件质量使之可以被测量对用户和软件开发商都有重要的意义。

 

何产品都有质量标准(国际标准,国家标准,部颁标准,企业标准等),没有质量的产品就没有市场。软件既然是一种产品(商品),就应该有它客观质量的标准尺度,不能依赖少数人的主观推理和臆测或做小范围功能点的人工测试. 软件质量应该量化！

 

如何丈量软件的质量？主要通过对代码，测试代码进行自动的分析，获得一系列相应的数据指标来说明软件的质量。主要做两个分析：

 

1．  静态分析Static Metrics Analysis

 

静态分析通过分析代码后获得的基本数据：

1）  文件总数

2）  代码总行数

3）  对象类的总数

4）  方法的总数

5）  平均每个方法的代码行数

6）  注释的行数

7）  每个方法中可执行语句的行数

8）  每个方法中符值语句的行数

9）  条件语句的行数

 

每个项目可以根据不同的需要定出需要符合的指标。例如美国国土安全局的软件项目规定每个方法的行数不可以超过62行，可执行语句不超过50行，而符值语句不可以超过12行。

 

在此基础上，还可以加入重复代码分析（ 防止开发人员简单的拷贝重复代码，重复代码会使软件的可扩展性大大降低），逻辑分析路径分析等智能分析功能，进一步检测软件的质量。

 

 

 

2．  覆盖分析 (Coverage Analysis)

 

静态分析的指标能反映质量的一个侧面，而覆盖分析则能展现软件的性能，可维护性，可测试性，也是软件质量最直观的体现。覆盖分析主要是运行各种单元测试，集成测试，并记录测试所覆盖的代码的信息。

 

覆盖分析采集的基本数据：

 

1）  代码行覆盖率。即多少代码行确实被测试所运行和测试。

2）  方法覆盖率。即多少方法确实被测试所运行和测试。

3）  条件语句覆盖率。即多少条件语句的分支是否被覆盖。

 

同样的每个项目可以根据需要定出项目合格的标准。例如军方项目的条件语句/方法覆盖率必须是100%的。

 

在此基础上，还可以添加更加智能/复杂的逻辑路径覆盖分析。

 

通过上面两个方面的分析产生的数据综合反映软件的质量。有了这些数据我们就可以丈量软件的质量。而且我们可以随时知道软件开发的质量并做出调整，而不是等到交付的时候才发现问题（管理学中的风险提前）。

 

对于软件外包行业，引入软件测量概念和方法，除了提升企业本身的素质和软件质量外，更应该在提交委托方的产品的时候伴随相应的测试代码和质量测量数据。这样做的好处是：

 

1）  提升用户的满意度。

2）  建立专业外包形象。

3）  和其他国家的外包服务拉开差距，形成质量为先的外包品牌。

 

结束语 :  有了量化的指标，除了能给软件开发项目的甲乙双方一个明确的软件质量合同外（不再单单是功能合同），更重要的是将软件质量保证制度化，进而迫使软件开发企业注重软件质量 // 流程管理的意识，改变旧的依赖人工测试的概念，引入测试驱动开发，自动单元测试，自动集成测试，每日集成，小规模发布等优秀的敏捷开发方法，切实提升软件的质量和开发效率。