探索式软件测试—Exploratory Software Testing

最近找到去年上半年看过一本关于测试方面书籍的总结笔记，一直放在我的个人U盘里，当时是用Xmind记录的，现在重新整理下分享给大家了！

James A.Whittaker [美] 詹姆斯·惠特克（软件测试领域绝对的大师）著作《Exploratory Software Testing》，中文名《探索式软件测试》，记得当时被这本书深深吸引啦（我不知道有多少做测试的小伙伴看过这本书）！感觉是测试方面一本必不可少的书籍，瞬间感觉测试的魅力！废话不多说，直接来干货，希望可以给对探索式测试喜欢或者感兴趣的小伙伴一点帮助！

测试人员进行测试时必须回答如下的问题。
(1)软件运行时的表现是否符合设计预期？
(2)用户为了某个功能而购买了软件，可是该软件是否实现了这个功能？
(3)软件运行时，是否足够快、足够安全、足够稳定，等等？

从许多方面来讲，测试的目的就是在这次测试中尽最大努力，同时确保下次可以做得更好。恰好探索式测试法可以提供很好的指导。

主要有两种指导方法，它们都可以帮助测试人员做具体决策。一种称为局部探索式测试法，它辅助测试人员在测试过程中即时作出决定。另一各称为全局探索式测试法，它用于帮助测试人员设计整体测试计划和测试策略。
如果把探索式测试和实质和使用脚本的手工测试合并起来，可以得到第三种探索式测试法，即混合探索测试技术。下面将分三部分来说明：

一、局部探索式测试法(exploratoy testing in the small)

此方法辅助测试人员在测试过程中即时作出决定。测试人员不需要知道很多信息就可以完成某些测试，比如决定文本框的输入值，如何解释错误消息，如何理解前一次后一次输入值之间的关系。

解决测试人员很多细节问题，它并不适合建立一个完整的测试架构，也不应该用于测试用例的整个设计过程。

主要关注下面五个方面：

1、用户输入  输入指的是由环境产生的一种刺激，该刺激导致被测试的应用程序有所响应。
                  测试包括合法输入和非法输入、输入筛选器、输入检查、异常处理代码、默认输入或用户提供的输入、使用输出指导输入选择。

2、状态  软件的一个状态就是状态空间中的一个点，它由所有内部数据结构的取值来唯一确定。

应用程序和其运行环境进行交互和接收到的所有输入导致软件状态发生变化。测试人员就是测试这些状态变化的情况。测试其是否正确更新了自身的当前状态？是不是进入了一些它不应该进入的状态？
            输入和状态之间的关系相当关键，在局部探索式测试法建议如下方式：
           1）使用状态信息来帮助寻找相关的输入
           2）使用状态信息来辨识重要的输入序列

3、代码路径  一条代码路径就是一连串的代码语句，它起始于软件开始运行的语句，终止于一条特定的语句，往往就是那条代表软件运行结束的语句。

测试人员必须明确知道程序里可能有哪些分支，并理解哪些输入会导致软件走这条分支而不另一条。

4、用户数据  如果预期软件需要存取海量的数据存储，比如一个数据库或大批量的用户文件，就需要在测试环境中设置一个数据存储。且该数据应该和软件真实用户使用的数据尽量一致。

5、运行环境  就是使用的操作系统和它的当前配置，还包括运行在同一操作系统上会和被测试软件进行交互的其他一些应用程序，包括会间接或直接影响被测软件本身或影响被测软件运行的任何驱动程序、代码、文件、设置等，还包括软件当前连接的网络情况、网络的可用带宽、性能等。

二、全局探索式测试法(exploratory testing in the large)

此方法用于帮助测试人员设计整体测试计划和测试策略。帮助测试人员在全局方面所必须做出的各种决定，比如在考虑特性交互、数据流以及在应用程序的用户界面上如何选择不同路径完成某些实际功能时。不再考察在单个输入面板上充当中间用途的原子输入，转而讨论那些可以帮助测试达到更重要目的的输入。实际上需要我们在开始就做出一个全局目标，用于指导以后的测试过程。使用全局探索式测试法，做出的决定一仅仅影响单个的对话框或者单个用户界面，它的范围涉及到软件的全局。不仅仅是确定如何测试某个单一功能，而是确定了如何对软件进行探索式测试的整体方向。

