探索性测试01-什么是探索性测试

一、什么是探索性测试

探索性测试，最早是由测试专家 Cem Kaner 博士在 1983 年提出的，并受到当时语境驱动的软件测试学派的支持。后来，Cem Kaner 博士在佛罗里达工学院的同事 James A. Whittaker，凭借着在微软和谷歌担任测试架构师和测试总监的经验积累，撰写了最早的探索式测试书籍《Exploratory Software Testing》，扩展了探索式测试的概念和方法。

常用于质量管理的戴明环（PDCA）是按照Plan(计划)、Do(执行)、Check(检查)和Act(处理)的顺序，循环不止地进行下去的一种科学程序。一个循环完了，解决一些问题，未解决的问题进入下一个循环，整个过程是阶梯式上升的。

探索性测试将戴明环方法使用到了极致，它强调将测试相关学习、测试设计、测试执行和测试结果解读作为相互支持的活动，并行执行。其思维模型CPIE包括4个阶段：

※ Collation（整理）：首先是测试相关学习，需要我们收集和整理被测产品的信息，并了解和理解它们。通常在这个阶段，我会翻开需求文档、方案文档看看，或者搜索之前的bug清单寻找思路

※ Prioritization（排序）：进行测试设计，确定所有测试任务的优先级

※ Investigation（调查）：对即将执行的测试任务进行仔细的分析并确定测试输入和预期输出，也属于测试设计的一部分

※ Experimentation（实验）：重点在测试执行和对测试结果的验证，验证我们的预期是否正确，检查我们在整理阶段获取到的信息是否正确。根据实验结果，测试人员将收集更多的信息，并调整测试任务的优先级。以此不断达到收集反馈、调整测试、优化价值的效果。

所以与其说探索性测试是一种测试方法，不如说它是一种基于"实践->反馈->实践"的思维方式。

二、探索性测试的典型方法

根据不同产品的特性，可以将产品功能测试分成三个层次：单一功能特性测试、交互特性测试和系统交互测试。针对每个层次，探索性测试的方法可以简单的概括为：局部探索性测试方法、全局探索性测试法和混合探索性测试法。

1、局部探索性测试方法

我们首先会对软件的单一功能进行比较细致的探索式测试。“探索”的过程主要是基于功能需求以及非功能性需求进行扩展和延伸。

比如以软件系统的用户登录功能为例，作为探索式测试人员，首先应该站在最终用户的角度去理解和使用登录功能。为此，探索式测试人员需要分析出用户登录功能的所有原子输入项。假定原子输入项只有用户名、密码和登录按钮。接着组合这些原子输入项构成最基本典型的测试场景。

再比如，用真实合法的用户名以及密码完成登录就是一个非常基本典型的场景，如果该场景能够成功登录，就可以切换到下一个；如果该场景不能够成功登录，就需要去“探索”为什么没能登录成功，比如你可能会怀疑是否是因为用户名或者密码是区分大小写的，又或者是不是因为你多次错误的尝试而导致的。

基于你的怀疑，进一步去设计新的测试用例来验证你的猜测。总之，通过以上这样的“探索”过程，你将测试学习、测试设计、测试执行和测试结果评估串联成了一个快速迭代的过程，并在你脑海中快速建立了登录功能的详细模型。

2、全局探索性测试

以用户登录功能为例，在系统交互的探索式测试中，就不仅要考虑单一的登录功能了，而是要考虑用户登录与系统其他功能相结合的场景。

比如，你可以尝试不登录直接访问登录后的路径去观察系统的行为；再比如，你可以尝试不登录就去查看订单状态的操作等等。这些组合场景的设计主要取决于你想要验证，或者说想要“探索”的系统功能。很多时候这些灵感来自于你之前对系统的探索而取得的系统认识，同时你的技术直觉也在此扮演了重要角色。

