通过设定衡量代码质量的八个度量项来对软件的质量进行量化打分，其设定度量项的标准参考了定义软件质量的 ISO25010 标准。这篇文章结合鸿渐科技团队多年的实践，将给大家介绍一下如何通过 ISO25010 标准来制定以下的质量指标。

30 年多年前，软件工程师 Barry Boehm 已经发现，如果在软件发布后发现缺陷，修复缺陷的成本会成倍增加。因此，如果能够在软件发布前有一种方法来衡量软件的代码质量，它将潜在地节约大量的成本。一个定义软件代码质量的 ISO25010 应运而生，这个标准定义了八个主要质量指标和许多子指标。八个主要质量指标为：

• 功能适用性 （Functional suitability）：软件所实现的功能达到其设计规范和满足用户需求的程度，强调正确性、完备性、适合性等。

• 可靠性 (Reliability)：在规定的时间和条件下，软件所能维持其正常的功能操作、性能水平的程度／概率，如成熟性越高，可靠性就越高；用 MTTF (mean time to failure，平均失效前时间) 或 MTBF（mean time Between failures，平均故障间隔时间）来衡量可靠性。

• 效率 (Performance efficiency)：在指定条件下，软件对操作所表现出的时间特性（如响应速度）以及实现某种功能有效利用计算机资源（包括内存大小、CPU 占用时间等）的程度，局部资源占用高通常是性能瓶颈存在；系统可承受的并发用户数、连接数量等，需要考虑系统的可伸缩性。

• 可操作性 (Operability)：对于一个软件，用户学习、操作、准备输入和理解输出所作努力的程度，如安装简单方便、容易使用、界面友好，并能适用于不同特点的用户，包括对残疾人、有缺陷的人能提供产品使用的有效途径或手段（即可达性）。

• 安全性 (Security)：要求其数据传输和存储等方面能确保其安全，包括对用户身份的认证、对数据进行加密和完整性校验，所有关键性的操作都有记录（log），能够审查不同用户角色所做的操作。它涉及保密性、完整性、抗抵赖性、可核查性、真实性。

• 兼容性 (Compatibility)：涉及共存和互操作性，共存要求软件能给与系统平台、子系统、第三方软件等兼容，同时针对国际化和本地化进行了合适的处理。

• 可维护性 (Maintainability)：当一个软件投入运行应用后，需求发生变化、环境改变或软件发生错误时，进行相应修改所做努力的程度。它涉及模块化、复用性、易分析性、易修改性、易测试性等。

• 可移植性 (Transferability)：软件从一个计算机系统或环境移植到另一个系统或环境的容易程度，或者是一个系统和外部条件共同工作的容易程度。它涉及适应性、易安装性、易替换性。

ISO25010 标准有助于在软件初期阶段评估质量。然而，它有两个主要缺点：

1. 标准没有规定如何测量质量属性。一些质量属性甚至似乎不适合客观测量。以“可操作性”为例， 其子属性如“界面友好”和“易用性”。如何测量这个，测量单位是什么？

2. 大多数定义的质量属性在不同的环境中具有不同的含义。因此，即使可以测量质量属性，也很难找到判断是好或坏的明确客观标准。“效率”就是这种情况的一个很好的例子。一些软件系统在 1 秒内做出响应就足够了，而另一些软件系统则要求在 1 毫秒内做出响应。

为了对软件质量进行系统的评估，经过多年的行业经验积累，制定出可以进行量化处理的八个度量项，它们分别是：

• 代码覆盖率

• 抽象解释 

• 圈复杂度

• 编译器警告

• 编码标准 

• 重复代码

• 扇出 

• 安全

这八个度量项基于 ISO25010 制定，其量化数值和软件质量属性有一定的映射关系，具体如下。

1. 代码覆盖率

在软件工程师将他们的代码移交到软件开发周期的下一个阶段之前，他们通常做一些单元测试。这些是小规模的自动化测试，可以检查程序的特定部分，例如单个函数，然后将这些自动化测试的实际结果与预期结果进行比较。单元测试是用来检查程序能否实现设计想达到的目的最低标准的一种有效的测试方法。代码覆盖率表示在单元测试运行期间，代码中有多少行代码或可执行分支被测试。覆盖率越低，所执行的单元测试的质量就越低。代码覆盖率是“功能适用性”和“可靠性”的一个度量指标。

下面的 C#代码展示了用代码覆盖率检测工具输出的一个简单示例。每一行颜色为“绿色”的代码都经过至少一次测试，而“红色”行的代码没用经过任何测试。

代码覆盖率测试工具的输出显示，除第 37 行外，此代码示例中的所有行都由（单元）测试覆盖。

