《e测试探索性测试》.doc

探索性测试 在开始实践敏捷的时候，就一直谈论着探索性测试。尝试了许多方式，多角度覆盖、路径漫游、逆向思维等等，虽然取得了一定的效果，但仍无法很自信的回答团队做的确实是探索性测试。因为一直忙测试开发的工作，而忽略了对测试工作本身的总结和思考。所以最近特意看了一些资料和书，才把探索性测试的方法论整个整理出来。（本文许多论点取自James A. Whittaker的探索式软件测试一书） 什么是探索性测试 在测试行业非常喜欢炒作的是自动化测试，但是自动化测试有一个致命的弱点就是“预言家难题”，意思是如何才能知道被测试的软件确实完成了它应该完成的任务，预言如何才能精准无任何差错？机器毕竟不是人，它只能按照固定的步骤来执行计算、判断，例如自动化运行中途出现：操作系统升级重启、机器断网、浏览器故障重启了、页面刷新较慢元素在该有的时间内没出现、HTTP丢包等等任何一些不稳定，自动化的流程就很容易崩溃并最终等待人的介入。所以过度依赖自动化是不明智的，手工测试永远都会继续发挥着作用。 如果想发现应用程序业务逻辑相关的缺陷，充分发挥主观能动性的手工测试也是最理想的选择。但随着软件测试的发展，手工测试越来越倾向于精心策划。现代软件项目是庞大的人员成本是有限的，如何保证在有限的时间内做最正确的事，需要手工测试在开展之前，有明确的战略和方向，但又必须预留一定的发挥空间让每个人的大脑可以充分运转起来，在测试的过程中随机应变。我们把这种测试方式称作探索性测试：它鼓励测试人员一边测试、一边计划、他们使用在测试中收集到的信息，影响自己进行测试的实际方式。 理解探索性测试有两个前提：第一，测试之前一定会有一个全局的方针战略，即整体的测试计划，它可以避免走错大方向，该测的部分没有覆盖到，计划之外的部分却投入了大量时间。第二，测试一旦开始，没有固定的思路，测试人员不受任何先入为主的条条框框约束，根据测试途中获取的信息，指导各自走不同的路径，最终目的就是发现潜藏的缺陷。 探索性测试的种类 JW的书中用了一个最恰当的比如来描述探索性测试的方法论，即把测试比做一场旅程。测试的对象就是旅游的目的地（比如说像伦敦这样一座古老的城市），软件的缺陷就比作是在这座城市里所有有趣的角落。显然，在软件发布周期规定的有限时间里，你不可能把城市的每一个角落都逛遍，这样你也就不可能发现城市里每一个有趣吸引你的角落，你得严格制定你的行程和各种后备方案，但同时你也会在旅途中遇到许多突发状况，临时改变你的路线，就为了能走遍最好玩的地方，往往有些角落是沿途发现的没出现在你的计划中。这样来比喻有计划又鼓励自由发挥的探索性测试，真是太贴切了！ 为了继续发挥这个比喻的效果，我还是引用JW书中的一些描述吧。我们在旅程开始之前，首先会做一些全局的计划，比如把一座城市划分为商业区、旅游景点、娱乐区、旅馆住宿区、历史区还有治安不太好的旧城区，这就像软件产品里的各个模块一样，有主打卖点的核心功能、也有辅助功能和历史遗留代码等（例如商业区就代表了真正产生经济效益的实际业务完成区域）。当我们设计路线的时候，通常我们会拿着一份城市的地图来做规划，同样的道理我们也可以拿着一份产品的说明书（F1效应）来设计探索性测试的路线。 这里列举了一些书中总结出来的探索性测试方法： 指南测试法：城市的题图通常都会标注一些热门的旅游景点，测试这些热门的区域是非常重要的。不管在任何一次发布的过程中，核心功能是肯定要覆盖到的。指南测试要求测试人员严格按照用户手册的建议执行操作，有可能是手册描述不到位或者核心功能并不像宣传的那样好。 卖点测试法：此方法是鼓励测试人员观看销售给客户演示的Demo，理解销售的角度哪些功能对客户来说是最大的卖点，他们未必就是核心功能，但值得测试人员把它们当核心功能来对待。同时，也许刁钻的客户会提出各种质疑，这些质疑和稀奇古怪的问题也可以纳入测试人员的设计中。 地标测试法： 在旅游的时候，如果我们设计了要到访的地方，通常会在地图上插上旗子，这就是地标。但是没有人规定我们应该按照何种顺序去到访这些地标。不同的测试人员可能会选择不同的顺序，有经验的测试人员会基于对软件产品架构和技术层面的理解，采取一些古怪的路径但更可能发现缺陷。 极限测试法：向软件提出难以回答的问题，比如最大可以发挥到什么程度，承受多少用户，承载多少数据。那个特性或功能会把软件逼到极限运作，哪些输入和数据会消耗软件最多的计算能力？哪些输入可能绕过它的错误检测？ 快递测试法：快递运送的货物，就好比软件里的数据，结果不同的地点转接，拆包装包最终到底目的地。所以快递测试专注的是数据，跟随它们走遍整个软件。 深夜测试法：城市灯火阑珊会在午夜过后逐渐安静下来，商场店铺纷纷打烊。但是软件不应该停止工作，软件测试人员有时应该刻意的关注在冷门时间段软