剖析短迭代
敏捷教练Dave Nicolette提出:我们应该如何设定迭代长度?是要根据发布周期的时间么?使用短迭代又有哪些好处?
作者 Geoffrey Wiseman译者 乔梁 发布于 2007年11月5日 上午1时24分
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 WebTest、Selenium、Testing和下一代功能测试工具。
英文原文链接:WebTest vs. Selenium: Real and Simulated Browser Testing
在项目中有同时使用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
是否可以开发这样一种中间层,即大家只写一套测试,即可以运行在WebTest上,
又可以运行在Selenium之上?这样,大家就可以得到WebTest和Selenium各自带来的好处
同感:
测试脚本的设计,开发和维护的工作量相当大,能够让正常跑起来实属不易。
不同厂商和组织提供许多测试工具,不过这些测试脚本并没有形成统一的标准和规范。
本文主要讲述了如何用JBoss Portlet Container 和JBoss Portlet Bridge创建新项目,怎样配置一个JSF应用去使用JBoss Portlet Bridge,以及JBoss Portlet Bridge所具备的功能。
在这篇文章里,Bryon Jacob和Chris Berry将和我们继续探讨AtomServer,它是基于Apache Abdera的完整Atom存储实现。作者还创建了几个Atompub规范扩展,其中包括自动标记、批处理和Feeds聚合。
InfoQ中文站的电子杂志《架构师》试刊第二期出版了!相比于上期,我们在内容的选择安排和版式上都根据读者的意见重新做了修正。“细节决定成败”,我们希望基于InfoQ中文站的专业内容,《架构师》能逐渐成为大家喜欢的电子刊物!
在本文中,Steven Haines探讨了Web应用性能调优问题。该领域过去更像是一门艺术而不是一门科学。他提出了一种称为基于等待调优的方法,使整个调优过程更加可度量,也因此更具科学性。
通常来说,改变技术路线时最艰难的部分是辨别语言语法之间的不同。这篇文章就为Java开发者提供了一份如何转向Flex基础语言ActionScript的指南。
本视频主要以财帮子为例,介绍了如何创建一个PV为百万级的Rails应用。其中包括:Rails应用的服务器架构、Rails Cache的优化、负载均衡的处理、Web服务器的调试、分布式解决方案、Open API的设计等等。
InfoQ首席架构师Alexandru Popescu在采访中谈论了InfoQ架构、Webwork与DWR、Hibernate与JCR、Hibernate可扩展性、最新的InfoQ视频流系统和InfoQ的未来规划。
2 条回复
回复