告诉你什么是探索性测试

上一篇 / 下一篇 2012-10-26 09:52:11 / 个人分类：杂谈

　　第一次听到探索性测试这个词是去年的10月份。一个微博上的朋友写了一篇关于探索式测试的blog，之后断断续续的阅读了不少相关资料，参加了数场相关讨论，但是还是没有得到一个系统的理解。8月29日晚上有幸聆听了测试顶级专家Micheal Bolton（不是唱歌的那个，是做测试的）关于探索性测试的演讲，解决了数个困扰我很久疑惑。我终于得以把这些知识理清，下面我会把我所理解的探索性测试跟大家做一个分享。

M%xR p9cYF4mZ0　　探索性测试的历史和主旨

　　探索性测试是近十几年内才形成体系的一种测试思想，它的核心理论由Jame Bach在1995年提出，并在数年间由学者和业界的测试工作者不断完善而形成的理论。测试大师Cem Caner在02年首次以“Exploratory Testing”（探索性测试）的名称在学界和业界开始相关的演讲和培训。探索式测试的方法论在这10余年期间不断被测试先锋们不断磨炼和修正，终于在11年，担任过微软和Google测试总监的James Whittaker出版了《探索性测试》一书，让探索式测试在业内获得了广泛关注，并掀起了一股学习和研究热潮。

　　探索性测试的核心思想是：测试是一个不断学习，不断探索的创造性过程。测试计划、分析、设计、执行其实是相辅相成，相互交织的。依照传统的测试理论，把这四部分在时间上严格区分会限制人的创造性和，进而影响测试效果。同时静态的测试方案和测试用例不足以覆盖对动态系统的测试。探索性测试强调不断的学习、探索，不断的修正测试方法，十分强调人的能动性是它最大的亮点。

　　探索性测试实际上是将戴明环方法（PDCA）做到了极致，也可以说做到了时间上的交织和同步------在做测试执行的时候，测试者也在做测试分析与设计，同时还可能在修改测试计划，这时候我们就会发现我们现在沿用的一些测试文档例如测试计划文档、测试需求、测试用例这些东西就不大好用了，因为修改频繁，全部记录下来代价太大，且强制划分文档类型会打乱思维。因此探索性测试强调灵活的记录测试的产物,而不必循规蹈矩，这在形式上与传统的测试（探索性测试将传统称为依托脚本的测试，script.test）是有极大矛盾的，这也是探索性测试在业界引起的最大争议。

　　探索性测试有迹可循么？51Testing软件测试网V^8@e:^.R

　　答案是肯定的。比照一下探索性测试的思想和我们的日常工作，大部分测试者其实已经在做着某种程度的探索性测试的工作，如果你在发挥能动性，使用多种获取需求的方法，你在做探索性测试;如果你根据测试实际系统的反馈修正测试用例，你在做探索性测试;如果你在做我们常说的自由测试，你也在做探索性测试，但是这肯定不是全部。51Testing软件测试网 atA#e7P-o-E*c

#p.UhJK5_y0G0　　探索性测试是有迹可循有具体实践方式的。Cem Kanner提供了一套详细的实践方案，你可以从下面链接获得：https://intranet2.arraynetworks.net/prx /000/http/www.testingeducation.org/BBST/exploratory/BBSTExploring.pdf

