如果完全抛开测试脚本（或者如同后面几章中提到的，使用定义得比较笼统的脚本），就称为探索式测试。测试人员在测试应用程序中可以天马行空地想怎么测就怎么测，利用应用程序所提供的信息自由发挥，没有限制，不受任何约束地探索程序的各种功能。对有些人来说，这看上去没有什么规律，但是对一个有经验并熟练掌握探索式测试法的人员来说，这种测试方式可以说非常强大有效。很多拥护探索式测试的人认为它可以让人脑不受各种先入为主的条条框框约束，从而充分发挥智慧，把精力完全集中在发现缺陷和验证软件功能上。

　　使用探索式测试并不是说不写文档。测试结果、测试实例和测试文档都会在运行测试时创建。这和普通测试在测试计划里预先编写好截然不同。用于记录探索式测试结果的最佳工具就是那些截屏软件和记录击键的软件。手工测试并不是说在测试过程中不能使用各种自动化工具，就像那些号称“纯手工打造家具”的工匠们也肯定需要使用各种各样的电动工具。所以即使测试人员测试时使用了含有调试信息的软件版本（debug build）、调试器（debugger）、代理程序（proxy）或其他某些分析工具，还是算作手工测试；只是比起那些不用工具的人，他们的工作会更有实效。

　　探索式测试最适用于现在那些新潮的使用“敏捷开发过程”（agile method）的Web应用程序。这种程序开发周期很短，基本没有时间可以编写正式的测试脚本，更不用说维护了。由于产品的功能变化很快，所以整个过程中要尽量减少那些不能通过工具自动生成的产物（比如必须预先编制的测试用例）。如果一个测试用例很可能马上就失效，当初就根本没有必要去编写它。难道不应该把更多的时间用于实际测试而不是维护那些测试实例吗？

　　探索式测试的缺点在于测试人员有可能在测试中没有重点，从而漫无目的地尝试各种情况来试图发现软件缺陷，这会浪费大量的时间。如果不充分准备，没有条理，缺乏方针就盲目测试，就会对某些功能重复测试多次，导致测试效率低下，在有多个测试人员或测试团队共同测试的时候，该情况就更为严重了。在没有测试文档的情况下，测试人员如何保证良好的测试覆盖率呢？

　　这里要强调指导方法的重要性。探索式测试如果没有一个好的指导方法，就好像游客新到一座城市，然后盲目彷徨想碰巧找到景点一样。但是有个导游就不同了，他可以帮你弄清自己的目的地到底是哪里（对我们而言，就是软件本身要测什么），让探险计划有条不紊。如果想在伦敦看海滩，那纯粹是浪费时间，想在佛罗里达找到中世纪的建筑也是一样。从测试策略的角度来说，明确到底要测什么和怎么测试同样重要。

　　探索式测试有两种指导方法，它们都可以帮助测试人员做具体决策。一种称为局部探索式测试法（exploratory testing in the small），它辅助测试人员在测试过程中即时作出决定。另一种称为全局探索式测试法（exploratory testing in the large），它用于帮助测试人员设计整体测试计划和测试策略。如果把探索式测试的实质和使用脚本的手工测试合并起来，就可以得到第三种探索式测试法——混合探索测试技术。

　　局部探索式测试法

　　手工测试人员的大部分工作都可以用下面一个词来形容，”变化无穷“。测试人员必须决定，具体使用哪种输入方式，浏览哪个页面或哪个用户界面，选择哪个菜单选项，在他们看见的每个输入字段中键入哪些字符。理论上可以这么说，运行任何一个测试实例都需要测试人员在测试期间做出几百个这样的抉择。

　　探索式测试法可以帮助测试人员在这种情况下做出明智的选择。当测试人员在面临前述抉择时，如果使用了探索式测试的策略，我就称之为局部探索式测试法，因为这里所做的决定基本上是针对局部小范围的。当测试人员面对一个网页、一个对话框或正在查看程序中某个类的一个方法时，他往往需要一些很明确的建议指导他如何处理这些情况。由于这个决策过程比较短，影响范围比较小，所以测试人员在运行一个测试用例中会多达几十次地重复该过程，在一天的测试工作中，则可能需要几百次经历这样的决策过程。

　　问题是很多测试人员在面临需要做出一系列这样”小“决定的时候往往不知所措。比如，如果这个文本输入框可以接收一个整数，选用哪个值呢？使用4是不是胜于使用400（这里指的是是否更有可能发现软件缺陷或更有可能产生某个特定的输出结果）？如果使用0或者负数，有没有什么特殊效果？测试人员会不会尝试键入一个无效的输入值？如果对应用程序已经有一些了解（比如已经知道该程序由C++编写而成或者是该程序和数据库直接相连），这会不会影响所采用的测试值？真的，探索式测试中有哪些智慧结晶可以帮助我们在测试时对这些细枝末节都能做出正确的决定呢？