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

　　复杂度是一种不同的软件元素间交互的度量。按照Shashi的说法，软件复杂度直接反映了软件的质量和成本：如果代码复杂度比较高，那么这段代码的质量就会比较低，而且它的维护成本也会比较高。　　Shashi提出，如果软件产品中有复杂的代码，那么组织会面临以下的问题：　　较高的缺陷风险　　难以增加新的功能　　难以理解或维护这段代码　　难以验证　　你可以使用McCabe圈复杂度来度量复杂度。这种度量规定了代码中线性独立的路径条数，它反映了测试难度和软件的可靠性。它可以用来评估开发和维护工作量。　　基于复杂度数据，你掌握要覆盖所有路径最少需要多少测试用例。复杂度数据可以帮助你去：　　集中力量搞好复杂的模块　　找到最有效的测试技术　　了解停止测试的时机　　增加软件的可测试性　　Shashi解释说，你在软件系统的管理中做到更具可预测性：　　在任何软件产品开始工作之前，如果有人知道它是一个复杂的模块，那么就有可能在评估期为它赋予一些额外的时间。了解了复杂度能够预先帮助项目团队去进行评估，这种做法要胜过在开发和测试期去关注它，从而确保不会让产品的质量做出妥协。　　英特尔收集了复杂度度量和模块变更数量的数据。这些复杂度数据结合了客户记录的缺陷。如果一个模块是复杂的，并且由于缺陷进行了大量的变更，那么就决定去重构它。在重构之前他们确保有覆盖这些代码的测试用例。这种工作方式增加了重构的投资收益率。　　Shashi探讨了他所看到的软件开发复杂度与质量相关的挑战：　　在竞争激烈瞬息万变的环境中，公司通过为它的用户提供更多的特性来努力使它的服务有所不同。这就导致了大量的代码行和复杂度，这是个大挑战。如果未采用适当的预防措施去管理产品的复杂度，那么很快这些产品就将成为难以维护的产品。随着时间的推移，很多公司都不在使用老代码和老技术了，他们知道自己的系统太复杂了，把它们进行新技术的移植是一项极其复杂的任务。　　“在高复杂度的环境中，创新和开发高质量软件是极其重要的”Shashi说。“组织可以设定去减少所有高复杂度程序的复杂度，更加频繁地变更以改进他们软件的质量”。

最新内容请见作者的GitHub页：