《探索式测试》节选

我提议从一个缺陷开始，反过来倒推出一个有效的流程。下面是我所认为的具体做法

第一步：收集我们发布给用户的所有缺陷（特别注意安全漏洞）。不要象对待会跳出来咬伤我们的蛇那样对待它们，相反，把他们认为是公司的一种资产。这样，它们就明确地指出我们是否有流程问题，思路是否有方向性错误，或是否犯了错误。如果不能从自己做错的事情中吸取教训，应该感到惭愧。如果我们拒绝承认自己做错了，那么问题就更严重了。

 

第二步：分析每一个缺陷，这样我们就可以做到三点：（1）停止类似的缺陷；（2）更擅长寻找类似的缺陷；（3）明白在类似缺陷发生时，如何识别它们。

 

第三步：在我们的团队中培养这样一种文化，每一个开发人员/测试人员或者技术人员都理解我们曾写过的每一个缺陷。

 

第四步：将学到的内容整理成文档。这是编制有关已知缺陷的系统知识的基础部分，它也是创建新的方法集的基础，这些方法可以预防我们再犯那些最糟糕的错误。

 

我们通过指认自己写过的缺陷来完成上述工作。我认为下列三个问题是一个很好的开始。

1.一开始是什么错误导致了这个缺陷？

2.出现什么样的失效症状时，能警示我们现在存在这个缺陷？

3.哪些测试技术能找到这个缺陷？

对于我们在测试中完全忽视的缺陷，需要理解哪些测试可以发现这种失效，并帮助我们诊断出这种故障。这样一来，便又在测试系统知识中加入真正能有效找到重要缺陷的测试。

其结果是更高效的测试和更短的测试周期。

二

测试错误代码

 开发人员写两种代码。第一，完成工作的代码，我们称这种代码为功能代码，因为它提供了满足用户需求的功能。第二，还有一种代码用于保护功能不会因为错误的输入（或者其他一些无法预计的环境条件）而失效。我们称这种代码为错误处理代码，因为它能处理错误。对于很多程序员来说，这种代码是他们被迫写的，而不是必要的，编写的过程也不是很让人愉悦。

测试错误处理代码需要考虑很多因素。最重要的是理解应用程序如何回应错误的输入。我试图区分三种不同的错误处理程序。