2.4 测试的第三重境界：挑战零缺陷

孔子说“人无远虑，必有近忧”，用在软件测试上，是什么意思呢？可以这样理解，如果我们不从发生问题的根源上解决问题，认为测试仅仅是找Bug，千方百计找Bug，觉得Bug总是找不完，意识中就会陷入“永无天日”的状态。然而，有小部分测试人员还真希望软件存在多一些问题（唯恐天下不乱），这样可以多提交Bug，认为业绩比没有提交多少Bug肯定要好。无独有偶，有小部分开发人员也把自己犯下的程序错误视为理所当然，甚至还有个别人会戏虐地说“软件如果没有Bug的话，测试人员不就失业了”。这好像在唱一出双簧戏。软件开发的整个过程中，Bug是理所当然要存在的，是这样吗？软件工程中软件危机的根源问题只能通过找到Bug的手段来控制吗？

实际上，我们都很清楚，任何一个Bug的产生都是有来源的，来源包括需求的设计、软件的设计（含代码的编写）等。相对于前端的设计，测试是事后的验证，是一种“堵”漏洞的措施。然而，在实际工作中，时间与成本并不允许我们去堵住所有的Bug。日本质量大师田口玄一说得好“质量是设计出来的，而不是测试出来的”。如果我们能变被动为主动，在设计之前，就做好设计的防患措施，为设计高质量的软件打下坚实的基础，这便是本节打算向读者介绍的测试的第三重境界：挑战零缺陷。

2.4.1 缺陷的防与堵

几乎在每次面试测试工程师时，笔者都会问一个这样的问题：“你所负责测试过的模块，是否存在漏测的情况”，几乎每个应聘者都回答说“有”。面对复杂的软件，纷繁复杂的运行环境，在有限时间内进行的测试活动，做到真正的零Bug是不可能的，也是不现实的。但这些都不是理由，所有的测试活动是有目的的商业活动，每个公司有自己测试通过的一套标准或原则。虽然漏测不可避免，但并不是说漏测是一种正常现象或应该的现象，出现的漏测问题如果超出公司所能接受的原则，就属于不正常的现象，很有必要进行漏测分析。进行漏测分析活动（需要特别注意的是它绝不是对漏测人员的批斗会），它的主要目的是通过分析过去的教训，找出问题的根源，分析测试中哪个环节工作存在缺失，以拿出规避的可操作的措施出来。

测试人员进行漏测分析时，免不了对问题进行追本溯源。软件是由开发人员设计出来的，所以漏测分析活动少不了开发人员在场，甚至有时还会涉及需求设计人员。关于漏测分析的追本溯源，这里有一个关于开发与测试之间的工作关系像修筑堤坝一样的有趣比喻，如图2-11所示。开发人员设计软件就像修筑一道堤坝，如果堤坝在结构上存在问题，当洪水冲击时，可能不只是局部的泄漏，而是直接的决堤，犹如软件的崩溃。高高的堤坝，难免会存在漏水的小洞，或渗水的小孔，就好像软件中存在的小Bug。越是在堤坝基部的漏水或渗水问题越难发现，解决的代价也越大。

在设计时要把结构建牢，不存在漏洞当然更好，这是一种防范。如果超越防范界线，把设计带出的大洞小孔遗留到测试环节，它只好拿着各种放大镜（使用各种方法）来检测，以网罗各种深深浅浅、大大小小的问题，最后通过“打补丁”的方式，堵住堤坝上的“百孔千疮”。

在对缺陷的防与堵方面，测试是发现问题的中间角色，告诉开发人员哪里漏水或渗水了。防与堵的工作是由建堤者来做的。当然，防是主动的，堵是被动的，主动变为被动后，中间经历了资源与时间的投入，诚然即使是同一个Bug，它们的代价也是完全不一样的。这种堵越在后面，影响越大，代价也就越大，如表2-6所示（摘自《代码大全》）是一个根据缺陷出现的阶段来增加测试成本的例子。

如表2-6所示为在需求阶段引入的一个缺陷。如果立即发现了此问题，修改成本只需要1美元，但如果在系统测试阶段发现它，修改成本就增加了10倍。更为严重的是，如果在版本发布后用户端发现了此问题，则需付出10倍以上甚至是100倍的代价。缺陷在系统中的时间越长，解决它的代价就越大，因为时间越长，开发与测试人员修改的成本就越高，还将影响大面积的用户端升级。

