如何正确理解敏捷测试中的探索性测试的含义

　　探索式测试(Exploratory Testing)是敏捷测试中的重要组成部分，其价值与一般性测试如用户故事测试或者自动化测试不同，它所关注的是“意料之外”的软件缺陷，探索式测试作为一个研究性、启发性和严肃性并存的测试方法，是一般性测试的重要补充。随着敏捷测试的推广，探索式测试逐渐受到大家的关注和重视。本文主要探讨了测试工程师在探索式测试方面的一些误区，并尝试纠正这些问题。

　　误区1：探索式测试是一种测试技术。

　　探索式测试本身不是一种测试技术，相反，它是一种可以应用于广泛测试技术的方式或态度。所以很遗憾，测试工程师可能在现实世界中找不到一款名为“探索式测试工具”的软件来帮助他们直观地完成探索式测试。《测试计算机软件》作者Cem Kaner明确地将探索式测试定义为“一种强调每位测试人员自由和责任的测试，每个测试人员通过将学习、测试设计、测试执行和测试结果解释作为贯穿项目的平行活动，从而持续地优化他们的工作价值”。

　　例如，在Web应用项目中，UI功能测试必不可少。探索式测试作为一种思想就可以而且应该贯穿于UI功能测试中。

　　具体来说，测试工程师在某个时刻准备按照事先编写好的测试用例开始测试某个网站用户注册的页面时，一步步的走下去，输入框、日期选择器......一切看起来都很顺利，但是等一下，探索式测试是一种启发式的方法，在循规蹈矩地做着一般性功能测试的时候，我们需要同时来点不一样的东西。

　　盯住用户注册界面!大脑或许可以这样开始思考：我看到光标在闪动，噢，我之前测试是用鼠标点击的，如果用户只用键盘操作，光标在各个输入域的遍历是顺序的吗?动手测试之!接下来，鼠标点击一下提交按钮，注册成功!噢，如果失败会是什么样子?用户需要重新填写所有数据吗?动手测试之!下一步，用户注册页面测试完毕，不过，它有帮助文档或者提示信息吗?作为测试工程师我们可能已经非常熟悉产品了，可第一次访问网站并准备注册信息的用户了解必要的内容吗?注册完的用户到底知不知道自己有什么权限呢?动手测试之......

　　凡此种种，都是些启发式思维的小例子，从中可以看出，探索式测试作为一种方法，可以运用于任何一般性测试中，如单元测试、功能测试、性能测试、系统测试等等，只要有探索性的思想并贯彻于实践中，探索式测试就会发挥它的重要作用，找到一般性测试没有涵盖的危险区域。

　　误区2：探索式测试是一种黑盒测试。

　　测试工程师和测试经理对黑盒测试并不陌生。黑盒测试指的是测试人员把待测产品看做一个包装完好的盒子，无法看到其中的实现细节，只通过产品规格说明书、用户反馈等途径来设计测试用例并执行、分析。探索式测试作为一种测试方法，在黑盒测试中确实可以得到??很好地应用，比如在上面提到的UI功能测试中，探索式测试可以作为一种有益的补充发现常规测试顾及不到的测试点。但是，探索式测试提倡的原则之一就是“努力深入了解待测产品”。常规测试用例覆盖范围不全面的一个重要原因就在于对产品的理解不够深刻，所以难以挖掘出深层次的问题。探索式测试更趋近于白盒测试，要求测试工程师对产品有比较透彻的理解，从而创造性地提出和执行一些“出乎意料”的测试。

　　举个例子，假设我们正在测试一款Web应用，部署在java/" target="_blank" >Java虚拟机为基础的Web服务器(以WebSphere Application Server为例)上。按照常规测试用例，我们可能测试了多用户并发访问的情况、集群环境的情况等等，看起来黑盒测试就OK了。

　　接下来，我们尝试从白盒测试的角度开始探索式测试。瞧瞧产品用例和源代码，噢，看到了“synchronized (......)”、“lock.unlock()”这样的语句，很自然地，我们意识到产品在使用多线程编程，这意味着什么呢?多核!哦，常规测试中产品是在单核还是多核环境中?单核上的性能怎么样?多核上的性能有提高吗?线性程度有多大?负载均衡吗?这些问题成为了探索式测试的猎物，设计测试用例，并动手执行之，然后分析结果。

　　接着看代码，看到了很多“new ......”，还看到了产品代码中预分配了一些内存池，很自然地想到内存管理，当然Java的内存管理都由Java虚拟机掌控，测试工程师还能做些什么?有的!如果仔细研究Java虚拟机的机制，就会发现初始堆大小、最大堆大小、垃圾回收日志是否输出、垃圾回收的不同算法等设置，默认情况下Web应用的运行情况如何?随着用户增加，堆会不会由于太小而导致运行失败?堆大小变化了，原来的垃圾回收算法是否能够保证Web应用的响应时间如之前快捷?这些问题又是探索式测试的启发式线索，我们据此可以设计用例、执行测试。

　　伴随着对产品的了解越来越深入，探索式测试会逐步发现更多的隐藏的潜在风险，通常情况下在白盒状态下的探索式测试更具价值，因为其成果都是建立在坚实的知识和理解基础上，其指向更有针对性。

　　误区3：探索式测试就是随机测试。

　　探索式测试与随机测试的关系有些微妙。随机测试一般是指??在无文档、无计划下的软件测试，通常能够在测试初期快速地发现重要的缺陷或者在测试末期快速地进行回归测试，在某些资料中，将随机测试作为探索式测试的一部分。从表面上看，“随机”和“探索”两个词之间的确存在着一些联系，但是细一想，探索并不意味着随机，虽然是启发式的思维方法，但是其仍然遵循着一定的有序过程，虽然这种过程无法用文字记录下来，也无法适用于所有测试场景，但是其思维过程仍然具有合理性、有序性。所以，探索式测试是更高级的随机测试，它借鉴了随机测试中自由、开放的特质，但是又融入了启发式思维的元素，较之更为严谨、正式。

　　下面我们来看一看James Whittaker博士在讨论软件故障模型(Software Fault Model)时，对用户界面??采用探索式测试提出几条的启发式建议：

　　确保所有类型的输入错误信息都触发一次，努力找出开发人员可能会忽视的无效值。

　　针对所有输入域，尝试错误类型的数值和可能会被错误对待和处理的字符串。研究产品运行的操作系统和编程语言的局限性和差异性，创建一些存在问题的字符串，并执行测试。

　　在每个输入域，键入所允许的最长字符。

原文转自：http://www.ltesting.net