BT

如何利用碎片时间提升技术认知与能力? 点击获取答案

WebTest比拼Selenium:模拟和真实浏览器上的测试

| 作者 Geoffrey Wiseman 关注 0 他的粉丝 ,译者 乔梁 关注 7 他的粉丝 发布于 2007年11月6日. 估计阅读时间: 6 分钟 | Google、Facebook、Pinterest、阿里、腾讯 等顶尖技术团队的上百个可供参考的架构实例!

Web应用软件的功能测试工具有很多种,但它们最根本的差异在于:某些工具可以驱动一个或多个真正的浏览器以便得到完全真实的环境,比如Selenium,而另一些工具只是模拟Web浏览器的操作,比如Canoo WebTest。Marc Guillemot这两种工具进行了对比,根据他的观点,WebTest以13:5的比分获胜。

Marc就以下方面内容对这两种工具进行了对比和评分:

Canoo WebTest
Selenium
Tied
Reports Browser Fidelity Testing Ajax
Speed Beginner Friendly
Integration into Development Process Support for Badly Formatted HTML Code
Scalability Multi-Language Support
Capture JS Errors

Documentation

Predictable Behaviour

XPath Support

Extensibility

Data-Driven Tests

Internationalization Support

Support for Non-HTML Content

Marc认为,这些测试不够快,但“WetTest 的工作不多,所有测试都运行在JVM上”。他也提到Selenium无法捕获Javascript错误导致的测试失败:

只要你的单元测试通过了,你就不在意编辑错误了吗?肯定不是!但事实上,Selenium就是这样的,因为它不能检测到你的应用程序中的javascript错误(除非这些测试直接导致测试失败)。

另外,他也提到Ajax 测试(一般来说,大家都认为这是浏览器模拟器的弱点)是一种纽带:

与一般的想法相反,你并不需要在浏览器中运行你的JavaScript测试来测试AJAX功能。HtmlUnit和WebTest可以完成这样的工作,甚至可以称为完全胜任这样的工作,因为它允许更好地测试页内请求,使不可预知的浏览器行为成为可预知的(参见我前一个帖子)。

另一方面,他相信Selenium可以支持多种语言,“Selenium RC可以与不同的开发语言(Java、Ruby、PHP等等)结合,而WebTest只能与Ant结合使用”,还支持不规范的Html以及真实的浏览器:

HtmlUnit对JavaScript支持已经大幅改善,但还不能(且永远不可能)与真正的浏览器行为一模一样。尽管Selenium也更改了一些Web应用的JavaScript正常执行,但它使用真正的浏览器工作,所以已经和浏览器的标准行为相当接近啦。

作为Canoo WebTest和HtmlUnit的首席开发人员,Marc明显倾向于他所接纳的这种形式的工具,在与他讨论之前,请一定要先读一下他的分析报告:

显然,作为WebTest(和HtmlUnit)的负责人,我的确是有倾向性的。但是,我也有多年开发和维护庞大的功能测试套件的经验。客观一点儿说,我可能在其它方向上过分担心了,应该相信Selenium。当然,我将不断地修正我在Selenium理解上的错误。但请您在开始批评我之前,一定要读一下这篇文章。

已经总结了这些反馈。Vitaly认为,WebTest和Selenium的关系可以看作是苹果和桔子的关系。“Selenium,WebTest(HttpUnit),DBUnit,JUnit和其它测试工具是互补的。有些事用这个工具可能完成,用另外一个工具却不成。”还有些人讨论了录制回放和脚本测试各自的优点,以及测试可维护性。Murali推荐使用PragmaticQA Element

Christian反驳了WebTest对Ajax支持的说法,并提及在他的应用中,“由于HtmlUnit不能解析Dojo的import子句,即使最简单的页面也会抛出异常。”

而Simon认为,对浏览器保真度最重要的一点就是:

象WebTest这样的工具有点太理论化了,它想证明代码完全正常工作,但是只能在理想环境下,与生产环境相去甚远。真正的用户使用的是IE或Firefox,而Selenium可以让我们在“真实的”条件下做测试,例如有内存泄漏问题的脆弱的浏览器,和不符合标准的代码。

没有客户使用WebTest使用的引擎,这意味着尽管我们知道它在某种环境上运行得很好,但并不意味着真的没有麻烦。相反,我们的Selenium测试运行在Firefox之上,也运行在IE之上,所以它会捕获跨平台使用中发生的很多问题。

最后,Kent Tong设想了结合两种方法的途径

是否可以开发这样一种中间层,即大家只写一套测试,即可以运行在WebTest上,又可以运行在Selenium之上?这样,大家就可以得到WebTest和Selenium各自带来的好处了。

你用过这些工具吗,或者其它功能测试工具?这会吸引你参与讨论下一代功能测试工具吗?更多的信息,请阅读Canoo WebTestSeleniumTesting下一代功能测试工具

英文原文链接:WebTest vs. Selenium: Real and Simulated Browser Testing

评价本文

专业度
风格

您好,朋友!

您需要 注册一个InfoQ账号 或者 才能进行评论。在您完成注册后还需要进行一些设置。

获得来自InfoQ的更多体验。

告诉我们您的想法

允许的HTML标签: a,b,br,blockquote,i,li,pre,u,ul,p

当有人回复此评论时请E-mail通知我

真实的环境下测试 by 胡 凯

在项目中有同时使用JWebUnit和Selenium, 虽然每天都在Selenium缓慢的运行中煎熬, 但是依然推荐使用, 进行这样功能测试的目的之一就是希望在所有目标环境中这部分功能都是可以正常工作的。 也就是在真实的条件下作测试, 在JWebunit中正确通过的功能, 能否在IE6/7, firefox,中正确工作? 所有人大概心里都没底。

JWebUnit的速度很快,但是在运行的过程中开发者缺乏对Web项目的最直观的体验, 而且其使用的JS 引擎对于某些正确的js也会抛出异常,后来不得不关闭JWebUnit的javascript engine.

事实上JWebunit测试可以用做整个开发流程的Checkin gate, 将覆盖基本功能,容易失败的测试用JWebunit完成,在测试通过后就可以提交,然后进行下一步的工作,同时在CI Server上在多个浏览器中运行较为缓慢的Selenium作为acceptance gate。 这大概是能兼顾速度和“真实”的一种方式。

--
Hu Kai

Re: 真实的环境下测试 by blogbin avatar

是否可以开发这样一种中间层,即大家只写一套测试,即可以运行在WebTest上,
又可以运行在Selenium之上?这样,大家就可以得到WebTest和Selenium各自带来的好处

同感:
测试脚本的设计,开发和维护的工作量相当大,能够让正常跑起来实属不易。
不同厂商和组织提供许多测试工具,不过这些测试脚本并没有形成统一的标准和规范。

允许的HTML标签: a,b,br,blockquote,i,li,pre,u,ul,p

当有人回复此评论时请E-mail通知我

允许的HTML标签: a,b,br,blockquote,i,li,pre,u,ul,p

当有人回复此评论时请E-mail通知我

2 讨论

登陆InfoQ,与你最关心的话题互动。


找回密码....

Follow

关注你最喜爱的话题和作者

快速浏览网站内你所感兴趣话题的精选内容。

Like

内容自由定制

选择想要阅读的主题和喜爱的作者定制自己的新闻源。

Notifications

获取更新

设置通知机制以获取内容更新对您而言是否重要

BT