工程质量-04-数据支撑
22 Jan 2022 • 3 min read在讲具体的方法之前，我们需要一些数据来做为支撑，建立一个基线，让我们整个目标能够更加聚焦一些。
在软件工程领域，评估一种方法是否能够有效的检测出软件缺陷有一个量化的指标：缺陷清除效率(Defect Removal efficiency, DRE)。
2011年前后，美国的缺陷清除效率平均值为85%，其变化范围从75%到极少案例才能够达到的99%。缺陷清除效率的计算根据发布前修复的缺陷总数加上发布后头90天内客户报告的缺陷数。例如，如果发布前开发者发现了90个BUG，客户在头3个月报告了10个BUG。那么本例中的缺陷清除效率是90%。这是非常重要的流程质量度量方法，因为和缺陷清除效率较低的类似应用程序相比，缺陷清除效率能够达95%的应用程序往往工期更短并且成本更低。这样的应用程序的消费者也更愉快，其维护成本也更低[4]。
从缺陷清除效率(DRE)理论中获取最重要的数据就是缺陷清除效率表，如下表所示，是《Code Complete》提供的缺陷预测率表[2]。
| Removal Step | Lowest Rate | Modal Rate | Highest Rate |
|---|---|---|---|
| 非正式的设计审查（Informal design reviews） | 25% | 35% | 40% |
| 正式的设计审查（Formal design inspections） | 45% | 55% | 65% |
| 非正式的代码审查（Informal code reviews） | 20% | 25% | 35% |
| 正式的代码审查（Formal code inspections） | 45% | 60% | 70% |
| 建模或者原型（Modeling or prototyping） | 35% | 65% | 80% |
| 个人桌面审查（Personal desk-checking of code） | 20% | 40% | 60% |
| 静态代码分析（Static code analysis） | 5% | 10% | 15% |
| 单元测试（Unit test） | 15% | 30% | 50% |
| 新函数/组件测试 （New function (component)test） | 20% | 30% | 35% |
| 集成测试（Integration test） | 25% | 35% | 40% |
| 回归测试（Regression test） | 15% | 25% | 30% |
| 系统测试（System test） | 25% | 40% | 55% |
低密度beta测试（少于10人）（Low-volume beta test (<10 sites)） |
25% | 35% | 40% |
高密度beta测试（大于1000人）（High-volume beta test (>1,000 sites)） |
60% | 75% | 85% |
这个表说明了一些非常重要的事实
- 没有任何一种方法是特别有效的。没有哪一种方法可以达到85%以上的效果，所有的方法平均效率只有40%左右。
- 我们最熟知的单元测试和集成测试只有大约30%到35%的效率。
- 上面效果最好的Modeling or prototyping和
High-volume beta test (>1,000 sites)其成本也是最高的。没有几个团队能够用得起这样的方法。 - 要想提高缺陷检测率的正确办法就是组合各种方案来进行检测。
上面还有一点值得注意，《Code Complete 2nd》成书于2002年，它的数据比较老。最近十年，上面的方法的检测率有一定的提升[6]。但是它们的相对效率并没有变，并不会影响到这一篇文章的方法。
还有一点，缺陷清除率并不是一成不变的，有研究表明，功能点越多的软件项目，缺陷清除率会越低，功能点越少的软件项目，缺陷清除率会越高[4]。在这一篇文章中，为了简化问题，我们假设这些方法的清除率是不变的。
要计算多种方法的缺陷检出率只需要使用最简单的概率计算。如果有两种方法，A方法的缺陷检出率是30%，B方法的缺陷检出率就40%。那么使用两个方法的缺陷检出率，为58%。
P_{mix} = 1 - (1 - P_{A}) * (1 - P_{B}) = 1 - 0.70 * 0.60 = 0.58
我见过的大部分普通团队只有非正式的设计审查、开发完成之后的集成测试以及提交了测试组之后的系统测试，其它的质量流程，可能会有，但是大多数流于形式，已经没有什么实际效果。整体的缺陷清除率如下所示
| Removal Step | Lowest Rate | Modal Rate | Highest Rate |
|---|---|---|---|
| 非正式的设计审查（Informal design reviews） | 25% | 35% | 40% |
| 集成测试（Integration test） | 25% | 35% | 40% |
| 系统测试（System test） | 25% | 40% | 55% |
| 缺陷排除预期累计效率值 | 57.81% | 74.65% | 83.80% |
通过上面的表，可以看，即使在最好的情况下，它的缺陷清除率只有83%左右，离及格的85%还差一些。然而真实的平均值可能只有74%左右。这样的软件质量维护成本是很高的。
我们后面的流程都会引用到这一张表，我们关注的是下限，会重点关注最低的情况下的缺陷清除率，只要保证最低的下限，高于这个值的都是惊喜。
值得特别注意的是，我们引用这一个指标只是用来做一个目标参考。这一张表里面很多活动看起来DRE值很高。但是他们由于成本很高，所以被淘汰了。我们后面的流程会引入代码审查、单元测试之类的，看起来DRE值并不高。但是
- 代码审查不仅仅能够预防BUG，更重要的是能够通过代码审查加强团队其他成员对代码的理解。这一点是单纯的DRE值不能够体现的，但是对于项目可持续维护非常重要。
- 单元测试不仅仅能够预防BUG，更重要的是通过单元测试能够更加的组织规划我们的代码结构，这也是单纯的DRE值不能够体现的，但是对保证整个产品质量却非常重要。
在引入各项流程的时候，我们会综合考虑各种因素。并不是简单的谁的DRE值最好，我们就优先引入什么流程。我们会考虑投入产出比，考虑引入的难度，考虑接受程度、考虑可持续性各方面的因素。
引用
- [1] Demarco T, Lister T. 人件[M]. 3. 机械工业出版社, 2016 :22-23.
- [2] McConnell S. Code Complete[M]. 2nd ed.. Microsoft Press, 2004.
- [3] Ariel Assaraf. This is what your developers are doing 75% of the time, and this is the cost you pay[EB/OL]. 2015 https://coralogix.com/blog/this-is-what-your-developers-are-doing-75-of-the-time-and-this-is-the-cost-you-pay/.
- [4] Jones C, Bonsignour O. 软件质量经济学[M]. 1. 机械工业出版社, 2014.
- [5] Fournier C. Software Engineering at Google[M]. First Edition. United States of America:O’Reilly, 2020 :27-42.
- [6] Capers Jones. Software Defect Removal Efficiency[EB/OL]. 2011. https://www.ppi-int.com/wp-content/uploads/2021/01/Software-Defect-Removal-Efficiency.pdf.
- [7] 阿里技术. 如何选择 Git 分支模式？[EB/OL]. 2020-07-10[2022-01]. https://zhuanlan.zhihu.com/p/158463879.
- [8] P. C. Rigby and C. Bird, “Convergent contemporary software peer review practices,” in Proceedings of the 2013 9th Joint Meeting on Foundations of Software Engineering. ACM, 2013, pp. 202–212.
- [9] IEEE Standard for Software Reviews and Audits, IEEE Std. 1028-2008.
- [10] T. Baum, O. Liskin, K. Niklas and K. Schneider, “A Faceted Classification Scheme for Change-Based Industrial Code Review Processes,” 2016 IEEE International Conference on Software Quality, Reliability and Security (QRS), 2016, pp. 74-85, doi: 10.1109/QRS.2016.19.
- [11] A. Porter, H. Siy, A. Mockus, and L. Votta. Understanding the sources of variation in software inspections. ACM Transactions Software Engineering Methodology, 7(1):41–79, 1998.
- [12] Baum, Tobias & Leßmann, Hendrik & Schneider, Kurt. (2017). The Choice of Code Review Process: A Survey on the State of the Practice. 111-127. 10.1007/978-3-319-69926-4_9.
- [13] Fowler M & 熊杰. 重构-改善既有代码的设计[M]. 2. 人民邮电出版社, 2010.
- [14] Khorikov V. Unit Testing-Principles, Practices, and Patterns[M]. 1. Manning Publications, 2020.
- [15] Martin R C. Clean Code-A Handbook of Agile Software Craftsmanship[M]. 1. Prentice Hall, 2008.