“那都有谁做到呢？”
“这个，其实没有。”
“我跟你说，其实软件根本就无法全面测试，所以要加这个那个测试用例，单个看都是合理的，全部都加是没戏的。”（见作者注2）
大毛像被敲了一棒子似的：那我忙了这一个星期还不够，得忙一辈子也不够啊。
“这……既然如此，那为什么还要复审呢？”
“既然无法全面测试，那就必须舍弃一些测试用例，同时确保重要的测试用例没有错误或者遗漏，在可能的时候减少测试用例的总量和执行需要的时间。”
“怎么区分重要不重要呢？”
领导忽然换了个话题，
“你上次说你挑出来的不少毛病都没有人去改正……”
“嗯，比如……”
“我知道，我都看过。这次复审通过的测试用例都是没有错误并且一直认为足够重要的，你把这些用例和你所挑出了毛病又没有得到改正的用例比较一下看看。”
一天以后，大毛心悦诚服的找到领导，
“我明白了，这些用例要么是不再重要了，要么是与新版本的功能不符，要么是执行时间太长了，反正就属于可以被舍弃的。”
“不错。当然了，这些毛病可以用来提醒同事不要在新测试用例中重犯错误，并不是没有价值的。”领导伸了个懒腰，“复审了好几次，累死了。下次好好想想怎样用更少的测试用例达到同样的效果，为了你，为了大家，还有为了我。”
作者注：第二版系统综合症（参见人月神话）不仅仅是架构设计的问题，在测试领域也有其症状。后续版本最终设计出来的测试用例不一定比第一版的要多，但是从实践上看，第一次复审能发现的测试用例错误、遗漏和冗余通常会很多。所以，软件领域的守业其实比创业需要更高的技术和工程能力。
相关链接：
