基于业务的Web自动化测试工具—Sahi

基于业务的Web自动化测试工具—Sahi

谈及开源Web  自动化 测试工具，相信很多人立刻会想到 Selenium。本文给大家介绍的是另一款开源Web  自动化测试工具Sahi。Sahi的网站上有关于与Selenium的对比，不过这不是我们今天探讨的主题。这篇 文章的主要目的是向读者简单的介绍一下Sahi并分享一下个人使用Sahi测试Dojo应用的经验，希望对大家能有所帮助。

　　 1. Web2.0应用测试的困境

　　在开始介绍Sahi之前，我们一起来看看在开发Web 自动化测试（特指Web 2.0应用）时常面临的两大技术问题。

　　 页面元素的识别

　　 根据个人经验，以下几点会给页面元素的识别带来障碍：

　　页面DOM树随着产品版本升级频繁发生变化。

　　页面元素没有id属性或者id属性值是动态的。

　　页面中具有相同属性的元素不止一个。

　　 通常的解决方案：

　　针对第一点，恐怕没有太好的解决方案，所以只能随着产品的改变更新自动化测试的代码。关于这一点，如果能够存在某种元素识别方法能够以最小的代码改动应对产品变化，那就是最理想的了。

　　针对第二点，解决方案是要求开发团队对所有测试中用到的元素增加用以识别元素的静态属性值。这听起来容易，但做起来未必简单。一来，开发团队通常以开发新产品功能为最高优先级，所以不太愿意花时间在这上面；二来，如果产品本身使用了某种封装后的技术框架，恐怕也会存在技术上的局限。

　　第三点事实上是识别的精确性的问题，这个问题可以使用XPath和CSS选择器来解决。但两者对于相对关系的限制都过于严格从而导致代码不能灵活适应DOM树的变化，最终会使维护成本直线上升。但是它很“脆弱”，当DOM树结构的变化很容易导致XPath的失效。并且，CSS选择器的使用还必须考虑浏览器的兼容性问题，如果需要支持的浏览器种类比较多，代码编写的成本也会比较高。

　　 那我们来看看Sahi关于元素识别的策略：

　　Sahi倡导使用“可见”属性识别元素，也就是元素的value, title等属性。这样做的好处很明显，就是可以减少对Firebug, Chrome Developer Tools的使用，从而提高开发效率。也就是“所见即所得”。当然，我们知道，只靠这些“可见”属性值是不够的。Sahi使用的元素识别方式是传入一个属性值，Sahi按照预先的设置进行查找。例如，_div(“name”)用来获取一个div, “name”或许是id也或许是name。Sahi允许用户针对每种元素类型定义新的属性并设置新的查找顺序，这也包括自定义属性名。

　　Sahi提供了基于上下文的元素识别API。目前它支持三种方式:

　　_in，在某个DOM节点下查找某个元素 (这显然好过用XPath或者CSS选择器)

　　_near，在某个元素附近查找符合条件的最近的一个元素。这也是个很有用的定位方式。

　　_under，在某个元素下方查找符合条件的最近的一个元素（前提是，两个元素需要有相同的偏移量（offset））, 比如table中同一个column中的cell就可以用这种方式相对定位。

　　Sahi API中所有的identifier参数都支持正则表达式，例如，_div(/name.*/) 用来识别所有以某种预属性值是name开头的div。

　　因此，Sahi基本上能够较好地解决前面提到的三大关于元素识别的障碍。

　 　页面等待

　　通常Web 2.0应用中有很多AJAX的应用。由于请求响应的返回是异步的，自动化测试程序如何决定是否可以继续下一个操作或者是开始验证呢？如果下一步操作在AJAX请求响应还没有返回时就执行了，毫无疑问会导致 测试用例的失败，并且是误判。

　　通常的做法是：

　　等待固定的时间，比如5秒。多长的等待算是合理呢？如果时间设置过短，被测应用在远程，由于网络因素使响应变慢，测试用例很可能失败；如果时间设置过长，即便在正常响应时间情况下，仍然要等待同样的时间，无疑是浪费。

　　轮询界面上某个指定元素，直至它出现从而继续下一步操作或者是超时，测试用例判定为失败。这种做法的坏处在于：一、必须找到这个“指定元素”，这往往不是那么容易的；二、如果AJAX在你所测应用中很普遍，这种代码可能会充斥你这个测试程序，从而导致开发速度下降。

　　Sahi能够判断AJAX请求是否已经处理完毕，然后继续下一步操作，这一点对用户是“隐式”的，也就是说用户不需要写任何代码。事实是，绝大多数情况下用户确实不需要自己写代码处理页面等待的问题，但是，有时应用的某个功能是执行多个AJAX请求完成的（例如，长时间操作的进度条显示），此时Sahi便无法胜任。这种情况下，用户只能利用Sahi提供的等待固定时间以及基于条件等待的API自己编写代码实现页面等待。