主要参考于漫游测试，漫游测试法为测试提供了一个构架，它可以帮助测试人员创建出比使用自由发挥的方式更有趣、也更有针对性的用户场景。它也为测试人员设定了一个目标，引导他们尝试更有趣和复杂的使用路径。漫游测试既能帮助测试人员思考如何测试应用程序，又能帮助他们组织实际的测试。当然这一系列的测试法可以编成一张测试核对表，这样可以避免测试人员遗漏某种测试类型，也可以帮助测试人员把应用程序的功能和适合这些功能的测试技术相匹配。

此外，这些测试法还可以帮助测试人员做出无数的决定，如何决定测试路径，如何选择输入值，使用哪些参数进行测试。在无数的决定中，对比选择不同的测试法，体会其精髓。这样算得上是真正意义上的测试指南。

根据漫游测试把软件不同区域类型，下面就不同区的相应测试一一说明：

1、商业区测试类型  侧重测试产品的卖点特性，并指导测试人员如何对这些特性的软件代码路径进行测试。有如下测试法：

1）指南测试法  要求测试人员通过阅读用户手册并严格遵照手册的建议执行操作。

2）卖点测试法  测试人员应该观摩那些销售演示，观看销售录像并跟着销售人员一起拜访客户。按照产品演示的步骤自己来执行一遍，并看看有没有发生问题。

3）地标测试法  测试人员提前确定那些关键的软件软性，就是这里的地标，在选择完地标后，需要确定它们的前后顺序，然后从一个地标执行到另一个地标来探索应用程序，直到访问了列表中的所有地标。

4）极限测试法  测试人员采用的途径是向软件提出很多难以回答的问题。比如如何使软件发挥到最大程度？哪个特性会使软件运行到其设计极限？

5）快递测试法  测试人员专注数据。应该确认那些被存储起来的输入数据并“跟随”它们走遍软件。

6）深夜测试法  测试人员关注主要特性外的代码运行情况，如各种维护任务等、应该程序自动做的些事情。变种的有清晨测试法，目的是测试软件的启动过程和脚本。

7）遍历测试法  测试人员通过选定一个目标，然后使用可以发现的最短路径来访问目标包含的所有对象。

2、历史区测试类型  主要针对老的功能和缺陷修复代码。

1）恶邻测试法  随着测试的深入，发现和报告越来越多的缺陷后，就可以把缺陷数目产品特性联系起来，从而可以跟踪究竟在哪些地方会出现产品的缺陷。

2）博物馆测试法  那些老代码或者接受重新修改，或者是没有被改动就放到新环境中运行，很容易发生失效的情况。故应该也要测试遗留代码和老的可执行文件。

3）上一版测试法  如果当前产品构造是对先前版本的更新，很重要的一点就是必须运行先前版本上支持的所有场景和测试用例。可以可验证用户已熟悉的功能在新产品上依然可行。如果新版本重新实现或者删除了一些功能，测试人员应该选择新版本定义方法来输入数据和使用软件。仔细检查那些在新版本中无法再运行的测试用例，以确保产品没有遗漏必需的功能。

3、娱乐区测试类型  这类测试帮助测试人员测试那些辅助特性，而不是主线特性，并确保这两种特性能够实用而又有意义地结合在一起。

1）配角测试法  鼓励测试人员专注于某些不是用户主要使用的特性，但是会和主要特性一同出现在显示器上，它们越紧邻主要功能，越容易被人注意，所以必须给予重视。

2）深巷测试法  如果测试部门跟踪了代码的覆盖率，这个测试法要求测试人员想办法去测试那些还没有被没测到的代码。变种混合测试法，就是试着把最流行和最不流行的特性放在一起混着测。

3）通宵测试法  测试人员会让程序一直保持运行，而不去关闭它。即连续不断地使用某些特性或者将文件一直保持在打开的状态。

4、旅游区测试类型  关心的是快速访问软件的各种功能。

