有些大批量测试方法产生的错误很难解决。很容易发现错误发生在一个特定的测试下，但导致错误发生的一个必要条件可能在真正失败之前已经经过了成千上百个测试。解决这些问题的方法就是设计一些比其他测试更有效的测试集合。
探索性测试
探索性测试是“测试人员积极地在设计测试的同时执行这些测试，利用在测试中获取的信息设计新的更好地测试”(Bach 2003a)。
Bach指出测试是一个跨越纯脚本(测试人员根据脚本明确的开展工作)和纯探索(测试人员的行为不是预先设计好的，并且除了BUG报告他们没有必要产生任何测试文档)的结合体。在这个结合体中任何给定的测试都是投劳的。甚至是由熟练的测试人员执行的杰出的、执行脚本前的测试也是探索性的测试。
“在原型用例中(Bach称之为“自由的探索性测试”)，探索性的测试人员不断地学习他们正在测试的软件、产品的市场、产品会失败的各种情形、产品的弱点(包括在应用历史中哪里出现过问题以及哪些开发这是解决哪种错误的)，并用最佳方法测这个软件。在学习这些的同时，探索性的测试人员也在测这个软件，报告他们发现的问题，主张解决他们发现的问题，并根据他们学习过程中获得的信息开发出新的测试。”(Tinkham & Kaner,2003)
探索性的测试人员可以使用任何类型的测试--域测试、基于规范的测试、压力测试、基于风险的测试、其中任何几个。根本性的问题是不管哪类测试是最好的，只要此时此刻能尽可能地展现测试人员寻找的信息即可。
探索性测试不是纯粹自发的。
测试人员需要做深入的研究，比如了解有竞争力的产品、这个或类似产品的失败历史、与程序员和用户交流、阅读规格说明书、与产品一起工作。
熟练的探索性测试与其他方法以及拙劣的探索性测试的区别是什么，区别是在测试的同时，做探索性测试的人也在忙于工作，学习、计划以及运行测试。好的测试用例提高了测试人员在寻求信息目标方面的知识。探索性测试很高程度上是目标驱动的，但是在测试人员获取到新知识时目标很快机会改变。
结论
生成“好的”测试用例没有简单的公式或规定可以遵循。即使是多年以来在测试方面感兴趣的人也很难做到这一点。软件测试
测试对展现你寻求信息的目的有好处。
我见过很多测试团队中大多数都坚持使用少数几类测试，以场景测试为主或以域测试为主，等等。只要他们擅长于他们偏爱的测试类型，他们的测试在某些方面就会变得极好。不幸的是，我们希望的测试类型不是在任何方面都极好的测试。为了让测试结果多样化、广泛化，我们必须有各方面的技术。
致谢
这项研究部分是由EIA-0113539 ITR/SY+PE：“提高软件测试者的教育”给予的支持。感谢Andy Thinkham,Al Jorgenson,和Pat McGee给以上的稿件的评论。
文章来源于领测软件测试网 https://www.ltesting.net/
