衡量软件质量的常用指标

最近，资深软件工程师 Cagdas Basaraner 在博客中总结了软件开发实践过程中常用的几个衡量软件质量的指标，包括源代码行数、代码段/ 模块/ 时间段内的平均Bug 数、代码覆盖率、设计/ 开发约束等。

源代码行数（SLOC）

计算源代码行数也许是最简单的办法。它主要体现了软件的规模，并为项目的发展和规划提供了有用的信息。比如，如果我们每月计算一次源代码行数，那么就可以绘制一个项目成长图。当然，这种方式并太不可靠，原因是重构和设计阶段等因素会对此产生影响，但是至少可以为项目描绘一个趋势。

源代码行数的统计如果只计算逻辑代码行，那么会得到比较准确的信息。逻辑代码行不包括空行、单个括号行和注释行等等。统计源代码行数的工具有很多，比如 Metrics 等。

代码行数不应该用于评估开发人员的效率，这可能会导致重复的、无法维护和不专业的代码。

Shahar Yair 和 Steve McConnell 早己指出，首先，使用代码行数之和无法有效评估一个项目的实际进度，因为它更注重行为而不是结果。最终产品在多大程度上依赖于代码的性能和质量，这也是代码行数无法说明的。因此，聚焦于此实际上是非常有限的工作效率测量方式。SLOC 无法表明要解决的问题的复杂性，也不能以可维护性、灵活性、扩展性等等因素来说明最终产品的质量。说到质量，它反而可能起到负面作用。通过重构、使用设计模式会减少代码行数，同时提升代码质量。代码量大，可能意味着有更多不必要的代码、更高不必要的复杂性、更加僵化难懂。

代码段 / 模块 / 时间段内的 Bug 数

缺陷跟踪对于更好的测试和维护是必不可少的。通过缺陷跟踪，我们可以利用报告工具（如 Mantis ）计算出每个代码段、模块或者特定时间段内的 bug 数量。凭借这些数据，我们可以尽早的查出和解决缺陷起因。

Bug 数量可能会作为衡量开发人员效率的指标之一，但是必须非常谨慎。如果把这项指标看得太重，那么开发人员和测试人员可能会成为敌人。在一个高效率的公司，所有的员工必须团结协作。为了更好地实现评估，bug 可以被分为低、中、高等，因为这些缺陷的重要性和解决成本不是相同的。

此前，InfoQ 中文站曾经针对“Bug 统计是否在浪费时间”做了讨论，大家的看法包括：

其实我一直都不低调：bug 统计到底有没有用见仁见智，关键要看怎么统计，想得到什么。从来没有认真分析过 bug 数据的人，肯定不会知道数据里面隐藏着什么。抛开 bug 统计这个问题，缺陷追踪工具到底是一个什么地位？一个项目 2000bug，如果没有工具辅助，所有人估计要崩溃了。没有人直接反对这个想法，应该这是 DEV 的内部会议，与测试无关。

双子的天马行空 -Adey ：其实我觉得他说得很有道理的, 真正的敏捷应该不需要 bug track system。Facebook 的开发模式，就是 dev 直接面向客户，它有多个直接面向客户的开发团队,，只要有需求，开发后直接上线。如果后面有 issue，是有 second tier 的 dev team 来 support fix。tier one 的 dev 永远在敏捷快速状态。

柴阿峰：回复 @双子的天马行空 -Adey : 三五个人的成熟团队敏捷也许不需要，大部分还是需要的。否则各种基于 bug trace 的管理系统就不需要开发持续集成、变更驱动测试的功能了。好的软件可以帮助实施敏捷，而不是反过来，不可能什么都靠嘴和白板的。

Sab866 ：敏捷的基础是团队成员都是自律自发且积极的，不需要用报告来鞭策，但是简单易用的缺陷管理工具还是必须的，不然还真是会一片混乱。

代码覆盖率

代码覆盖率反映了程序当中源代码被测试的程度。有许多自动化工具可以完成该功能，比如 Cobertura 。

代码覆盖率不能完全代表单元测试的整体质量，但是可以反映出测试覆盖率的问题。它可以和其他测试指标一起作为软件质量的指标。同时，单元测试代码、集成测试场景和结果应该经常地被审查。

有关质量模型的问题，支付宝 SQA 团队的西剑提出有效的代码度量模型应具备以下特征：

• 与组织的目标一致：代码度量模型的底线要与组织的要求一致，和业务相关的东西会体现在规范里。在支付宝，代码安全规范、敏感信息处理规范被作为代码质量最基本的要求。
• 有针对性：要做针对性分析，比如对线上故障的研发原因进行分析，分析的规则会有周期性变动的，但不要太频繁，而且规则会随着组织的成熟度而改变。
• 可操作性：要对度量维度做进一步分解，比如测试要有明确的检查点，覆盖要完整，可重复运行。支付宝就制定了具体的度量维度，从多个维度对系统加以度量。
• 有工具支持：这不是必要条件，工具不能解决所有问题！能用工具最好，不行的话就人工检查。工具检测维度要按照优先级和操作性，逐步增加精细化维度。这一点上，支付宝将一些编码规则的检查放入了持续集成工具之中，以求尽早检查、频繁检查。

设计 / 开发约束

在软件开发过程中，存在许多设计约束和准则，其中包括：

• 类和方法的长度
• 单个类里方法和属性的个数
• 方法或者构造函数的参数个数
• 代码中的魔数、字符串用法等等
• 注释行比例等

这些准则对代码可维护性和可读性至关重要。开发团队可以选择一些工具来统计这些约束的实施情况，比如 maven pmd plugin 。

有关设计 / 开发约束的讨论，读者朋友可以查看 InfoQ 的《代码之丑》和《编码那些事》专栏，最新一期的文章是《代码覆盖的 15 种典型情景》：代码覆盖为何物？相信程序员特别是测试人员不陌生，很多人都喜欢用代码覆盖来驱动测试的开展和完善。确实代码覆盖可以找出测试疏漏和代码问题，但是单纯的代码覆盖率高低并不能直接反映代码质量的好坏。大多我们的努力方向都是找出那些没有覆盖到的代码，然后补充用例，完善测试。而摆在我们面前的问题是：是否我们已经充分认识到哪些不需要、不能、必须被覆盖？只有对代码覆盖的各种情景了然于胸，才能不盲目乐观于代码覆盖率之高，悲观于代码覆盖率之低。在实践中（本文面向主要 Java 语言，基于 emma 工具），梳理可知，对于代码覆盖我们可能都会遇到以下 15 种典型情景……