使用复杂度度量去改进软件质量

阅读数:1036 2014 年 10 月 27 日

话题:测试重构文化 & 方法

复杂度度量可以用来评估开发和测试活动,决定应该对哪里进行重构以提升质量和预防问题。在QA&Test 2014 conference 大会上,来自于英特尔的 Shashi Katiyar 就有效利用针对软件质量改进的复杂度度量提出了自己的见解。

复杂度是一种不同的软件元素间交互的度量。按照 Shashi 的说法,软件复杂度直接反映了软件的质量和成本:如果代码复杂度比较高,那么这段代码的质量就会比较低,而且它的维护成本也会比较高。

Shashi 提出,如果软件产品中有复杂的代码,那么组织会面临以下的问题:

  • 较高的缺陷风险
  • 难以增加新的功能
  • 难以理解或维护这段代码
  • 难以验证

你可以使用 McCabe 圈复杂度来度量复杂度。这种度量规定了代码中线性独立的路径条数,它反映了测试难度和软件的可靠性。它可以用来评估开发和维护工作量。

基于复杂度数据,你掌握要覆盖所有路径最少需要多少测试用例。复杂度数据可以帮助你去:

  • 集中力量搞好复杂的模块
  • 找到最有效的测试技术
  • 了解停止测试的时机
  • 增加软件的可测试性

Shashi 解释说,你在软件系统的管理中做到更具可预测性:

在任何软件产品开始工作之前,如果有人知道它是一个复杂的模块,那么就有可能在评估期为它赋予一些额外的时间。了解了复杂度能够预先帮助项目团队去进行评估,这种做法要胜过在开发和测试期去关注它,从而确保不会让产品的质量做出妥协。

英特尔收集了复杂度度量和模块变更数量的数据。这些复杂度数据结合了客户记录的缺陷。如果一个模块是复杂的,并且由于缺陷进行了大量的变更,那么就决定去重构它。在重构之前他们确保有覆盖这些代码的测试用例。这种工作方式增加了重构的投资收益率。

Shashi 探讨了他所看到的软件开发复杂度与质量相关的挑战:

在竞争激烈瞬息万变的环境中,公司通过为它的用户提供更多的特性来努力使它的服务有所不同。这就导致了大量的代码行和复杂度,这是个大挑战。如果未采用适当的预防措施去管理产品的复杂度,那么很快这些产品就将成为难以维护的产品。随着时间的推移,很多公司都不在使用老代码和老技术了,他们知道自己的系统太复杂了,把它们进行新技术的移植是一项极其复杂的任务。

“在高复杂度的环境中,创新和开发高质量软件是极其重要的”Shashi 说。“组织可以设定去减少所有高复杂度程序的复杂度,更加频繁地变更以改进他们软件的质量”。

查看英文原文:Using Complexity Measurements to Improve Software Quality