一.Sahi簡(jiǎn)介

　　1. Web2.0應(yīng)用測(cè)試的困境

　　在開(kāi)始介紹Sahi之前，我們一起來(lái)看看在開(kāi)發(fā)Web 自動(dòng)化測(cè)試(特指Web 2.0應(yīng)用)時(shí)常面臨的兩大技術(shù)問(wèn)題。

　　1. 頁(yè)面元素的識(shí)別

　　根據(jù)個(gè)人經(jīng)驗(yàn)，以下幾點(diǎn)會(huì)給頁(yè)面元素的識(shí)別帶來(lái)障礙：

　　頁(yè)面DOM樹(shù)隨著產(chǎn)品版本升級(jí)頻繁發(fā)生變化。

　　頁(yè)面元素沒(méi)有id屬性或者id屬性值是動(dòng)態(tài)的。

　　頁(yè)面中具有相同屬性的元素不止一個(gè)。

　　通常的解決方案：

　　針對(duì)第一點(diǎn)，恐怕沒(méi)有太好的解決方案，所以只能隨著產(chǎn)品的改變更新自動(dòng)化測(cè)試的代碼。關(guān)于這一點(diǎn)，如果能夠存在某種元素識(shí)別方法能夠以小的代碼改動(dòng)應(yīng)對(duì)產(chǎn)品變化，那是理想的了。

　　針對(duì)第二點(diǎn)，解決方案是要求開(kāi)發(fā)團(tuán)隊(duì)對(duì)所有測(cè)試中用到的元素增加用以識(shí)別元素的靜態(tài)屬性值。這聽(tīng)起來(lái)容易，但做起來(lái)未必簡(jiǎn)單。一來(lái)，開(kāi)發(fā)團(tuán)隊(duì)通常以開(kāi)發(fā)新產(chǎn)品功能為高優(yōu)先級(jí)，所以不太愿意花時(shí)間在這上面;二來(lái)，如果產(chǎn)品本身使用了某種封裝后的技術(shù)框架，恐怕也會(huì)存在技術(shù)上的局限。

　　第三點(diǎn)事實(shí)上是識(shí)別的精確性的問(wèn)題，這個(gè)問(wèn)題可以使用XPath和CSS選擇器來(lái)解決。但兩者對(duì)于相對(duì)關(guān)系的限制都過(guò)于嚴(yán)格從而導(dǎo)致代碼不能靈活適應(yīng)DOM樹(shù)的變化，終會(huì)使維護(hù)成本直線上升。但是它很“脆弱”，當(dāng)DOM樹(shù)結(jié)構(gòu)的變化很容易導(dǎo)致XPath的失效。并且，CSS選擇器的使用還必須考慮瀏覽器的兼容性問(wèn)題，如果需要支持的瀏覽器種類比較多，代碼編寫(xiě)的成本也會(huì)比較高。

　　那我們來(lái)看看Sahi關(guān)于元素識(shí)別的策略：

　　Sahi倡導(dǎo)使用“可見(jiàn)”屬性識(shí)別元素，也是元素的value， title等屬性。這樣做的好處很明顯，是可以減少對(duì)Firebug， Chrome Developer Tools的使用，從而提高開(kāi)發(fā)效率。也是“所見(jiàn)即所得”。當(dāng)然，我們知道，只靠這些“可見(jiàn)”屬性值是不夠的。Sahi使用的元素識(shí)別方式是傳入一個(gè)屬性值，Sahi按照預(yù)先的設(shè)置進(jìn)行查找。例如，_div(“name”)用來(lái)獲取一個(gè)div， “name”或許是id也或許是name。Sahi允許用戶針對(duì)每種元素類型定義新的屬性并設(shè)置新的查找順序，這也包括自定義屬性名。

　　Sahi提供了基于上下文的元素識(shí)別API。目前它支持三種方式:

　　_in，在某個(gè)DOM節(jié)點(diǎn)下查找某個(gè)元素 (這顯然好過(guò)用XPath或者CSS選擇器)

　　_near，在某個(gè)元素附近查找符合條件的近的一個(gè)元素。這也是個(gè)很有用的定位方式。

　　_under，在某個(gè)元素下方查找符合條件的近的一個(gè)元素(前提是，兩個(gè)元素需要有相同的偏移量(offset))， 比如table中同一個(gè)column中的cell可以用這種方式相對(duì)定位。

