在实际项目开发过程中，我们经常会看到一个现象，很多团队把产品质量全押宝在测试环节上，这显然是不够科学的。测试只是发现问题的一种手段，而本身不能解决问题。而产品质量问题是个体系问题，体系问题则需要系统的解决方法，所以押宝在任一环节都不足以达到我们所期望的结果。开发团队陷入这种思维的原因，往往还是构建环节上的问题，而对”软件工程“的理解决定了我们所采用的构建方法。采用什么样的态度与方法，很大程度上是取决于我们如何看待”软件开发“这件事情。
用生活中的意象来描述软件开发中的问题是一种非常方便的帮助我们理解软件开发中的概念和问题的方法，例如我们用 Bug 这个单词表示软件缺陷。不同的意象决定了我们对待其构建的方法，而不同的构建方法决定了我们项目的成败和质量。如果你把软件开发理解为”写作“，那么可能就偏随性一些，想到哪写到哪，如果你理解为软件开发为盖间房子或者一大栋房子，那么我们采取的方法自然就是千差万别。很显然，实际的项目复杂度和工程量是千差万别的，要求也可能不尽相同，不同的情况我们需要采取相对应的开发方法，更有利于我们按时，按质量的完成开发目标。
不同构建环节的缺陷检测率
我都熟悉软件开发的一些主要环节（详细设计、编码、调试、集成、开发者测试), 而其中开发者测试又分单元测试，集成测试等部分。可想而知，软件开发包含如此多的活动，而且各个环节都需要不同的人员进行相互配合，遵循木桶原理，任何环节的短缺都不足以早出质量过硬的产品。下图展示了各个开发环节对软件缺陷检测率的影响情况：
上图的数据还是比较有意思的。如果不算上大规模 Beta 测试，在所有检错措施中，最低检出率最高的是正式代码检查阶段，为 45%，典型检出率最高则为建立模型或者原型 65%，最好检出率则仍然是建立模型或者原型这一措施。从整个检错措施中我们可以看出，无论是哪一项措施都无法到达足够的检出率，所以现实开发中，往往是会结合多个措施作用到项目上，才能达到比较好的结果。
现实中的软件开发工作比较复杂，受限于例如人员、时间、团队等资源因素的限制，所以并不是所有的构建方法都会使用这种构建组合，而是适当的根据自己的情况做一些调整。下图是极限编程（Extreme Programming）缺陷检出率的一份评估表：
极限编程是一种轻量级的软件工程方法，其提倡对需求能做快速响应。所以在整个构建活动上也是有所缩减。目前很多小型团队都是采用这种软件工程的方法论。
形成合适团队的构建方法
很显然没有完美的构建方法，受限于业务模式，团队，时间等各种因素的制约，我们很难按照一些软件工程的方法论进行全面实践，需要适当的对一些环节进行裁剪和调整。《代码大全》在书中推荐了一种基本的构建质量的组合：
- 对所有的需求，架构，系统关键部分的设计进行正式检查
- 建模或者创建原型 (原型评审，设计检查)
- 代码阅读或者检查
- 执行测试（单元测试，集成测试，回归测试）
即使缩短到这么几个构建环节，很多团队都做不好，或者是做不了，例如在实际工作中，我发现很多团队原型评审上很粗糙，没有代码审查，测试只有基本的功能测试，对于一个想挣钱的商业项目来讲，这显然是不够可靠的。
至此，在给产品做质量体系建立工作的时候，越早设立质量目标，且越早做规划越好。测试显然是非常重要的一环，不过想要达到更高的质量目标，我们应该尽量使用组合拳。
最后修改于 2019-07-04