神奇的曲线:探索式测试与基于脚本的测试之关系

原来准备在上海MPD上和大家分享以前在新浪微博(查看原文:http://t.cn/zOSXmst)提到的 神奇的曲线:探索式测试与基于脚本的测试之关系,结果上周接到培训任务,去成都做了一场培训,和学员做了简单分享。

探索式测试(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,而且不同的组织环境或项目环境,随时间的投入是不一样的,这就是那两条神奇的曲线:

脚本测试 vs 探索式测试

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

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

项目开发生命周期

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

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

发表评论

电子邮件地址不会被公开。 必填项已用*标注

联系我
  • 上海市嘉定区曹安公路4800号同济大学软件学院
  • kerryzhu@vip.163.com