测试话题2
上期针对xx实施组在软件测试过程中的感受，我提出了一些自己的看法，这期，我们继续讨论这个话题。
测试，这是一个古老的话题，它的出现是非常简单的：因为没有软件没有错误，只有没有被找出来的错误和错误是否可容忍2种情况，例如我们最常用的Windows系统，据微软内部人士透露，测试出来的问题足足有4000个以上，但是，这些错误对于99.99%的操作来说是看不到的，或者不影响操作的，所以它们是可以被容忍的，我曾经有幸体会过一次Windows系统的错误，那是在日本的时候，还是NT 4.0，有一次需要从1台老服务器上迁移N个G的文件到新服务器上，我们一帮新手插上网线开始拷贝了，过了1会儿，就看见Windows报告，还有多少多少个文件，需要负的多少分钟才能拷贝完成，很明显就是文件数太多，造成变量溢出，这就是典型的可以容忍的错误，呵呵。
上面说了软件的好话，接下去言归正传，在测试中，最常见的问题是，先找出一个错误，修改后，只测了这个问题是否解决，其实修改后，必须是整个再测试一遍的，因为每次的软件修改所带来的可能影响到的其他方面是未知的，而且有些修改必须是“级联”的，例如修改了一个表的结构，整个软件就有可能所有的单元都得改一遍，这就带来了2个软件开发和测试的原则：
1、除非无计可施，否则绝对不要变更表结构，有时宁可新增1个表，因为这样修改的范围和风险是可控的
2、1次测试必须完成，不能测试出一个问题就修改，这样永远测试不完，必须是1次完成的测试，然后统一修改，再测试，再修改。
正话讲的差不多了，现在说下我知道的事情：在日本，测试是异常严厉的，bug票（测试错误表）都是1个bug一张纸。话说03年的时候，丰田公司打算把ITS软件（一种车内智能管理系统）外包到中国来做，专门找了上海同济大学的博士后辅导站，由于第一次合作，日方比较谨慎，先拿了个10万的小单子出来，然后声明，这次没问题，下次是50万，50万没问题，就是长期给了。校方对此事也异常重视，派了最好的几个导师带了N个博士生做，做的很顺利，很快软件就交付了。等过了2周，日方怒气冲冲的回复：后续就不用想啦，就这么个小单子，居然让本部的测试部门查出了1400多个错误，光bug票就打了整整1天。这就是软件测试出问题带来的重大问题啦，所以我希望每个搞技术的员工都实实在在的把质量和测试放在第一位，算法、效率不好问题不是很大，但是质量出了任何疏漏都是致命的问题。

Steel