在读了几篇《探索式测试》笔记类文章，发现对于书中的诸如“旅馆区测试类型”比喻，由于不理解前因后果，找不到关联性，有点云里雾里，遂重读原书，在原文章的基础上进行了自己的重新梳理，以及典型BUG举例，便于自己理解记忆。
个人觉得第3、4、5章是重点需要理解的地方，文后附 "软件戒律"也可以学习下。
参考文章：
【1】探索式测试整理 https://blog.csdn.net/zimingzim/article/details/82466413#comments_18326875
【2】书籍点评 James Whittaker – 探索式软件测试 (Exploratory Software Testing) https://testerhome.com/topics/11709

文章目录

    • 一、软件质量
      • 1.1 软件的魔力
      • 1.2 软件失效
      • 1.3 小结
    • 二、手工测试
      • 2.1 软件缺陷的根源
      • 2.2 权限预防和检测
      • 2.3 手工测试
      • 2.4 小结
    • 三、局部探索式测试法★
      • 3.1 用户输入
      • 3.2 状态
      • 3.3 代码路径
      • 3.4 用户数据
      • 3.5 运行环境
      • 3.6 小结
    • 四、全局探索式测试法★
      • 4.1 摘要
      • 4.2 目标
      • 4.3 旅游者比喻
      • 4.4 漫游测试
        • 4.4.1 商业区测试类型 （指南针、卖点、地标、极限、快递、深夜、遍历）
        • 4.4.2 历史区测试类型（恶邻、博物馆、上一版）
        • 4.4.3 娱乐区测试类型（配角、深巷、通宵）
        • 4.4.4 旅游区测试类型 （收藏家、长路径、超模、测一送一、苏格兰酒吧）
        • 4.4.5 旅馆区测试类（取消、懒汉）
        • 4.4.6 破旧区测试类型（破坏、反叛、强迫症）
      • 4.5 漫游测试法实战
      • 4.6 小结
    • 五、混合探索式测试法★
      • 5.1 场景和探索
      • 5.2 使用基于场景的探索式测试
        • 5.2.1 故事1：通过场景操作引入变化
        • 5.2.2 故事2：通过漫游测试引入变化
      • 5.3 小结
    • 六、实践中的探索式测试
      • 6.1 dynamics AX客户端的漫游(Nicole Haugen 的体会)
      • 6.2 利用漫游查找隐错(David GorenaElizondo 的体会)
      • 6.3 在windows mobile设备中的漫游实践 (Shawn Brown 的体会)
      • 6.4 windows没提播放器的漫游测试实践(Bola Agbonile 的体会)
      • 6.5 停车场测试法及在VS测试版的应用(Geoff Staneff 的体会)
      • 6.6 漫游测试中的测试规划和管理
      • 6.7 小结
    • 七、漫游与测试中的棘手问题
      • 7.1 漫无目的
      • 7.2 重复性
      • 7.3 暂时性
      • 7.4 单调性
      • 7.5 健忘性
      • 7.6 小结
    • 【附 软件诫律】

一、软件质量

1.1 软件的魔力

  • 未来50年，软件必将推动更多的发明创造软件的魔力

  • 在人类创造的所有产品中，软件出问题的可能性是其他所有产品无可匹敌的

  • 人类迫切需要软件来实现未来的梦想，但是在现实生活中，软件却又是最不可靠的一种产品

  • 软件对我们的未来至关重要，但目前软件故障率已达到让人触目惊心的程度

1.2 软件失效

  • 有些软件缺陷会使用户工作效率降低，软件缺陷还会给用户带来各种各样的不便，或者会让用户暗暗摇头

  • 软件缺陷是软件魔力上的瑕疵

  • 理解软件缺陷是如何产生的，熟悉查找软件缺陷的各种方法，从而充分兑现软件魔力的诺言

1.3 小结

  • 科学孕育了软件，给予它非凡的魔力，现在是通过软件魔力来创造新科学的时代了，我们需要这种魔力来解决世界上亟待解决的各类问题

  • 软件在其中都扮演着重要的角色，这就迫切需要尽可能地提高软件质量，过去的失败再也无法忍受

二、手工测试

2.1 软件缺陷的根源

  • 软件缺陷的根源来自于软件开发本身

  • 软件现在不是毫无缺陷的，将来多半也不会是

我们会讨论两种缺陷：程序员引入的缺陷和运行环境导致的缺陷

2.2 权限预防和检测

缺陷预防

缺陷检测

测试人员该怎么办呢？如果测试人员不能依靠开发人员的缺陷预防工具和自动化手段，他们还能希望于什么呢？唯一的答案就是手工测试

2.3 手工测试

2.3.1 概要

  • 手工测试，就是需要人来动手进行测试

  • 由人来进行手工测试，可以最大程度地发挥人的主观能动积极性，设计出真实的用户情况，在真实的用户环境中使用真实的用户数据，同时可以识别出那些显而易见的缺陷和那些比较难以觉察的缺陷

  • 如果想发现与应用程序业务逻辑相关的缺陷，手工测试是最理想的选择

  • 一直以来，软件产业在手工测试都没有很好地发展