小贴士：

2.4.2“零缺陷”文化

在2.4.1节的例子中，我们已经清楚地知道一个缺陷自它诞生后，如果发现得越晚则修改成本越大。那么有没有可能使缺陷根本就不发生，或是将它控制在一个可接受的状态呢？

早在20世纪60年代初，被誉为“全球质量管理大师”的菲利浦·克劳斯比（Crosbyism）提出了“零缺陷”（Zero Defect）思想，并在美国推行零缺陷运动。后来，零缺陷的思想传至日本，在日本制造业中得到了全面推广，使日本制造业的产品质量得到迅速提高，并且领先于世界水平，继而进一步扩大到工商业所有领域。如今，“零缺陷”已经成为国际卓越企业的工作标准。

零缺陷，对软件来说，是神话还是另有其意呢？在大多数人的印象中，软件常常是有一堆堆Bug存在的，而迫于市场竞争的压力，又不得不面市，然后通过不断发补丁包升级来解决不同的漏洞。一些业界朋友还常自嘲“国际软件巨头微软的软件尚且如此，何况我们这些小兵开发的无名软件了”。实际上，克劳斯比的“零缺陷”并不是说绝对没有缺点，或缺点绝对要等于零，而是指要以“缺点等于零为最终目标，每个人都要在自己工作职责范围内努力做到无缺点”。它要求生产工作者从一开始就本着严肃认真的态度把工作做得准确无误，在生产中对产品的质量、成本与消耗、交货期等方面进行合理安排，而不是依靠事后的检验来纠正，它特别强调预防系统的控制和过程的控制。2.4.1节中关于建筑堤坝的防与堵所带来的成本消耗差异也正说明了这一点。

我们总是在默默地埋头苦干，想着找到更多的Bug，认为找到更多的Bug就是胜利在望。然而，常言道“饮水思源”，必须找到Bug的源头，如果不从源头上控制，就像一个多病的孩子，即使把所有Bug找出来（实际上不可能），也是治标不治本，说不准哪一天加入一个新需求点，在实现后又带出一拨新的Bug。就这样，软件改了测，测了又改，周而复始，版本发布的时间拖了又拖。下面的小故事就是一个关于追本溯源的典型事例。

【小故事】

有一天，一个村民在村边的一条河边上走，看到有个人在河里快要淹死了，他跳进河里，把这个人救了上来。还没等休息，他看到河里还有一个人，他一边喊着，一边又回去接着救人。河里出现了更多的溺水者，更多的村民也都被召集来加入救人的行列。在一团混乱中，有个人走开了，沿着河边的一条小道朝上游走去。一个村民叫住他问：“你去哪儿啊？我们需要你的帮助。”他说道：“我要找出是谁在把这些人扔进河里。”

在软件开发的周期里，是谁把Bug扔了进来？同样地，我们需要追本溯源，找出问题的根源，分析后提出防范措施，并加以执行。你也许会说这已超出测试的工作范围，应由公司的专门质量管理团队来负责，但是质量管理团队也需我们的协助。从测试技术的角度出发，测试可以提出更多、更实际的软件设计质量防控的措施，所以，通常测试团队会承担着管理质量的某些方面工作。

“零缺陷”是一个体系，不是依赖于某个人、某个团队就能做好，需要围绕产品的整个开发链的所有团队、所有人都参加进来，同时需要有高层领导充当质量的倡导者。

2.4.3“零缺陷”后的误区

有不少人有这样的担忧，公司实行零缺陷运动后，是不是意味着测试人员该下岗了。从2.4.2节零缺陷的定义中，我们便可以否定这个问题。但是有一点是肯定的，那就是实行零缺陷运动后，软件中的Bug将减少，测试的难度将增强，测试人员的主要精力将会消耗在找深层次的Bug上面。

零缺陷后，测试中的有些人可能开始担任质量保证角色或其他角色，如转去做需求，转去做QA，这也是可能的。这些人将会在分析和实施过程中改进缺陷预防技术，成为零缺陷运动质量文化的大使。

如今大多数软件都复杂、庞大，尽管“零缺陷”听起来很美妙，执行后的结果也好像很好，然而软件是由人做的，人不可能不犯错误，软件测试作为软件开发过程中质量把关的最后环节是少不了的。即使在微软，也同样是用测试来确保产品质量的。