探索性测试
在开始实践敏捷的时候,就一直谈论着探索性测试。尝试了许多方式,多角度覆盖、路径漫游、逆向思维等等,虽然取得了一定的效果,但仍无法很自信的回答团队做的确实是探索性测试。因为一直忙测试开发的工作,而忽略了对测试工作本身的总结和思考。所以最近特意看了一些资料和书,才把探索性测试的方法论整个整理出来。(本文许多论点取自James A. Whittaker的探索式软件测试一书)
什么是探索性测试
在测试行业非常喜欢炒作的是自动化测试,但是自动化测试有一个致命的弱点就是“预言家难题”,意思是如何才能知道被测试的软件确实完成了它应该完成的任务,预言如何才能精准无任何差错?机器毕竟不是人,它只能按照固定的步骤来执行计算、判断,例如自动化运行中途出现:操作系统升级重启、机器断网、浏览器故障重启了、页面刷新较慢元素在该有的时间内没出现、HTTP丢包等等任何一些不稳定,自动化的流程就很容易崩溃并最终等待人的介入。所以过度依赖自动化是不明智的,手工测试永远都会继续发挥着作用。
如果想发现应用程序业务逻辑相关的缺陷,充分发挥主观能动性的手工测试也是最理想的选择。但随着软件测试的发展,手工测试越来越倾向于精心策划。现代软件项目是庞大的人员成本是有限的,如何保证在有限的时间内做最正确的事,需要手工测试在开展之前,有明确的战略和方向,但又必须预留一定的发挥空间让每个人的大脑可以充分运转起来,在测试的过程中随机应变。我们把这种测试方式称作探索性测试:它鼓励测试人员一边测试、一边计划、他们使用在测试中收集到的信息,影响自己进行测试的实际方式。
理解探索性测试有两个前提:第一,测试之前一定会有一个全局的方针战略,即整体的测试计划,它可以避免走错大方向,该测的部分没有覆盖到,计划之外的部分却投入了大量时间。第二,测试一旦开始,没有固定的思路,测试人员不受任何先入为主的条条框框约束,根据测试途中获取的信息,指导各自走不同的路径,最终目的就是发现潜藏的缺陷。
探索性测试的种类
JW的书中用了一个最恰当的比如来描述探索性测试的方法论,即把测试比做一场旅程。测试的对象就是旅游的目的地(比如说像伦敦这样一座古老的城市),软件的缺陷就比作是在这座城市里所有有趣的角落。显然,在软件发布周期规定的有限时间里,你不可能把城市的每一个角落都逛遍,这样你也就不可能发现城市里每一个有趣吸引你的角落,你得严格制定你的行程和各种后备方案,但同时你也会在旅途中遇到许多突发状况,临时改变你的路线,就为了能走遍最好玩的地方,往往有些角落是沿途发现的没出现在你的计划中。这样来比喻有计划又鼓励自由发挥的探索