[科普中国]-探索性测试-

探索性测试可以说是一种测试思维技术。它没有很多实际的测试方法、技术和工具，但是却是所有测试人员都应该掌握的一种测试思维方式。探索性强调测试人员的主观能动性，抛弃繁杂的测试计划和测试用例设计过程，强调在碰到问题时及时改变测试策略。

定义对探索性测试最直白的定义是：同时设计测试和执行测试。探索性测试有时候会与即兴测试（ad hoc testing）混淆。即兴测试通常是指临时准备的、即兴的Bug搜索测试过程。从定义可以看出，谁都可以做即兴测试。由Cem Kaner提出的探索性测试，相比即兴测试是一种精致的、有思想的过程。

在对测试对象进行测试的同时学习测试对象并设计测试，在测试过程中运用获得的关于测试对象的信息设计新的更好的测试。这个有趣的过程如下图所示。

探索性测试强调测试设计和测试执行的同时性，这是相对于传统软件测试过程中严格的“先设计，后执行”来说的。测试人员通过测试来不断学习被测系统，同时把学习到的关于软件系统的更多信息通过综合的整理和分析，创造出更多的关于测试的主意。1

基本过程识别软件系统的目的；

识别软件系统提供的功能；

识别软件系统潜在的不稳定的区域；

在探索软件系统的过程中记录关于软件的信息和问题；2

类型探索式软件测试一共分为自由式探索式测试、基于场景的探索式测试、基于策略的探索式测试和基于反馈的探索式测试。下面将详细介绍4种类型的应用场景。

一：自由式探索式测试

自由式探索式测试指的是对一个应用程序的所有功能，以任意次序、使用任何如数进行随机探测，而不考虑哪些功能是否必须包括在内。自由式测试没有任何规则和模式、只是不停的去做。很不幸，很多人认为所有的探索式测试都是自由式的，从长远的观点来看，这种看法低估了探索式测试技术的能力，我们在随后将看到这类测试的一些变种。

一个自由测试用例可能会被选中成为一个快速的冒烟测试，用它来检查是否会找到重大的崩溃或者严重的软件缺陷，或是在采用先进的技术之前通过它来熟悉一个应用程序。显然，自由式探索式测试无需也不应该进行大量的准备规则。事实上，它更像是“探索”而不是“测试”，所以我们应当相应的调整对它的期望值。

自由式测试不需要多少经验或者信息。但是，同以下提到的探索式技术相结合后，它将成为一个非常强大的测试工具。

二：基于场景的探索式测试

基于场景的探索式测试和传统的基于场景的测试有类似之处。两者都涉及到一个开始点，就是用户故事或者是文档化的端到端场景的开始之处，那也是我们所期望的最终用户开始执行应用程序的地方。这些场景可以来自用户研究、应用程序、以前版本的数据等，并作为脚本用于测试软件。探索式测试是对传统场景测试的补充，把脚本的应用范围扩大到了更改、调整和改变用户执行路径的范畴。

使用场景作为指导的探索式测试人员经常会修改他感兴趣的输入或者是追寻一些并没有包括在脚本中的潜在副作用。不过，由于最终的目标是完成给出的场景，这些测试上的弯路、最终总是会回到脚本文件记载的用户主要执行路径。

三：基于策略的探索式测试

将自由式测试探索式与具有测试老手的经验、技能和感知融合在一起，就成为基于策略的探索式测试。它属于自由式的探索，只是他是在现有的错误搜索技术下引导完成的。基于策略的探索式测试应用所有的已知技术(如边界值分析或组合测试)和未知的本能(如异常处理往往容易出现软件缺陷)，来指导测试人员进行测试。

这些已知的策略是基于策略的探索式测试成功的关键，存储的测试知识越丰富，测试就会更有效率。这些策略缘于积累下来的知识，它们指导软件缺陷隐藏在哪里，如何综合人工输入数据，那些代码路径常常出现故障。

基于策略的探索式测试结合了测试老手的经验和探索型测试人员的随机性。

四：基于反馈的探索式测试

基于反馈的探索式测试缘于自由式测试，但是随着测试历史的形成，测试人员们就会利用反馈来指导今后的探索。“覆盖”就是典型的例子。一名测试人员通过咨询那些覆盖指标(代码覆盖、用户界面覆盖、特性覆盖、输入覆盖或者其中的某一些组合)来选中新的测试用例，以使这些覆盖指标得以提高。覆盖指标只是收录反馈信息的标志之一。我们也会看其他标志，如代码改动数量和软件缺陷密集程度等。

基于反馈的探索式测试时一种“上一次测试”：在上一次我根据应用程序的最后状态选了每某一个输入之后、下一次我就会选中另外一个输入。或者是，在上一次遇到这个界面时我用A属性，这一次我就会用B属性。

基于反馈的探索式测试工具是非常有价值的，它可以是测试人员保存、搜索测试历史并据此采取实时行动。不幸的是这样的工具很少。2

适用时机当测试者是新手，可以一边训练一边测试

需要快速的对程式进行评估

在传统的测试脚本（Test Script）中发现新的问题需要快速验证

当有需要去确认另一位测试者的工作状况

当团队内有熟悉相关领域知识（Domain Knowledge）的测试者

当需要做烟雾测试

当程式设计完后并没有预先规划并准备好测试脚本

当专案使用敏捷软件开发

专案很复杂并且难以了解

当测试者并没有权限去创建测试案例

当想要针对某个程序错误进行深入调查

当专案尚未稳定到可以执行脚本测试（Script Test）

当想要扩大脚本测试的多样性时1

优点与缺点优点

鼓励创造性。

可增加机会找到新的、未知的程式缺陷。

允许测试者花较多的时间去测试一些有趣或复杂的状况。

可较快速的对受测的系统做出快速的评量。

可让你知道系统是否容易使用。

可变通的，有弹性的。

它比脚本测试有趣，因为它不会一成不变。

缺点

不容易被协调及调整。

无法对系统作全面性的测试。

提供有限的测试可信度。

非常的依靠测试者的领域知识（domain knowledge）以及技术。

无法保证最重要的程序错误一定被发现。

并不适用要执行很久的测试（例如执行一整个晚上的测试）。2

本词条内容贡献者为:

曹慧慧 - 副教授 - 中国矿业大学