一个实际例子看漏测的严重后果(转)
漏测一个提示界面，不仅损失158万
漏测，这个词对于测试界的朋友来说，是最不想听到的一个词。尽管我们不太可能把软件中所有的bug 都找出来，就像开发人员不太可能开发出零bug 的软件，但对测试人员提交给自己的bug 常耿耿于怀。另外一方面，漏测与否一直以来是很多公司衡量一个测试人员工作质量的重要考核点。
漏测，指测试人员测试通过的软件在后来被他人或自行发现仍存在bug ，这种现象常被叫做漏测。由于软件的特殊性，漏测现象常发生，每发现存在漏测bug ，相关测试与开发人员需要进行漏测分析，分析此bug 的严重度，发生的概率，测试用例是否存在缺失，开发更改代码后的影响分析是否存在不足等。重要的是找出漏测的根源，提出改进的措施，避免同类问题反复出现。
【案例】
事情虽过去10多年了，但依然记忆犹新。那时笔者与一些测试同事一起工作在一家研发与生产PD A 的私营台资企业。一天早晨，老板一反常态地在他的办公室里与电话对方发生大声的争吵，最后非常生气地把电话挂掉了。接着，开发与测试主管被叫到他的办公室，
办公室的门被关上了，他们在悄悄地商量着什么。后来，才知道我们已发布出去的软件，在法语版本上，有一个提示界面仍用英文显示着。测试漏测了，而这个点在用户试用现场，被用户发现了。我们听后都不相信这个事实，因为这个提示信息在常规操作中就能出现。问题已出来了，怀疑无济于事，开发与测试相关同事立即动手检查分析，最后开发定位到是由于有一个地方的处理用了HardCopy （硬拷贝），把英文字符串直接写在代码中了（据负责的工程师说，当时是为了调试的方便，后来在把字符串提取出来作为独立的资源文件时，漏了此字符串。后来对字符串资源进行本地化翻译时，也没有意识到此问题的存在。
对于测试来说，是漏了这条用例，是用例设计的遗漏。
查出问题的原因后，软件很快更改好了，测试复测，补丁版本当天即可以重新发布。然而，事情影响的严重性却超乎我们的意料。老板跟我们说，那家客户因为与其他代理商合同的原因，已不能接受我们的产品了，一个158万的单就此泡汤。一个单是小事，重要的是由它带来的负面影响是很难用短期的金钱来衡量的。这也许就是老板为什么会如此生气的主要原因吧。后来负责此模
块的开发、测试人员受到通报批评，并扣除本季度全部奖金，相比之公司的损失，确实也算不了什么。
第二天，老板把我们每一个测试人员叫到他的办公室，问及我们漏测的原因是否找出来了，对日后如何进行防范是否有什么措施。反思的过程中，觉得问题与我们现在的测试模式密切相关，我们没有用例，是在看着简单描述的需求来测试，时间长了，连需求都不看了（自认为需求记住了，看懂了）。平时测试完全是在一种随机测试（目前很多人把它叫做Ad hoc测试），无系统可言，测试者的想法及操作没有留下记录，俗话说“好记性不如烂笔头”，一段时间后，哪些路径测试过，哪些没有覆盖到，无从说起。最后导致一些业务流程被测试N 遍，而有些用户场景却一次都没有遍历到，也是顺理成章的事。
真佩服当时的老板, 讨论解决办法的当时, 亲自拿出一张A4空白纸, 在上面写着一个个测试功能点, 要求我们按照这种方法把各模块的功能点一个个列出来, 测试过的则在旁边的小框内打钩。后来我们把它叫做测试checklist 。回想起来，这虽然不是合格的测试用例，但比起原来拍脑袋式的随机测试，已向前跨了重要的一步。
俗话说“失败是成功之母！”，但愿事例中的惨重代价对测试朋友有所启发与借鉴，把测试工作的核心--用例设计的工作做得更加扎实，为项目的测试成功打下坚实的基础。
注：本文转自网络，http://www.51testing.com/?uid-26026-action-viewspace-itemid-217955