人们经常会明确地区分“自动化”测试和“探索性”测试。这就如同明确区分“红色”轿车和“家庭型”轿车一样存在弊端。之所以这么说，是因为“红色”（指一种颜色） 和“家庭型”（指某种目的概念） 是正交类型。一辆轿车，无论其用途是什么，都可以是任何一种或其他颜色；反之，无论其是什么颜色，都可以用于特定的用途。测试，无论是不是探索性测试，都可以或多或少地使用一些工具。测试，无论是否需要使用工具，都可以是高度脚本化测试或是高度探索性测试。
“探索性”测试也不是“手工”测试。无论怎样，“手工”都不是一个令人满意的形容软件测试的词汇。当你在测试时，其实并不是用手来做测试，这就好像当你在骑自行车时，并不是用脚来推动自行车前进一样。实际上，是人的“大脑”在做测试；手，最多只是提供了一种手段来完成输入以及与正在测试的事情进行交互而已。从是否使用工具或机器的意义上讲，甚至“手工”测试也不是手动的。在测试时，你确实还是在使用计算机的，难道不是吗？
（很好，大多数情况下如此，虽然并不总是这样。如果你是在评审需求，规格说明书，代码或者文档，虽然你可能只是在看文件，但实际上你仍是在测试。一个思考实验或者一次关于产品的讨论，都可以是一种测试；因为您是在质疑一些东西以便对其进行评估，以一种随意的方式把一些想法与其他想法进行对立和比较。你在评审时，是不是在用笔对正在阅读的资料做批注？有没有用记事本来记录自己的观察结果？有没有在文档的重要位置粘便签？如果你有这样做，那么你就是在使用工具了，即便这些工具的技术含量可能比较低。）
一提到测试自动化，有些人就会联想到一个敲击虚拟键盘的机器人，感觉这个机器人比人类更快速、更可靠、更精准。这无疑是测试自动化的一种可能的概念，但却是非常局限的。对于测试自动化的传统观点认为，自动化主要集中在执行检查，但这并不是自动化应用于测试的唯一方式。
在“快速软件测试类别”中，James Bach 和我建议了一个更为宽泛的测试自动化观点，即使用任何可能的工具来支持测试。这有助于使我们对以下观点保持一种开放的心态：机器可以帮助我们完成几乎任何的单一形态的、重复性的、非智能的测试方面，这样我们才能够将时间和精力集中在多形态的、可变的、智能的测试方面。探索是一项多形态的活动，但它可以包括单一形态的活动，且需要后者支持。Cem Kaner 和 Doug Hoffman 采取了类似的方法：探索性测试自动化是指“支持学习被测软件质量的新信息的计算机辅助测试。”学习新信息是探索性测试的一个特征，它通常更多地强调变化而不是重复。
这就是说，即使你是在用高度探索性的方法，也可以有机械化重复的一席之地，例如当测试的重复方面是为了支持发现一些新的或意外的东西的时候。关键不在于你是否将活动机械化。关键在于当活动结束时发生了什么。一项活动的结果越无法提示后续测试，那么这个方法就越是脚本化的。如果重复是能够立即对自身产生反馈的学习回路 （一个包括探索、发现、调查和理解的循环） 的一部分，那么这个方法就是探索性的。James 还发布了很多关于重复测试的动机，每一个 （“失效或无差异”可能例外） 都与探索完全相符且十分匹配。
对于部分不需要人类判断或智慧的行为而言，使用工具可以比人类执行的更好。人性甚至可能妨碍得到理想的结果。例如，当你对产品一些方面的探索建立在统计分析的基础上，而随机选择是测试设计的一部分时，就很有必要记得如果要人去生成随机数，那将是非常糟糕的。即使人们相信他们是在随机选择数字，也会有潜在的 （且通常是相当无意识的） 模式和偏倚在预示着他们的选择。这时候，如果你想生成随机数，工具可以帮你。
工具可以在很多其他方面支持探索：数据生成；系统配置；模拟；记录和视频捕获；检查系统内部状态的调查；检测产品中特定类型的错误条件，或生成类似真实的结果以供比较的测试判定准则；数据集的可视化；要观察的关键要素；关系，或定时，测试活动的记录和报告。
几年前，我曾经在一家银行做柜员机工作站应用程序的测试 （我在如何降低软件测试成本一书中曾提及）。当时，在国内交易领域工作的其他测试人员在工作时仍然依赖于脚本，且该脚本包含大量令人痛苦的，繁琐而明晰的步骤及观察结果。（脚本带有截屏作为补充，但文字和图像并不总是一致，这是痛苦产生的部分根源。）我的测试任务涉及外汇，且我接受的测试工作是没有脚本的，即在很大程度上是自定义的。为了快速地学习这个应用程序，我不得不去探索，但这绝不意味着我不使用工具。相反，事实上在那个环境下，Excel 是我手边最方便最强大的工具。我使用Excel （及其嵌入式 Visual Basic for Applications） 来执行以下任务：
● 维护和更新 （一个击键） 规模巨大的货币、汇率、交易类型表
● 通过正则表达式解析来访问表中相应的条目
● 在测试环境下模仿应用的业务规则
● 通过交易显示预期的资金流向
● 为显著的测试结果和测试场景添加可视标记
● 使用比较算法，提供清晰的结果以方便将产品的结果进行比较
● 帮助对测试理念进行非常快的评估
● 创建客户数据表，这样我就可以使用各种人物角色进行测试
● 加速我对于产品和测试空间的理解
● 提升我关于布尔代数及其在算法中的使用的学习
● 记录我的工作并为我的客户阐述成果
● 在必要时进行快速计算
● 帮助我发现更多的实际问题，总数超过其他四个测试人员联合起来发现的问题
所有这些活动都是以一种高度探索性的方式发生的；每一项活动都与其他活动相互作用。我以非常快的周期来审视下面需要学习应用程序的哪一部分；尝试并执行测试；编程；向主题问题专家、程序员、经理请教问题；报告；阅读参考文档；调试和学习。并行发生的紧凑的活动循环正是探索性进程的特点。但是，这并不是一项不使用工具的工作；在我对产品的探索和学习中，以及寻找程序错误的过程中，工具绝对占据着核心的地位。的确，如果没有工具，关于能够测试什么及如何进行测试，我的想法会非常有限。
旧时代的探索者们使用如下工具：指南针和星盘，地图和航海图，绳索和滑轮，船和火车。今天，软件测试员在探索应用程序时使用思维导图软件和文本编辑器；电子表格和计算器；数据生成工具和搜索引擎；脚本工具和自动化框架。这些代表着探索性测试的概念不是输入机制，后者可以是手指在键盘上敲击，API 调用向程序灌注的数据表，通过网络传输的字节，可变电压控制器发出的信号。探索性测试是你工作的方式，是测试设计、测试执行和学习相互支持，相互增强的程度。工具通常是这个进程中关键的组成部分。
相关链接：
