1、在项目发布后发现和修复Bug的成本是需求和设计阶段所需的一百倍！
2、80%可避免的重复劳动源自于20%的缺陷，其中两大主要来源包括草率的需求定制和象征性的案例设计和开发。
3、大约80%的缺陷来自20%的模块，而约半数的模块是几乎没有缺陷。
4、90%的软件的停工期最多来自于10%的缺陷。
上面四条原则说明了两个问题，一是错误越早发现成本越低，而且大部分的错误都是在软件开发的前面阶段引入的。二是大部分的错误都集中在少数的模块。
测试作为最有效的“马后炮”，一直被认为最有效的保证软件质量的手段。果真那么有效果吗？首先得考虑一下这个问题：“为什么80%的缺陷会在20%的模块，而过半数的模块几乎没有缺陷呢？”。
缺陷集中出现有两种可能，一是大量出现缺陷的模块特别复杂，以至于软件设计者和程序员没有能力保证程序没有错误。二是编写这些模块的程序员比编写其他模块的程序员水平要低，或者做事情要毛糙。第一种可能是可以避免的，如果模块太复杂就将其分解为若干更小的模块，直道划分的模块够简单为止，这也是模块划分过程中应该要做的。核心技术应该由骨干人员进行技术攻关，保证其正确无误的实现。至今也没有听说过有程序员实现不了的软件，程序员、特别是优秀的软件设计师的能力无需怀疑的。那么问题出现在编写程序的程序员的水平有高低，或者质量意识不够强。10个程序员中如果9个编写的程序都没有问题，另外1个人水平欠缺就可能导致问题都出现在他编写模块中。
等到软件编码完成后，进行测试的时候发现了问题，这个时候再去改正，那么错误修正费用已经发生了。何不一开始就替换掉能力低下的程序员，或者干脆少了这两个程序员而延长项目开发时间来保证软件的质量呢？测试虽然能够发现问题，却不能节约成本。
将测试引入到需求分析阶段，将需求的问题，在需求分析阶段就找出来。这样就可以节约100倍修复开销，这样的只赚不赔的事情为什么不做呢？
软件质量靠的不仅是测试，而是软件企业对软件质量的关注程度，如果一开始就将质量放到一个比较高的位置，我想测试这种“马后炮”才能够更充分的发挥它的作用。
