本书的第3章就致力于传授这些智慧火花。我必须承认，这些大多不是我的发明。我只是非常幸运，能有机会可以和那些有史以来最优秀的测试人员一起工作。从IBM到爱立信（Ericsson），再到微软（Microsoft）、Adobe、谷歌（Google）、思科（Cisco）和其他很多不知名的小公司，我获得了各种各样的建议，我会在这里转述其中大部分的内容。在《如何攻破软件》（How to Break Software）一书中对前述很多信息都有所描述，所以读者可以把本书当成《如何攻破软件》一书的知识升级版。当然，我这里是从如何发现软件缺陷的角度来谈，所以本书的主题更广泛，更全面。我们感兴趣的不仅仅是如何寻找软件缺陷，我们还希望可以通晓软件的方方面面，对应用程序的功能、界面和代码有比较全面的了解，然后可以从头到尾对软件进行彻底测试，使软件的质量标准提高到可发布的水准。
全局探索式测试法
对测试而言，不仅仅是必须对所有这些细节做出正确的抉择，还有更多的东西。事实上，在所有的细节问题都解决之后，有可能会发现我们还缺乏一个综合的测试集，该测试集用来确定软件是否已经满足正式发布所需达到的质量标准。在同一时刻，完整运行这个综合的集中测试的所有测试所带来的价值，比单独运行它们大得多。这是因为各个测试用例之间都是相互有联系的，每个测试用例都是测试集的一个有机组成部分。加入测试集的每一个新的测试用例，都应该把测试集变得更完善，这种提高是本质上的，并且是可以度量的（虽然这一点还有争议）。
这就说明测试人员非常需要一种可以帮助他们设计测试用例的策略。单个单独的测试用例应该覆盖软件的哪些功能？哪些软件的功能必须放在一起测？应该先测哪个功能？如何决定哪个功能先测，哪个后测？如果一个项目中有多个测试人员，应该使用什么样的测试策略，以确保各个测试人员的工作相辅相成，而不是相互重叠？对于这些较高层次上有关总体测试和测试策略的决定，测试人员如何使用探索式测试法进行取舍呢？
这里我把前述问题的答案称为”全局探索式测试法“，因为这里做出的决定不仅仅影响单个的对话框或单个用户界面，它的范围涉及到软件的全局。这里所做的决定不仅仅是确定如何测试某个单一功能，而是确定了如何对软件进行探索式测试的整体方向。
这里，我把全局探索式测试法和旅游进行类比。可以这么来看，如果一个游客来到一个从没有去过的城市，他需要参考那些全局性的建议选择去哪个饭店吃饭，然后再参考那些局部性的建议来决定点哪些菜和喝什么饮料。全局性的建议有助于确定一整天的行程，告诉你一天要干些啥，参观哪些景点，观看哪些演出，去哪里就餐。局部性的建议不仅可以帮助你一一处理这些事情，还可以协助你处理全局性建议无法涉及的细节问题。如果测试人员能把这两种方法很好地有机结合起来，那他就可以称得上是一名探索式测试人才了。
同时使用探索式测试和脚本测试
没有必要把探索式测试和使用脚本的手工测试对立起来，也没有必要认为两者不能并存。事实上，这两种方法可以很好地结合起来。使用正式脚本可以为探索式测试设立一个明确的框架范围，探索式测试则可以提高脚本测试的有效性，为脚本中的测试用例提供更多种多样的变化。在所有手工测试方法中，探索式测试和脚本测试算是两个极端，俗话说”异性相吸“，也就是说两者其实并不排斥，它们之间更可说是一种互补关系。如果使用得当，它们完全可以相辅相成。测试人员最终可以发现位于这两者中间的一个平衡点，在那里进行测试会最有效。
据我所知，同时使用这两种方法最好是从正式脚本开始，然后再使用探索式测试法在脚本中加入各种各样的变化。这样做的话，单一的测试脚本会演化出很多探索式测试用例。
在传统的脚本测试中，首先需要形成一个描述用户经历或描述完整用户场景的文档，该文档记录的是我们认为最终用户会做的那些事。这些场景都是通过用户调研或软件前一版本的使用情况等途径搜集而来，然后再用来编写测试软件的脚本。在传统的基于用户场景测试的方案中加入探索式测试，不仅可以拓宽脚本所包含的范围，还可以在脚本中添加了更多的变化可能、更多的用户使用方式和更多的检测方式。
使用用户场景作为指导的探索型测试人员经常会另辟蹊径，尝试一些比较另类的输入值，或是使用那些并没有写在脚本里的、却有可能导致副作用的输入值。当然这里的最终目标依然是执行脚本描述的用户场景，所以必须做到殊途同归，最后还是要回到脚本中最主要的用户使用方式上。比如可以有计划地修改脚本定义的某些步骤再进行测试，或是先脱离脚本的描述，对接下来的几个步骤使用探索式测试法自由发挥，随后马上回到脚本。我将在第5章专门讲述基于脚本的探索式测试法，因为这个主题太重要了，它算得上是手工测试人员必备的关键利器之一。
相关链接：
