“任何足够先进的技术，看上去都与魔法无异”，出自英国著名未来学家亚瑟 克拉克，他曾于出版了经典科幻小说《2001天空漫游》。
探索式测试（Exploratory Testing，也称探索性测试）是一种软件测试方法，最先是Cem Kaner 在1983年提出的。这是一种强调个人自由与责任的测试方法，让独立测试人员可以借用不断的学习来改善测试的规划与测试的执行，而在测试的过程中也会同时改善测试案例达到相辅相成的效果。在Nortel和微软的很多项目中，都采用了这一新颖、有趣和富有创意的测试方法。探索式软件测试的实践者，软件测试大师James Whittaker在其新作《探索式软件测试》中，对此方法进行了全面的演绎和创新，呈现了微软内部使用此方法的心得体会。
此方法在很早的时候已经被提出，在我国有很多人也开始学习和研究，但用于企业的却很少，最近一段时间发现此方法渐渐地被人们所接受，不管你是去听分享会或者沙龙等都有所哦涉及，那我们就来了解了解吧。
根据度娘告知：探索性测试可以说是一种测试思维技术。它没有很多实际的测试方法、技术和工具，但是却是所有测试人员都应该掌握的一种测试思维方式。探索性强调测试人员的主观能动性，抛弃繁杂的测试计划和测试用例设计过程，强调在碰到问题时及时改变测试策略。
顶测认为探索式测试就是采用新的测试思路，边学习、边设计、边测试、边思考。
一、探索性测试的基本过程
a.探索性测试识别软件系统的目的；
b.识别软件系统提供的功能；
c.识别软件系统潜在的不稳定的区域；
d.在探索软件系统的过程中记录关于软件的信息和问题；
二、探索式软件测试类型
a.自由式探索式测试；
b.基于场景的探索式测试；
c.基于策略的探索式测试；
d.基于反馈的探索式测试；
三、探索式测试的目的
a.需要快速学习一款产品；
b.需要寻求多样化的测试；
c.在进行脚本测试后，还想要进行多样化的测试；
d.想要在最短的时间内发现最多严重的bug；
e.想要检查一个测试人员的工作；
四、探索式测试的条件
a.项目要求；
b.产品稳定；
c.产品重要；
d.测试员要求；
e.有激情感兴趣；
f.掌握探索式测试理论和方法；
五、what情况或者what时间使用探索式测试
我们所进行的软件测试通过几轮之后，基本功能相对稳定，根据Test Requirement（测试需求）编写Test Case（测试用例），在过程中必然会出现难以发现的部分问题，测试人员需转换相关思路，补充更多的测试细节。
六、如何进行探索式测试
a.看 PRD（Product requirements document，产品需求文档） 和原型等各种可提供的文档；
b.确定核心功能模块；
c.与项目组测试人员沟通，确定bug最多风险最大的模块；
d.制定探索式计划： 测程数、每个测程的任务、每个测程的时间；
e.根据计划执行；
f.根据计划，边学习、边设计、边测试、边思考；根据具体情况随时修改测试策略；
g.发送缺陷报告；
七、测试结果总结
a.阅读需求文档，确定核心模块；
b.查看bug管理系统或与测试人员沟通，确定问题较多的模块；
c.根据需求，探索核心模块的功能；
d.根据启发式测试策略模型和漫游测试模型挑选补充测试策略进行测试；
e.根据计划，边学习、边设计、边测试、边思考；根据具体情况随时修改测试策略；
八、存在的误区
误区1：探索式测试是一种测试技术。
探索式测试作为一种方法，可以运用于任何用例测试中，如单元测试、功能测试、性能测试、系统测试等等，只要有探索性的思想并贯彻于实践中，探索式测试就会发挥它的重要作用，找到用例测试没有涵盖的危险区域。
误区2：探索式测试是一种黑盒测试。
探索式测试提倡的原则之一就是“努力深入了解待测产品”。伴随着对产品的了解越来越深入，探索式测试会逐步发现更多的隐藏的潜在风险，通常情况下在白盒状态下的探索式测试更具价值，因为其成果都是建立在坚实的知识和理解基础上，其指向更有针对性。
误区3：探索式测试就是随机测试。
探索式测试会存在文字记录，会做覆盖率分析，比随机测试更为有序和可控。
误区4：探索式测试阶段在用例测试之后。
探索式测试应用于测试的各个阶段，尽可能最大化它的价值。
误区5：探索式测试需要老手来做。
敏捷测试专家Lisa Crispin总结了必要的技能：
小心的观察者：观察不正常和不期望的结果，并对正确性的假定很小心，能够细微的观察软件特征或模式。
认真的思考者：在运行中检查测试并将其改到非预期的方向上，能够解释寻找缺陷的逻辑并提供清晰的测试状态。
系统的叛逆者：思维严密、系统化，同时还要具有多样化的观点。
资源的挖掘者：探索测试人员应该发掘更多他们可以使用的工具、技术、测试数据、朋友和信息源。
探索性测试在游戏中应用也是有指导性的意义。连续多次使用探索性测试可以将你的对应方法的测试思维熟练化；同一种思路发现的方法在测试类似功能的时候很容易借鉴。
最近一次参加的测试沙龙中，有一位老师这么比喻的：ST 相当于跟团游，ET相当于丛林探险。
通过资料的整理，相信大家也比较明确了。
Smpidus发表一下个人观点：
1.学习能力弱的新手，无法第一时间达到需求所要求结果，但就因为他们过于简单的思路却让我们更看清了本质。（唉，分明在说我，我就是这一类的）
2.学习能力强的新手，通过新鲜的事物更好地去发掘。
3.经验丰富的老手，将原有的事物更细化、更完善。
衡量一个人是否适合使用ST，是用我们的技能去探索的，而不是新手还是老手。处于产品比较稳定，进一步作出补充，覆盖系统测试所不及的场景。
既然我们从事于某个行业，就没有适不适合一说，而是我们应该站在什么角度去考虑问题。整理的不是很完善，希望大家可以提出不足和自己的观点。