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

　　选择一些能够引起底层数据运算的输入域，多次重复输入相同的值，观察结果是否相同。

　　对每一个输出域，思考其在不同情况下出现的不同结果显示，然后将这些情况分别应用到测试中，观察输出域是否和预料相同。

　　对每一个输出域，思考哪些结果是不能或者不应该出现的，然后想办法触发这些非法的结果，看看是否能够实现。

　　尝试触发递归式的函数调用，如文档中嵌套自身文档，超链接中嵌套自身链接，类似的错误。

　　尝试触发数据的存储溢出，观察由此导致的结果。

　　看到上面的建议，我们不会认为这是在做随机测试。针对用户界面的探索式测试显得很有“条理”，虽然随机测试也可能会涉及到上面提到的几条建议，但这是“随机”的，测试工程师无法控制测试覆盖的范围。探索式测试则不同，它会存在文字记录，会做覆盖率分析，比随机测试更为有序和可控。

　　误区4：探索式测试阶段在一般性测试之后。

　　这是一个普遍的误解，总有人认为探索式测试是一种后期测试，当一般性测试都结束之后，再搬出探索式测试来找找漏洞。这里再强调一遍，探索式测试是一种测试思想和方法，不是测试技术，它可以应用于广泛的一般性测试之中。正因为如此，在敏捷世界中，探索式测试和一般性测试所处的位置是一样的，没有前后之分，只要测试工程师需要探索式测试，那么它就可以存在。

　　以一个迭代周期为例，在计划阶段，测试工程师通过了解用户的需求和用户故事的制定和优先级评定来审视当前的测试计划和流程，挖掘现有计划中未覆盖的重要测试点，这也是探索式测试的组成部分。在正式开发阶段，测试工程师在测试过程中与开发人员不断的交流，从中寻找潜在的产品问题，有时候开发人员的一句提醒就可以成为测试的重要线索，而探索式测试就是要凸显这些发现问题的机会。在收尾阶段，测试工程师会总结此轮迭代的缺陷列表和分析，在回顾过程中可能发现其他的问题，为下一次的探索式测试做准备。

　　如果探索式测试位于迭代的后期，那么测试工程师就会错失计划、开发等阶段深入参与项目的机会，或者说即使深入参与了项目，但是如果没有探索式测试的意识贯穿于其中，那么发现问题的机会往往会从身边溜走，而这是测试工程师最忌讳的事情。所以，如果你需要探索式测试，那么就把这种思想应用于测试的各个阶段，尽可能最大化它的价值。

　　误区5：探索式测试需要老手来做。

　　探索式测试看起来很神秘、很酷，所以大家可能有些望而生畏，觉得是一个很高深的东西，怀疑自己是否适合做探索式测试，导致的结果就是在一个测试团队里可能会把探索式测试重担交给富有经验的老手来做。这种做法正确吗?我们不妨先来分析一下新手与老手的主要特点。

　　新手缺少测试经验，没有经过系统的学习和思维训练， 喜欢按照指令来做事情，不过接受新事物能力强，偶尔会因为不懂状况而搞出一些“小意外”;老手则是久经沙场，对测试技术和方法有充分的理解，喜欢有所突破，不过惯性思维影响了接受新鲜事物的意识。这里所说的特点是笔者在日常工作中观察的结果。分析完特点，再回头看看探索式测试，它是一种启发式的思维方式，我们需要创新，需要跳出常规测试的条条框框，需要找到“意外”的问题。对照新手、老手的特点，探索式测试更适合谁呢?这不是一个是非问题，新手、老手各有其优点：新手能够快速打开自己的创新思路，老手可以快速深入产品的内部机理。所以，不论是新手还是老手，都不要为自己贴上标签，探索式测试工程师需要一定的技能，具备了这些特质，你就可以出色地完成探索式测试，敏捷测试专家Lisa Crispin总结了必要的技能：

　　小心的观察者：观察不正常和不期望的结果，并对正确性的假定很小心，能够细微的观察软件特征或模式。

　　认真的思考者：在运行中检查测试并将其改到非预期的方向上，能够解释寻找缺陷的逻辑并提供清晰的测试状态。

　　系统的叛逆者：思维严密、系统化，同时还要具有多样化的观点。

　　资源的挖掘者：探索测试人员应该发掘更多他们可以使用的工具、技术、测试数据、朋友和信息源。

　　总结

　　探索式测试还处于摸索和发展阶段，有关对它的认识还在不断的演变当中，探索式测试作为一种测试方法，值得测试工程师应用于广泛的常规测试中，它需要建立在对产品深入了解的基础上，不是黑盒测试，它虽是启发式的思维方式，但是又具有条理性、可控性，探索式测试需要贯穿于整个测试周期中，以发挥其价值。探索式测试的适合人员不是以新手老手为衡量标准，必要的技能才是考量的要素。

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