1）收藏家测试法  建议测试收集软件的输出，收集得越多越好。应该确保能观察到软件能生成的任何一个输出。比如对于文本处理器，要确保它能打印、拼写检查、格式化文本等。

2）长路径测试法  就是测试离应用程序开始点尽可能远的特性。比如哪个特性需要点击N次才能被用到？选择那个特性，一路点击过去，然后测试它。这里的主要指导思想是到达目的地之前尽量多地在应用程序中穿行。

3）超模测试法  重点不是在功能或测试功能间真正的相互作用，而只是测试界面。注意观察界面上各个元素。比如它们有没有被正确地绘制出来？性能是否良好？变化界面时，刷新情况如何？图形界面的按钮和控件与期房值相符合？

4）测一送一测试法  测试同时运行同一应用程序多个拷贝的情况。即测试时运行一个应用程序，然后运行该程序的另外一个拷贝，然后再运行一个拷贝。

5）苏格兰酒吧测试法  适用于大规模的复杂应用程序。对于程序某些地方，测试人员需要事先知道如何看到他们。可以找到用户组并参与他们的讨论，读产业博客，花大量时间深入了解待测的应用程序。

5、旅馆区测试类型 测试人员放过那些主要的和最受欢迎的功能，而去测试一些经常被忽视的或者在测试计划中较少描述的次要及辅助功能。

1）取消测试法  就是启动操作然后停止它。比如打印文件并在文件打印完成之前就取消打印。可对任何提供取消选择的功能或者需要较长时间才能完成的功能做同样的操作。至少应该确信被取消的操作可以再次执行并成功结束。

2）懒汉测试法  测试人员做尽量少的实际工作，就意味着软件接受所有默认值……关注软件是否对默认值进行了处理，是否运行处理空白输入的代码。

6、破旧区测试类型

1）破坏测试法  测试人员试图利用每个可能的机会暗中破坏应用程序。a.强迫软件做一些操作b.掌握软件成功完成操作必须使用的资源c.在不同程序上移除那些资源或者限制使用那些资源。比如增加或者删除文件，改变文件权限，断开网线，在后台运行其他应用程序，把要测试的应用程序布署在有问题的机器上等。

2）反叛测试法  要求输入最不可能的数据，或者已知的恶意输入。如果真正的用户输入字母a，那么使用反叛测试人员就永远不输入a，取而代之的是去找些没意义的输入值。

　　　　　　有三个方法可实现反叛行为：
　　　　　　a.逆向测试法 每次输入那些最不可能的数据 为了测试应用程序的错误处理能力。
　　　  　　 b.歹徒测试法 输入一些不应该出现的数据 测试人员在测试中违反输入会导致很多错误消息，输入突破限制的数据
　　　　　　c.错序测试法 要求测试人员以错误的顺序做事情。

3)强迫症测试法  强迫测试人员一遍又一遍地个输入同样的数据，反反得得地执行相同的操作。比如在屏幕上输入一些数据，然后马上回来再输入一次，看看开发人员是否编写了错误处理程序。

三、混合探索式测试技术

探索式测试可以和场景测试结合起来，帮助测试人员为给定场景引入大大小小的各种变化。如果场景描述的是用户要采取的某些特定动作，下面的技术就可以用来改变这些动作的顺序，并从场景中派生出衍生场景，用于测试不同状态和不同代码路径。此技术主要使用基于场景的探索式测试，这种形式的探索式测试采用了给场景注入变化的方法。通过有系统地考虑输入选择、数据使用和环境条件，一个场景可以演变出许多测试用例。使用了两个主要技术：场景操作和漫游测试。

1、通过场景操作引入变化  为了使测试人员以更系统更策略的方式考虑替换路径，引入了场景操作，就是对场景的步骤加以操作，来给场景注入变化。

1）插入步骤  给场景增加额外的步骤可使它们更加多样化，从而测试更多的功能。

　　　　　　可以用到发下这些类型
　　　　　　a.增加更多数据
　　　　　　b.使用附加输入
　　　　　　c.访问新的界面
　　　　　　注意这些步骤最终都需要测试人员返回到原始场景。我们的目的是加强场景，而不是彻底改变场景的基本目标。

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

