探索式测试（Exploratory Testing）是一种软件测试方法，也可以说是一种测试思维方法，最先是 Cem Kaner 在 1983 年提出的。这是一种强调个人自由与责任的测试方法，让独立测试人员可以借用不断的学习来改善测试的规划与测试的执行，而在测试的过程中也会同时改善测试案例达到相辅相成的效果。它的本质是测试策略，边学习、边设计、边测试、边思考。换句话说，探索式测试是测试人员自发进行的测试工作，在执行测试的同时根据所获得的信息来设计测试策略的方法。它强调要根据当前的实际情况来选择最合适的测试技术，进行测试。测试人员使用探索式测试从客户的角度评估软件的实际工作方式。它更注重的是「思考」和「学习」，不断的发现新的问题。一般在时间相对较紧张，且测试对象说明不完善，即我们常说的「敏捷开发模式」的情况下，探索式测试可以起到突出的效果
采用敏捷开发流程迫使测试团队在更短的时间周期内完成测试。以前需要数周或数月才能测试的团队，现在必须加速测试，以便在几小时或几天内提供更全面的测试结果。因此，必须在极大的时间压力下进行测试，不仅如此还需要减少资源和预算。
由于探索式测试不需要预先进行费时费力的计划，因此团队通常会在开发完成后立即开始测试新功能。这促进了在极短的开发周期内快速检测缺陷。
探索式测试是以用户的角度来测试，它为传统的结构化测试（即从底层开始测试）做了补充，以保护频繁迭代的用户体验。这意味着探索式测试不仅关注系统设计是否良好，还关注用户体验，因此它更容易发现比结构测试更严重的缺陷。
探索式测试正在被越来越多的被应用于用户体验测试。它通常与传统结构化测试形成对比，后者仅侧重于系统逻辑验证（即，是否满足要求/用户故事中概述的验收标准）。结构化测试保障已知风险，而探索式测试主要侧重于分析潜在风险。
虽然不用事先创建测试用例，但是测试人员通过发散性的思维去思考每个模块、每一步甚至每个按钮可能会出现的缺陷问题，可以让测试人员的时间和精力更多地集中在创造性思维上，发现更多隐藏的缺陷。
探索式软件测试一共分为以下 4 种：
·自由式探索式测试
·基于场景的探索式测试
·基于策略的探索式测试
·基于反馈的探索式测试
1.测试之前一定会有一个全局的方针战略，即整体的测试计划，它可以避免走错大方向、该测的部分没有覆盖到或者投入了大量时间到计划之外的部分。
2.测试一旦开始，没有固定的思路，测试人员不受任何先入为主的条条框框约束，根据测试途中获取的信息，指导各自走不同的路径，最终目的就是发现潜藏的缺陷。
1.从产品需求文档（PRD）和原型等文档中获取需要测试的范围和深度，识别软件的根本目的，确定需要测试的核心功能点。
2.与项目组产品、开发人员沟通，获取更多业务信息和系统架构信息，以确定更多的风险点。
3.与其他测试人员沟通，确定风险点最高的模块或功能点。
4.制定探索式测程（Session）：测程表（Session Sheet）、时间盒（Time Box）、主题（Charter）。（可参见 Session-Based Test Management）
5.执行探索式测试计划，在此过程中边测试、边学习、边设计、边思考，并根据具体情况随时更改测试策略。
6.测试的过程中记录软件逻辑，发现 BUG，给开发人员建立缺陷。
信息来源：51testing