2.3.2 手工测试中使用脚本

2.3.3 探索式测试

  • 局部探索式测试法

  • 全局探索式测试法

  • 同时使用探索式测试和脚本测试

2.4 小结

  • 从事手工探索式测试算得上是最有挑战性和最让人称心的一份工作

  • 长久以来，对探索式测试一直没有比较好的参考指南，只有那些摸索探索式测试法多年并从实践中掌握了经验教训的老手才真正地在使用它

  • 本模型关于探索式测试法的大量经验教训和真知灼见，希望可以更快更多地培养出精通该技术的人才，为软件产业提供高质量的软件测试，为开发高质量软件做一份贡献

  • 在测试软件时，必须全神贯注，决不能心不在焉。本模型帮助我们集中精力，全力以赴，使测试更彻底、更完整

三、局部探索式测试法★

3.1 用户输入

需要先了解用户输入的基本知识、合法输入和非法输入

  1. 输入筛选器（输入限制）

    第一，开发是否正确的实现了该功能？

    第二，是否可以绕过屏蔽器？或者当输入值进入系统后还可以修改？

  2. 输入检查

    测试必须仔细阅读每一条错误信息，检查该信息是否写错了，错误信息还可以透漏开发编程时的一些想法。

    输入检查和异常处理的区别：输入值检查提示的错误信息很精准，异常处理提示的错误信息比较笼统。

  3. 使用异常处理

    如果测试看到一个空乏的通用出错信息，建议测试再反复测试同一段函数，继续很用刚才引发异常的输入数据，或稍微修改一下，看看会不会导致出错。尝试运行其他一些要调用该函数的测试用例，看看会发生什么情况。

  4. 常规输入还是非常规输入

    所有和Ctrl、Alt、Esc按键组合的字符都算的上是特殊字符，需要在应用程序中测试；

    操作系统、编程语言、浏览器和运行时环境的特定保留词，如windows的COM1，输入保留此可能会崩溃。

  5. 默认输入或用户提供的输入

    输入空或者默认值

  6. 使用输出来指导输入选择

    把输出分为合法输出和非法输出，这里主要测合法输出。

    测试先确定用户希望程序什么输出结果，然后考察所有的用户场景，看看如何去生成期望的结果。

    举例：测试接口时，需要测试record_not_exists返回，可以通过删除本地文件、修改本地文件名称2种方式。

输入选择的复杂性只是测试人员在软件测试中最先遭遇的技术难题。不断地对软件进行输入后，就出现了软件状态的问题

3.2 状态

应用程序和其运行环境进行交互和接收到的所有输入导致软件状态发生变化。测试人员就是测试这些状态变化的情况。测试其是否正确更新了

自身的当前状态？是不是进入了一些它不应该进入的状态？

输入和状态之间的关系相当关键，在局部探索式测试法建议如下方式：

1）使用状态信息来帮助寻找相关的输入

​ 举例：录音暂停状态，什么输入可能会导致录音暂停，手动按下暂停，应用退至后台，来电、其他程序抢占麦克风等。

2）使用状态信息来辨识重要的输入序列

3.3 代码路径

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

举例：在if else的地方设计测试用例，覆盖多种条件分支

3.4 用户数据

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

需要考虑：如何模仿真实的用户数据，使用用户真实数据时，如何解决“隐私问题”。

3.5 运行环境

当软件被安装到一个崭新的却它从来没见过的环境中时，还可能会失效，这是因为环境本身就算是一种输入源，所以测试人员在产品发布之前必须尽量尝试各种各样地用户环境。

任何可以影响被测试软件行为的因素都是运行环境的一部分，在测试中都必须考虑到

运行环境包括：

  • 使用的操作系统 （如安卓的系统版本）

  • 系统当前配置 （如用户配置，权限通知管理等）

  • 和被测试软件进行交互的其他一些应用程序 （如OCR调用系统相机）

  • 间接或直接影响被测软件本身 或影响被测软件运行 的任何驱动程序、代码、文件、设置等 （如PC的硬件驱动、依赖开发环境、体验产品的注册表等）

  • 软件当前连接的网络情况、网络的可用带宽、性能等 （如手机代理、移动网络/wifi、限速）

3.6 小结

输入、代码路径、状态、被存储的数据和运行环境等，这里有太多太多的因素，而每种因素又 有太多的变化可能，这一切使得软件测试变得极其复杂，最终无论做了哪些测试，软件测试的复杂性都决定了我们所作的总是远远不够的。

探索式测试试图把制定计划、进行测试、重新制定计划等多个过程有机地结合起来，每次只前进一小步，但这 每一步都是由软件过去和当前的运行状况、软件在测试时表现出来的各种行为和软件运行时留下的种种蛛丝马迹来即时确定的。

