探索式测试（Exploratory Testing）是敏捷测试中的重要组成部分，其价值与一般性测试如用户故事测试或者自动化测试不同，它所关注的是“意料之外”的软件缺陷，探索式测试作为一个研究性、启发性和严肃性并存的测试方法，是一般性测试的重要补充。随着敏捷测试的推广，探索式测试逐渐受到大家的关注和重视。本文主要探讨了测试工程师在探索式测试方面的一些误区，并尝试纠正这些问题。
误区1：探索式测试是一种测试技术。
探索式测试本身不是一种测试技术，相反，它是一种可以应用于广泛测试技术的方式或态度。所以很遗憾，测试工程师可能在现实世界中找不到一款名为“探索式测试工具”的软件来帮助他们直观地完成探索式测试。《测试计算机软件》作者Cem Kaner明确地将探索式测试定义为“一种强调每位测试人员自由和责任的测试，每个测试人员通过将学习、测试设计、测试执行和测试结果解释作为贯穿项目的平行活动，从而持续地优化他们的工作价值”。
例如，在Web应用项目中，UI功能测试必不可少。探索式测试作为一种思想就可以而且应该贯穿于UI功能测试中。
具体来说，测试工程师在某个时刻准备按照事先编写好的测试用例开始测试某个网站用户注册的页面时，一步步的走下去，输入框、日期选择器......一切看起来都很顺利，但是等一下，探索式测试是一种启发式的方法，在循规蹈矩地做着一般性功能测试的时候，我们需要同时来点不一样的东西。
盯住用户注册界面！大脑或许可以这样开始思考：我看到光标在闪动，噢，我之前测试是用鼠标点击的，如果用户只用键盘操作，光标在各个输入域的遍历是顺序的吗？动手测试之！接下来，鼠标点击一下提交按钮，注册成功！噢，如果失败会是什么样子？用户需要重新填写所有数据吗？动手测试之！下一步，用户注册页面测试完毕，不过，它有帮助文档或者提示信息吗？作为测试工程师我们可能已经非常熟悉产品了，可第一次访问网站并准备注册信息的用户了解必要的内容吗？注册完的用户到底知不知道自己有什么权限呢？动手测试之......
凡此种种，都是些启发式思维的小例子，从中可以看出，探索式测试作为一种方法，可以运用于任何一般性测试中，如单元测试、功能测试、性能测试、系统测试等等，只要有探索性的思想并贯彻于实践中，探索式测试就会发挥它的重要作用，找到一般性测试没有涵盖的危险区域。
误区2：探索式测试是一种黑盒测试。
测试工程师和测试经理对黑盒测试并不陌生。黑盒测试指的是测试人员把待测产品看做一个包装完好的盒子，无法看到其中的实现细节，只通过产品规格说明书、用户反馈等途径来设计测试用例并执行、分析。探索式测试作为一种测试方法，在黑盒测试中确实可以得到??很好地应用，比如在上面提到的UI功能测试中，探索式测试可以作为一种有益的补充发现常规测试顾及不到的测试点。但是，探索式测试提倡的原则之一就是“努力深入了解待测产品”。常规测试用例覆盖范围不全面的一个重要原因就在于对产品的理解不够深刻，所以难以挖掘出深层次的问题。探索式测试更趋近于白盒测试，要求测试工程师对产品有比较透彻的理解，从而创造性地提出和执行一些“出乎意料”的测试。
举个例子，假设我们正在测试一款Web应用，部署在Java虚拟机为基础的Web服务器（以WebSphere Application Server为例）上。按照常规测试用例，我们可能测试了多用户并发访问的情况、集群环境的情况等等，看起来黑盒测试就OK了。
接下来，我们尝试从白盒测试的角度开始探索式测试。瞧瞧产品用例和源代码，噢，看到了“synchronized (......)”、“lock.unlock()”这样的语句，很自然地，我们意识到产品在使用多线程编程，这意味着什么呢？多核！哦，常规测试中产品是在单核还是多核环境中？单核上的性能怎么样？多核上的性能有提高吗？线性程度有多大？负载均衡吗？这些问题成为了探索式测试的猎物，设计测试用例，并动手执行之，然后分析结果。
接着看代码，看到了很多“new ......”，还看到了产品代码中预分配了一些内存池，很自然地想到内存管理，当然Java的内存管理都由Java虚拟机掌控，测试工程师还能做些什么？有的！如果仔细研究Java虚拟机的机制，就会发现初始堆大小、最大堆大小、垃圾回收日志是否输出、垃圾回收的不同算法等设置，默认情况下Web应用的运行情况如何？随着用户增加，堆会不会由于太小而导致运行失败？堆大小变化了，原来的垃圾回收算法是否能够保证Web应用的响应时间如之前快捷？这些问题又是探索式测试的启发式线索，我们据此可以设计用例、执行测试。
伴随着对产品的了解越来越深入，探索式测试会逐步发现更多的隐藏的潜在风险，通常情况下在白盒状态下的探索式测试更具价值，因为其成果都是建立在坚实的知识和理解基础上，其指向更有针对性。
误区3：探索式测试就是随机测试。
探索式测试与随机测试的关系有些微妙。随机测试一般是指??在无文档、无计划下的软件测试，通常能够在测试初期快速地发现重要的缺陷或者在测试末期快速地进行回归测试，在某些资料中，将随机测试作为探索式测试的一部分。从表面上看，“随机”和“探索”两个词之间的确存在着一些联系，但是细一想，探索并不意味着随机，虽然是启发式的思维方法，但是其仍然遵循着一定的有序过程，虽然这种过程无法用文字记录下来，也无法适用于所有测试场景，但是其思维过程仍然具有合理性、有序性。所以，探索式测试是更高级的随机测试，它借鉴了随机测试中自由、开放的特质，但是又融入了启发式思维的元素，较之更为严谨、正式。
下面我们来看一看James Whittaker博士在讨论软件故障模型（Software Fault Model）时，对用户界面??采用探索式测试提出几条的启发式建议：
看到上面的建议，我们不会认为这是在做随机测试。针对用户界面的探索式测试显得很有“条理”，虽然随机测试也可能会涉及到上面提到的几条建议，但这是“随机”的，测试工程师无法控制测试覆盖的范围。探索式测试则不同，它会存在文字记录，会做覆盖率分析，比随机测试更为有序和可控。
误区4：探索式测试阶段在一般性测试之后。
这是一个普遍的误解，总有人认为探索式测试是一种后期测试，当一般性测试都结束之后，再搬出探索式测试来找找漏洞。这里再强调一遍，探索式测试是一种测试思想和方法，不是测试技术，它可以应用于广泛的一般性测试之中。正因为如此，在敏捷世界中，探索式测试和一般性测试所处的位置是一样的，没有前后之分，只要测试工程师需要探索式测试，那么它就可以存在。
以一个迭代周期为例，在计划阶段，测试工程师通过了解用户的需求和用户故事的制定和优先级评定来审视当前的测试计划和流程，挖掘现有计划中未覆盖的重要测试点，这也是探索式测试的组成部分。在正式开发阶段，测试工程师在测试过程中与开发人员不断的交流，从中寻找潜在的产品问题，有时候开发人员的一句提醒就可以成为测试的重要线索，而探索式测试就是要凸显这些发现问题的机会。在收尾阶段，测试工程师会总结此轮迭代的缺陷列表和分析，在回顾过程中可能发现其他的问题，为下一次的探索式测试做准备。
如果探索式测试位于迭代的后期，那么测试工程师就会错失计划、开发等阶段深入参与项目的机会，或者说即使深入参与了项目，但是如果没有探索式测试的意识贯穿于其中，那么发现问题的机会往往会从身边溜走，而这是测试工程师最忌讳的事情。所以，如果你需要探索式测试，那么就把这种思想应用于测试的各个阶段，尽可能最大化它的价值。
误区5：探索式测试需要老手来做。
探索式测试看起来很神秘、很酷，所以大家可能有些望而生畏，觉得是一个很高深的东西，怀疑自己是否适合做探索式测试，导致的结果就是在一个测试团队里可能会把探索式测试重担交给富有经验的老手来做。这种做法正确吗？我们不妨先来分析一下新手与老手的主要特点。
新手缺少测试经验，没有经过系统的学习和思维训练， 喜欢按照指令来做事情，不过接受新事物能力强，偶尔会因为不懂状况而搞出一些“小意外”；老手则是久经沙场，对测试技术和方法有充分的理解，喜欢有所突破，不过惯性思维影响了接受新鲜事物的意识。这里所说的特点是笔者在日常工作中观察的结果。分析完特点，再回头看看探索式测试，它是一种启发式的思维方式，我们需要创新，需要跳出常规测试的条条框框，需要找到“意外”的问题。对照新手、老手的特点，探索式测试更适合谁呢？这不是一个是非问题，新手、老手各有其优点：新手能够快速打开自己的创新思路，老手可以快速深入产品的内部机理。所以，不论是新手还是老手，都不要为自己贴上标签，探索式测试工程师需要一定的技能，具备了这些特质，你就可以出色地完成探索式测试，敏捷测试专家Lisa Crispin总结了必要的技能：
总结
探索式测试还处于摸索和发展阶段，有关对它的认识还在不断的演变当中，探索式测试作为一种测试方法，值得测试工程师应用于广泛的常规测试中，它需要建立在对产品深入了解的基础上，不是黑盒测试，它虽是启发式的思维方式，但是又具有条理性、可控性，探索式测试需要贯穿于整个测试周期中，以发挥其价值。探索式测试的适合人员不是以新手老手为衡量标准，必要的技能才是考量的要素。
| 欢迎光临 51Testing软件测试论坛 (http://bbs.51testing.com/) | Powered by Discuz! X3.2 |