探索式软件测试

在敏捷测试里面，很重要的一项就是探索性测试，但是当我们提到探索式测试，很多人感觉是一个很虚无缥缈的东西，我们怎样才能更好地做探索性测试呢？

探索性测试 ≠ 即兴测试

对探索性测试最直白的定义是：同时设计测试和执行测试。所以很多时候有的人会把探索性测试与即兴测试弄混淆。

探索性测试是由Cem Kaner提出，相比即兴测试是一种精致的、有思想的过程。而即兴测试通常是指临时准备的、找寻bugs的过程。如下图，熟悉戴明环的朋友们可能会发现，探索式测试实际上运用了戴明环的理论。

探索式测试的执行

《探索式软件测试》这本书提供了很多测试方法，在全局漫游测试中，有旅游做类比，把软件测试分成了不同的区，比如商业区，历史区，娱乐区，旅游区等等，针对每种区域，有不同的方法。

比如历史区代表遗留系统，作者指出可以用恶邻测试法（某个区域代码缺陷很多，建议对邻近功能使用遍历测试法进行测试，以此来验证那些修复已知缺陷的代码没有引入新的缺陷。），上一版测试法等等，想了解详细方法的同学可以参照《探索式软件测试》这本书。

但是即使是看完了《探索式软件测试》这本书，我相信很多同学也还是会一头雾水。我们究竟怎样去做呢？

在做探索性测试之前，必须深入的了解系统的功能和目的，了解系统中之前存在问题的地方，并且必须要对已经测试的部分进行记录。 我们需要仔细分析业务需求，好好想想测试场景，包括业务关联、各系统接口、各边界情况等。

然后通过自己计划和脑海中的具体步骤，去有目的性的探索、去发现问题，这样比盲目即兴进行测试更加容易掌握问题根源，其实探索性测试也就是去创新的过程。

我们之前项目的一些经验

我之前在一个产品公司待过很久，当时我们对探索式测试进行了深入的研究。 

产品包含很多模块，比如API，Report，Install Process，UI Test，Win8 Test等等。在进行探索性测试的准备阶段，我们针对不同的模块，一起进行头脑风暴，人为把不同模块映射到不同的区域（比如商业区，历史区等等），并且运用里面相应的方法，产出很多不同的脑图。 如下如

当测试不同的模块的时候，我们会基于我们脑洞出来的结果进行进一步的发散。当然还是那句话，这必须基于对对卡片以及软件的深刻了解。

在做探索性测试的同时，记录很重要，虽然不要求很详细的记录。但是要把所有测试中学习到的关于软件系统的知识要点、问题和疑问、测试的主意、进行了怎样的测试等相关信息记录下来，然后周期性地与其他人进行讨论。同时也能为以后的持续改进提供素材。记录的方法有很多种，只要能达到目的就行，我们当时是直接在脑图里面去标记的。

探索式测试可以理解为一种测试思维，它有一些相关的测试方法，但是更多的是一种思维方式。它更加强调设计和测试执行的同时性，这其实是针对传统的先设计，后执行而言。测试人员需要通过不断的探索，不断学习，从而更好的进行探索性测试。