51Testing软件测试论坛

 找回密码
 (注-册)加入51Testing

QQ登录

只需一步,快速开始

微信登录,快人一步

手机号码,快捷登录

查看: 2829|回复: 0
打印 上一主题 下一主题

[原创] 应用Selenium和Ruby进行面向领域的Web测试[2]

[复制链接]

该用户从未签到

跳转到指定楼层
1#
发表于 2008-8-14 10:28:22 | 只看该作者 回帖奖励 |倒序浏览 |阅读模式
2. Assertation
   只有行为还构不成测试,我们还要判断行为结果,并进行一些断言。简单回顾一下上面的例子,会发

现还有一些很重要的问题没有解决:   我怎么判断登录成功了呢?我如何才能知道真的是处在登录页面

了呢?中国IT室验实如果我调用下面的代码会怎样呢?
   $selenium.open url_of_any_page_but_not_login
   on LoginPage {}
   因此我们还需要向page object增加一些断言性方法。至少,每个页面都应该有一个方法用于判断是

否真正地达到了这个页面,如果不处在这个页面中的话,就不能进行任何的业务行为。下面修改

LoginPage使之包含这样一个方法:
   LoginPage.class_eval do
       include Test::Unit::Asseration
       def visible?   
           @driver.is_text_present() && @driver.get_location ==  
       end
   end
   在visible?方法中,我们通过对一些特定的页面元素(比如URL地址,特定的UI结构或元素)进行判

断,从而可以得之是否真正地处在某个页面上。而我们目前表达测试的基本结构是由on方法来完成,我

们也就顺理成章地在on方法中增加一个断言,来判断是否真的处在某个页面上,如果不处在这个页面则

不进行任何的业务操作:
   def on page_type, &block
       page = page_type.new $selenium
       assert page.visible?, "not on #{page_type}"
       page.instance_eval &block if block_given?
       page
   end
   这个方法神秘地返回了page对象,这里是一个比较取巧的技巧。实际上,我们只想利用page != nil

这个事实来断言页面的流转,比如,下面的代码描述登录成功的页面流转过程:
   on LoginPage do
       assert_equal 'Welcome!', welcome_message
       login_as :name => 'xxx', :password => 'xxx'
   end
   assert on WelcomeRegisteredUserPage
   除了这个基本断言之外,我们还可以定义一些业务相关的断言,比如在购物车页面里,我们可以定义

一个判断购物车是否为空的断言:
   def cart_empty?
       @driver.get_text('xpath=') == 'Shopping Cart(0)'
   end
   需要注意的是,虽然我们在page object里引入了Test::Unit::Asseration模块,但是并没有在断言

方法里使用任何assert*方法。这是因为,概念上来讲 page object并不是测试。使之包含一些真正的断

言,一则概念混乱,二则容易使page object变成针对某些场景的test helper,不利于以后测试的维护

,因此我们往往倾向于将断言方法实现为一个普通的返回值为boolean的方法。
   3. Test Data
   测试意图的体现不仅仅是在行为的描述上,同样还有测试数据,比如如下两段代码:
   on LoginPage do
       login_as :name => 'userA', :password => 'password'
   end
   assert on WelcomeRegisteredUserPage
   registered_user = {:name => 'userA', :password => 'password'}
   on LoginPage do
       login_as registered_user
   end
   assert on WelcomeRegisteredUserPage
   测试的是同一个东西,但是显然第二个测试更好的体现了测试意图:使用一个已注册的用户登录,应

该进入欢迎页面。我们看这个测试的时候,往往不会关心用户名啊密码啊具体是什么,我们关心它们表

达了怎样的测试案例。我们可以通过DataFixture来实现这一点:
   module DataFixture
       USER_A = {:name => 'userA', :password => 'password'}
       USER_B = {:name => 'userB', :password => 'password'}
       def get_user identifier   
           case identifier   
           when :registered then return USER_A   
           when :not_registered then return USER_B   
           end
       end
   end
   在这里,我们将测试案例和具体数据做了一个对应:userA是注册过的用户,而userB是没注册的用户

。当有一天,我们需要将登录用户名改为邮箱的时候,只需要修改DataFixture模块就可以了,而不必修

改相应的测试:
   include DataFixtureDat
   user = get_user :registered
   on LoginPage do
       login_as user
   end
   assert on WelcomeRegisteredUserPage
   当然,在更复杂的测试中,DataFixture同样可以使用真实的数据库或是Rails Fixture来完成这样的

对应,但是总体的目的就是使测试和测试数据有效性的耦合分离:
   def get_user identifier
       case identifier
       when :registered then return User.find '.'   
       end
   end
分享到:  QQ好友和群QQ好友和群 QQ空间QQ空间 腾讯微博腾讯微博 腾讯朋友腾讯朋友
收藏收藏
回复

使用道具 举报

本版积分规则

关闭

站长推荐上一条 /1 下一条

小黑屋|手机版|Archiver|51Testing软件测试网 ( 沪ICP备05003035号 关于我们

GMT+8, 2024-9-23 14:25 , Processed in 0.069911 second(s), 28 queries .

Powered by Discuz! X3.2

© 2001-2024 Comsenz Inc.

快速回复 返回顶部 返回列表