《探索式软件测试》读书笔记（上）
《探索式软件测试》读书笔记（上）
2015-05-12
一、局部探索式测试
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. 旅游区
旅游区- 有些特性和功能对新用户非常有吸引力，然而老用户不再使用他们。
- 收藏家测试法 - 该测试法建议我们收集软件的输出，收集得越多越好。
- 长路径测试法 - 哪个特性需要点N次才能被用到？选定那个特性，一路点过去，然后测试它；哪个特性需要经过最多的界面才能访问？选定它，然后进行测试。这里的主要思想是到达目的地之前尽量多地的应用程序中穿行。选择长的路径，把埋在应用程序最深处的界面作为测试目标。
- 超模测试法 - 这个测试法，要求测试人员去关心那些表面的东西。只测试界面。测试中注意观察界面上各种元素。它们看上去怎么样？有没有被正确的绘制出来？它们的性能是否良好？变化界面时，图形用户界面刷新情况如何？如果软件用颜色来传达某种意思，这种信息是否一致？界面是否违反了任何惯例或标准？
- 测一送一测试法 - 只测试同进运行同一应用程序多个拷贝的情况。让各个程序在内存中做些事情，同时在磁盘上做些事情。试着用所有的不同拷贝同时打开同一个文件，或者让它们同时在网络上传输数据。备注：为什么叫测一送一，因为如果有一个拷贝上发现了一个缺陷，就在所有的拷贝上发现了同样的缺陷。
- 英格兰酒吧测试法 - 特别适用于大规模的复杂应用程序。在这些应用程序的有些地方，测试人员需要事先知道如何去找到它们。也就是说要找到用户组并参与他们的讨论，读产业博客，花大量时间深入了解待测的应用程序。
4. 娱乐区
娱乐区- 软件也有一些辅助特性和功能，用于精疲力竭之后的休闲娱乐。
- 配角测试法 - 鼓励测试人员专注于某些特定的特性，它们虽然不是我们希望用户使用的主要特性，但和那些主要的特性一同出现在显示器上。
- 深巷测试法 - 建议测试人员应该测试该使用情况列表中排在最下面的几项特性。该测试法要求测试人员想办法去测试还没有测试到的代码。深港测试法的一个变种-混合测试法，尝试将最流行和最不流行的特性放在一起混着测试。
- 通宵测试法 - 这里的关键是通宵，必须从不中断。让程序一直保持运行，而不去关闭它。测试可能出现的问题：内存泄露、数据毁坏、竞态条件等。
5. 旅馆区
旅馆区- 当软件“休息”时，它实际上是非常忙碌的。
- 取消测试法 - 其思想是启动操作然后停止它。也可以尝试开始一个操作，不要停止它，然后开始另一个同样的操作。我们应该假定用户偶尔会取消一些操作，但是他可能马上又重新做了一次相同的操作。
- 懒汉测试法 - 有时候什么也不做反而会迫使软件执行得更繁忙，因为当用户留下数据字体空白时，程序正尽头执行IF-Then-Else条件中的Else来寻找下一步要做什么；当用户不做决定时，默认的逻辑也会执行大量的操作。懒汉测试法指测试人员做尽量少的实际工作。
6. 破旧区
- 破坏者 - 在这种方法中，我们会试图利用每个可能的机会机会暗中破坏应用程序。强迫软件做一些操作；掌握软件成功完成操作必须使用的资源；在不同程度上移除那些资源或限制使用资源。
- 反叛测试法 - 要求输入最不可能的数据，或者已知的恶意输入。1）逆向测试法 每次都输入那些最不可能的数据。2）歹徒测试法 这是关于如何处理非法输入的测试法。基本想法是输入一些不应该出现的数据，违反规则的数据等。3）错序测试法 要求测试人员以错误的顺序做事情。选择一组合法的行为，将它们混在一起，造成前后顺序不合法。例如在购物车空的时候结账，或者退还一个没买的货物等。
- 强迫症测试法 - 反反复复的执行同样的操作。
三、混合探索式测试技术
1.通常有价值的场景会做下面一些事情：
- 讲述用户故事 - 通常是记录用户使用软件的动机、目的以及具体动作
- 描述需求
- 演示产品功能 - 这些场景出现在在线帮助或为用户准备的书面说明书中
- 演示集成场景 - 描述功能在集成后是如何工作的，用户在一些实际任务中如何使用这些集成后的功能
- 搭配设置和安装
- 描述警告和出错情形
2.使用基于场景的探索式测试
1) 通过场景操作引入变化
- 插入步骤：给场景插入一个或多个步骤能增加软件失败的机会。增加更多数据，使用附加输入（比如添加一条产品评论后，对其他评论进行评分），访问新的界面
- 删除步骤：可使用递进的方式重复场景，每次只删除一个步骤。每减少一个步骤，场景都在被测软件上执行一次，直到获得一个最短的测试用例，然后循环结束。
- 替换步骤：如果场景中某些步骤可以有多种方法完成，就可以用替换步骤的场景操作来修改这个场景。
- 重复步骤
- 替换数据：这里的思路是理解应用程序连接和使用的数据源，并确保它们之间的交互是稳定可靠的
- 替换环境：如替换硬件，替换容器（如不同浏览器），替换版本，修改本地设置（应用程序是否使用Cookie或者在用户机器 上写文件吗，使用本地注册表吗，如果用户修改浏览器设置来限制这类活动会怎样？如果用户直接改变应用程序的注册表设置会怎样？）
2) 通过漫游测试引入变化
- 卖点测试法 - 为场景加入新功能
- 地标测试法 - 从场景中选取特定功能的地标，并打乱这些地标的顺序
- 极限测试法 - 修改场景 以使软件更加努力的工作，也可以说挑战软件，向它提困难的问题
- 深港测试法 - 是卖点测试法的变种，也是加入新功能，不过这里是加入不可能乃至的或最没用的功能
- 强迫症测试法 - 重复场景中的每个步骤两次或三次，可以按自己的喜好来做
- 通宵测试法 - 当测试场景可以被自动化或录制回放时，最适合这个测试法。它需要不断重复运行场景而不退出程序。选择使软件满负荷的场景，使用内存或网络，或者在其他方面消耗资源
- 收藏家测试法 - 执行场景和衍生场景时用文档记录下所观测到的每个输出，甚至可以根据产生的输出数量来给场景打分。测试人员能否创建出新场景，让它具有其他场景中没有的输出？能否创建一个可以产生最多输出数据的超级场景。
- 超模测试法 - 强迫数据尽可能频繁的显示以寻找屏幕刷新问题
- 配角测试法 - 总是选那些在某种意义上“最邻近”的选择
- 取消测试法
- 混票测试法 - 检查所有的场景并找出那些使用通用数据，侧重于通用功能，或具有通用步骤的场景
参考
[1] 读书笔记_《探索式软件测试》
