什么是千行代码缺陷率?

什么是千行代码缺陷率?

  • 1 定义
  • 2 目的
  • 3 CMMI定义
  • 4 指标的缺点
  • 5 改进
    • 5.1 圈复杂度
    • 5.2 平均缺陷修复时间
  • 6 其他推荐指标

1 定义

先来看下【千行代码缺陷率】是怎么回事?

  • 一千行代码产生的缺陷,这个概念在CMMI中有定义;
  • 计算公式为:bug数/代码行数*1000

2 目的

  • 为了度量产品质量,通过这一数据督促开发提高代码质量,提高产品质量。

3 CMMI定义

  • CMMI定义为:
CMMI级 千行代码缺陷率
1级 11.95‰
2级 5.52‰
3级 2.39‰
4级 0.92‰
5级 0.32‰
  • 度量的标准为:千行代码Bug率数值越小质量越好。

4 指标的缺点

  • 从这个指标我们可以看出,分子越小,分母越大,质量越好,表面看似简单的数据呈现,其实这样的衡量太过单一;
  • 我们举个例子:某公司的千行代码缺陷率要求,CMMI3级,即2.39‰ ,以下是三个程序员的对功能M模块的进行实现:

例一:
A程序员用20万行代码实现了功能M,产生了bug20个,千行代码缺陷率为1.0‰;这个指标符合公司的要求。但是A的代码极度复杂,为了修改bug,代码耦合性很高,维护成本极大;

例二:
B程序员用5000行代码实现了功能M,产生了bug20个,千行代码缺陷率为4.0‰,不满足公司的标准要求。但是B的代码非常精练,可读性高,便于维护,移植性好;

例三:
C程序员用5000行代码实现了功能M,产生了bug30个,千行代码缺陷率为6.0‰,不满足公司的标准要求。但是C非常好学,他很努力在向B学习,争取使得自己的代码更具有可读性;

  • 然后呢,公司根据以上三个人的千行代码缺陷率,定义三者的绩效为A最好,B不及格,C被淘汰了;
  • 过了N年,这个M模块需要重构,A程序员的代码维护起来非常困难,面对庞大的代码,因为可读性差,维护会产生很多bug;B程序员的代码很容易进行修改,感觉很简单;C的代码仅次于B。但是呢最后评绩效的时候,仍然是A最好,B不行,为什么?

大家都认为A很牛逼,代码量庞大;B的代码太简单了。

所以从此刻开始,公司的开发同事就使劲的增加分母,让代码足够大,这样处于分子的缺陷再多,也会绩效很好。而B优秀的代码被抛弃,像B这样的程序员被淘汰。那么可想而知这个公司的最终之路是什么??

5 改进

  • 综上所述,现在的产品质量不能单一的使用千行代码缺陷率来表示,起码我是这样认为的,那我们用哪些指标更好呢?
  • 博主通过查阅资料得到以下指标:

5.1 圈复杂度

  • 圈复杂度越高的代码会有越多的Bug;
  • 圈复杂度反应了代码的耦合度;
  • 推荐的圈复杂度不要超过10;
  • 测量圈复杂度的工具:

Source Insight、Code Metrics、Cobertura

5.2 平均缺陷修复时间

  • 平均缺陷修复时间能够更好地反映代码本身的质量状况,以及团队的成熟程度;
  • 平均修复时间较长的代码都是复杂度高,耦合度高的代码;
  • 平均修复时间短的代码都是结构相对清晰,命名规范,容易理解,扩展和变更的代码。

6 其他推荐指标

以下这些仅供参考:

  • 缺陷修复率;
  • 重新打开缺陷占比;
  • 严重及以上缺陷占比;
  • 缺陷遗留DI值等。

你可能感兴趣的:(#,测试理论,软件测试)