漫游测试模型	方法	测试策略
商业区	指南测试	1、严格按照用户手册的建议进行操作； 2、以完全不了解系统视角严格按照手册进行操作； 3、将多分指南（需求、概要设计、帮助手册）放在一起，边理解边测试
	卖点测试	1、了解销售对客户的演示，从中挖掘用户关心的内容作为测试点 2、一团建用户不同身份关注每个用户最吸引人的特性功能
	地标测试	1、将指南测试法及卖点测试法中的标记定义为一个路标
	极限测试	1、尽可能寻找软件边界； 2、在软件允许的范围内，找一些不一定有意义的测试，或者用户很少这样操作，但是软件并不禁止的操作
	快递测试	1、通过消息流转或者类似于debug过程，来定点这条路径中的关键数据节点流转是否正确 2、确认哪些被存储起来的输入数据并”跟随“它们走遍整个软件
	深夜测试	1、关注数据备份归档、维护监控任务的运行等等 2、在拥挤的时刻加入功能测试 3、关注软件启动过程和脚本
	遍历测试	1、将程序路径绘制出来，采用最短路径来访问这些目标对象，从而遍历所有的路径点
历史区	恶邻测试法	1、复杂的功能要多测，bug多的区域要多测
	博物馆测试法	1、关注软件中的遗留代码是否有过改动，有改动就需要测试
	上一版本测试法	1、如果当前产品是对原有产品的重构或更新，则需要验证所有场景
娱乐区	配角测试法	1、关注某些辅助的特性，并将这些特性与主流业务特性放在一个视角来测试
	深巷测试法	1、关注最不可能用到或者那些不吸引人的用户特性
	通宵测试法	1、长期稳定性测试
旅游区	收藏家测试法	1、尽可能分析梳理出软件的每条测试路径，将输出结果记录下来，整理成checklist
	长路径测试法	1、寻找隐藏最深的的产品界面，并观察经过的每一个界面
	超模测试法	1、观察界面的设置、按钮是否好看、易用 2、元素是否被正确绘制、颜色风格是否一致、界面切换是否清晰
	测一送一法	1、不同程序同时打开一个文件，或者多个客户端同时操作一批数据
	苏格兰酒吧测试法	1、找到用户组并参与讨论，从中获取测试灵感 2、阅读产业博客，深入了解待测应用程序，挖掘测试场景
旅馆区	取消测试法	1、刚一启动就停止 2、启动一个耗时操作后，立即启动另一个耗时操作，以此来检测应用程序的自我清除能力
	懒汉测试法	1、输入保持默认值、空白输入
破旧区	破坏测试法	1、读取文件数据时破坏、删除或改变此文件权限 2、传输之前或传输中拔掉网线、断开网络连接
	反叛测试法	1、利用反向思维，用一些违反规则的数据进行测试
	强迫症测试法	1、重复、复制、粘贴一些数据并进行操作

3、混合探索性测试

混合探索性测试就是将探索性测试与传统的基于场景的测试方法相结合，通过引入变化达到系统交互测试的目的。

类型	方法	测试策略
通过场景操作引入变化	插入步骤	1、增加更多数据 当场景要求增加10条数据库记录时，测试人员可以提高到20或30条甚至更多记录，或者当场景要求创建一个新账号，可给那个账号提供超过场景要求的信息。 2、使用附加输入 这里的想法是了解哪些附加功能和场景提到的功能有关联，然后增加输入来测试这些新的附加功能。 3、访问新的界面 当场景要求测试人员调用某些屏幕或对话框时，测试人员应该找到其他相关的一些屏幕或对话框，并把它们加入到场景中。
	删除步骤	使用递进的方式重复应用这个场景操作，每次只删除一个步骤，每减少一个步骤，场景都在被测软件上执行一次，直到获得一个最短的测试用例，然后循环结束。
	替换步骤	当被测软件提供了两种选项，则可通过创建衍生场景的方式来测试第二种选择。
	重复步骤	通过重复和重新安排步骤，可以测试新的代码路径，发现那些可能与数据初始化相关的缺陷。
	替换数据	例如，如果测试可以使用真实的数据库则可代替默认是数据库；模拟数据源停止工作或者无法连接的情况；数据源的记录增加等情况。
	替换环境	1、替换硬件：使用用户可能用到的不同类型硬件。 2、替换容器：确保测试场景在用户可能使用的所有主要容器中正常运行。 3、替换版本：所有前面提到的容器都有过去的版本，测试版本兼容性。 4、修改本地设置：浏览器本地设置、本地注册表修改等。