探索性测试总结笔记

探索性测试

在开始实践敏捷的时候，就一直谈论着探索性测试。尝试了许多方式，多角度覆盖、路径漫游、逆向思维等等，虽然取得了一定的效果，但仍无法很自信的回答团队做的确实是探索性测试。因为一直忙测试开发的工作，而忽略了对测试工作本身的总结和思考。所以最近特意看了一些资料和书，才把探索性测试的方法论整个整理出来。（本文许多论点取自James A. Whittaker的探索式软件测试一书）

 

什么是探索性测试

在测试行业非常喜欢炒作的是自动化测试，但是自动化测试有一个致命的弱点就是“预言家难题”，意思是如何才能知道被测试的软件确实完成了它应该完成的任务，预言如何才能精准无任何差错？机器毕竟不是人，它只能按照固定的步骤来执行计算、判断，例如自动化运行中途出现：操作系统升级重启、机器断网、浏览器故障重启了、页面刷新较慢元素在该有的时间内没出现、HTTP丢包等等任何一些不稳定，自动化的流程就很容易崩溃并最终等待人的介入。所以过度依赖自动化是不明智的，手工测试永远都会继续发挥着作用。

 

如果想发现应用程序业务逻辑相关的缺陷，充分发挥主观能动性的手工测试也是最理想的选择。但随着软件测试的发展，手工测试越来越倾向于精心策划。现代软件项目是庞大的人员成本是有限的，如何保证在有限的时间内做最正确的事，需要手工测试在开展之前，有明确的战略和方向，但又必须预留一定的发挥空间让每个人的大脑可以充分运转起来，在测试的过程中随机应变。我们把这种测试方式称作探索性测试：它鼓励测试人员一边测试、一边计划、他们使用在测试中收集到的信息，影响自己进行测试的实际方式。

 

理解探索性测试有两个前提：第一，测试之前一定会有一个全局的方针战略，即整体的测试计划，它可以避免走错大方向，该测的部分没有覆盖到，计划之外的部分却投入了大量时间。第二，测试一旦开始，没有固定的思路，测试人员不受任何先入为主的条条框框约束，根据测试途中获取的信息，指导各自走不同的路径，最终目的就是发现潜藏的缺陷。

 

探索性测试的种类

JW的书中用了一个最恰当的比如来描述探索性测试的方法论，即把测试比做一场旅程。测试的对象就是旅游的目的地（比如说像伦敦这样一座古老的城市），软件的缺陷就比作是在这座城市里所有有趣的角落。显然，在软件发布周期规定的有限时间里，你不可能把城市的每一个角落都逛遍，这样你也就不可能发现城市里每一个有趣吸引你的角落，你得严格制定你的行程和各种后备方案，但同时你也会在旅途中遇到许多突发状况，临时改变你的路线，就为了能走遍最好玩的地方，往往有些角落是沿途发现的没出现在你的计划中。这样来比喻有计划又鼓励自由发挥的探索