测试本身很复杂，但是有效地利用探索式测试技术可以帮助我们驯服这匹桀骜不驯的烈马，从而发布一个高质量的软件产品

四、全局探索式测试法★

4.1 摘要

此方法用于帮助测试人员设计整体测试计划 和 测试策略。

帮助测试人员在全局方面所必须做出的各种决定，比如在考虑特性交互、数据流以及在应用程序的用户界面上如何选择不同路径完成某些实际功能时。不再考察在单个输入面板上充当中间用途的原子输入，转而讨论那些可以帮助测试达到更重要目的的输入。

实际上需要我们在开始就做出一个全局目标，用于指导以后的测试过程。使用全局探索式测试法，做出的决定一仅仅影响单个的对话框或者单个用户界面，它的范围涉及到软件的全局。不仅仅是确定如何测试某个单一功能，而是确定了如何对软件进行探索式测试的整体方向。

4.2 目标

漫游测试法为测试提供了一个构架，

它可以帮助测试人员创建出比使用自由发挥的方式更有趣、也更有针对性的用户场景；

它也为测试人员设定了一个目标，引导他们尝试更有趣和复杂的使用路径；

漫游测试既能帮助测试人员思考如何测试应用程序，又能帮助他们组织实际的测试。

当然这一系列的测试法可以编成一张测试核对表，这样可以避免测试人员遗漏某种测试类型，也可以帮助测试人员把应用程序的功能和适合这些功能的测试技术相匹配。

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

4.3 旅游者比喻

即使用上全世界所有的资金也不能保证可以测全软件的所有方面

旅游者的目的对实际策略的选用起着举足轻重的作用 作为测试人员，我们并不是经常能有机会在将来重新测试该应用程序，我们的第一次拜访很可能会成为唯—一次挖掘和探索应用程序的机会

我们负担不起漫无目的的游荡，因为这会导致错过重要功能和缺陷。我们必须使我们的每次访问都有收获

有组织有目标的旅游和自由风格漫无目的的闲逛紧密地结合起来

4.4 漫游测试

我们这里所说的特定测试通常要求把应用程序的多个特性和功能以崭新的方式组合起来，而且这种组合方式是那些严格以特性为基础的传统测试模式无法做到的

软件测试人员应该探索应用程序的运行路径，以不同的顺序执行许多特性。因此，在进行类比测试时，我们对旅游指南做了一些修改：

4.4.1 商业区测试类型 （指南针、卖点、地标、极限、快递、深夜、遍历）

对软件来说，商业区是指“在那里完成实际业务”，位于软件的启动及关闭代码之间，并包含用户要使用的软件特性和功能。“商业区”就是软件包装盒上描述的那些特性，还包括市场商业活动中演示的各种特性及实现代码。

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

1）指南针测试法

类比旅游手册，作者划定界限，新手在此范围内安排游玩，对软件而言是用户手册。

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

变种一：博客测试法，遵循第三方的建议来测试；

变种二：专家测试法，根据差评创建测试用例

变种三：竞争对手测试法，测试人员遵循专家或博客为竞争对手们提供的建议来测试

2）卖点测试法

比较好理解，旅游区的代表景点，如埃及金字塔，软件的卖点特性也是需要格外关注。

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

变种：质疑测试法：创建用户非常在意的测试用例

3）地标测试法

户外去某个目的地，使用指南针先断定一个地标，走过去用指南针确定下一个地标，如此反复，只要所有地标都在一个方向上，就能到达目的地。地标测试法在vs团队是最受欢迎且最有用的测试法。

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

4）极限测试法

作者举了一个自己在英国旅行的例子，团队中有个历史专家，经常问导游一些极限的问题，最终戳穿了导游的谎言，他并不是从小生活在伦敦，而是仅居住5年。

对于探索式测试而言，极限测试法采用的途径是向软件提出很多难以回答的问题。比如如何使软件发挥到最大程度？哪个特性会使软件运行到其设计极限？哪些输入和数据会耗费软件最多的运算能力？哪些输入可能欺骗它的错误检验例程？

测试文本处理器时：创建 充满图形、表格、多列和脚注等 错综复杂的文档；

测试网上购物系统时：创造最复杂的订单；

变种：找麻烦测试法：故意设置各种障碍来看软件如何反应。

5）快递测试法

在快递测试法中，数据类似那些通过快递系统中不断被移动的包裹一样，在软件中也不断的流动，数据从被输入后就开始了它的生命周期，先被存储在内部变量和数据结构中，然后在计算中被频繁操作、修改和使用。最后，这个数据作为输出被递送给用户或目的地。

测试人员必须于专注数据，应该确认那些被存储起来的输入数据并“跟随”它们走遍软件。如在购物网站输入一个地址后，会显示到哪里，哪些特性会用到该地址，在每个节点显示正确。

如C2的录音各种参数设置，在录音笔模式和麦克风模式都能生效。

