软件测试工程师如何有效开展质量度量
2020/3/13 10:15:35
千行代码缺陷率=缺陷数量/每千行代码
按照上述的公式来看,缺陷的数量越少表示质量越高。而提交的的代码越多,可以容忍的缺陷数量也就越多。乍一看,这个公式应该是可以很好地检测代码质量的。然而,事情并不是这么简单,在实际落地时大家会面临两个选择:1、增大分母——提高代码行数——简单;2、减小分子——减少缺陷数量——难。
如果我们对它进行刻意度量甚至考核,大家会选择相对容易的方案,这个虽然说通过其他的手段(codereview)可以补偿,但本质上就会让它变成一个目标和方法背道而驰的指标。
而选择稀释代码就是个最简单的策略,那么稀释代码的最佳策略是什么?复制粘贴,复制粘贴的最大问题是什么?引入更多的bug。这个结果显然不是我们想要的。为什么会出现这样的情况呢?这背后的最重要的原因就是:功能的多少和代码行数不成正比关系,也不呈现正相关关系。
那该如何解决这个问题呢?
鼎恒商学院认为只需要跳出来重新定义一下问题:我们追求的是产品最终的交付质量以及缺陷发生后的恢复速度,所以可以从以下3个指标去来展开质量度量:
01
cc,圈复杂度
圈复杂度越高的代码越容易引入缺陷,这个是业已被证明了的,圈复杂度反应了代码的耦合度,所以大家要写低耦合高内聚的代码。
02
ddp,缺陷探测率
缺陷探测率越高,也就是qa发现的缺陷越多,发布后线上用户发现的错误就越少,可获得较高的测试投资回报率。
03
mttr,平均缺陷恢复时间
发生缺陷并不可怕,可怕的是修复的时间过长。平均缺陷修复时间能够更好地反映代码本身的质量状况,以及团队的成熟程度。往往平均修复时间较长的代码都是复杂度高,耦合度高的代码。而平均修复时间短的代码都是结构相对清晰,命名规范,容易理解,扩展和变更的代码。