TomJ.McCabe：寻找度量软件的本源

作者&＃xff1a;McCabe & Associates 公司创始人、CEO及董事会主席、McCabe 圈复杂度的始创者Tom J. McCabe 数学思维和软件工程思维的结合并非偶然。对于圈复杂度测试方法&＃xff0c;我认为其属于数学范畴&＃xff0c;这一方法创立的灵感来自于数学中的图论。对一切可操作的事物都要先进行量化才能进行管理的思想&＃xff0c;正是数学带给我们的礼物。 在软件工程的理论体系中&＃xff0c;结构测试过程相当严格&＃xff0c;要求每个判定输出都被独立地测试到&＃xff0c;这使我想到这一过程与数学定有必然联系。白盒测试全周期的基本理念是要在测试时考虑全体软件的测试执行&＃xff0c;尤其是在软件的规格说明书含糊、不完整时更要依赖上述理念。结构测试和基于功能的测试在有效测试阶段的作用是相当的&＃xff0c;对软件质量的提高都有助益。 软件度量是对软件开发周期中的开发对象、过程及最终产品进行数据定义、收集及分析的持续性量化过程&＃xff0c;目的在于对软件进行理解、预测、评估、控制和改善。可以这样认为&＃xff0c;不经过度量&＃xff0c;就无法将软件开发从暗箱中挑出来。软件复杂度是软件度量分支中直接关注软件的方法&＃xff0c;与项目节点状态和报告系统缺陷等软件度量形成对比。 选取度量的一个重要标准就是应用的一致性&＃xff0c;业内通常采用“open reengineering”正基于此。恰如“open system”被广泛应用于商业软件&＃xff0c;其原因就是提供给用户一定程度的互用性——应用程序几乎可以在所有的通用平台上工作&＃xff0c;并且在硬件平台上交互也并非难事。“open reengineering”的理念是&＃xff1a;用于表现软件系统的抽象模块应该具有独立性。一个理想的度量值&＃xff0c;不管源代码使用Ada&＃xff0c;C&＃xff0c;FORTAIN还是其他语言&＃xff0c;都应该能显示一致的内部实现。大部分基本复杂度度量&＃xff0c;例如代码行数虽然对程序语言&＃xff0c;代码风格&＃xff0c;和代码格式高度敏感&＃xff0c;但却不符合“open reengineering”规范&＃xff1b;对于圈复杂度度量&＃xff0c; 其度量对象是函数判定逻辑的总和&＃xff0c; 符合“open reengineer ing”的理念&＃xff0c;它完全独立于代码格式&＃xff0c; 并且与所使用的程序语言基本无关&＃xff0c; 即使部分判定结构相同也可以使用。按照理想的状态&＃xff0c; 复杂度应该同时具备描述性和规范性。描述性度量会将软件认为是易于出错的&＃xff0c;难于理解、修改和测试的。规范性度量则认为改进操作步骤将有助于控制软件。我们说的软件复杂度和测试之间有着千丝万缕的联系&＃xff0c;结构测试方法使得这种联系更加明显。首先&＃xff0c;过于复杂是软件错误的根源&＃xff0c;无论是以抽象或者具体的思维角度来看&＃xff0c;都可以得出上述结论。抽象来说&＃xff0c;复杂性超出一定程度将会严重影响人类的精确处理能力并导致错误&＃xff1b;具体的讲&＃xff0c;大量研究和经验表明圈复杂度与软件模块中的错误紧密相关&＃xff0c;假如一个模块比较复杂&＃xff0c;那么它也就比较容易出错&＃xff1a;超出了度量的阈值&＃xff0c;模块中的错误数量也会随着急剧增长。基于上述结论&＃xff0c;无论在欧美还是亚洲&＃xff0c;重视软件质量和对产品负责的企业部门都开始应用圈复杂度&＃xff0c;以提高软件整体的可靠性。其次&＃xff0c;复杂度也能用于衡量测试的工作量。通过复杂度和软件出错之间的联系来加强在那些容易出错部分的测试投入。为加深对复杂度的理解&＃xff0c;可以采用自动化的工具&＃xff0c;比如我们公司在中国的合作伙伴&＃xff0c;北京旋极信息技术股份有限公司所推广的产品McCabe IQ等。 圈复杂度&＃xff0c;能够帮助你对软件的质量进行深入判断、剖析、组织和反复的运用&＃xff0c;进一步通过圈复杂度方法去认识软件&＃xff0c;了解软件和架构软件。 (本文来自《程序员》杂志0908期)