一个实际例子看漏测的严重后果

漏测，这个词对于 测试界的朋友来说，是最不想听到的一个词。尽管我们不太可能把软件中所有的bug都找出来，就像开发人员不太可能开发出零bug的软件，但对测试人员提交给自己的bug常耿耿于怀。另外一方面，漏测与否一直以来是很多公司衡量一个测试人员 工作质量的重要考核点。

　　漏测，指测试人员测试通过的软件在后来被他人或自行发现仍存在bug，这种现象常被叫做漏测。由于软件的特殊性，漏测现象常发生，每发现存在漏测bug，相关测试与开发人员需要进行漏测分析，分析此bug的严重度，发生的概率，测试用例是否存在缺失，开发更改代码后的影响分析是否存在不足等。重要的是找出漏测的根源，提出改进的措施，避免同类问题反复出现。

　　【案例】

　　事情虽过去10多年了，但依然记忆犹新。那时笔者与一些测试同事一起工作在一家研发与生产PDA的私营台资企业。一天早晨，老板一反常态地在他的办公室里与电话对方发生大声的争吵，最后非常生气地把电话挂掉了。接着，开发与测试主管被叫到他的办公室，

　　办公室的门被关上了，他们在悄悄地商量着什么。后来，才知道我们已发布出去的软件，在法语版本上，有一个提示界面仍用英文显示着。测试漏测了，而这个点在用户试用现场，被用户发现了。我们听后都不相信这个事实，因为这个提示信息在常规操作中就能出现。问题已出来了，怀疑无济于事，开发与测试相关同事立即动手检查分析，最后开发定位到是由于有一个地方的处理用了HardCopy（硬拷贝），把英文字符串直接写在代码中了（据负责的工程师说，当时是为了调试的方便，后来在把字符串提取出来作为独立的资源文件时，漏了此字符串。后来对字符串资源进行本地化翻译时，也没有意识到此问题的存在。

　　对于测试来说，是漏了这条用例，是用例设计的遗漏。

　　查出问题的原因后，软件很快更改好了，测试复测，补丁版本当天即可以重新发布。然而，事情影响的严重性却超乎我们的意料。老板跟我们说，那家客户因为与其他代理商合同的原因，已不能接受我们的产品了，一个158万的单就此泡汤。一个单是小事，重要的是由它带来的负面影响是很难用短期的金钱来衡量的。这也许就是老板为什么会如此生气的主要原因吧。后来负责此模块的开发、测试人员受到通报批评，并扣除本季度全部奖金，相比之公司的损失，确实也算不了什么。

　　第二天，老板把我们每一个测试人员叫到他的办公室，问及我们漏测的原因是否找出来了，对日后如何进行防范是否有什么措施。反思的过程中，觉得问题与我们现在的测试模式密切相关，我们没有用例，是在看着简单描述的需求来测试，时间长了，连需求都不看了（自认为需求记住了，看懂了）。平时测试完全是在一种随机测试（目前很多人把它叫做Ad hoc测试），无系统可言，测试者的想法及操作没有留下记录，俗话说“好记性不如烂笔头”，一段时间后，哪些路径测试过，哪些没有覆盖到，无从说起。最后导致一些业务流程被测试N遍，而有些用户场景却一次都没有遍历到，也是顺理成章的事。

　　真佩服当时的老板,讨论解决办法的当时,亲自拿出一张A4空白纸,在上面写着一个个测试功能点,要求我们按照这种方法把各模块的功能点一个个列出来,测试过的则在旁边的小框内打钩。后来我们把它叫做测试checklist。回想起来，这虽然不是合格的测试用例，但比起原来拍脑袋式的随机测试，已向前跨了重要的一步。

　　俗话说“失败是成功之母！”，但愿事例中的惨重代价对测试朋友有所启发与借鉴，把测试工作的核心--用例设计的工作做得更加扎实，为项目的测试成功打下坚实的基础。