3）替换步骤  如果场景中某些步骤可以有多种方法完成，就可以用替换步骤的场景操作来修改这个场景。实际上是前面两个操作的组合，就是先删除步骤，然后再插入步骤。故测试人员必须研究其他替代的方法来执行场景中每个步骤或动作。

4）重复步骤  场景经常包含非常明确的动作顺序。重复步骤的场景操作通过重复单独的步骤或者重复一组步骤来改变这个顺序，以创建额外的变化。通过重复和重新安排步骤，我们可以测试新的代码路径，发现那些可能与数据初始化相关的缺陷。

5）替换数据  理解应用程序连接和使用的数据源，并确保它们之前的交互是稳定可靠的。比如通过读取、修改或者操作数据来代替默认的数据库来测试当前场景。比如如果数据源的现有记录数增加了十倍，会发生什么情况？

6）替换环境  基本要点是测试场景本身并不改变，只是在软件上执行这些场景时，所使用的系统发生了改变。

　　　　　　需要考虑的因素：
　　　　　　a.替换硬件 改变实测应用程序所运行的硬件。可以充分利用虚拟机的技术来完成这项任务。
　　　　　　b.替换容器 需要确保测试场景可以在用户有可能使用的所有主要容器中运行，如不同浏览器。
　　　　　　c.替换版本 被测应用程序在老版本上运行得怎么样？
　　　　　　d.修改本地设置 测试应用程序是否使用cookie或者在用户机器上写文件吗？它使用本地注册表吗？如果用户修改浏览器设置来限制这类活动会怎样？如果用户直接改变应用程序的注册表设置会怎样？作为测试人员，最好能在应用程序发布前知道它如何处理上述情况。

2、通过漫游测试引入变化  场景操作侧重于场景中小的、逐渐增加的变化以及可有可无的步骤，而漫游实际上可以创建出相当长的和范围更广的衍生场景。

1）卖点测试法  模拟用户已有的工作习惯，在原始场景中加入一些新功能，让用户使用过程通过学习某个功能，掌握它，然后随着对应用程序的熟悉而逐渐转移到新功能上。

2）地标测试法  从场景开始并从场景中选取特定功能的地标，然后随机打乱这些地标的顺序，这样得到的场景就和原始场景不同了。如有必要，重复这个过程，不断用新地标顺序来运行测试。

3）极限测试法  检查并修改场景以使软件更加努力地工作，即挑战软件，向它提困难的问题。如很长的字符串输入会产生问题吗？

4）深巷测试法  关注使用最不可能用到的或者最没有用的功能。

5）强迫症测试法  重复场景中的每个步骤两次或者三次。比如在软件中四处移动数据历来可以有效的找到重要缺陷。

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

7）破坏测试法  在运行场景测试时，在资源调用处进行破坏活动。如场景要求在网络上传输数据，可以执行步骤之前或者之中拔掉网线等。

8）收藏家测试  执行场景和衍生场景时用文档记录下所观测到的每个输出。

9）超模测试法  运行场景时只关注界面。确保所有元素都在它们应该在的位置上，界面应该设计合理，尤其要注意可用性问题。

10）配角测试法  测试人员不是执行测试脚本描述的功能，而是找到最近的邻近功能来执行。

11）取消测试法  不但充分利用取消按钮（运行场景时只要看到它就点击），而且执行了启动和停止功能。如在开始执行某些功能时，通过取消或者Esc来取消。

12）混票测试法  从一个场景跳到另一个，从而把两个或者更多场景结合为一个具有混合目的的场景。检查所有的场景并找出那些通用数据，侧重于通用功能。

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

总结：凡是研究过探索式软件测试的测试人员绝对会发现这是种可以给你们提供更多测试思路，可以找到软件更多缺陷，从而更确保软件的正确性、稳定性等等。当然由于其中思路方法之多，也绝不是看一两下就可以体会的，需要测试人员多次阅读并在实践中努力尝试其中的方法，不求全部用到，只用到其中一部分，我想肯定会给自己带来很大的感受。正如大师所言，软件测试是必不可少但有难度的事，望所有测试人员任重道远！