背景介绍
剧本式测试
考虑到软件测试如此的重要，难免会有不少的测试人员试图完成“完全测试”——通俗地说即使想将软件的方方面面、每一行代码都测试覆盖到。
但是，“完全测试”是不存在的，是一个难以实现的梦想，究其原因，软件测试的投入（时间、人力等）是一个巨大的限制因素。我们不可能围绕一个软件投入无穷的时间和人力进行测试，并且软件是一个不断发展和迭代的产品，当测试人员在前一个迭代周期测试的一个功能可能在下一个迭代周期就会发生变化，测试的要点也会相应的发生变化。
众所周知，传统的脚本式测试流程的主要包括测试设计和测试执行。测试人员严格地按照设计好的测试用例执行测试，比对期望输出和实际测试输出，最终判定测试结果通过与否。
由此可见，脚本测试严重依赖于测试设计人员对被测功能的熟悉度，忽视了测试执行人员在测试过程中发挥的作用（某种程度上认为测试人员只需要机械性地严格按照测试脚本执行即可）。
但在实际工作中，剧本式测试往往存在以下问题：
1)测试设计人员不可能严格的、精确的描述每一个测试用例
在工业实践和真实的生产环境中，测试用例往往很难设计，实践人员也很少会严格按照设计的测试用例进行测试，预期结果的设计和评估都需要依靠测试人员要根据经验和隐性知识，而不是严格地记录技术和结果。
2)测试人员需要花费大量的时间维护测试脚本
软件应用具有开放性、快速迭代、频繁变更、存在多种接口、重用户体验等特点，相应的测试用例也需要频繁修改，因此需要耗费大量人力和时间成本维护测试用例或测试脚本。
3)剧本式测试忽略了测试人员在测试执行中的创造性
有数据表明，不同的测试人员使用相同的测试策略、按照相同的测试脚本执行测试，测试结果（挖掘出的缺陷数量和缺陷质量）也会存在较大差异。
4)剧本式测试的机械性特点导致测试人员的功能性被削弱，测试人员的可替代性被增强
正是由于剧本式测试的机械性，已有的许多关于剧本式测试的研究的关注点都在于自动化测试用例的设计、生成和优先级，或者测试技术的选择，而非测试人员本身，导致生产实践中不少企业或个人都认为软件测试是一项可以被机器替代的工作。
探索性测试
无数经验告诉我们，影响用例设计、用例执行过程的不只是单纯的测试技术，测试经验和智力性创造也发挥着重要作用。为了提高测试工作的效率，充分发挥测试人员在测试工作中的智力性，“探索性测试”在剧本式测试的包围圈中异军突起。
探索性测试最早是由测试专家 Cem Kaner 博士在 1983 年提出，并发展成为一门学科。它指的不是某种具体的测试技术，而是一种自由的测试风格或者说测试思维技术。
本文源自第六十九期《51测试天地》
《探索性测试研究是如何开展的》一文
查看更多精彩内容，请点击下载：
版权声明：本文出自《51测试天地》第六十九期。51Testing软件测试网及相关内容提供者拥有51testing.com内容的全部版权，未经明确的书面许可，任何人或单位不得对本网站内容复制、转载或进行镜像，否则将追究法律责任。