6）深夜测试法

晚上，旅游者不会选择去商业区，但是测试人员需要关注，营业时间之后，软件中执行卖点特性的代码可能不运行了，但是还有其他应用程序在工作，他们执行各种维护任务，将数据归档，备份文档等等。

测试人员关注主要特性外的代码运行情况，如各种维护任务等、应该程序自动做的些事情。比如埋点数据、日志的上传，静默升级检测程序。

变种：清晨测试法，目的是测试软件的启动过程和脚本。

举例：2008.12.31，该年有366天，而程序中只处理了365天的情况，while（days>365）就会死循环，导致Zune设备播放器全部停机。

7）遍历测试法

垃圾车司机采用最短路径，挨家挨户将垃圾运走，每家短暂停留。类比到软件，就好比是有计划的抽查，最短路径，不追求细节以免影响测试进度，只检查明显的东西。

测试人员通过选定一个目标（例如所有菜单项、所有错误消息、对话框），然后使用可以发现的最短路径来访问目标包含的所有对象。

4.4.2 历史区测试类型（恶邻、博物馆、上一版）

对于软件来说，它的历史就是它从前版本留下的代码，还有那些曾经出现较多缺陷的特性和功能，正如真正的历史，遗留代码通常难以理解，包含、修改或使用遗留代码时，通常我们要做出许多假设。

主要针对老的功能和缺陷修复代码。

1）恶邻测试法

每个城市都有不好的社区，一般旅游者会被告知应避免访问那里，对软件而言，就是缺陷横行的代码段，应多花时间去测试这些区域。

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

2）博物馆测试法

展示古董的博物馆深受旅游者喜爱，代码中的老古董也应被多加关注。

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

3）上一版测试法

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

4.4.3 娱乐区测试类型（配角、深巷、通宵）

旅游者游览了所有景点之后，一些不需要费脑筋的休闲娱乐可以用来消磨时间，对于软件而言，指的就是辅助特性和功能，使用娱乐区测试法，可以补充不足，使测试计划更加完善。

这类测试帮助测试人员测试那些辅助特性（如页面布局、背景等），而不是主线特性，并确保这两种特性能够实用而又有意义地结合在一起。

1）配角测试法

作者讲述了在听导游讲解景点时，反而被旁边的景色吸引，推理在销售演示产品时，会有用户的注意力分散到附近的其他特性上。

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

2）深巷测试法

除了大家喜闻乐见的旅游区，还有一些小众的地方，如迪士尼的“后台内幕参观之旅”，软件中指的是最不可能、最不吸引用户的特性。

如果测试部门跟踪了代码的覆盖率，这个测试法要求测试人员想办法去测试那些还没有被没测到的代码。

变种：混合测试法，就是试着把最流行和最不流行的特性放在一起混着测。

3）通宵测试法

通宵旅游，专为晚上不想回家而在夜店狂欢的人设计，考验人的身体素质能否坚持，程序长时间运行能坚持到最后吗？

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

4.4.4 旅游区测试类型 （收藏家、长路径、超模、测一送一、苏格兰酒吧）

许多城市都设有旅游区，本地人不太会去，只有旅游者才去，在软件中，指的是某些特性和功能对新用户很有吸引力，然而老用户不再使用它们。

关心的是快速访问软件的各种功能。

1）收藏家测试法

作者举的例子是父母在一张空白地图上标记，每去一个地方就涂色，并且收集当地有趣的东西。

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

2）长路径测试法

作者举例：一个朋友经常出差，三点一线，于是把宾馆定在远离工区的地方，尽可能走更远的路了解城市。

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

3）超模测试法

第一印象，不管测试什么，不要超过表面皮肤的深度。

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

4）测一送一测试法

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

5）苏格兰酒吧测试法

作者旅游时遇到一群苏格兰游客，他们擅长泡吧，作者加入之后，跟着他们去了很多酒吧，若没有他们的带领，自己绝对找不到。苏格兰酒吧测试法，测试人员需要事先知道如何去找到程序中的某个地方。

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

4.4.5 旅馆区测试类（取消、懒汉）

当软件休息时，它实际上还是非常忙碌。适用于旅馆区的测试法就是要测试软件的这种特性。

1）取消测试法

人们在旅行中遇到天气变化，可能取消行程。

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

2）懒汉测试法

旅行团中的懒汉什么都不做，导游做更多工作调起它的兴趣，软件中当用户不做决定时，默认的逻辑也会做大量的操作if else。

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

4.4.6 破旧区测试类型（破坏、反叛、强迫症）

不吃香的地方，有很多违法乱纪的事，尽管吸引了某些旅客，但尽量还是少去为妙，但是破旧区对测试人员来说是必须要去的，因为这里可能存在非常令人讨厌的漏洞。

1）破坏测试法

测试人员试图利用每个可能的机会暗中破坏应用程序。

a. 强迫软件做一些操作

b. 掌握软件成功完成操作必须使用的资源

