首页 | 新闻 | 新品 | 文库 | 方案 | 视频 | 下载 | 商城 | 开发板 | 数据中心 | 座谈新版 | 培训 | 工具 | 博客 | 论坛 | 百科 | GEC | 活动 | 主题月 | 电子展
返回列表 回复 发帖

使用 Sahi 实现 Web 自动化测试(1)

使用 Sahi 实现 Web 自动化测试(1)

Web 测试背景随着 Web 技术和互联网的发展,Web 应用产品越来越丰富,基于 Web 页面测试的需求与日俱增。在当前全球软件都在追求高效、敏捷的开发模式的大背景下,Web 自动化测试成为了新一波技术探讨和研究的热潮。因为传统的手工测试不仅效率低,并且测试质量受限于测试人员的一些情绪和心情。若当一个测试人员带着烦躁情绪来测这些繁杂的大量重复性工作,测试的质量令人担忧。更何况,当这项测试工作涉及到全球化方面的测试时,多语言版本的测试工作导致该测试工作量的成倍增加,这无疑是一项巨大的考验!
Sahi 的特性和优势:当提及面向 Web 的自动化测试,相信许多读者会想到或者说使用过 Selenium、Watir 等工具,而对于 Sahi 就可能比较陌生。首先,让我们先来了解下 Sahi 工具。它是一款印度公司 Tyto Software 开发的成熟的开源 Web 自动化测试工具。Sahi 简单易用,能良好支持 Ajax 和 Web2.0 技术,同时适用于敏捷和传统的不同测试模式。那么,它与其他非常流行的 Web 自动化测试工具有哪些不同和优势呢?让我们将其与主流自动化测试工具 Selenium 和 Watir 来进行一番对比,请参考图 1:
图 1. Sahi 与其他工具的对比从上图的对比可以看出,Selenium 支持的脚本语言比较丰富,且自带 Selenium IDE 自动录制工具,Watir 执行的速度相对其他较快。而 Sahi 同样具备了自带的录制器,且支持几乎所有浏览器,且对 JS 支持较好,拥有页面等待判断机制,内置 Java 异常报告,支持 Ajax 等优势。
下面,本文将详细介绍一下 Sahi 的几大优势。
基于上下文的页面识别机制:大多数如 Selenium 等 Web 自动化测试工具或是自动化框架,都采用类似基于 DOM 的定位策略、Xpath 定位策略和 id、name、identifier 等页面元素定位策略。
Identifier 定位是最普遍的一种定位方式,当不能识别为其它定位方式后,默认为 identifier 定位。在这种策略下,第一个使用 id 的页面元素将被识别出来,如果没有使用指定 id 的元素,那么将识别第一个名字与指定条件相符的元素。
例如,identifier 识别 username 元素的定位策略:identifier=username
Id 定位是在知道元素具体 id 特征的情况下的一种更精确定位。例如,定位页面元素 loginFrom:id=loginFrom
name 定位方式是去识别第一个匹配名称属性的 UI 元素。如果多个元素拥有相同的名称属性,可以使用 value 过滤器来进一步优化您的定位策略。例如,定位页面元素为 username:
name=username
Xpath 定位是在 XML 中定位元素的方法,而 HTML 可以被看作是 XML 的一种实现。XPath 扩展了上面 id 和 name 定位方式,提供了绝对路径和相当路径两种查找方式。
绝对路径:html/body/div[1]/div[1]/div[3]/div[1]/form/span/input[1]
相对路径查找://div[@id='fm']/form/span/input
然而,在实际的情况下,页面元素并非如预期般明确。一些动态页面的 DOM 树常常随着 Web 产品的更新而频繁改变。许多的元素值如 ID、Name 等在代码中并不是必须的,常常会缺省。并且,属性值往往不是唯一对应的,页面中有时会存在相同属性的元素。当缺省 id 值或是 Xpath 定位失效时,上述这几种查找定位方式往往显得无助和脆弱。
Sahi 采用了一种主动查找的机制,它不受限于特定的元素属性。在没有 ID、Name 值的情况下,它可以使用一些如“title,value”等属性,这些都是页面可见的属性,所见即所得。同时,Sahi 会通过传入这些可见可识别的属性值,来按照 Sahi 预设的机制进行查找识别。Sahi 允许开发者对每一种元素设置不同属性和特定的查找顺序,包括那些自定义的属性名。所以 Sahi 相对于其他的 Web 自动化测试工具更灵活更开放。
比如,_link(“valueName”)用来定位一个定义为“valueName”的 link,这里的 valueName 并不一定是 value 的属性值,也可以是它的    id、title 等。
前面提到了 Sahi 主动查找的机制,那么它是如何去查找 DOM 节点下的特定元素的呢?Sahi 主要提供了三种基于上下文的元素 API:_in,_near 和_under。
从字面意思上,我们不难理解,_in 是指在某个 DOM 节点下查找某个元素,这比 Xpath 的不管是绝对路径或是相对路径查找都来的灵活,不会因为 DOM 树内部结构发生变化而导致路径失效找不到元素的问题。
_near 是指在某个元素附近查找相应设定规则条件的最近一个元素,这对于一个页面中有多个相同属性值的情况提供了一个很好的解决方式,使查找的范围更精确。
_under 是指在某个元素下方开始查找,找到符合条件的最近一个元素,一般_under 都适用在具有相同偏移量的同一列中。下面,我们来看一个例子,加深对 Sahi 这种基于上下文识别查找机制的理解:
图 2. 案例网页假设,在图 2 显示的 Web 页面的所有 text box 的 name=”q”,那么,Sahi 的侦探器通过一些标识来鉴别它们,如(_textbox("q"), _textbox("q[1]")和_textbox("q[2]"))。
如果,我们要定位“Ruby for Rails”那一行的 text box,即_textbox("q[1]")。传统的元素识别会遇到多个相同属性元素的问题,即使是 Xpath 的定位方式也会因为在它前面加了一行新的数据而导致 Xpath 定位失败的情况。
这时 Sahi 可以通过_near 这种方式来定位:
1
_textbox("q",_near(_cell("Ruby for Rails")))