2. 抽象解释 

现在有一种通过运行抽象解释工具（也称为深流分析工具）来检测软件程序中可能存在的“可靠性”问题的新技术。这些工具能够自动检测与程序控制流程相关的各种编程错误。例如空指针解引用、除零和未关闭的数据库连接。这些工具的优点是它们在不实际运行程序的情况下就能产生结果，这是通过以计算程序所有可能的路径来完成的。抽象解释发现的错误是严重的编程错误，可能导致崩溃。这个度量项和程序“可靠性”属性息息相关。关于抽象解释问题的一个简单示例展示在下面的 Java 代码中。

抽象解释工具将在第 228 行标记一个可能出现的空指针解引用缺陷，因为函数“get Order”会在订单没有有效日期的情况下返回 NULL。如果发生这种情况，将抛出异常，可能导致程序崩溃。

3. 圈复杂度

 圈复杂度是最经典的软件度量项之一。圈复杂度在数量上表现为独立现行路径条数。例如，每个“if”语句就会添加了一条额外的代码路径。圈复杂度越高，程序代码的判断逻辑就越复杂。此外，路径越多，就需要编写更多的测试用例来实现更高的代码覆盖率。每个函数的平均圈复杂度是一个指标，可以比较程序之间的复杂性。圈复杂度在一定程度上展示了程序代码的“可维护性”。下面以一段 C#代码为例展示如何计算圈复杂度。

函数“get Value”在第 123 行的圈复杂度为 2（因为包含一条“then”路径和一条“else”路径”）。

4. 编译器警告

为了在计算机上执行软件程序，首先需要经过编译或解释。编译器或解释器会生成错误和警告而且错误必须修复，否则程序无法运行。警告虽然不一定需要解决，但是一些编译器警告表明程序存在严重缺陷。留下这些未解决的问题可能会影响代码的“可靠性”。除此之外，大多数编译器警告还体现了“可移植性”问题。因此，这个度量项和软件程序的“可移植性”也有很强的关联。下面是关于编译器警告在 C 语言代码片段的一个简单示例。

大多数编译器会在第 32 行的 if 条件下发出警告（可能是为了进行比较的原因）。

5. 编码标准

 软件维护是软件工程师最耗时的任务之一。其原因之一是经过多次更新后，软件工程师很难理解程序代码编写原本的意图。降低软件维护成本的一种方法是引入编码标准。编码标准是代码工程师应该遵循的规则。这些编码规则涉及已知的语言缺陷、要避免的代码构造，还涉及命名约定和程序布局。由于编码标准通常包含许多不同的规则，所以它们可以反应大多数代码质量属性问题。大多数规则涉及“可维护性”和“可靠性”，但也有可用于“可移植性”和“效率”的规则。下面是一个违反编码标准的示例。

任何 C 编码标准都不推荐第 36 行使用的 goto 语句。

6. 重复代码

 有些时候软件工程师会复制大量现成代码并对其进行一些小的修改而不是重新编写。大量重复代码的缺点是，如果出于某些原因（修复 bug 或添加丢失的功能）必须更改代码的一部分，那么其他重复的代码也很可能需要更改。一旦有所疏忽，重复的大量代码将产生巨大的工作量。这非常影响程序的“可维护性”。

7.  扇出

软件程序通常是由模块或组件构造的。这些模块和组件存在层次调用的情况。扇出表示某个模块使用的下级模块的个数。如果模块需要许多其他模块才能正确运行（高扇出），那么模块之间就有很高的相互依赖性，这使得代码更难修改。因此，扇出在一定程度上反映了软件程序的“可维护性”。下面的 Java 代码显示了一个高扇出的示例。

在这段代码中，我们采用了扇出的简单定义来度量 import 语句。因此，上面 Java 文件的扇出数量是 16。

8.  安全