c. 在不同程序上移除那些资源或者限制使用那些资源。比如增加或者删除文件，改变文件权限，断开网线，在后台运行其他应用程序，把要测试的应用程序布署在有问题的机器上等。

2）反叛测试法

旅行团中叛逆的旅客，别人进去酒吧，她在外面等，别人出来，她又进去点了一杯酒。

要求输入最不可能的数据，或者已知的恶意输入。

如果真正的用户输入字母a，那么使用反叛测试人员就永远不输入a，取而代之的是去找些没意义的输入值。

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

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

4.5 漫游测试法实战

pass

4.6 小结

漫游测试法既能帮助测试人员思考如何测试应用程序，又能帮助他们组织实际的测试 ；

这一系列的测试法可以编成一张测试核对表，这样可以避免测试人员遗漏某些测试类型，它还可以帮助测试人员把应用程序的功能和适合这些功能的测试技术相匹配；

漫游测试法还可以帮助测试人员作出无数的决定，如何决定测试路径，如何选择输入值，使用哪些参数进行测试；

在微软，漫游测试法被看作汇总各部门间测试经验的一种机制，通过这一机制，一些测试法最终会被证明是很成功的。

探索式软件测试学习笔记-编程知识网

五、混合探索式测试法★

5.1 场景和探索

  • 摘要
  • 测试场景
  • 有价值的场景
  • 探索型测试人员应尽力确保从所有这些分类中收集尽可能多的场景，然后的任务就是根据这些场景加入合适的变化。通过有系统地考虑输入选择、数据使用和环境条件，一个场景可以演变出许多测试用例。使用了两个主要技术：场景操作和漫游测试。

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

5.2.1 故事1：通过场景操作引入变化

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

  • 插入步骤

    给场景增加额外的步骤可使它们更加多样化，从而测试更多的功能，可以用到以下这些类型：

    • 增加更多数据
    • 使用附加输入
    • 访问新的界面

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

  • 删除步骤

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

  • 替换步骤

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

  • 重复步骤

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

  • 替换数据

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

  • 替换环境

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

    需要考虑的因素：

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

5.2.2 故事2：通过漫游测试引入变化

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

  • 卖点测试法
    模拟用户已有的工作习惯，在原始场景中加入一些新功能，让用户使用过程通过学习某个功能，掌握它，然后随着对应用程序的熟悉而逐渐转移到新功能上。
  • 地标测试法
    从场景开始并从场景中选取特定功能的地标，然后随机打乱这些地标的顺序，这样得到的场景就和原始场景不同了。如有必要，重复这个过程，不断用新地标顺序来运行测试。
  • 极限测试法
    检查并修改场景以使软件更加努力地工作，即挑战软件，向它提困难的问题。如很长的字符串输入会产生问题吗？
  • 深巷测试法
    关注使用最不可能用到的或者最没有用的功能。
  • 强迫症测试法
    重复场景中的每个步骤两次或者三次。比如在软件中四处移动数据历来可以有效的找到重要缺陷。
  • 通宵测试法
    当测试场景可以被自动化或者可以被录制回放时，最适合使用的是通宵测试法，只需要不断重复运行场景而不需退出被测应用程序。
  • 破坏测试法
    在运行场景测试时，在资源调用处进行破坏活动。如场景要求在网络上传输数据，可以执行步骤之前或者之中拔掉网线等。
  • 收藏家测试法
    执行场景和衍生场景时用文档记录下所观测到的每个输出。
  • 超模测试法
    运行场景时只关注界面。确保所有元素都在它们应该在的位置上，界面应该设计合理，尤其要注意可用性问题。
  • 配角测试法
    测试人员不是执行测试脚本描述的功能，而是找到最近的邻近功能来执行。
  • 取消测试法
    不但充分利用取消按钮（运行场景时只要看到它就点击），而且执行了启动和停止功能。如在开始执行某些功能时，通过取消或者Esc来取消。
  • 混票测试法
    从一个场景跳到另一个，从而把两个或者更多场景结合为一个具有混合目的的场景。检查所有的场景并找出那些通用数据，侧重于通用功能。

5.3 小结

静态场景测试和探索式测试并不冲突；

场景可以代表探索式测试的一个绝佳起点，探索可以给场景加入宝贵的变化，否则场景将很有限；

明智的测试人员会把这两种方法结合起来，以便更好地覆盖应用程序，得到更多的输入序列、代码路径和数据使用的变化；

探索式软件测试学习笔记-编程知识网

六、实践中的探索式测试

6.1 dynamics AX客户端的漫游(Nicole Haugen 的体会)

