在软件开发中,软件质量是衡量软件是否符合需求、标准的重要体现。除了代码质量外,影响软件整体质量的因素还有很多。因此,要确保软件的整体质量,就需要在各个环节严格控制。
本文列出了衡量软件质量的5个最常用的指标。
1. SLOC(Source Lines of Code,源代码行)
计算代码行数可能是最简单的衡量指标,主要体现了软件的规模,并为项目增长和规划提供了相关数据。例如,如果每月统计一次代码的行数,就可以绘制一个项目发展概览图。当然,由于存在项目重构或是设计阶段等因素,这种方式并不太可靠,但是可以为项目的发展提供一个视角。
可以只统计逻辑代码行(Source Logical Line of Code,SLLOC),这样可以获得稍准确的信息。逻辑代码行不包含空行、单个括号行和注释行。可以使用Metrics工具来统计。
代码行数不应该用来评估开发者的效率,否则,可能会产生重复、不可维护的或不专业的代码。
2. 每个代码段/模块/时间段中的bug数
要想实现更好的测试以及更高的可维护性,bug跟踪是必不可少的。每个代码段、模块或时间段(天、周、月等)内的bug可以很容易通过工具统计出来(如Mantis)。这样,可以及早发现并及时修复。
Bug数可以作为评估开发者效率的指标之一,但必须注意,如果过分强调这种评估方法,软件开发者和测试者可能会成为敌人。在生产企业中,要保证员工彼此之间的凝聚力。
为了更好的实现评估,可以根据重要性和解决成本将bug划分为低、中、高三个级别。
3. 代码覆盖率
在单元测试阶段,代码覆盖率常常被拿来作为衡量测试好坏的指标,也用来考核测试任务完成情况。可以使用的工具也有很多,如Cobertura等。
代码覆盖率并不能代表单元测试的整体质量,但可以提供一些测试覆盖率相关的信息,可以和其他一些测试指标一起来使用。
此外,在查看代码覆盖率时,还需注意单元测试代码、集成测试场景和结果等。
4. 设计/开发约束
软件开发中有很多设计约束和原则,其中包括:
类/方法的长度
一个类中方法/属性的个数
方法/构造函数参数的个数
代码文件中魔术数字、字符串的使用(魔术数字指直接写在代码中的具体数值,其他人难以理解数字的意义)
注释行比例等
代码的可维护性和可读性是很重要的,开发团队可以选择以上这些原则中的一个或全部,并通过一些自动化工具(如maven pmd插件)来遵循这些原则,这将大大提高软件产品的质量。
5. 圈复杂度(Cyclomatic Complexity)
圈复杂度是用来衡量一个模块判定结构的复杂程度,已经成为评估软件质量的一个重要标准,能帮助开发者识别难于测试和维护的模块,在成本、进度和性能之间寻求平衡。圈复杂度可以使用pmd工具来自动化计算。
圈复杂度数量上表现为独立路径的条数,即合理的预防错误所需测试的最少路径条数,圈复杂度大说明程序代码可能质量低且难于测试和维护。
计算公式为:V(G) = E - N + 2P
E:边,代表节点间的程序流;
N:节点,程序中代码的最小单元
P:出口节点
上图中共8条边,7个节点,因此圈复杂度为8 - 7 + 2*1=3。这意味着,理论上需要编写3个测试用例来覆盖所有的判定条件。
其实,圈复杂度的计算还有更直观的方法,因为圈复杂度所反映的是“判定条件”的数量,所以圈复杂度实际上就是等于判定节点的数量再加上1,也即控制流图的区域数,对应的计算公式为:V(G)=区域数=判定节点数+1。
在项目开发中,可以根据项目类型,来定义上限数(6、8或10等)。
以上是最常用的5种软件质量度量指标,当然,还可以结合其他的指标,对项目有一个更清晰的认识。
本文列出了衡量软件质量的5个最常用的指标。
1. SLOC(Source Lines of Code,源代码行)
计算代码行数可能是最简单的衡量指标,主要体现了软件的规模,并为项目增长和规划提供了相关数据。例如,如果每月统计一次代码的行数,就可以绘制一个项目发展概览图。当然,由于存在项目重构或是设计阶段等因素,这种方式并不太可靠,但是可以为项目的发展提供一个视角。
可以只统计逻辑代码行(Source Logical Line of Code,SLLOC),这样可以获得稍准确的信息。逻辑代码行不包含空行、单个括号行和注释行。可以使用Metrics工具来统计。
代码行数不应该用来评估开发者的效率,否则,可能会产生重复、不可维护的或不专业的代码。
2. 每个代码段/模块/时间段中的bug数
要想实现更好的测试以及更高的可维护性,bug跟踪是必不可少的。每个代码段、模块或时间段(天、周、月等)内的bug可以很容易通过工具统计出来(如Mantis)。这样,可以及早发现并及时修复。
Bug数可以作为评估开发者效率的指标之一,但必须注意,如果过分强调这种评估方法,软件开发者和测试者可能会成为敌人。在生产企业中,要保证员工彼此之间的凝聚力。
为了更好的实现评估,可以根据重要性和解决成本将bug划分为低、中、高三个级别。
3. 代码覆盖率
在单元测试阶段,代码覆盖率常常被拿来作为衡量测试好坏的指标,也用来考核测试任务完成情况。可以使用的工具也有很多,如Cobertura等。
代码覆盖率并不能代表单元测试的整体质量,但可以提供一些测试覆盖率相关的信息,可以和其他一些测试指标一起来使用。
此外,在查看代码覆盖率时,还需注意单元测试代码、集成测试场景和结果等。
4. 设计/开发约束
软件开发中有很多设计约束和原则,其中包括:
类/方法的长度
一个类中方法/属性的个数
方法/构造函数参数的个数
代码文件中魔术数字、字符串的使用(魔术数字指直接写在代码中的具体数值,其他人难以理解数字的意义)
注释行比例等
代码的可维护性和可读性是很重要的,开发团队可以选择以上这些原则中的一个或全部,并通过一些自动化工具(如maven pmd插件)来遵循这些原则,这将大大提高软件产品的质量。
5. 圈复杂度(Cyclomatic Complexity)
圈复杂度是用来衡量一个模块判定结构的复杂程度,已经成为评估软件质量的一个重要标准,能帮助开发者识别难于测试和维护的模块,在成本、进度和性能之间寻求平衡。圈复杂度可以使用pmd工具来自动化计算。
圈复杂度数量上表现为独立路径的条数,即合理的预防错误所需测试的最少路径条数,圈复杂度大说明程序代码可能质量低且难于测试和维护。
计算公式为:V(G) = E - N + 2P
E:边,代表节点间的程序流;
N:节点,程序中代码的最小单元
P:出口节点
上图中共8条边,7个节点,因此圈复杂度为8 - 7 + 2*1=3。这意味着,理论上需要编写3个测试用例来覆盖所有的判定条件。
其实,圈复杂度的计算还有更直观的方法,因为圈复杂度所反映的是“判定条件”的数量,所以圈复杂度实际上就是等于判定节点的数量再加上1,也即控制流图的区域数,对应的计算公式为:V(G)=区域数=判定节点数+1。
在项目开发中,可以根据项目类型,来定义上限数(6、8或10等)。
以上是最常用的5种软件质量度量指标,当然,还可以结合其他的指标,对项目有一个更清晰的认识。