談及開源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自己編寫代碼實現頁面等待。