第4章 全局探索式测试法
-
探索式测试有下面几个目标
- 理解应用程序如何工作，它的接口看起来怎样，它实现了哪些功能
- 强迫软件展示其全部能力
- 找到缺陷
-
旅游者比喻，我觉得非常恰当，我们需要花些时间来确定旅游的策略和目的，这对于实际策略的选用起着举足轻重的作用。
-
漫游测试，引入了feature测试的概念，简化了分配资源和跟踪进度的难度，但也带来了很大的风险。
-
为了便于组织，我们把软件特性分成相互重叠的“区域”，它们分别是：
- 商业区：我理解，就是软件最基本、最主体的功能
- 历史区：从前版本留下的功能，遗留代码通常难以理解（我发现我现在测试的系统，刚好有很多历史区，很多需求是1年前做的，我要花很多时间去理解这个功能的背景、操作步骤、对现有系统的影响，很花费时间和经历。。。）
- 旅游区：对新用户很有吸引力，老用户很少使用（我觉得有些报表就是旅游区，不知道老板会不会来砍我。。。）
- 娱乐区：不需要费脑筋的，补充其他区域中各种测试的不足，使得测试计划更加完善（作者你出来，告诉我哪些是娱乐区？我怎么感觉只有纠结区，没有娱乐区啊。等我看完，你要是将不明白娱乐区，我就撕书了啊。）
-
旅馆区：休息的地方？不明白，我测的系统不需要休息
-
破旧区：不吃香的地方，但是必须要测试
4.1 商业区测试类型
商业区测试类型侧重于测试产品的重要特性，并指导测试人员如何对执行这些特性的软件代码路径进行测试。
指南测试法 - 强迫测试人员按用户的使用方式，把软件特性串起来测试，同事还要求这些特性按用户的真实使用方式相互交互。
1. 相对于旅游手册，探索式测试使用的是用户说明书。（当然，我们根本不写用户说明书，我觉得就只能看产品经理的需求了。如果需求也不明确，那就只有口头交流了。我们出现过几次因为需求错误，导致的返工。）
2. 需求（甚至包括微软的文档）往往没有一整条完整的操作路径。换句话说，它只告诉你各个点该怎么做，而没有完整的solution，这也是个人遇到的问题。所以，最终我还是不得不自己去写测试用例，把前提条件，执行步骤和验证点一一列出，有些复杂功能还需要截图说明。
3. 其他变种：A. 博客测试法(Blogger's tour)，要求测试人员遵循第三方的建议来测试。B. 专家测试法(Pundit's tour)，这种方法要求测试人员根据哪些怒气冲冲的评论者的抱怨来创建测试用例。（哎，说白了，就是从用户那里收集BUG嘛，补充自己没有测到的点。）C. 对手测试法（Competitor's tour）
> 卖点测试法 （The Money tour)
1. 我觉得，卖点测试法就是测试软件的核心功能。作为测试人员来说，最好能够把执行过程中的截图保存下来，作为证据。
2. 变种：质疑测试法（Skeptical Customer tour）OS: 这个我擅长啊，当然也可能是因为我对系统还没有太熟悉，我测试的过程中经常会有问题，只能求助测试小伙伴或者开发。
地标测试法
我们使用指南针指向位于我们目的地方向上的某个物体来精确标定方位，走到那里，然后确定下一个目标。如此反复，只要所有地标在一个方向上，就能走出森林。步骤：选择地标，确定前后顺序，从一个地标到另一个地标。
我的理解，就是将软件功能拆分成多个相对独立的地标，从前到后（或者有几个步骤并行）的执行测试，保证每一个地标都有走到。变种：测试前可以选择多个起始地标，或者在测试后增加新的地标，还可以改变几个地标的执行顺序。
极限测试法
快递测试法：专注于数据。
深夜测试法：数据归档，备份文件等
遍历测试法：通过选定一个目标，使用可以发现的最短路径来访问目标包含的所有对象。
4.2 历史区测试类型
恶邻测试法 博物馆测试法 上一版测试法
4.3 娱乐区测试类型
配角测试法
深巷测试法：要求测试人员想办法去测试那些还没有被测到的代码
通宵测试法
4.4 旅游区测试类型
收藏夹测试法
长路径测试法
超模测试法：只测试界面
测一送一测试法：同时操作一个文件，或者同时在网络上传输数据
苏格兰酒吧测试法：很难找到的一些地方（通常是一些大型网站）
4.5 旅馆区测试类型
取消测试法：启动操作然后停止它
懒汉测试法：接受默认值，少填数据，走最不费力的一边
4.6 破旧区测试类型
破坏者
反叛测试法：输入最不可能的数据，或者恶意输入
强迫症测试法
实战
这点我非常认同！！其实我想找的就是一种统一的测试方法论，我们如果可以按照方法论认真执行，能得出80%相同的结果，那就是一种普适的测试方法，就应该去推动和实践。
我们现在测试，太依赖个人对产品的理解和做事习惯，有些短板可能会很短。怎样找一种方法，使得大家的最低得分都高于80分（甚至是60分），是一种迫切需要的东西。