Dynamics AX 是企业资源规划 (ERP) 解决方案，这些程序都是在 20 多年前全部采用 C++ 语言实现的。作为客户端团队，在这里，我们需要通过图形用户界面 (GUI) 来测试 Dynamics AX，在此之前，我的团队主要测试公共应用程序接口 (API)，所以，这对我们是一种思维方式的转变。在这个转变过程中，我们学到以下几件事情。

  • 很多缺陷都不是通过测试设计中所定义的测试用例找到的
  • GUI 测试引入的场景和复杂的用户交互似乎无穷尽，不容易使用自动化测试
  • 不管测试是手动的还是自动的，都必须放到回归测试中加以维护。团队中有成千上万的测试用例，所以必须不断地考虑每一个新测试用例所带来的投资回报率
  • Dynamics AX 是一个大型的应用程序，我们并不清楚其中的每一部分，更不用说应该如何对它进行测试。 探索式测试有助于我们解决以上所有的问题。最终我们是用下面的方法把它融入到我们的流程中。
  • 在每个功能迁入 (check in) 之前，测试人员对代码执行探索式测试。这样做是为了在迁入前更快、更好地找到重要错误。如果代码修复的是关键性的或高风险的缺陷，我们对他们也采取了同样的做法。
  • 探索式测试用于帮助我们在测试设计中开发出测试用例，它也可以帮助我们发现在官方说明书中可能漏掉的用户场景。
  • 手工测试阶段，我们从测试脚本出发，然后引入探索式测试。个人经验是，未经改动的手工测试很少能检测到新问题；但是对现有测试做哪怕是最细微的改动都可能发现许多缺陷。
  • 在缺陷” 大扫除”(bug bash) 时，我们采取了探索式测试，以引导我们到当前功能以外的地方去发现相关的缺陷。

有用的探索漫游

  • 出租车测试法

    – 解释：从强迫症测试法派生出来，最终目标是重复执行某项特定的操作，但是不重复执行完全相同的测试路径。条条大路通罗马。
    – 典型缺陷：使用所有的路径执行菜单项漫游，当时用快捷键访问菜单，再接着按下某一菜单加速键崩溃

  • 出租车禁区测试法

    – 解释：目的是验证无论选择哪一条路径用户始终无法到达目的地，重点测试禁区功能无法被绕过达到。
    – 典型缺陷：用户不能打开超过8个工作区，寻找用户打开一个新工区的所有路径，先打开7个，再遍历路径打开第8个，某一路径可以打开9个工作区，导致程序崩溃。

  • 多元文化测试法

    – 解释：软件的本地化测试

    a. 要求没有硬编码的文本，修改系统语言，验证静态文本、异常消息、工具提示、菜单项、窗口标题等是否已经不再显示为英语，有些特定词语不应该被翻译

    b. 尝试右往左的语言，如阿拉伯语，验证控件窗口能正常运行，可以改变下窗口大小、检查是否正常。

    – 典型BUG： windows<alt+W>没有正确改编为意大利版本的 finestre <alt+F>

漫游测试策略

  • 超模测试法与配角测试法相结合

    测试有图形界面的产品时，超模测试法是去除界面中明显缺陷的重要手段，在配角测试中，为了获得整体效果，必须把注意力向左或向右转10度 与配角测试法相结合。

  • 深巷测试法与混合目的地测试法相结合

    目的是测试不同特性之间是如何交互的。

  • 取消测试法

    取消被测对象之前应该改变它的状态。

  • 地标测试法

    对负责范围之外的其他功能不熟悉，找一个互补的熟悉另一功能的专家结伴测试。

6.2 利用漫游查找隐错(David GorenaElizondo 的体会)

  • 取消测试法

    典型BUG：

    • 在取消和工程项目最初设置的连接后，我们就无法再通过手动方式连接到该项目
    • 再删除一个配置变量时，无论取消还是确认都会被再提示
    • 选区不同的测试套件时，如果正在加载测试用例，该操作不会被取消
    • 反复刷新几次，刷新时间开始成倍增长
    • 疯狂刷新测试设置管理器，程序崩溃了

  • 破坏测试法

    典型BUG：

    • 没有tfs连接，却试图查看配置时，程序崩溃
    • 启动时，如果config被破坏，持续崩溃
    • 配置文件很大时，程序崩溃

  • 快递测试法

    典型BUG：

    • 从工作项返回后，测试计划没有自动刷新
    • 修改一个测试计划的属性，程序崩溃
    • 测试计划使用已删除的版本会导致程序崩溃

  • 测一送一测试法（关注多用户）

    典型BUG：

    制定新的测试计划属性时，如果不是新的配置文件，程序会崩溃

6.3 在windows mobile设备中的漫游实践 (Shawn Brown 的体会)

