继续附录2的下半篇...
4.三击不中出局，是新的打击手上场的时候了
20世纪早期，软件质量的问题显而易见，为了纠正这些问题，提出了多种方法，如下：
1）正式方法
正式方法是一个很好的想法。本质上，它将电脑编程等同于解决一个数学问题。但首先，软件开发人员不会使用它们。其次，使用正式方法的人仍然会写出有很多缺陷的代码。
2）工具
工具在很大程度上能减轻软件开发任务的痛苦，但是它们不能保证零缺陷。工具在使用正确时很有帮助，但是它们很难掌握而且功能有限。还有，它们自己有缺陷。
3）流程改进
最新的关于控制软件质量问题的尝试是由流程改进的提倡者开始的。因为软件开发是一个技术问题而流程 改进却是一个管理问题，所以它不大可能对质量产生多大的影响。
因此，需要第四种提案，它应该很平常，这样开发人员可以将其无缝集成到它们正常的设计模式；它应该很直观，这样开发人员会评价它“简单，不难做嘛！”
5.软件测试是艺术、技巧或学科？
最适合软件测试书籍的标题应该是软件测试学（Discipline of Software Testing）。“学科”这个词能更好地定义我们作为测试人员的工作，并为我们提供一个有用的训练和职业模式的模型。掌握一门学科是通过训练来实现的。训练的意思是理解学科的每一个细节。
每个人在训练时应该注意：首先，精通软件测试的测试人员应该理解软件；第二，精通软件测试的测试人员应该理解软件故障；第三，精通软件测试的测试人员应该理解软件失效。
6.恢复对软件行业的尊重
我们充满缺陷的软件创造了多少新的单词：垃圾邮件、网络钓鱼、域名欺骗等。
1）事与愿违的过去
过去，软件开发实践的重点一直被放在Spec、体系结构和开发上，它们都位于软件开发生命周期的早期部分，因为“质量不是测试来的”。最后，我们发现这种流程失效了，事实上，需求经常变化，导致计划赶不上变化。
2）寻找更好的方法
我们学习失败以创建新的开发流程，我提议停止将缺陷当作一件坏事。因为没有比直接研究那些使我们的行业成为工程学科中笑柄的东西更好的改进方法了。
3）分析安全漏洞和质量问题的流程
我觉得应该做如下的事情：
第一步，收集我们发布给用户的所有缺陷（特别是安全漏洞）
第二步，分析每一个缺陷，这样我们可以做到：停止写出类似的缺陷；更擅长寻找类似的缺陷；明白类似的缺陷发生时，如何识别它们。
第三步，在团队中培养这样一种文化，每个开发人员、测试人员或技术人员都理解我们曾写过的每一个缺陷。
第四步，将学到的内容整理成文档，它也是创建新的方法集的基础，这些方法可以预防我们再犯那些最糟糕的错误。
可通过质问自己写过的缺陷来完成上述工作：
a）一开始是什么错误导致了这个缺陷？
这个问题的答案将教会开发人员更好地理解他们在写代码时犯下的错误。理解错误后，开发小组内部形成一套系统知识，这样进入测试阶段的软件质量更高。
b）出现什么样的失效症状时，能警示我们现在存在这个缺陷？
一般缺陷出现可能由于某种原因没能被发现，或者被发现了却有意不修复。前者，测试人员可建立起一套关于如何更好地将缺陷分离出来的系统知识和工具。后者，整个软对需要对真正重要的缺陷有统一的认识。结果是发布给用户的软件质量更高。
c）哪些测试技术能找到这个缺陷？
可在测试系统知识中加入真正能有效找到重要缺陷的测试。
因为既然我们不可能理解如何正确开发软件，那么就让我们理解自己是如何做错的，然后停止那样做。作为结果的系统知识无法告诉我们应该如何开发软件，但是它可以告诉我们什么是不该做的。
至此，附录2下半篇学完了，整体感受是，让我对缺陷有了更深刻的认识，原来缺陷的作用不仅仅是缺陷！
