探索吧!深入理解探索式软件测试-全局探索详细描述的方法和好的日常测试法！

全局探索式测试，有很多新颖独特的方法，来自于James A. Whittaker的《探索式软件测试》；这些方法我觉得完全可用于我们的日常测试工作中。我觉得好的方法、好的测试思路探索吧!深入理解探索式软件测试，无论在哪个阶段或那种测试类型中，都是可以被应用的。所以通过学习结合我自己的理解进行了整理。

全局探索图

全局探索详细描述：

一、需求挖据

指南测试法：

通过阅读用户手册并严格按照手册建议执行。这样既可以测试用户手册，也可以测试系统功能。由此方法衍生出来的方法还有博客测试法、专家测试法、竞争对手测试法。

卖点测试法：

根据销售人员的演示步骤进行测试；或者根据卖家的广告宣传进行测试，验证软件的主要卖点功能是否OK。其实我感觉跟指南测试法类似，都是根据已有的文档、系统的描述进行的测试。

深夜测试法：

是指在营业时间之后，软件中执行卖点功能的代码可能不运行了，但是还有一部分代码才刚刚开始工作。执行各种维护任务、数据归档、文件备份等。针对这些在系统非忙碌状态下执行工作的代码进行测试，帮助我们避免功能的遗漏。

二、重点挖掘

恶邻测试法：（对bug较多的功能进行再测试）

对于bug比较多的模块，一般是由于逻辑复杂、需求、设计考虑不周全，或者开发人员工作经验不足等等造成的。在这样的模块很容易导致测试人员心情烦躁、失去信息和耐心；就会可能遗漏问题，或者由于开发改完旧的bug又带出了新的问题。所以对于bug比较集中的地方，我们应该重点再测试一下。

博物馆测试法：（根据代码修改点判断对原有代码的影响）

一些老的代码被重新修改，或者没有被改动而被放到新的环境中运行，或者是相关的其他代码发生了改变。这些都可能会导致老的代码无法运行或者出现问题。特别是在需求和设计方面可能出现疏忽的地方，导致老的代码与新的代码不兼容。

收藏家测试法：（收集并验证所有输入输出）

收集软件的输出，收集的越多越好。这个测试方法背后的想法是测试人员到达所有可到达的地方，并把观察的输出结果记录下来。除了输出，我认为还可以收集所有的输入。此方法还是应该用在核心功能中，不然工作量会非常大。

快递测试法：（收集并验证过程中的状态及逻辑分支）

把某一项测试数据作为我们的快递包裹，需要我们跟踪包裹在配送过程中的所有状态及变化。

以及在每一个环节对包裹的处理。看我们的包裹是否会在某一个环节出现问题。

我觉得这个方法可以让我们更细节的关注数据，关注数据的变化，关注数据所处的环境；关注数据所接受的动作；

关注数据在所有环节、所有环境包括内部系统以及外部系统中，他的健康状况。

在这个测试方法中，测试人员必须专注于数据。

三、功能挑战

极限测试法：（极限、找别扭测试）

对软件的各种操作发挥到极致，验证软件功能是否OK。比如购买一件商品，是否可以一下订购1000个或者更多，购物车添加几百种商品是否OK？提交订单，我多次重复点击是否OK？支付金额我们更换不同的支付方式，或者更换不同的信用卡是否OK？总之，把每一种操作都发挥到极致，看软件是否还正常就是极限测试法。

取消测试法：

取消测试法的思想就是启动操作然后取消它。比如我们转账的时候突然点击取消、退出等操作。或者直接断网、断电、关机。验证转账功能是否能正常转账成功或成功的回滚。对于浏览器中的操作可以点击ESC或者或程序中的回退按钮。

通宵测试法：（稳定性测试）

通宵测试法就是让程序一直保持运行，而不去关闭它。比如打开一些文件，但不关闭他们，甚至不存储他们以避免存储文件时可能出现重新设置的情况。他们连接到一些远程资源，但从不断开。

破坏测试法：（异常情况测试）

试图利用每个可能的机会破坏应用程序探索吧!深入理解探索式软件测试，使运行环境恶劣（内存少、权限、断网、故障数据等）。使用此方法一定要多考虑一场情况，然后模拟异常的测试环境进行测试。虽然异常情况很少发生，但是还是很有可能会发生。一旦发生，我们的系统必须有相应的应对措施。

测一送一测试法：

测试人员同时运行同一个应用程序的多个实例，或者多人同时使用同一个功能。

四、用户体验

懒汉测试法：

指测试人员做尽量少的工作；接受所有默认值，保持输入字段继续为空，表单中尽量少填写数据，尽量少点击界面中按钮。

总之，

超模测试法：

测试人员关注的重点不是功能，而是界面。测试中注意界面的各种元素。把系统当作一个超级模特，这种方法只是观察其外观是否漂亮是否有瑕疵，是否满足满足要求。

用户体验法：

krug可用性三大定律

1、别让我思考

2、点击多少次没关系，只要每次点击都无需思考

3、去掉每个页面上一半的文字，然后把剩下的文字再去掉一半

用户体验规则：

1、符合用户实际场景

2、易用性要强易用性包括易 理解性、易学性、易操作性。

3、给用户的选择尽量少

4、提供用户想要的信息

5、快速、响应

6、友好准确的提示

7、及时性

8、一致性

9、容错性

10、协助用户记忆原则

捡漏测试法(自创) ：

在经过几轮的测试之后，需求上提到的，测试人员基本都会转化到用例并测试过了。这时我们要想发现问题，肯定是比较难的，基本类似于捡漏。但是如何捡漏呢？而且能让捡到的漏还能有价值？我觉得首先就需要选择核心的功能，也就是用户经常使用的功能。然后除了验证主要流程，更需要关注的就是一些细节、一些流程之外的不起眼的功能。别走过的路，我们再走肯定很难发现新的问题，所以我们必须另辟蹊径，才能发现新的问题，才能有漏可捡。