2000 年微软发布一项产品，它是一种便携式的设备，可移植性很多全功能计算机上才有的功能。这个设备叫做 Pocket PC，它开启了 Windows Mobile 系列 (2009 年，微软将其更名为 Windows Phone) 版本的发布。随着 Windows Mobile 系列的发布，它的功能也越来越多。在我的 Windows Mobile 职业生涯期间，我负责测试连接管理器，一些较早版本的 Office 应用程序，还有就是我的最爱 —– 打电话功能。
进行 3 小时的野外游，根据用户的实际环境进行测试。目标是发现 20 个缺陷，结果他们找到了 25 个缺陷。且发现破坏测试法、超模测试法和强迫症测试法最为有用。

  • 取消测试法

    典型BUG：

    后台搜索进程根据条件进行查询，输入一个预先知道不会返回任何结果的搜索字符串，删除搜索字符串的第一个字符，结果与搜索字符不匹配的数据被显示出来

  • 使用破坏测试法

    • 解释：如果测试的是使用网络连接的应用程序，那就是使用破坏测试法的好地方
    • 典型BUG：模拟联系人列表同步错误，导致同步看上去成功，但实际上存储的是空白的快速拨号

  • 使用超模测试法

    • 探索不同屏幕分辨率下的用户界面中心点和定位点
    • 典型BUG：选择一个不常见的屏幕分辨率，日历月视图中更改月份，没有顶部对齐，而是中间对齐

6.4 windows没提播放器的漫游测试实践(Bola Agbonile 的体会)

  • 遍历测试法
    根据功能相似度进行分类，分贝是所有的用户界面、对话框、文字框、边界、所有按钮，然后按照规定的次序进行测试
  • 超模测试法
    发现文字拼写错误的秘密，读出一个单词，然后默数一、二之后，再读下一个单词
  • 极限测试法
    整理25个“假如”类型的问题，查看WMP是否工作正常

6.5 停车场测试法及在VS测试版的应用(Geoff Staneff 的体会)

停车场测试法，某种程序上，是地标和超模测试法的结合体

  • 拿到版本之后，先做简短的停车场漫游来了解应用程序的各个部分是如何协同工作的，再把那些值得关注和后续测试的区域记录下来，下一步任务的重点是针对每个特性进行测试，通常在测试中还会有意识的加强某一方面的测试，例如可访问性，或处罚所有的错误对话框，或强迫采用所有的默认值…… 一般情况下，上述执行之后，最明显的缺陷基本都会被找到。
  • 进行更有针对性，也更加彻底的一轮测试。主要采用深巷测试法和强迫症测试法，这些测试方法都是基于过去几天对产品行为的观察和理解，以及和开发人员关于具体代码实现的相互交流。 另外和开发人员约定一种低开销的工作模式：如果开发人员可以再本周末前修复缺陷，那么测试人员就不会正式记录该缺陷。对开发和测试人员都有好处：产品质量可以迅速提高，没有人需要花额外的时间去上报缺陷和写缺陷文档。但是如果缺陷的周转要好几天而不是几小时，那么就要上报缺陷。
  • 通过分析缺陷和找到它们时使用的测试方法，对所找到的缺陷进行分类，结果如下：
    • 9%，出租车测试法 (键盘、鼠标等)
    • 9%，遍历测试法 (释放或者消除资源后，再进行检查)———————–严重缺陷
    • 15%，深巷测试法 (试图进行某种已知的不良操作，如关闭对话框两次) ——-严重缺陷
    • 18%，强迫症测试法
    • 19%，地标测试法
    • 30%，超模测试法 —————————————————– 大多不是严重缺陷

6.6 漫游测试中的测试规划和管理

pass

6.7 小结

微软内部使用的漫游概念有助于软件测试人员更好地组织他们的手工测试，让他们的测试更一致、针对性更强、目的性更强；

所有参加这些活动以及其他案例研究的测试人员们都觉得此概念很有用，他是一种用于描述测试技术和交流测试技巧的优秀方法；

现在测试人员们已经很少把注意力集中于底层单个的测试用例，而更专注于较高层的测试设计及测试技术等概念

七、漫游与测试中的棘手问题

7.1 漫无目的

  • 决定需要测试什么

  • 决定何时测试

  • 决定如何测试

7.2 重复性

  • 知道已经运行过哪些测试

  • 知道什么时候注入变异

7.3 暂时性

大多数测试人员不生活在软件中，他们只是“暂住”而已，一旦应用程序投入市场，他们就会转到下一个项目；

发现软件问题需要实际用户在实际的环境中，用实际的数据，去做实际的工作。测试人员不会接触到这些问题，这些问题的暴露需要时间；

最终测试人员是暂时性的，我们只能做力所能及的工作；

7.4 单调性

测试是枯燥的

实际上测试充满了有趣的策略问题，它既有娱乐性又有挑战性

在急于测试的情况下，测试策略问题常常被忽略，因为解决策略问题会增加测试量；

测试的战术方面实际上包括运行测试用例并报告错误，这是工作中乐趣较少的那部分；

有头脑的测试经理和测试主管要认识到这种现象，确保每一个测试人员把他们的时间合理分配在测试策略和测试战术上；

这种识别、记录、共享和优化以漫游为基础的测试方法的行为（漫游测试） ，称得上是一种高效率、高产出率、高创造性和更有趣的测试方法；

7.5 健忘性

测试任务从时间上来说比较侧重当前状况；

