首页 > 业界动态 > 正文

5个衡量软件质量的标准(可自动化)

2019-04-01 开源中国 佚名 点击: 评论
1 Sourc Lines of Code (SLOC) 统计代码行数可能是最简单的方法。它能体现软件的规模,为项目的发展和计划提供一些数据支撑。例如,我们每个月统计一次代码的行数,我们就能大体知道项
       1. Sourc Lines of Code (SLOC) 
      统计代码行数可能是最简单的方法。它能体现软件的规模,为项目的发展和计划提供一些数据支撑。例如,我们每个月统计一次代码的行数,我们就能大体知道项目的发展情况。当然,这不是一个值得信赖的标准,因为有重构以及设计的因素。 
       SLOC 最好是统计 Source Logical Line of Code (SLLOC) 以获得更准确的信息。Logical code lines 不包含空行,单个括号行以及注释行。你可以通过 Metrics 这样的工具很容易的统计 SLLOC。 
       代码行数不应该被用来衡量开发效率。否则容易造成重复的,不易维护的和不专业的代码。 
       2 . Bugs per code_section/module/time_period 
       问题跟踪是保证测试和可维护性的关键步骤。假如所有的问题(bug)都是有跟踪的话,每个代码单元,每个模块或者某个特定时间(day, week, month...)的问题就很容易被统计(例如 Mantis 工具)。当我们有了这些数据以后,问题的根源就可以被尽早发现并处理。 
       问题数量可以作为衡量开发质量的一个标准,但必须用的很小心。假如过分强调 bug 数量,那么开发和测试的关键就会很紧张。在一个有效率的公司,所有的员工都应该融洽的相处。 
        为了更好的对代码质量进行评估。Bug 可以分为 low, medium, high 三种级别,因为它们的重要性和修复的成本是不一样的。 
        3. Code Coverage 
        Code coverage 表明了代码被测试的程度。有很多工具可以自动统计这个数据,例如 Cobertura 。 
        Code coverage 不能说明单元测试的整体质量,但是能说明测试的覆盖面。它可以和其他一些指标一起用来衡量软件的质量。当然,我们也需要经常回顾单元测试代码和集成测试的用例。 
        4. Design/Development Contraints 
        软件开发中有很多设计规则,例如:           - 类/方法的长度 
         - 方法/属性的数量 
         - 方法的参数数量 
         - 特殊数值以及字符串的使用量 
         - 注释的比例 
        这些规则都是保证代码可读性和可维护性的重要指标。开发团队应该选择一些或者全部的规则来实施(例如 maven pmd plugin )。这将帮助提高软件产品的质量。 
        5. Cyclomatic Complexity(环路复杂度) 
        把环路复杂度单独列出来讲是因为它和其他的设计准侧不太一样。环路复杂度是关于代码实现和执行。它也可以通过工具自动计算,例如 pmd 。 
        这个数值是独立的代码执行路径数量。例如:   


        Cyclomatic Complexity = E(edges) - N(nodes) + 2P (exit nodes)          So, Cyc.Cmp. = 8 - 7 + 2*1 = 3 
        你也可以看到,从起点到终点,有三条不同的路径。这个值往往是针对方法来计算。根据不同的项目类型,我们可以设定这个值的上限,例如6,8,或者10。 
        一个指标不能说明整个项目的质量。使用更多的指标,会让你对项目的质量有更全面的了解。


英文原文: http://codebuild.blogspot.com/2012/09/5-common-automized-software-quality.html 开源中国译

转载文章请标明来自天晟网 timsion.com > 业界动态 >
标题:5个衡量软件质量的标准(可自动化)
网址:http://www.timsion.com/news/4139.html

上一篇:苹果的地图决策存在乔布斯的阴影
下一篇:IT未来发展五大趋势

免责声明:以上内容来自互联网和用户投稿,不代表本站的观点和立场,版权归原作者所有,如有侵权,请与我们联系。