　　Sahi API中所有的identifier參數(shù)都支持正則表達(dá)式，例如，_div(/name.*/) 用來(lái)識(shí)別所有以某種預(yù)屬性值是name開(kāi)頭的div。

　　因此，Sahi基本上能夠較好地解決前面提到的三大關(guān)于元素識(shí)別的障礙。

　　2. 頁(yè)面等待

　　通常Web 2.0應(yīng)用中有很多AJAX的應(yīng)用。由于請(qǐng)求響應(yīng)的返回是異步的，自動(dòng)化測(cè)試程序如何決定是否可以繼續(xù)下一個(gè)操作或者是開(kāi)始驗(yàn)證呢?如果下一步操作在AJAX請(qǐng)求響應(yīng)還沒(méi)有返回時(shí)執(zhí)行了，毫無(wú)疑問(wèn)會(huì)導(dǎo)致測(cè)試用例的失敗，并且是誤判。

　　通常的做法是：

　　等待固定的時(shí)間，比如5秒。多長(zhǎng)的等待算是合理呢?如果時(shí)間設(shè)置過(guò)短，被測(cè)應(yīng)用在遠(yuǎn)程，由于網(wǎng)絡(luò)因素使響應(yīng)變慢，測(cè)試用例很可能失敗;如果時(shí)間設(shè)置過(guò)長(zhǎng)，即便在正常響應(yīng)時(shí)間情況下，仍然要等待同樣的時(shí)間，無(wú)疑是浪費(fèi)。

　　輪詢界面上某個(gè)指定元素，直至它出現(xiàn)從而繼續(xù)下一步操作或者是超時(shí)，測(cè)試用例判定為失敗。這種做法的壞處在于：一、必須找到這個(gè)“指定元素”，這往往不是那么容易的;二、如果AJAX在你所測(cè)應(yīng)用中很普遍，這種代碼可能會(huì)充斥你這個(gè)測(cè)試程序，從而導(dǎo)致開(kāi)發(fā)速度下降。

　　Sahi能夠判斷AJAX請(qǐng)求是否已經(jīng)處理完畢，然后繼續(xù)下一步操作，這一點(diǎn)對(duì)用戶是“隱式”的，也是說(shuō)用戶不需要寫(xiě)任何代碼。事實(shí)是，絕大多數(shù)情況下用戶確實(shí)不需要自己寫(xiě)代碼處理頁(yè)面等待的問(wèn)題，但是，有時(shí)應(yīng)用的某個(gè)功能是執(zhí)行多個(gè)AJAX請(qǐng)求完成的(例如，長(zhǎng)時(shí)間操作的進(jìn)度條顯示)，此時(shí)Sahi便無(wú)法勝任。這種情況下，用戶只能利用Sahi提供的等待固定時(shí)間以及基于條件等待的API自己編寫(xiě)代碼實(shí)現(xiàn)頁(yè)面等待。

　　2. Sahi的工作原理

　　圖1.Sahi架構(gòu)圖

　　Web自動(dòng)化測(cè)試的本質(zhì)是模擬用戶事件(單擊、雙擊、輸入文本等操作)獲取結(jié)果狀態(tài)并驗(yàn)證是否符合預(yù)期。如上圖所示，Sahi的核心一個(gè)用Java編寫(xiě)的代理服務(wù)器。它位于Web應(yīng)用與瀏覽器當(dāng)中。當(dāng)HTTP請(qǐng)求響應(yīng)通過(guò)Sahi代理服務(wù)器時(shí)，便被注入了用來(lái)回放測(cè)試用例的Javascript。這些Javascript中，一部分是Sahi本身用來(lái)驅(qū)動(dòng)腳本運(yùn)行的代碼，另一部分是用戶代碼被Sahi代理服務(wù)器解析成的Javascript。目前Sahi支持三種編程語(yǔ)言：Sahi腳本， Java和Ruby。

　　3. Sahi控制器

　　運(yùn)行/bin/dashboard.sh可以啟動(dòng)Sahi的Dashboard窗口。Dashboard窗口中顯示了所有Sahi預(yù)配置并且用戶系統(tǒng)上存在的瀏覽器。如果需要手工添加新的瀏覽器，可以點(diǎn)擊下方的Configure修改瀏覽器配置文件。

　　圖2.Sahi Dashboard

　　點(diǎn)擊瀏覽器圖標(biāo)，會(huì)彈出相應(yīng)的瀏覽器窗口(此時(shí)Sahi已經(jīng)自動(dòng)給瀏覽器配置了Sahi代理服務(wù)器)。