探索式测试-第五章-读书笔记

场景和探索

本章将展示如何把探索式测试的思维方法与传统的基于场景的测试方法结合起来。这种混合技术充分利用了探索式测试的指导思想，它打破了脚本测试法所固有的那种死板，提供了更多的灵活性。

因为用户不可能只局限于按我们设想的方式使用软件，所以应该扩展我们的测试以覆盖被描述场景的各种变化情况。

基于场景的探索式测试能够覆盖单一场景测试所无法覆盖的情况，并能更准确地模拟真正用户。真实的用户使用软件时往往和我们设想的主要场景有偏离，毕竟我们的产品确实允许各种各样的使用方式。

基于场景的探索式测试背后的想法是，就像探险家们在穿过荒野或者穿越其他不熟悉的地域时需要使用地图，这里就使用现有设计好的场景。场景就像地图一样，是关于在测试时该做什么事情的一般性指导建议，告诉我们选择哪些输入，执行哪些代码路径，但这些又不是完全绝对的。我们的地图不是想让我们找到最短的路径，而是帮我们找到更多的路径。我们测的路径越多越好，这样他让我们有更多的理由相信，在软件被交付到那些不按常规操作的用户手里后也能可靠地运行。

测试场景本身经常来自于非测试部门。我们可以从设计和开发过程中收集场景。任何一个场景或所有这些场景都可以作为探索测试的起点。

通常来说，有价值的场景会做下面列出来的一件或多件事情。

1、讲述用户故事：通常记录用户使用软件的动机、目的以及具体动作。

2、描述需求：应该涉及如何使用产品来执行这些功用。

3、演示产品功能：通常是非常具体和明确的，经常出现在在线帮助或为用户准备的书面说明书中。

4、演示集成场景：通常定义了功能集成后的场景或端对端的场景。

5、描述设置和安装：安装说明描述了初始安装过程，安装和配置，账号创建或者其他一些管理任务，可选安装标识的设定以及定制功能。这些都可以轻松用作探索式测试的场景。

6、描述警告和出错情形：描述故障排除和维护过程的文档可以用来创建非常好的场景。

探索型测试人员应尽力确保从所有这些分类中收集尽可能多的场景，然后的任务就是根据这些场景加入合适的变化。

使用基于场景的探索式测试

场景测试之所以有效是因为它模拟了真正用户的行为，因此能发现那些已经逃过其他测试方法却可能给实际用户造成麻烦的伤害。通过有系统地考虑输入选择、数据使用和环境条件，一个场景可以演变出许多测试用例。这个过程使用了如下两个主要的故事：场景操作和漫游测试。

通过场景操作引入变化

探索式测试可以和场景测试结合起来，帮助测试人员为给定场景引入大大小小的各种变化。场景操作的构想是对场景的步骤加以操作，来给场景注入变化。我们对现有场景进行场景操作时，会得到一个新的场景。

插入步骤

给场景插入一个或多个步骤能增加软件失败的机会。增加的步骤可以是如下类型。

增加更多数据：当场景需要10条数据库记录时，测试人员应该把它提高到20或者30个甚至更多记录。

使用附加输入：当场景要求测试人员输入一系列值时，测试人员可以看看是否能够给出一些没有被提到的额外输入值。

访问新的页面：当场景要求测试人员调用某些屏幕或对话框时，测试人员应该找到其他相关的一些屏幕或对话框，并把它们加入到场景中。

这些步骤都要求测试人员返回到原始场景。我们的目的是加强场景，而不是彻底改变场景的基本目标。

删除步骤

我们可以去掉冗余和可选的步骤，这个操作的想法是使场景的步骤尽可能地减少。也许因此而衍生出的场景缺乏那些设置初始条件的步骤，这种场景可以用来测试应用程序是否可以识别出现在缺少信息或者缺乏一些从属功能。

替换步骤

如果场景中某些步骤可以有多种方法完成，就可以用替换步骤的场景操作来修改这个场景。替换步骤实际上是前面两个操作的组合，就是先删除步骤，然后再插入步骤。

重复步骤

场景经常包括非常明确的工作顺序。重复步骤的场景操作通过重复单独的步骤或重复一组步骤来改变这个顺序，以创建额外的变化。测试人员的任务是理解这些变化并创建适当的重复顺序。

