一、局部探索式测试 1.如何测试用户输入
1）合法输入和非法输入
输入筛选器
输入检查
异常处理代码
2）常规输入还是非常规输入
3）默认输入或用户提供的输入
4）使用输出来指导输入选择
2.如何测试软件状态
3.代码路径
4.用户数据
5.运行环境
二、全局探索性测试
分类 | 方法 |
商业区 | 指南测试法 |
卖点测试法 | |
地标测试法 | |
极限测试法 | |
快递测试法 | |
深夜测试法 | |
遍历测试法 | |
历史区 | 恶邻测试法 |
博物馆测试法 | |
上一版测试法 | |
旅游区 | 收藏家测试法 |
长路径测试法 | |
超模测试法 | |
测一送一测试法 | |
英格兰酒吧测试法 | |
娱乐区 | 配角测试法 |
深港测试法 | |
通宵测试法 | |
旅馆区 | 取消测试法 |
懒汉测试法 | |
破旧区 | 破坏者 |
反叛测试法 | |
强迫症测试法 |
三、混合探索式测试技术 1.通常有价值的场景会做下面一些事情：
2.使用基于场景的探索式测试
1) 通过场景操作引入变化
2) 通过漫游测试引入变化
一、局部探索式测试
返回
1．如何测试用户输入
输入定义：输入必须导致软件执行某些代码，并以某种方式作出反应（不反应也算一种反映）。
1）合法输入和非法输入
大多数开发人员都不喜欢写错误处理代码
输入筛选器
输入筛选器：用于防止非法的输入值被传递给应用软件的功能代码。
如何测试？
- 是否正确实现了该功能
- 是否可以绕过屏蔽器？比如可以通过编辑Web页面的HTML源代码来修改输入筛选器，或修改通过输入筛选器输入的值，那么后面的代码还要进行输入检查。
输入检查
输入检查：它们会接收一条输入，如果输入值合法则接着处理，否则产生一条错误消息并中止处理。
如何测试？
- 我们必须仔细阅读每一条错误信息，检查该错误信息是否写错了，错误信息还可以透露开发人员编程时的一些想法。错误信息一般会指出当前输入值被认定为非法值的根本原因，及如何修正。这可以给我们很多启发（如哪些输入可以触发错误信息，哪些输入应该导致报错而软件却没报错等）
异常处理代码
异常处理代码：异常处理代码就想一个错误检测，但是它不对每一个输入值进行检测，异常代码把整个例程当作一个整体看待，检测其上发生的任何一个错误。
如何测试？
- 如果测试人员看到这样一个通用的出错信息，可以接着反复测试同一段函数，继续使用刚才出现异常的输入数据，或者是稍微修改一下，看看会不会导致出错；尝试运行其他一些调用该函数的测试用例；接连不断的引发异常很可能让程序彻底崩溃。
2）常规输入还是非常规输入
- 常规输入是开发人员计划的输入，也是真实用户经常用到的输入。
- 非常规输入只在比较特殊的情况下才发生，或者完全是由于某个机缘巧合才发生。
3）默认输入或用户提供的输入
- 看到开发人员设置的默认值后，首要任务是把默认值删除，留下一个空白的字段。
- 接着尝试输入在默认值附件的一些其他值，如果是字符串，可修改默认字符的头部几个字符，尾部几个字符，添加或删除几个字符。
- 还可尝试使用和默认字符具有相同长度但不同字符的字符串。
4）使用输出来指导输入选择
- 先观察输出结果，然后再选择新的输入，并保证新的输出是重新计算后的结果，或者是确保新的输出与原先不同。
- 很多时候，第一次测试的是软件处于一个未被初始化的状态时如何产生输出，而第二次测试是软件处理一个已被初始化的状态时如何产生输出。
- 修改被保存起来的输出结果，可以测试这些值是否在原值的基础上被重新生成了。
2．如何测试软件状态
可以这么来看待软件状态，在我们选择下一步使用哪个输入时，必须考虑从前使用过那些输入所造成的累计效应。
软件状态的定义（非正式）：软件的一个状态就是状态空间中的一个点，它由所有内部数据结构的取值来唯一确定。
软件状态可以看成是用于描述软件记住过去发生的所有输入和输出的一种方式。状态可以是临时的（当程序中止时，该状态就被忘记了），也可以是长期保存的。
输入和状态之间的关系相当关键。
测试建议：
- 使用状态信息来帮助寻找相关的输入。测试输入的各种组合可以说是测试的一个基本常识。如果两个或多个输入在某种程度上是相关联的，那么它们应该放在一起测试。
- 使用状态信息来辨识重要的输入序列
3. 代码路径
测试人员必须明确知道程序里可能有哪些分支，并理解哪些输入会导致软件走这条分支而不是另一条
4．用户数据
5．运行环境
二、全局探索性测试
返回
探索式测试的几个目标：
- 理解应用程序如何工作，它的接口看起来怎样，它实现了哪些功能；
- 强迫软件展示其全部能力；
- 找到缺陷。
漫游测试 - 这是本书的核心内容，它用旅游来类比测试过程。旅游地点一般可或划分为商业区、历史区、旅游区、娱乐区、旅馆区、破旧区，我们的测试软件也包含与这些“区域”，可根据不同区的特征，有针对性的进行测试。具体如下：
1. 商业区
商业区- 相当于软件包装盒上描述的那些特性，及市场商业活动中或者销售演示中的各种特性和实现这些特性的代码。
- 指南测试法
- 卖点测试法
- 地标测试法☆
- 极限测试法☆
- 快递测试法
- 深夜测试法
- 遍历测试法 - 通过选定一个目标（如所有的菜单项，所有错误消息或者所有对话框），然后使用可以发现的最短路径来访问目标包含的所有对象。测试中不追求细节以免影响测试速度，遭遇只检查那些明显的东西。
2. 历史区
历史区
- 恶邻测试法
- 博物馆测试法
- 上一版测试法
3. 旅游区
旅游区- 有些特性和功能对新用户非常有吸引力，然而老用户不再使用他们。
- 收藏家测试法
- 长路径测试法
- 超模测试法 - 这个测试法，要求测试人员去关心那些表面的东西。只测试界面。测试中注意观察界面上各种元素。它们看上去怎么样？有没有被正确的绘制出来？它们的性能是否良好？变化界面时，图形用户界面刷新情况如何？如果软件用颜色来传达某种意思，这种信息是否一致？界面是否违反了任何惯例或标准？
- 测一送一测试法
- 英格兰酒吧测试法
4. 娱乐区
娱乐区- 软件也有一些辅助特性和功能，用于精疲力竭之后的休闲娱乐。
- 配角测试法
- 深巷测试法
- 通宵测试法- 这里的关键是通宵，必须从不中断。让程序一直保持运行，而不去关闭它。测试可能出现的问题：内存泄露、数据毁坏、竞态条件等。
5. 旅馆区
旅馆区- 当软件“休息”时，它实际上是非常忙碌的。
- 取消测试法- 其思想是启动操作然后停止它。也可以尝试开始一个操作，不要停止它，然后开始另一个同样的操作。我们应该假定用户偶尔会取消一些操作，但是他可能马上又重新做了一次相同的操作。
- 懒汉测试法
6. 破旧区
- 破坏者- 在这种方法中，我们会试图利用每个可能的机会机会暗中破坏应用程序。强迫软件做一些操作；掌握软件成功完成操作必须使用的资源；在不同程度上移除那些资源或限制使用资源。
- 反叛测试法
- 强迫症测试法
三、混合探索式测试技术
返回
1.通常有价值的场景会做下面一些事情：
- 讲述用户故事 - 通常是记录用户使用软件的动机、目的以及具体动作
- 描述需求
- 演示产品功能 - 这些场景出现在在线帮助或为用户准备的书面说明书中
- 演示集成场景 - 描述功能在集成后是如何工作的，用户在一些实际任务中如何使用这些集成后的功能
- 搭配设置和安装
- 描述警告和出错情形
2.使用基于场景的探索式测试
1) 通过场景操作引入变化
- 插入步骤：给场景插入一个或多个步骤能增加软件失败的机会。增加更多数据，使用附加输入（比如添加一条产品评论后，对其他评论进行评分），访问新的界面
- 删除步骤：可使用递进的方式重复场景，每次只删除一个步骤。每减少一个步骤，场景都在被测软件上执行一次，直到获得一个最短的测试用例，然后循环结束。
- 替换步骤：如果场景中某些步骤可以有多种方法完成，就可以用替换步骤的场景操作来修改这个场景。
- 重复步骤
- 替换数据：这里的思路是理解应用程序连接和使用的数据源，并确保它们之间的交互是稳定可靠的
- 替换环境：如替换硬件，替换容器（如不同浏览器），替换版本，修改本地设置（应用程序是否使用Cookie或者在用户机器 上写文件吗，使用本地注册表吗，如果用户修改浏览器设置来限制这类活动会怎样？如果用户直接改变应用程序的注册表设置会怎样？）
2) 通过漫游测试引入变化
- 卖点测试法 - 为场景加入新功能
- 地标测试法 - 从场景中选取特定功能的地标，并打乱这些地标的顺序
- 极限测试法 - 修改场景 以使软件更加努力的工作，也可以说挑战软件，向它提困难的问题
- 深港测试法 - 是卖点测试法的变种，也是加入新功能，不过这里是加入不可能乃至的或最没用的功能
- 强迫症测试法 - 重复场景中的每个步骤两次或三次，可以按自己的喜好来做
- 通宵测试法 - 当测试场景可以被自动化或录制回放时，最适合这个测试法。它需要不断重复运行场景而不退出程序。选择使软件满负荷的场景，使用内存或网络，或者在其他方面消耗资源
- 收藏家测试法 - 执行场景和衍生场景时用文档记录下所观测到的每个输出，甚至可以根据产生的输出数量来给场景打分。测试人员能否创建出新场景，让它具有其他场景中没有的输出？能否创建一个可以产生最多输出数据的超级场景。
- 超模测试法 - 强迫数据尽可能频繁的显示以寻找屏幕刷新问题
- 配角测试法 - 总是选那些在某种意义上“最邻近”的选择
- 取消测试法
- 混票测试法 - 检查所有的场景并找出那些使用通用数据，侧重于通用功能，或具有通用步骤的场景