B.O(_Q&l-v|Y0　　当然你也可以使用James Bash和Micheal Boltonl的方法：

"ki Fx(@m!a-n0　　http://www.developsense.com/resources/et-dynamics3.pdf51Testing软件测试网Mk byY6X

9?j8Q%GqA&n0　　你也可以读一下James Whittaker的书：探索式软件测试方法（这本书跟上面两家不是一个流派，不过也能学到很多具体的测试方法，很实用。）

6p(ab`M0　　http://product.dangdang.com/product.aspx?product_id=20834199

/o@T:{wP4x_TR0　　以及我们国内一线测试人员写的一本中文书：探索式测试实践之路（还未读过）

　　http://product.dangdang.com/product.aspx?product_id=22844980

|.G Ok7CL9O0　　浏览上面的资源你可以得到相当具体的技术和方法，因此这里不在赘述了。除了James Whitaker那本书，剩下3份资源都应该属于上下文驱动流派（context-driven school），是一个路数。据我所知国内的一流测试专家邰晓梅女士也在实现一套基于测试驱动的探索性测试实践方案，让我们一起期待：）。51Testing软件测试网2e}6des1_

*i m$HMbU0　　其实探索性测试和所谓的传统测试并不是冲突和矛盾的，在实践过程中也不会走两个极端。我在交流过程中问了Micheal Bolton他们是否矛盾的问题。他的回答是：“我们可以找两个端点，一端是把人当作生产线螺丝的严格依照脚本进行测试方式，一端是把人比作一个小孩的完全探索性测试，实际工作中，我们肯定是在这两个点连线中的某一个点。具体这个点在哪里，要看它在哪里能够更好的开展测试。”正所谓法无定法，我们其实完全没有必要去恪守、捍卫教条，并非争出个高下来，黑猫白猫，抓住老鼠就是好猫。

　　探索性测试的应用情况

'AS6_V;oz0　　据我所知，目前探索性测试还处在一个方兴未艾的阶段。国外的少部分业界领先的公司（微软，google等）已经从某种程度上应用了探索性测试方法。在国内，百度，淘宝等知名企业也开始从一定程度上来使用探索性测试，在近期的Chinatest大会上，他们也都各自分享了自己的实践方案，值得一提的是，Chinatest大会上，探索性测试分会场是最火爆的，参与人数是其它会场的快2倍了。因此在国内大家还是对探索性测试相当有兴趣，大家都希望能够把它引入实践来提升实际测试能力。相信在未来的几年，一定是探索性测试大发展的时期。51Testing软件测试网{5h@BF

]9RM:V.U#@fuud5M0　　探索性测试能应用到我们的工作中来么？

HT^9A a"G0　　答案必然也是肯定的。依照我的判断，它对于我们近期重点工作项都可能会带来一定的益处。51Testing软件测试网UF A"v@t

6VicQ5y/h1P)E0　　● 于分布式测试

　　目前我们和重庆的分布式测试合作主要采取了“分层测试”的模式，即北京同事编写测试用例，重庆的同事来进行执行。从目前的情况来看，分层测试有效的实现了北京重庆之间的测试协作，分流了很多北京的测试工作量，且保持了测试质量不下降，测试进度没有延长，可以说分层测试是比较成功的。但是，我们的分布式测试是否还可以做进一步改进呢？仔细想想还是有的。51Testing软件测试网I-G5Ww-ma.s

x&qF"`U,Fi0　　随着分布式测试的不断发展，由于重庆测试资源的源源不断补充，解决测试人力资源不足问题将不再会是工作的重点，工作的重点将会慢慢转移到如何提高整体测试能力上来。目前，重庆测试人员能力在逐步提高，已经有了一定的测试设计能力，严格依照测试用例进行测试的方式会一定程度上限制他们能力的发展，但是项目的复杂性及重庆的异地因素又导致重庆无法有效独立完成测试的分析及设计工作。再者，测试工作的精华很大一部分在于测试执行部分，如果放弃测试执行，也不利于北京测试人员的发展。探索式测试的核心思想认为测试过程是不能被简单分割的，我们可以采用这个思想对我们的测试流程做一定改造。

X OZ-W2]*P x H:`0　　即，从一定程度上打破这种严格意义上的阶段区分，例如，如让重庆同事参与部分测试用例分析、设计工作，北京同事也参与用例执行工作等。两边可以进一步增进交流，进一步释放双方的能动性，达到提升航信测试部门整体测试水平的目的。

5y)V#My0cL$`b0　　● 于自动化：

　　自动化是减轻重复劳动的利器，但是自动化是无法代替手工测试的。因为测试是一项依靠人的创造性的活动。人类可以感知，可以联想，可以推理，可以创造，这些元素都是测试执行期间必不可少的因素，而目前别说是自动化脚本，就是最好的人工智能程序也离上述元素差着十万八千里。因此自动化只能是测试活动的一部分。51Testing软件测试网d8p2A"J-eh"RM

　　由于自动化可以有效减轻重复劳动，探索性测试索要避免的就是被重复性劳动牵涉太多精力，其实两者是一个非常好的互补。有一个非常好的办法可以让两者很好的结合起来，那就是，及时的整理探索性测试中的用例，将它们及时变成自动化脚本。这种做法其实跟我们经常说的持续集成的思想是一致的。同时，良好的自动化脚本也是测试资产的一个积累，从某种程度上弥补了探索性测试不太注重文档的问题。

　　● 于敏捷：

$G4Ja T*xE:?F8e0　　探索性测试简直就是为敏捷而生的，敏捷宣言中的个体和互动高于流程和工具、工作的软件高于详尽的文档、响应变化高于遵循计划与探索性测试的核心思想不谋而合。随着敏捷开发在公司的深入开展，我们可以尝试性的将探索式测试与敏捷开发结合起来。根据同其它公司的同行交流，这种方法能够带来很好的效果。