替换数据

很多情况下，场景要求和数据库、数据文件或者其他本地或远程数据源相连接。这些场景会明确指出测试人员要执行的动作，例如以何种方式来读取、修改或操作数据。测试人员需要知道与应用程序相关的数据源并创建各种各样的变化。这里的思路是理解应用程序连接和使用的数据源，并确保他们之间的交互是稳定可靠的。

替换环境

软件在一个环境中可以成功地运行十亿次以上的测试，把它放到另一个环境却可能会全部失败。这个操作的基本要点是测试场景本身并不改变，只是在软件上执行这些测试场景时，所使用的系统发生了改变。下面是需要考虑的因素。

替换硬件：改变环境最容易的方法是改变被测应用程序所运行的硬件。

替换容器：如果被测程序运行在所谓的容器应用程序中（如浏览器），我们需要确保测试场景可以在用户有可能使用的所有主要容器中运行。

替换版本：所有前面提高的容器都有过去的版本，它们依然占有一定的市场份额。

修改本地配置：修改注册表？修改浏览器设置？用户机器上写文件等，作为测试人员，最好能在应用程序发布前知道它如何处理上述情况。

使用上述任何操作来创建衍生场景时，我们都会尽量使它接近原始场景。如果操作过多或者操作使衍生场景与原始场景的差别巨大，通常没什么益处。

通过漫游测试引入变化

使用漫游测试则是另一种方法，想法很简单：测试人员查看脚本，找到需要测试人员做决定的地方或者找到可能产生逻辑分支的地方，先往完全完全不同的方向走，然后再返回到脚本描述的主要路径。

我喜欢用汽车旅游或者丛林中步行来类比这种方法。小的顺路游代表漫游，长的乘车过程代表执行场景。这是给场景注入变化的一项有用技术。

场景操作和漫游的关键不同是漫游通常比场景操作产生更长的顺路游。操作侧重于场景中小的、逐渐增加的变化以及可有可无的步骤，而漫游实际上可以创建出相当长的和范围更广的衍生场景。

卖点测试法

任何不在场景中的主要功能都能轻易地加入到场景中吗？如果是，加入一个或多个这样的新功能。许多用户都是通过学习某个功能，掌握它，然后随着对应用程序的熟悉而逐渐转移到新功能上。卖点测试法技术模拟了该使用模式。

地标测试法

从场景中选取特定的功能，然后随机打乱这些地标的顺序，这样得到的场景就和原始场景不同了。

极限测试法

挑战软件，向他提困难的问题。

深巷测试法

卖点测试法的一个变种，两者都建议我们为场景注入新的功能，但是深巷测试法建议的是使用最不可能用到的或最没用的功能。

强迫症测试法

重复场景中的每个步骤两次或三次，可以按自己的喜好来做。

通宵测试法

当测试场景可以被自动化或者使用录像回放时，最适合使用的是通宵测试法，只需要不断重复运行场景而不需退出被测应用程序。

破坏测试法

场景是破坏活动的绝好开始，场景测试时，在资源调用处进行破坏活动。

收藏家测试法

执行场景和衍生场景使用文档记录下所观测到的每个输出，甚至可以根据产生的输出数量来给场景打分。

超模测试法

运行场景时只关注界面。

配角测试法

我把这看成是邻居测试法，测试人员不是执行脚本的功能，而是找到最近的邻居功能来执行。记住，总是选择那些在某种意义上“最邻近的”选择。

取消测试法

不但充分利用了取消按钮，而且执行了启动和停止功能。

混票测试法

专门针对基于场景的测试，概念是有些人旅游开始时没有交钱报名，逐渐加入进来，融入旅游人群并假装一直在那里。

作为测试人员我们能这么做是因为两个场景都经过应用程序的同一部分，我们会跟随一个场景到那里，然后跟随另外的场景离开。

小结

静态场景测试和探索式测试并不冲突。场景可以代表探索式测试的一个绝佳起点，探索可以给场景加入宝贵的变化，否则场景将很有限。明智的测试人员会把这两种方法结合起来，以便更好地覆盖应用程序，得到更多的输入序列、代码路径和数据使用的变化。