测试手段之探索性测试(1)

　　上次说到了理想中的测试模型，有很多测试手段，细心地人可以发现那里面加了一个很关键的一个测试手段就是探索性测试。其实这里面把它叫为测试手段不是很科学，而且容易产生歧义。

　　所以后面把它叫做一种测试方法。

　　自己研究探索性测试快半年了，对其有一定的了解，而且在国内也有相关的介绍，个人认为：

　　1. 大部分是正确的

　　2. 相当浅显的介绍探索性测试

　　3. 没有介绍探索性测试的实践情况

　　自己看过了探索性测试(以下简称ET)的3个核心人物的一些关于ET的paper，也小小的实践了一个ET的一种形式，有很多感慨。但一直没有去写，有以下原因：

　　1. 不知道怎么表达出来比较好，一直都认为自己理解ET不深

　　2. 为了不让大家对ET存在误区，且自己对于ET某些的认识也是存在不同的看法(随着与James bach的沟通变得不一样)

　　3. 自己对于ET具体的测试方法的抽象还存在部分疑惑

　　最后发现了一点点的感觉了，就想把自己了解的一些情况记录下来Share给大家，希望能给大家带来不一样的认识。也希望不要给大家带来ET认识上的误区。

　　这里把ET叫做一种测试方法，而非测试技术，是有理由的。我们先可以分析下我们目前的测试模型，是集成在spiral或waterfall或类似的开发模型下，这就存在如下的几个特点：

　　1. 测试文档(计划和设计和用例)必须非常详细和明确

　　2. 测试设计和测试用例对于开发的文档的依赖非常大

　　3. 测试执行的时候对于测试用例的依赖非常大

　　4. 测试执行的时候对于需求变更的应对力较差

　　我们可以把有以上特点的测试方法叫Scripted based testing(简称ST)，显然我们目前就是这种测试方法，由于这个方法有些缺点，从而产生了一个新的测试方法：ET。

　　下面我们对于ET和ST进行了一些简单的比较：

　　在这里我们可以看到一点就是ET似乎就是弥补ST的一些缺点，理智的人就会想到能不能ST和ET结合起来。这样带来的效果是不是更好呢?

　　我们认为大部分的项目的最佳组合地方是在中间，也就是我们可以采用ST的优点和ET的优点进行组合。但这里要说明的是ET是Context-Driven School的代表作，其强调的就是没有最佳实践，任何项目都有自己的特点，根据特有的特点制定最佳的测试方法组合策略。

　　对于上面的模型图，可以看到有如下的特点：

　　最左边就是Pure Scripted，也就是完全的按照测试用例来执行测试;而且测试用例非常详细。

　　最右边是Freestyle ET，也就是自由式的ET，没有任何测试文档;不需要记录任何东西(bug除外);测试执行之前不需要任何准备。

　　可以看到上面的两种方式都是不成熟的，而且都是不常见的，有点走极端。我们自己做项目过程中不可能完全走Pure Scripted或Freestyle ET。这里比较好的办法就是混合ST和ET，并在不同的项目当中采取不同的混合策略来进行比较完善的测试方法的策略。在大部分的项目过程中，组合ST和ET会带来意想不到的效果，

　　目前我们所有的项目都是ST为主导的，偶尔会在测试执行的时候会去发散性的去测试一些东西，但这个完全建立在经验和时间和功能等众多因素上。为了更好的混合ST和ET，我们考虑尽量减少文档的编写时间，提高更多的在测试执行时创造性的发挥，更加的体现在测试执行过程中持续性学习产品带来的思维扩展性。

　　这里介绍下混合ST和ET时，需要用到的几个关键性的因素：

　　Vague Scripted：比较模糊的测试用例，一般不是很详细，这里可以理解为有一些测试用例(但没有一些比较详细的预期结果)，也会有一些步骤(但会预留有一些其他详细的步骤而不是必须要做的)。

　　Fragmentary test cases：使用一句话或几个词语制定测试用例。

　　Charters：ET过程中使用到的一个非常清晰地任务列表，指出了要测试什么，怎么测试(强调策略，不是详细测试步骤)，要寻找什么样的bug，有哪些风险，要去检查什么文档等。

　　Roles：ET过程中给测试人员一个独立的角色去测试产品的一部分。由他们自己掌控进度和质量。

　　这里主要说明了ET和ST的一些方式上的不同，至于ET的定义这里就不说了，下次介绍下ET在什么情况下适合做，ET做的好不好与哪些因素有关系。大家想要了解什么或者有什么问题，都可以留言。

　　以上分析参考James Bach等的paper

原文转自：http://www.ltesting.net