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

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

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

 

• James Bach, Exploratory Testing Explained
• Cem Kaner, James Bach, The Nature of Exploratory Testing, 2004

 

 

 

 

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

 

James Bach：What Is Exploratory Testing?And How It Differs from Scripted Testing

 

 

 

 

 

史亮：探索式测试：基本概念

 

 

 

 

 

回到正题，谈谈探索式测试与基于脚本的测试（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？