孔子说“人无远虑，必有近忧”，用在软件测试上，是什么意思呢？可以这样理解，如果我们不从发生问题的根源上解决问题，认为测试仅仅是找Bug，千方百计找Bug，觉得Bug总是找不完，意识中就会陷入“永无天日”的状态。然而，有小部分测试人员还真希望软件存在多一些问题（唯恐天下不乱），这样可以多提交Bug，认为业绩比没有提交多少Bug肯定要好。无独有偶，有小部分开发人员也把自己犯下的程序错误视为理所当然，甚至还有个别人会戏虐地说“软件如果没有Bug的话，测试人员不就失业了”。这好像在唱一出双簧戏。软件开发的整个过程中，Bug是理所当然要存在的，是这样吗？软件工程中软件危机的根源问题只能通过找到Bug的手段来控制吗？
实际上，我们都很清楚，任何一个Bug的产生都是有来源的，来源包括需求的设计、软件的设计（含代码的编写）等。相对于前端的设计，测试是事后的验证，是一种“堵”漏洞的措施。然而，在实际工作中，时间与成本并不允许我们去堵住所有的Bug。日本质量大师田口玄一说得好“质量是设计出来的，而不是测试出来的”。如果我们能变被动为主动，在设计之前，就做好设计的防患措施，为设计高质量的软件打下坚实的基础，这便是本节打算向读者介绍的测试的第三重境界：挑战零缺陷。
缺陷的防与堵
几乎在每次面试测试工程师时，笔者都会问一个这样的问题：“你所负责测试过的模块，是否存在漏测的情况”，几乎每个应聘者都回答说“有”。面对复杂的软件，纷繁复杂的运行环境，在有限时间内进行的测试活动，做到真正的零Bug是 不可能的，也是不现实的。但这些都不是理由，所有的测试活动是有目的的商业活动，每个公司有自己测试通过的一套标准或原则。虽然漏测不可避免，但并不是说 漏测是一种正常现象或应该的现象，出现的漏测问题如果超出公司所能接受的原则，就属于不正常的现象，很有必要进行漏测分析。进行漏测分析活动（需要特别注 意的是它绝不是对漏测人员的批斗会），它的主要目的是通过分析过去的教训，找出问题的根源，分析测试中哪个环节工作存在缺失，以拿出规避的可操作的措施出 来。
测试人员进行漏测分析时，免不了对问题进行追本溯源。软件是由开发人员设计出来的，所以漏测分析活动少不了开发人员在场，甚至有时还会涉及需求设计人员。关于漏测分析的追本溯源，这里有一个关于开发与测试之间的工作关系像修筑堤坝一样的有趣比喻，如图2？11所示。开发人员设计软件就像修筑一道堤坝，如果堤坝在结构上存在问题，当洪水冲击时，可能不只是局部的泄漏，而是直接的决堤，犹如软件的崩溃。高高的堤坝，难免会存在漏水的小洞，或渗水的小孔，就好像软件中存在的小Bug。越是在堤坝基部的漏水或渗水问题越难发现，解决的代价也越大。
在设计时要把结构建牢，不存在漏洞当然更好，这是一种防范。如果超越防范界线，把设计带出的大洞小孔遗留到测试环节，它只好拿着各种放大镜（使用各种方法）来检测，以网罗各种深深浅浅、大大小小的问题，最后通过“打补丁”的方式，堵住堤坝上的“百孔千疮”。
在对缺陷的防与堵方面，测试是发现问题的中间角色，告诉开发人员哪里漏水或渗水了。防与堵的工作是由建堤者来做的。当然，防是主动的，堵是被动的，主动变为被动后，中间经历了资源与时间的投入，诚然即使是同一个Bug，它们的代价也是完全不一样的。这种堵越在后面，影响越大，代价也就越大，如表2-6所示（摘自《代码大全》）是一个根据缺陷出现的阶段来增加测试成本的例子。
表2-6 根据缺陷的引入和检测时间，修正同一缺陷所需的平均成本
引 入 时 间 | 需 求 | 体 系 结 构 | 建 设 | 系 统 测 试 | 发 布 之 后 |
需求 | 1 | 3 | 5～10 | 10 | 10～100 |
体系结构 | -- | 1 | 10 | 15 | 25～100 |
建设 | -- | -- | 1 | 1 | 10～25 |
如表2-6所示为在需求阶段引入的一个缺陷。如果立即发现了此问题，修改成本只需要1美元，但如果在系统测试阶段发现它，修改成本就增加了10倍。更为严重的是，如果在版本发布后用户端发现了此问题，则需付出10倍以上甚至是100倍的代价。缺陷在系统中的时间越长，解决它的代价就越大，因为时间越长，开发与测试人员修改的成本就越高，还将影响大面积的用户端升级。
相关链接：
软件测试的第一重境界：围着Bug转
软件测试的第二重境界：站在Bug之上