1.场景和探索
基于场景的探索式测试背后的想法是，就像探险家们在穿过荒野或其它不熟悉的地域时需要使用地图，这里使用的是设计好的场景。测试场景描述了基本的功能，探索则增加了尽量多的变化。
有价值的场景会做下面列出的一件或多件事情：
a）讲述用户故事：记录用户使用软件的动机、目的以及具体动作，比如：用户输入他的银行信息
b）描述需求：需求描述了软件具有的功能，描述这些需求的场景应该涉及如何使用产品来执行这些功能。
c）演示产品功能：演示产品功能的场景通常非常具体和明确。
d）演示集成场景：与其他应用程序相集成的产品通常定义了功能集成后的场景或端对端的场景。
e）描述设置和安装：安装说明描述了初始安装过程、安装和配置或者其它一些管理任务。
f）描述警告和出错情形：描述故障排除和维护过程的文档可以用来创建非常好的场景。
2.使用基于场景的探索式测试
真正的用户很少局限于按照场景的描述来使用软件，用户可能随意增加或减少步骤来改变场景。
3.通过场景操作引入变化
场景操作（scenario operator）的构想是对场景的步骤加以操作，来给场景注入变化。当我们对现有场景进行场景操作时，会得到一个新的场景，我们称之为衍生场景（derived scenario）。
1）插入步骤
增加的步骤可以是以下类型：
a）增加更多数据：比如只要10条数据，但加入20条数据
b）使用附加输入：比如需要输入一系列值时，可以看看是否能够给出一些没有被提到的额外输入值
c）访问新的界面：当要求调用某些屏幕或对话框时，Tester应该找到其他相关的一些屏幕或对话框。
2）删除步骤
测试人员可以使用递进的方式重复应用这个场景操作，每次只删除一个步骤。在此过程中，每减少一个步骤，场景都在被测软件上执行一次，直到获得一个最短的测试用例，然后循环结束。
3）替换步骤
如果场景中某些步骤可以有多种方法完成，就可以用替换步骤的场景操作来修改这个场景。比如，购买商品时，可以使用键盘快捷键而不是鼠标来操作。
4）重复步骤
重复步骤的场景操作通过重复单独的步骤或重复一组步骤来改变这个顺序，以创建额外的变化。我们可以测试新的代码路劲，发现那些可能与数据初始化相关的缺陷。比如，查看余额->支付->存款->退出登录，我们可以查看余额->支付->查看余额->支付。
5）替换数据
这里的思路是理解应用程序连接和使用的数据源，并确保它们之间的交互是稳定可靠的。测试人员需要知道与应用程序相关的数据源并创建各种各样的变化。
6）替换环境
a）替换硬件
改变环境的最容易方法是改变被测应用程序所运行的硬件。
b）替换容器
如果被测程序运行在所谓的容器应用程序中（如浏览器），那么需要测试在用户有可能使用的所有主要容器中运行。
c）替换版本
前面提到的容器都有过去的版本，需要测试被测应用在老版本的容器上运行得如何。
d）修改本地设置
如果应用程序使用cookie或注册表，那测试人员应该修改浏览器设置或注册表设置来增加测试。
使用上述任何操作来创建衍生场景时，都会尽量使它接近原始场景。
上篇到此结束，下表整理了场景中引入变化的方法，下篇从第4小结开始~
