软件探索性测试方法

 这里把ET叫做一种测试方法，而非测试技术，是有理由的。我们先可以分析下我们目前的测试模型，是集成在spiral或waterfall或类似的开发模型下，这就存在如下的几个特点 测试文档（计划和设计和用例）必须非常详细和明确

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

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

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

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

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

	ST	ET
测试与测试用例的关系	测试用例在之前就设计和记录好，过后再测试执行或被其他测试人员执行	测试设计和执行时在同一时间完成，而且他们不是必须记录下来，但也有可能
与测试执行的关系	可以控制测试执行	可以提升测试设计
过程的交互性	就像做个已准备好的演讲，由之前想好的想法引导着	就像一个对话，是自动向导的

　　在这里我们可以看到一点就是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做的好不好与哪些因素有关系。