1、探索性测试的定义
测试专家 Cem Kaner 博士在1983年提出探索式测试，后来Kaner 博士在2006年1月Exploratory Testing Research Summit 会议上将探索式测试的定义为:
Exploratory software testing is a style of software testing that emphasizes the personal freedom and responsibility of the individual tester to continually optimize the value of her work by treating test-related learning, test design, test execution, and test result interpretation as mutually supportive activities that run in parallel throughout the project.
从上面定义看到，探索式测试是一种软件测试风格，不是一种具体软件测试技术。软件测试技术是指等价类划分、边界值分析、因果图等等。强调测试人员的个人自由和责任，通过与测试相关的测试学习、测试设计和测试执行、测试结果评估等活动相互支持且在项目中可以并行的，以持续优化测试工作价值。
探索性测试的最大特色是在对测试对象进行测试的同时学习测试对象并设计测试，在测试过程中运用获得的关于测试对象的信息设计新的更好的测试。它的典型过程如下图：
这相对于传统软件测试过程中严格的“先设计，后执行”来说，是具有很大区别的。
探索测试的本质是测试策略，边学习、边设计、边测试、边思考。换句话说，探索式测试是测试人员自发进行的测试工作，在执行测试的同时根据所获得的信息来设计测试策略的方法。它强调要根据当前的实际情况来选择最合适的测试技术，进行测试。测试人员使用探索式测试从客户的角度评估软件的实际工作方式。它更注重的是「思考」和「学习」，不断的发现新的问题。
2、探索性测试的基本过程
探索性测试的基本过程包括如下：
识别软件系统的目的；
识别软件系统提供的功能；
识别软件系统潜在的不稳定的区域；
在探索软件系统的过程中记录关于软件的消息和问题；
创建一个测试纲要，使用它来执行测试。
注意：上面的过程是一个循环的过程，并且没有很严格的执行顺序，完全能够先创建测试纲要，执行测试，然后在测试中进修软件系统；也能够先探索软件系统的各个区域，然后再列出需要测试的要点。
探索性测试强调创新的测试思维，在测试过程中不断地出现许多关于测试的新想法，
因而就像一把叉，下图就是一个所谓的“探索叉”（exploratory forks）。
探索性测试强调测试过程中要有更多的发散思维，这也是与保守测试方式的最大区别。
保守测试方式强调设想完善的测试用例，测试人员严格按测试用例执行测试，这多少限制了测试人员的测试思维，测试人员往往缺乏主观能动性。
下图展示了一个发散思维的过程，探索性测试强调发散，但并不是盲目地发散，在适当的时候还要收敛回来。
例如，当发觉在一个测试的分支路径上已经花了很长时间也没有找到问题的答案时，则能够考虑先放弃那个区域的探索，因为还有一个主线的测试任务。
适合场景：
探索性测试尤其适合于那些需求不是很明确的测试任务，或者是一名刚刚接手一项新的测试任务的测试人员使用。
探索式测试可以将此方式运用于任何种类的开发均能产生价值，然而，它最适合于那种快速循环和突发变化很常见的敏捷开发。开发和测试的方法有很多共通之处。
3. 基于会话测试管理的探索性测试
在我们日常工作中，如果利用探索式测试只是对某个功能进行补充测试，通常测试员利用以往经验、业务理解、与产品和开发交流，通过不断探测也能发现bug。
如果在敏捷测试中，以探索式测试为主，如果没有流程管理，容易忽略测试目标，保证不了产品的质量和测试效率。通过什么方法来管理呢？Jon Bach 和 James Bach 提出了基于会话的测试管理(Session-Based Test Management ，SBTM)。SBTM是指会话时间(30min、60min)内完成一个具体特定测试目标，在会话时间内对测试学习、测试设计、测试执行、测试结果评估进行快速迭代。围绕着目标不断地拷问、质疑被测系统。
每个会话里的具体特定测试目标可以由测试目标分解，每个具体特定测试目标通过一个或几个会话来完成。在SBTM把特定目标称为章程。章程模板如下：探索（目标）、使用（资源）、发现（信息）。
一个简单的三段式模板：
·目标：要探索什么？它可能是一个特性、一个需求或者一个模块。
·资源：可以利用什么资源进行测试。一切皆资源：某个工具、数据集、技术、配置或者某个相互依赖的特性。
·信息：希望发现什么信息呢？发现系统功能特性是否如期实现，发现系统安全性、系统性能、可靠性、兼容性和可用性等是否满足设计要求。
一个优质探测章程能提供方向，同时又不会过度地细化了测试行为。反过来看，探测章程若是太过宽泛也有风险，可能无法提供足够的关注。如果目标太大，你就很难分辨自己是否已经完成了探索。一个优质探测章程即是一个提示信号：它指出了灵感之源，又避免了对行动或结果做出事无巨细的规定。
以探测输入框是否存在漏洞为例：
目标：探索输入框
资源：使用SQL注入和跨站脚本攻击等资源
信息：发现系统安全漏洞信息
在会话过程中运用SQL注入和跨站脚本攻击方法在输入框输入内容，观察测试结果，迭代测试内容。从上面的测试章程可以看到，需要具体使用什么sql语句注入和什么跨站脚本攻击，而是提供了某一个方向或者灵感，剩下的工作需要你自己去探索和尝试。
工作中应该如何挖掘探索性测试的点
为了大家能找到有价值的探索性测试点，这里帮大家归纳几个可以寻找测试点的思路。
1) 需求评审：挖掘探索性测试点的理想时机
2) 有意义的变量：在一个软件/系统中，会存在很多变量，而这些变量是可以作为我们探索的点，下面列出需要注意的变量。
可计数的东西(边界值)：比如：用户登录次数、操作次数、存储文件的数量等，通常可以用一些特别的数字作为探索点：0，1，多，过多，过少。
格式：在程序中的很多东西都有格式，比如：日期、邮寄地址、文件路径、URL、文件内容、信息等等。而这些格式都可以被改变，来进行探索。
大小：在程序中文件是有大小的，比如：图片、配置文件、上传的各种文件。
深度：在程序中任何带有层级的东西都有深度，比较常见的有XML配置文件、带括号的运算操作、程序中的循环。
时间点、频率和持续时间：在程序中频率和持续时间，是比较容易发现问题的变量因素，比如：你用monkey对某个app做稳定性压力测试、快速的滑动某个页面有可能造成crash，或者你可以试试，让你的程序运行一晚上或者更长时间来验证问题。
输入和导航: 比如：你在输入的时候可以复制粘贴，也可以直接输入；在关闭弹窗时，你可以点击屏幕上的按钮，也可以使用快捷键，这些都是变量。
4、探索性测试的价值
4.1、探索性测试可以用来找到深层次的BUG。
因为探索性测试人员是优秀的观察者，他们观察不正常和不期望的结果，并进行认真的思考，这种状态和按部就班的执行用例是不一样的，因此，它更容易发现一些隐藏的很深的问题。
4.2、探索性测试可以加深测试人员对被测系统的了解。
探索性测试强调对被测试对象的学习，并且是在测试过程中的学习，并在此基础上设计测试，因此，它使测试人员更容易深入的理解被测系统。
探索式测试是以用户的角度来测试，它为传统的结构化测试（即从底层开始测试）做了补充以保护频繁迭代的用户体验。这意味着探索式测试不仅关注系统设计是否良好，还关注用户体验因此它更容易发现比结构测试更严重的缺陷。
探索式测试正在被越来越多的被应用于用户体验测试。它通常与传统结构化测试形成对比，后者仅侧重于系统逻辑验证（即是否满足要求/用户故事中概述的验收标准）。结构化测试保障已知风险而探索式测试主要侧重于分析潜在风险
虽然不用事先创建测试用例，但是测试人员通过发散性的思维去思考每个模块、每一步甚至每个按钮可能会出现的缺陷问题，可以让测试人员的时间和精力更多地集中在创造性地思维上，发现更多隐藏的缺陷。
5、探索性测试的误区
5.1、不要将探索性测试和随机测试混淆。
探索性测试不是在键盘前坐下并敲击，没有熟练技能，不会认真思考的“黑盒”测试人员所做的并不是探索性测试，一个合格的探索性测试人员需要认真思考和分析结果，并且在探索测试的过程中做记录。
5.2、不要将探索性测试和回归测试混淆。
探索性测试更注重的是思考和学习，不断发现新的问题，而版本的回归测试，是对原有的功能的保证，为持续迭代构筑安全网。重复的功能回归测试应该尽量用自动化的方式来完成，这样，才有足够的人力来进行探索性测试。
5.3、探索性测试不能用来评估软件质量。
尽管探索性测试是一种有效的测试方法，但是它不意味着是一种全面覆盖的测试方法。如果你要评估测试是否全面，可能你需要其他的手段。
三本探索测试方面的书
1) Elisabeth Hendrickson的《探索吧，深入理解探索式软件测试》
《探索式测试之路》和《探索软件测试》
参考连接
http://www.cnblogs.com/reach296/
https://zhuanlan.zhihu.com/p/68097024
网友评论