我们计划测试、设计测试、运行测试、分析结果，测试结束后马上就忘；

我们没有花大量时间思考如何在应用程序的未来版本中或其他测试项目中使用同样的测试；

测试团队对未来要干什么想的就更少了。测试用例被创建、被运行、最后被废弃；

测试用例并不是解决这种记忆问题的最好方法。对应用程序的改变常常导致测试用例的维护开销大幅上升，而且杀虫剂悖论也降低了现有测试用例的价值

漫游测试在一定程度上效果更好，因为一条漫游路径可以代表任何数量的实际测试用例

7.6 小结

/

【附 软件诫律】

  1. 汝应使用大量输入反复锤炼汝之应用程序

用大规模随机测试来面对无穷尽的排列组合的输入。测试人员无论如何都要打起精神来面对无穷。这是每个测试人员工具箱里必备的一个工具。极少测试项目能够没有它。
大规模测试必须是自动化的。虽然第一次做总是有些难度，但是随着项目的积累会越来越简单，最终变为机械的工作。它可能不会找到大量的缺陷，但是它是对剩余测试用例的一种极好的健全性检查，随机测试有时能找到一些高质量 (尽管数量上很少) 的缺陷；仅仅在编写大规模随机测试计划的过程中，我几乎总能找到缺陷或是想到一些很好的测试点子。

  1. 汝应贪图汝之邻居的应用程序

不要将应用程序孤立起来测试。否则很可能陷入” 应用程序兼容性” 的噩梦里。一种方法是储备一些应用程序 (旧的，新的，借来的……并且保证在运行应用程序的同时也运行这些程序。当然针对操作系统也要进行这项工作。例如安装某个操作系统升级服务包之后因公用程序无法运行……。所以我们要开始贪图那些应用程序和服务包，越多越好。

  1. 汝应亲自寻找睿智的预言家

我们测试软件的时候需要知道该软件是否按照既定的方式回应我们的输入。如果无法验证，测试就无法有效进行。测试人员在谈到知道所有答案的睿智的预言家时，称其为” 预言家难题”(oracle problem)。这需要我们的预言家 (也就是测试的基准) 清楚地了解在给定特定输入和环境条件组合的情况下，应用程序应有的行为。将测试基准进行自动化是很困难的一件事，但是很值得去追求，因为这不仅仅可以创建一个很有价值的测试工具，其本身也是一个启迪智慧的追求过程。无论你最终是否成功的是测试基准自动化了，强迫你自己像它一样思考，常常比你可能选择做其他任何事更有工作效率。

  1. 汝不应崇拜无法重现的失效

这条诫律的教育意义是双向的。第一，尽你最大的努力注意并记住 (或记录下来) 对软件才去的动作次序，同时记住应用程序的响应。第二，考虑使用调试器之类的能追踪动作和软件状态的工具。

  1. 汝应尊重你的模型和自动化测试

诫律 1 是关于随机测试的重要性 —— 重点在于随机。而这条诫律是关于智能的随机测试 —— 重点在于智能。把智能和自动化测试合二为一，其结果就是基于模型的测试 (model-based testing)。这是主导未来的自动化测试技术。
好的模型可以使自动化测试足够聪明，能响应错误和覆盖那些笨拙的自动化测试无法覆盖的代码。哪怕你没有耐心实现自动化建模，进行建模的过程也至少能让你更好地准备测试。

  1. 汝应利用开发人员的过错与他们作对

如果开发人员编写某个模块时犯了一个错误，我们应该假设其它开发人员在类似的模块中可能会犯同样的错误。如果某个开发人员倾向于写死循环，那么我们需要保证在该开发人员编写的每个模块都需要测试这类错误。这就是” 从经验中学习”，我们的任务是保证我们的开发人员采取正确的行为：理解他们的错误模式，从而避免那些错误。

  1. 汝应醉心于谋杀应用程序

作者清楚地记得他的第一个蓝屏缺陷，它好像就发生在昨天。任何一个缺陷不能不进行深入调查就轻易放过。这条诫律的教育意义是在每一个好的缺陷背后，都可能隐藏这一个更好的缺陷。在确实了解缺陷的影响程度和破坏力之前永远不要停止探索。

  1. 汝应保持安息日的圣洁

作为测试人员，我们只是需要在给定的时间之内完成尽可能多的工作。我们不应该抱怨发布日期，而是应该提前警告后果。这是我们的职责范围，也是我们应该担心的范围。

  1. 汝应贪图开发人员的源代码

如果可以接触到源代码，就好好利用它。我们应该像一个测试人员而不是像开发人员那样利用源代码。阅读源代码可以学习到很多东西。阅读源代码时，我工作列表上的第一项就是寻找错误处理代码和能为我们指明错误代码正在执行的对话框。从用户界面上最难见到或得到的代码就是错误处理代码。花时间理解代码中写了哪些错误处理，哪些输入能触发它们，这样做是值得的。