qileilove

blog已经转移至github,大家请访问 http://qaseven.github.io/

探索式测试与基于脚本的测试之关系

探索式测试(Exploratory Test)经常被简称为ET,由 Cem Kaner 1983年建立的测试概念,这几年随着敏捷方法而大行其道。敏捷方法的迭代频率很快,每个迭代时间很短,自然想到如何减少文字工作,避免写测试用例,ET自然是一个很好的选择。ET简单理解为测试设计与执行同步进行。

   不过,我们以前熟悉测试中的错误猜测法、Ad hoc测试等方法,不管Cem Kaner承认不承认,ET概念很有可能来源于这些先前的概念,在这些概念的基础上丰富它,试图给ET建立一个比较系统的体系,例如引入基于上下文驱动 (Context-driven)、基于session的测试等。想当初,我们用错误猜测法、Ad hoc测试方法时,一定也会考虑业务或功能的上下文关系,没有上下文还做什么测试?也会考虑某些场景,更多会考虑一些特别的场景,如人们常说的 corner case,right? 当然,ET和错误猜测法、Ad hoc测试是有区别的。

  谈谈探索式测试与基于脚本的测试(Script-base Test 或 Scripted Testing,ST)之关系,不论是在传统测试流程还是在敏捷测试中, 这两者是相辅相成的,谁也不能代替谁,正如James Bach也谈到“Balancing Exploratory Testing with Scripted Testing,... two approaches to testing are fully compatible” 。而且在不同的场景有各自的优势,例如:

  ● 发现问题来看,探索式测试效率会更高些,甚至高得多;

  ● 测试乐趣看,也会优先选择探索式测试;

  ● 敏捷中新功能测试会选择探索式测试;

  ● 探索式测试不易实现自动化,所以自动化测试先需要脚本,然后执行;

  ● 归测试比较确定,需要不断运行,自然会选择基于脚本的测试(ST);

  ● 产品线来看,开发周期长,复用会大大提高效率,ST也具有很大优势。

  所以,在一个项目中,经常是同时采用这两种方法——ST和ET,而且不同的组织环境或项目环境,随时间的投入是不一样的,这就是那两条神奇的曲线:

  当初我没有在线上标ST和ET,就是因为每根线都可能是ET或ST,例如:

  1、如果自动化测试水平低或没有自动化测试,就需要在前期有更多的ET,在发现产品问题的同时学习产品、更深地理解产品,并通过发现问题来完善测试用例。而为了降低产品质量风险,后期需要进行更系统的测试,特别是要完成大量回归测试、对产品质量有一个完整的评估,需要执行ST。由于自动化水平低,这时人力都投在ST上,就没有经历做ET,而且也不必要。

  2、如果自动化水平高,前期需要开发脚本,ST的投入自然大。但自动化执行时,虽然会运行大量用例,但解放了生产力,测试人员有更多时间投入ET。

  实际环境所处的场景会更多,不管怎样,先要清楚自己测试工作中有什么问题,然后采用合适的方法来解决问题。或者说,要清楚自己的目标,是让团队获得激情还是让公司处在稳定的不败之地、还是为了尽快发现Bug还是提高产品的质量,方法何时使用、如何使用、谁使用等都可能不同。即先问Why?What?然后才考虑How、Who、Where?

  关于探索式测试和脚本测试还有许多东西可以谈,时间关系,今天就谈到这里。

  出自:http://blog.csdn.net/kerryzhu/article/details/7489319

posted on 2012-05-15 09:33 顺其自然EVO 阅读(188) 评论(0)  编辑  收藏 所属分类: 测试学习专栏


只有注册用户登录后才能发表评论。


网站导航:
 
<2012年5月>
293012345
6789101112
13141516171819
20212223242526
272829303112
3456789

导航

统计

常用链接

留言簿(54)

随笔分类

随笔档案

文章分类

文章档案

搜索

最新评论

阅读排行榜

评论排行榜