本故事纯属虚构，如有雷同，纯属巧合
大毛隐隐觉得自己是被提升了，但是又觉得不靠谱：这么容易就提升了？
不管怎样，大毛毕竟是能做更为有意义的工作，起码不再是机器人了。更何况，挑毛病确实是一种赏心乐事，尤其能在一些看上去比自己资深的同事的工作里面挑出毛病。这让他精神百倍，还有一种“朝为田舍郎，暮登天子堂”的感觉，直到他发现很多挑出来的毛病其实一直都没有改正。
大毛不禁有些泄气，他的工作到底意义何在呢？
正好项目告一段落，大毛找领导谈了他的困惑。
领导没有回应他的问题，而是说，
“明天有个项目计划的会议，你也去参加，负责设计其中一个组件的测试用例。”
好吧，至少是些新的工作。
项目是做上一个项目的第二个版本，测试的方法也差不多，设计测试用例也是照葫芦画瓢的事，人手也是差不多……大毛想，原来设计和执行测试用例也就是隔层纸的区别嘛。
如果不是在复审会议上被板砖拍得半死的话，大毛还是能一直保持这种良好感觉的。
同事A：界面改成HTML了，为什么没有cross-site scripting（见作者注1）的测试用例呢？
同事B：密码输入框已经强制使用软键盘了，为什么这些测试用例还是用键盘输入呢？
同事C：用户配置文件在两个版本间的兼容性没有测试用例哦。
同事D：我们需要测试用例来保证关键点的性能相比第一版没有下降。
……
风水轮流转，大毛终于找到被挑毛病的感觉了，而且很多意见他还没搞明白是什么意思。
忙了一个星期，查阅了不少文档，大毛总算通过了复审。他不但没有如释重负的感觉，反而觉得绝望：照复审意见的精神，还有很多测试用例没有设计呢，就算都做出来，怎么可能全部执行完呢？再看看其他同事的测试用例，咦，好像也不全嘛，怎么领导就通过了呢。
领导瞄了一眼大毛的神情，说，“到我办公室来聊聊呗。”
“你觉得毛病挑的合理不？”
“挺合理的。”
“然后你觉得全部意见都接受是没法做到的？”
“呃……也是可以做到的。”
“那都有谁做到呢？”
“这个，其实没有。”
“我跟你说，其实软件根本就无法全面测试，所以要加这个那个测试用例，单个看都是合理的，全部都加是没戏的。”（见作者注2）
大毛像被敲了一棒子似的：那我忙了这一个星期还不够，得忙一辈子也不够啊。
“这……既然如此，那为什么还要复审呢？”
“既然无法全面测试，那就必须舍弃一些测试用例，同时确保重要的测试用例没有错误或者遗漏，在可能的时候减少测试用例的总量和执行需要的时间。”
“怎么区分重要不重要呢？”
领导忽然换了个话题，
“你上次说你挑出来的不少毛病都没有人去改正……”
“嗯，比如……”
“我知道，我都看过。这次复审通过的测试用例都是没有错误并且一直认为足够重要的，你把这些用例和你所挑出了毛病又没有得到改正的用例比较一下看看。”
一天以后，大毛心悦诚服的找到领导，
“我明白了，这些用例要么是不再重要了，要么是与新版本的功能不符，要么是执行时间太长了，反正就属于可以被舍弃的。”
“不错。当然了，这些毛病可以用来提醒同事不要在新测试用例中重犯错误，并不是没有价值的。”领导伸了个懒腰，“复审了好几次，累死了。下次好好想想怎样用更少的测试用例达到同样的效果，为了你，为了大家，还有为了我。”
作者注：第二版系统综合症（参见人月神话）不仅仅是架构设计的问题，在测试领域也有其症状。后续版本最终设计出来的测试用例不一定比第一版的要多，但是从实践上看，第一次复审能发现的测试用例错误、遗漏和冗余通常会很多。所以，软件领域的守业其实比创业需要更高的技术和工程能力。
作者注1：参见http://msdn.microsoft.com/zh-cn/partners/ms533047。
作者注2：参见The Art of Software Testing, Second Edition。作者用一个简单的程序展示测试用例如何组合爆炸，使得完全测试是不可能的。http://book.douban.com/subject/1769687/。
扫一扫
1427
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