软件的安全性反应了在未获得授权的数据访问时软件程序有多容易被攻击，以及利用安全漏洞对软件进行更改的难易程度。这种安全漏洞的例子有缓冲区溢出（让程序崩溃)和敏感数据的暴露(从而给用户提供信息以获得未经授权的访问）。下面的 C 代码给出了一个安全泄漏的示例。

在第 319 行，一个非常长的字符串被写入一个名为“buf”的数组，该数组只能容纳 8 个字符。不适合“buf”的字符被保存在其他地方，可能会覆盖应该执行程序的代码。通过利用这个漏洞，攻击者可以运行另一个程序，而不是运行的本来的程序。修正后的例子是下图。

通过使用“snprintf”而不是“sprintf”，写入缓冲区的字符数受到第二个参数的限制。

 以上就是给出的八个度量项，从上文可以发现一些度量项可以很容易地映射某些质量属性。例如，如果一个文件的代码重复率为 0%，那么这被认为是质量较高的一段代码，而如果重复率是 50%，那会被认为是糟糕的编程。然而，对于八个度量项中的四个，“抽象解释”、“编译器警告”、“编码标准”和“安全”并没有和质量属性间存在非常明确的对应关系。例如，如果代码中有 3000 个编码标准问题，那么这段编码的质量高低还取决于以下 3 个附加因素：

1. 测量了多少编码规则？如果一个编码标准比另一个编码标准有更多的规则，那么违规的可能性就会更高。但这并不意味着该代码的代码质量较低。

2. 违反的规则的严重程度是多少？如果只违反了不重要的规则，那么代码质量就会比同样违规数量的其他代码更好。

3. 代码的数量级是多少？如果在一个由 1000 万行代码组成的系统中有 3000 起违反代码规则事件，那么与一个只有 1000 行代码的系统相比，情况就显得不那么严重了。

为了解决这一问题，引入了“加权因子” (compliance factor) 的概念。加权因子表示软件代码在多大程度上符合某一组规则。例如，这可能是一组编译器警告或一组安全规则。

具体的计算公式如下：

对此公式的详细解释大家可以参看文末相关文献链接。许多项目中使用这一定义已有 20 多年，在实践中效果显著。通过行业经验确定了度量项在软件质量属性中所占权重大小，然后分别计算每个度量项分数后进行加权汇总，得到反应软件质量等级和评分的一个检测报告。

质量指标是一种非常实用的方法，可以在软件程序发布前甚至在系统测试之前对软件代码的质量进行量化概述。该指标结合了最著名的代码质量度量项，通过公司现有的代码检测工具定义了它们是如何测量的，以及如何判断质量的高低。按照得到的分数，将软件系统依次标记为 A（优秀质量）到 F（质量差)多个不同的质量等级。

鸿渐科技的现有的“源代码检测系统”可以对代码的圈复杂度，扇入扇出和重复代码比例做量化分析，同时，参考众多国内外顶会文章的相关指标量化的设计也在积极努力的开发中，造烛求明,学他求理，鸿渐科技必将在代码质量量化道路上继续披荆斩棘，奋勇向前。

参考

[1] Boehm, Barry W.; Philip N. Papaccio, “Understanding and Controlling Software Costs”, IEEE Transactions 

on Software Engineering, v. 14, no. 10, October 1988, pp. 1462-1477. 

[2] ISO, “Systems and software engineering – Systems and software Quality Requirements and Evaluation 

(SquaRE) – System and software quality models”, ISO/IEC 25010:2011, 2011, obtainable from 

http://www.iso.org/iso/iso_catalogue/catalogue_tc/catalogue_detail.htm?csnumber=35733. 

[3] Wikipedia, “Cyclomatic Complexity”, extracted July 2012, obtainable from 

http://en.wikipedia.org/wiki/Cyclomatic_complexity. 

[4] Wikipedia, “Duplicated Code”, extracted July 2012, obtainable from 

http://en.wikipedia.org/wiki/Duplicate_code. 

[5] Wikipedia, “Code Coverage”, extracted July 2012, obtainable from 

http://en.wikipedia.org/wiki/Code_coverage. 

[6] Wikipedia, “Abstract Interpretation”, extracted July 2012, obtainable from 

http://en.wikipedia.org/wiki/Abstract_interpretation. 

[7] Wikipedia, “Coding Conventions”, extracted July 2012, obtainable from 

http://en.wikipedia.org/wiki/Coding_standard. 

[8] Henry, S.; Kafura, D., “Software Structure Metrics Based on Information Flow”, IEEE Transactions on 

Software Engineering Volume SE-7, Issue 5, September 1981, pp. 510–518. 

[9] OWASP, “OWASP top 10 - 2013, The ten most critical web application security risks”, extracted 

December 2016, obtainable from https://www.owasp.org/index.php/Top_10_2013. 

[10] CERT, “CERT Secure Coding”, extracted December 2016, obtainable from https://www.cert.org/secure

coding/. 

[11] Jansen, Paul; Krikhaar, Rene; Dijkstra, Fons, “Towards a Single Software Quality Metric – The Static 

Confidence Factor”, 2006, obtainable from 

http://www.tiobe.com/content/paperinfo/DefinitionOfConfidenceFactor.html. 

[12] Wikipedia, “European Union energy label”, extracted July 2012, obtainable from 

http://en.wikipedia.org/wiki/European_Union_energy_labe