当要定位 check box 时,我们又会发现,“Ruby for Rails”这一行有“Recommend”和“Already own”两个 check box,为了更准确地定位,我们可以结合_under,例如:_checkbox(0,_near(_cell("Ruby for Rails")),_under(_cell("Recommend")))。
如果在整个页面中存在多个这样的表格,我们还可以用_in 来进一步缩小范围,如:_checkbox(0,_near(_cell("Ruby for Rails")),_under(_cell("Recommend")),
_in(_cell("Cost))).
同时值得一提的是,Sahi API 中的 identifier 参数都支持正则表达式,例如,_div(/name.*/) 用来识别所有以某种预属性值是 name 开头的 div。
隐式页面加载响应等待机制:现在越来越多的 Web 应用采用 Ajax 的应用技术,来支持网页数据的异步请求响应。当前一般的 Web 自动化测试工具没有一个智能的处理机制,来判断何时可以继续下一个操作。像 Selenium 等自动化测试工具通常会在脚本中人为来设定一个固定的等待时间。但这往往被证实不一定是准确的。实际测试中,人是很难准确判断每一个操作请求需要的合理时间数值。因为,等待时间设置过短,下一步操作在被测应用请求还未返回就执行了,或是由于网络因素使正常的响应时间变长,都可能导致测试过程找不到相应的页面元素,从而导致整个测试用例失败的情况。而如果把时间设置过长,又会造成在一些正常响应过程中的不必要等待的时间浪费,降低了测试效率。
当然,一些测试人员会在自动化测试脚本中加入一些自定义的代码。通过轮询界面上某个指定元素,来判断请求响应是否返回,进而决定继续下一步操作或者是超时。但是,这样的查找过程会导致整个脚本代码变得非常臃肿,加大了开发的成本。更何况,在一个动态的页面找到指定的元素本身就不是一件容易的事。
Sahi 内置了智能的页面等待机制,能够自动判断 Ajax 请求是否已经处理完毕,然后继续下一步操作。并且,这一点对于用户是“隐式”的,不需要增加额外的代码。
返回列表