本文首先列舉了 Dojo 應用 UI
自動化測試所面臨的挑戰(zhàn)，進而引出設(shè)計 Dojo 應用 UI 自動化測試的框架時應考慮的一些原則。對于正從事 Web UI 自動化測試
工作的讀者（即便所測試的應用不是 Dojo 應用）或者對這方面感興趣的讀者，本文都有一定的參考價值。
隨著富 Internet 應用（RIA）的不斷興起，各種 JavaScript 開發(fā)工具包的功能也在不斷增強，Dojo 正是其中的佼佼者。Dojo 提供了一套完整的開發(fā)解決方案，包括核心的 JavaScript 庫、簡單易用的小部件（Widget）等。當越來越多的企業(yè) Web 應用選擇 Dojo 作為前端技術(shù)框架的時候，作為測試人員，我們便需要考慮如何有效地進行自動化測試開發(fā)與實施。Dojo 是一個 Web 前端技術(shù)框架，所以這里所說的自動化測試，具體是指 Web UI 自動化測試，更進一步說是 Web 2.0 UI 自動化測試。
考慮到 Web UI 的特性以及 Web UI 自動化測試的投入產(chǎn)出比（ROI），關(guān)于是否應該進行 Web UI 自動化測試，測試領(lǐng)域存在不同的觀點。我個人認為還是有必要的。不過這不是本文要討論的重點。決定 Web UI 自動化測試成敗（或者說收效）的因素有很多，技術(shù)框架的選取和設(shè)計是其中之一，個人認為也是比較重要的一個因素。本文將從 Dojo 應用 UI 自動化測試面臨的諸多挑戰(zhàn)談起，進而討論針對 Dojo 應用 UI 自動化測試的框架適用的設(shè)計原則。
雖然本文探討的主題是 Dojo 應用的 UI 自動化測試，但不少內(nèi)容也適合其他的 Web 2.0 應用。希望讀者朋友或多或少都能從中獲益。
Dojo 是什么？
Dojo 是一個 JavaScript 實現(xiàn)的開源 DHTML 工具包。它是在幾個項目捐助基礎(chǔ)上建立起來的(nWidgets，f(m)，Burstlib) 。 Dojo 的最初目標是解決開發(fā) DHTML 應用程序遇到的一些長期存在的歷史問題，現(xiàn)在，Dojo 已經(jīng)成為了開發(fā) RIA 應用程序的利器：
Dojo 讓您更容易地為 Web 頁面添加動態(tài)能力，您也可以在其它支持 JavaScript 的環(huán)境中使用 Dojo ；
利用 Dojo 提供的組件，您可以提升 Web 應用程序的可用性和交互能力；
Dojo 很大程度上屏蔽了瀏覽器之間的差異性，因此，您可以不用擔心 Web 頁面是否在某些瀏覽器中可用；
通過 Dojo 提供的工具，您還可以為代碼編寫命令行式的
單元測試代碼。
Dojo 的打包工具可以幫助您優(yōu)化 JavaScript 代碼，并且只生成部署應用程序所需的最小 Dojo 包集合。
Dojo 應用 UI 自動化測試面臨的挑戰(zhàn)
Dojo 應用 UI 自動化測試面臨的挑戰(zhàn)可以歸為兩類：開發(fā)階段的挑戰(zhàn)和維護階段的挑戰(zhàn)。
開發(fā)階段的挑戰(zhàn)：
異步請求的處理
元素定位
Dojo 復雜性
產(chǎn)品復雜性
維護階段的挑戰(zhàn)：
頻繁的 UI 更改
Dojo 升級
下面，我們具體講解每一種挑戰(zhàn)。為了后文講解設(shè)計原則時能方便的對應到這些挑戰(zhàn)，我們用英文字母標記每個挑戰(zhàn)。
A. 異步請求的處理
在傳統(tǒng)的 Web 應用中，用戶每點擊頁面上的超鏈，瀏覽器就會向服務器發(fā)出一個請求，等待服務器做出響應，然后返回一個完整新網(wǎng)頁，但在大多數(shù)情況下用戶不得不忍受頁面閃爍和長時間的等待。為了解決傳統(tǒng)的 Web 應用中出現(xiàn)的問題，出現(xiàn)了 Ajax。通過使用 Ajax 頁面和應用向服務器請求它們真正需要的東西，也就是頁面中需要修改的部分，服務器就提供哪部分，這使得通信量更少，更新更少，用戶等待頁面刷新更短，用戶更加滿意。
但是，Ajax 的到來對 Web UI 自動化測試卻未必是好消息。Web UI 自動化測試框架的執(zhí)行方式類似于一個“隊列”:用戶定義了一系列的頁面操作和驗證，之后 Web UI 自動測試框架把它們按順序一一執(zhí)行。在傳統(tǒng) Web 應用中，由于每次向服務器端發(fā)起請求都會導致頁面跳轉(zhuǎn)，Web UI 自動化測試框架能很容易地判斷出合適該執(zhí)行下一個動作。 但是，Ajax 的行為是異步的，也就是說，用戶的操作跟服務器端的處理現(xiàn)可以是并行的，不存在嚴格的順序。起初，這給 Web UI 自動化測試框架的開發(fā)者帶來了困擾，而且很長一段時間里這個問題都沒有被很好的解決。
起初，Web UI 自動化測試開發(fā)人員主要有兩種解決方案：硬編碼等待時間和基于條件的等待。
硬編碼等待時間： 這種方式是指在代碼中指定一個靜態(tài)等待時間，比如指定等待 30 秒后執(zhí)行下一個操作。通常，這種數(shù)值的設(shè)置來源于經(jīng)驗。可以想象，如果這個等待時間比實際等待時間小，自動化腳本執(zhí)行就會失敗。而且，不幸的是，這樣情況的確經(jīng)常發(fā)生。隨著測試環(huán)境的變化，實際需要的等待時間事實上是一個變量。以下幾個因素都有可能導致它發(fā)生變化：
測試服務器在遠程還是本地：毫無以為，由于網(wǎng)絡(luò)的影響，服務器如果在遠程，等待時間就會增加。
使用的瀏覽器： 瀏覽器 JavaScript 引擎的執(zhí)行速度對等待時間也有影響。根據(jù)經(jīng)驗， Firefox 和 Chrome 都比 IE 要快。因此，如果用的是 IE，等待時間也會增加。 測試運行時的網(wǎng)絡(luò)環(huán)境：如果測試時的網(wǎng)速較慢，等待時間會增加。
測試服務器的負載：測試服務器可能是獨占也可能是共享的。如果自動化測試執(zhí)行時的服務器負載較大，也會導致等待時間增加。
對于上述硬編碼等待時間的問題，Web UI 自動化測試開發(fā)人員一般有如下對策。
盡量將等待時間設(shè)置的大一些。這樣做存在一些問題。一來未必能保證在任何情況下該值都足夠大；二來它意味著無論服務器在本地還是遠程瀏覽器是快是慢，執(zhí)行時間都一樣，這對于服務器在本地以及瀏覽器比較快的測試環(huán)境是很大的時間成本浪費。
設(shè)置放大因子。這種方法是在編碼的時候給等待時間乘上一個因子。這個因子或者是硬編碼的，比如定義在一個參數(shù)文件中。當測試環(huán)境比較好的時候，設(shè)置小一點；測試環(huán)境比較差的時候，設(shè)置大一點。 高級一些的，可以動態(tài)地設(shè)置這個因子。比如，可以把某一個操作的執(zhí)行時間作為計算該因子數(shù)值的參照。這個方法使情況得到了部分改善，但是仍然不能保持其執(zhí)行的穩(wěn)定性。
基于條件的等待： 由于硬編碼等待時間方式的不穩(wěn)定性，Web UI 自動化測試框架開始支持“基于條件的等待”。這種方式是采用“輪詢”的機制判斷是否可以開始執(zhí)行一個操作。假設(shè)，當前要執(zhí)行的操作是一個按鈕點擊動作。這個按鈕默認是被禁用的，當頁面從服務器端加載了數(shù)據(jù)之后這個按鈕才被啟用。因此，如果要保證這個操作成功，就需要“輪詢”這個按鈕的狀態(tài) – 直到發(fā)現(xiàn)它被啟用了，才執(zhí)行點擊操作。 如果由于存在 bug 按鈕一直不啟用怎么辦？所以，基于條件的等待的方法需要設(shè)置“超時時間”。如果超過這個時間按鈕還沒有啟用，就認為這個測試用例失敗了。所以，大家發(fā)現(xiàn)了，這個超時時間的設(shè)置其實還是個“硬編碼等待時間”，所以某種程度上，這種方式仍存在硬編碼等待時間方式的弊端。這種方式的另外一弊端是它帶來了額外的編碼成本，并且自動化測試代碼中可能充斥了許多條件判斷代碼，而它們本身不完成我們的“業(yè)務”目標，僅是輔助代碼。
B. 元素定位
一般的 Web UI 自動化測試編碼無非包含這樣幾個步驟：定位及獲取元素，執(zhí)行操作以及驗證結(jié)果。而且，通常 Web UI 自動化測試開發(fā)人員在元素定位和獲取這個步驟上花費相當多的時間。大多數(shù) Web UI 自動化測試開發(fā)人員希望所需獲得的元素能有一個靜態(tài) id 屬性。根據(jù)規(guī)范，id 屬性的值在 DOM 樹中必須是唯一的，因此通過 id 屬性就可以很簡單并且準確地定位元素。但是，這樣的需求常常不是產(chǎn)品的需求，而只是為了滿足 Web UI 自動化測試代碼開發(fā)的簡便。所以，對于產(chǎn)品開發(fā)人員來說，給每個需要在 Web UI 自動化測試中使用到的元素增加靜態(tài) id 屬性不是高優(yōu)先級的工作。而且，從技術(shù)角度上講，有些 Dojo 應用中的元素也無法設(shè)置靜態(tài) id 屬性。
對于 Dojo 應用，情況又復雜了一些。圖 1 展示的是一個 Dojo 按鈕小部件在 Firebug 中呈現(xiàn)的 DOM 結(jié)構(gòu)。最外層的 SPAN 元素上有一個 widgetid 屬性，內(nèi)部的 SPAN 元素上定義了 id 屬性，共同點是它們都是由一個前綴和一個動態(tài)的數(shù)字構(gòu)成的。這個數(shù)字是由運行時該 Dojo 小部件在整個 DOM 樹上的位置決定的，索引從 0 開始。因此可知，圖 1 中的按鈕小部件是整個 DOM 樹上的第二個按鈕。Widgetid 是每個 Dojo 小部件都有的屬性，如沒有特別指定的話，它就是如圖中所示的動態(tài)結(jié)構(gòu)。
所以，如何通過這種動態(tài)格式的 id 和 widgetid 定位獲取頁面中的元素成為另一個 Dojo 應用 UI 自動化測試開發(fā)的挑戰(zhàn)。
圖 1. Dojo 按鈕小部件
C. Dojo 復雜性
讀者不要誤會，這里說的“Dojo 復雜性”不是說 Dojo 使用起來很復雜，而是說 Dojo 應用最后生成的頁面 DOM 結(jié)構(gòu)比較復雜。如圖 1 所示，原本用一個 INPUT 元素實現(xiàn)的按鈕，現(xiàn)在嵌套了四層 SPAN 元素。 所以，Dojo 小部件已不再是一個簡單的 HTML 元素，而是由諸多 HTML 元素組合而成的。Dojo 按鈕小部件只是一個簡單的例子，對于像表格、日歷之類的 Dojo 小部件，它們的結(jié)構(gòu)更加復雜。針對某個 Dojo 小部件的操作也不再像操作普通的 HMTL 元素那樣簡單（調(diào)用某個 JavaScript 方法就可以實現(xiàn)），而是要具體定位響應事件（比如點擊事件）的 Dojo 小部件的內(nèi)部對應元素，然后觸發(fā)具體的事件。
多數(shù)的 Web UI 自動化測試框架只能處理基本的 HTML 元素。這是合理的，因為框架開發(fā)者不知道最終的自動化測試開發(fā)者使用什么樣的前段框架，因而只能提供最基本的“小磚塊”。如果具體應用的自動化測試開發(fā)者有任何需求，可以在其之上進行二次開發(fā)。
對于 Dojo 應用的 UI 自動化測試開發(fā)者來說，可以選擇直接定位和操作 Dojo 小部件內(nèi)部元素的方法。但是，這樣做的弊端很明顯 – 缺乏重用性。 因此，應該將 Dojo 小部件作為最小操作單元。如何將 Dojo 小部件模塊化成為了又一個挑戰(zhàn)。
D. 產(chǎn)品復雜性
產(chǎn)品復雜性包含兩層意思。
一是指產(chǎn)品本身頁面層次多，界面元素多以及功能邏輯復雜。Web UI 自動化測試開發(fā)過程中，編寫定位元素的代碼通常占據(jù)很大一部分時間，編寫這部分代碼的工作量直接受頁面元素多少的影響。功能復雜度一般不太會直線性增加編碼工作量，但是有可能會增加調(diào)試的工作量。
二是指產(chǎn)品頁面 DOM 結(jié)構(gòu)復雜。Web 2.0 應用的開發(fā)模式與傳統(tǒng) Web 應用的開發(fā)模式有很大的不同。傳統(tǒng) Web 應用開發(fā)基本上是一個頁面對應一個物理的程序文件（比如，.jsp 文件）。而 Web 2.0 應用的開發(fā)通常是整個應用只有少數(shù)幾個物理的程序文件，頁面的跳轉(zhuǎn)和呈現(xiàn)通過 JavaScript 更新 DOM 樹結(jié)構(gòu)完成。所以，在瀏覽器中的跳轉(zhuǎn)頁面實際上往往只是 DOM 樹結(jié)構(gòu)被更新了。這樣，就有可能帶來這樣一個問題：DOM 樹上同時存在多個頁面的 DOM 子節(jié)點。如果其他頁面有與當前要定位的元素類似的元素，就很容易出現(xiàn)“錯誤定位”。
如何能在產(chǎn)品變得越來越復雜的同時，盡可能的減少開發(fā)工作量，也是一個 Dojo 應用 UI 自動化測試開發(fā)者要解決的問題。
E. 頻繁的 UI 更改
頻繁的 UI 更改在“敏捷開發(fā)”大行其道之后成為了又一個讓 Web UI 自動化測試開發(fā)者頭痛的問題。迭代中的產(chǎn)品 UI 經(jīng)常隨著客戶的反饋不斷地修改，于是自動化測試代碼需要跟著更新。由此帶來的 Web UI 自動化測試腳本巨大的維護工作量也成為了很多人反對進行 Web UI 自動化測試的重要原因之一。
難道，因此就放棄 Web UI 自動化測試嗎？我認為，作為 Web UI 自動化測試開發(fā)者需要考慮的應該是：在這樣的現(xiàn)實之下，如何能夠最小化頻繁的 UI 更改帶來的代碼維護工作量。從經(jīng)驗來看，并非 Web UI 上的任何一點點更改都會導致自動化測試代碼的修改。這個問題的解決極大程度上依賴于測試框架適應 DOM 結(jié)構(gòu)變化的能力以及元素定位時所使用的方法。
F. Dojo 升級
Dojo 升級有可能會引發(fā) Dojo 小部件 DOM 結(jié)構(gòu)的變化，繼而帶來自動化測試代碼的維護工作量增加。盡管根據(jù)經(jīng)驗，這一點的影響不是很顯著，因為目前一些常見的 Dojo 小部件（比如按鈕輸入框之類）都已經(jīng)十分成熟，但是還是需要考慮。如果一個小部件的 DOM 結(jié)構(gòu)發(fā)生了變化，如何能夠最小化對自動化測試代碼的影響？這是 Dojo 應用 UI 自動化測試開發(fā)者要考慮的問題。
Dojo 應用 UI 自動化測試框架挑選（設(shè)計）原則
講解完了所有的挑戰(zhàn)，讓我們來看看當我們要設(shè)計或者選取一個 Dojo 應用 UI 自動化測試框架時需要考慮的因素和原則。
概括起來，主要有以下八大原則。括號內(nèi)是該原則所對應解決的挑戰(zhàn)。
隱式等待（A）
位置關(guān)系操作（B，E）
封裝 Dojo 小部件 （C，D，F(xiàn)）
IBM 框架 （E）
代碼生成（D）
測試數(shù)據(jù)的管理（D）
錄制與編碼 （D）
接下來，我們一一來講解每一條原則。為了幫助讀者理解，講解過程中會引用內(nèi)部自行開發(fā)的 Dojo 應用 UI 自動化測試框架 Water Bear 的部分內(nèi)容。
隱式等待
挑戰(zhàn) A 提到了異步請求處理的問題也描述了幾種解決方案，但都不甚理想。最理想的情況是自動化測試框架能夠自己處理異步請求的問題，并且不需要開發(fā)者編寫任何代碼。這就是所謂的“隱式等待”機制。
目前，不少 Web UI 自動化測試框架都具備“隱式等待”功能，比如 Sahi 和 Selenium。Water Bear 使用的是 Sahi。當然，Sahi 同時也提供了對“硬編碼等待時間”和“基于條件的等待”的 API 支持（因為，有些情況下還是不得不使用“硬編碼等待時間”或“基于條件的等待”）。根據(jù)經(jīng)驗，超過 90%的情形是 Sahi 的“隱式等待”功能可以覆蓋的，但是像“進度條”這樣的功能就不得不用“基于條件的等待”。在進度條達到 100%之前，前端代碼不斷地向后臺發(fā)起 Ajax 請求輪詢進度狀態(tài)。這種情形，Sahi 無法智能地得知哪一個 Ajax 請求的返回是“最后一個”，因此，就無法決定何時可以執(zhí)行下一個動作。
清單 1. “進度條”代碼示例
BrowserCondition cond = new BrowserCondition(getBrowser()) {
public boolean test() throws ExecutionException {
return getBrowser().isVisible(getBrowser().div("100%").in(es));
}
};
getBrowser().waitFor(cond, waitTime);
清單 1 展示了 Water Bear 中部分實現(xiàn)進度條功能的代碼，也就是 Sahi“基于條件的等待”的代碼。在 test 方法返回“真”之前（也就是代碼發(fā)現(xiàn)文本“100%”出現(xiàn)了），waitFor 方法一直處于輪詢狀態(tài)。waitTime 是一個超時時間。如果這個時間達到了，即便 test 方法仍然返回“假”，waitFor 還是返回。通常，這時已經(jīng)可以認定 Web UI 的功能執(zhí)行出現(xiàn)了問題。
只所以把“隱式等待”放在第一個來講，是因為 Web UI 自動化測試框架是否具備該功能對于 Dojo 應用 UI 自動化測試實施成敗是至關(guān)重要的。
位置關(guān)系操作
Dojo 應用 UI 自動化測試框架應當具備根據(jù)給定對象定位其他對象的功能。這種相對的位置關(guān)系通常包括：在里面、在附近、在左面（右面）以及在上面（下面）等等。目前，Sahi 支持所有這些位置關(guān)系查找，另外還支持“在上面或者下面”以及“在左面或者右面”。這當中，“在里面”使用的最為頻繁。
為什么要使用位置關(guān)系操作？有以下幾個原因：
準確定位頁面對象。在挑戰(zhàn) D 中，我們提到了在一個 DOM 樹中有可能存在與要查找的對象屬性與 DOM 結(jié)構(gòu)完全相同的對象。尤其對于“確定”或者“取消”按鈕，這種情況很常見。這時，必須要通過限定父對象來縮小查找范圍。一般來講，只要限制到當前頁面的邊界元素能夠阻止跨頁面 DOM 節(jié)點查找就夠了（因為，當前頁面有哪些對象一目了然，但是其他頁面的 DOM 節(jié)點是由運行時的操作控制的，無法預料）。
封裝 Dojo 小部件。這一點會在下面具體講解。
提供更豐富的查找方式，如根據(jù)“標簽”查找 Dojo 小部件。通常，文本框的左側(cè)會有一個文本，比如“名稱：”。如果，該文本框沒有任何其他合適的靜態(tài)屬性用來定位，就可以通過“在附近”查找的方法，先定位“名稱：”所在的元素，再找到這個文本框。
當 DOM 樹結(jié)構(gòu)未發(fā)生“功能性”變化時，避免自動化測試代碼改動。所謂“功能性”變化是指頁面上增加、替換或者移除了控件，比如按鈕或者輸入框等。當發(fā)生這些變化時，自動化測試代碼不得不修改。但，如果發(fā)生的僅僅是 DOM 樹結(jié)構(gòu)上的變化，比如增加了不可見的 DIV 或者 SPAN 元素，只要位置關(guān)系操作使用得當，自動化測試代碼可以做到不需要修改。
我們來看一個例子。圖 2 左邊是所測應用現(xiàn)在的狀態(tài)：一個 Dojo 按鈕小部件被一個 DIV 元素包圍。在代碼中，我們用按鈕的文本“OK”并限制在圖示的 DIV 中來定位它。之后，DOM 樹結(jié)構(gòu)發(fā)生了變化，變成了圖 2 右邊的樣子，在原有的 DIV 元素和按鈕之間增加了兩層 DIV 元素。此時，代碼不需要更改，因為這個“OK”按鈕仍然在之前的 DIV 元素里。但是，如果用 XPath 定位元素，這種情況就很有可能要修改了。
圖 2. 位置關(guān)系操作示例
封裝 Dojo 小部件
在挑戰(zhàn) C 中，提到了 Dojo 小部件 DOM 結(jié)構(gòu)的復雜性。最好的方式是封裝 Dojo 小部件，將每個 Dojo 小部件作為一個整體操作。
Water Bear 使用的編程語言是 Java。它將頁面中的 Dojo 小部件映射成一個 Java 類，以此封裝所有該 Dojo 小部件的行為。由于 Sahi 支持“在里面”的位置關(guān)系操作，使得封裝更加容易 – 只需要定位到 Dojo 小部件的最外層 HTMl 元素（一般是 DIV），其他的元素定位都限制在該元素之內(nèi)。從而，即便頁面上同時有兩個同類型的 Dojo 小部件，也不會出現(xiàn)跨部件的錯誤操作。
圖 3 展示了 Water Bear 中定義的與 Dojo 小部件對應的一些類。最上層父類 WebElement.java 代表一般的 HTML 元素，它封裝了基本 HTML 元素的方法。DojoWidget.java 是所有 Dojo 小部件類的抽象。它定義了所有 Dojo 小部件類的通用方法，比如 getWidgetId()等。所有 Dojo 小部件類均繼承自 DojoWidget.java 并定義自己的方法，比如 ComboBox.java 需要定義 selectByText 方法。
圖 3. Water Bear 中與 Dojo 小部件對應的類
那么，頁面上 Dojo 小部件如何和這些類對應關(guān)聯(lián)起來呢？Water Bear 中通過.wdef 文件把兩者關(guān)聯(lián)起來。
清單 2. .wdef 文件示例
org.waterbear.core.widgets.dijit.Textbox=div|textbox|labelnear|dijit_form_ValidationTextBox,\
evo_form_ObjectNameTextBox,dijit_form_NumberTextBox,dijit_form_TextBox,aspen_config_directory_DNTextBox
org.waterbear.core.widgets.dijit.Checkbox=div|checkbox|labelnear|dijit_form_CheckBox
org.waterbear.core.widgets.dijit.Select=table|table|labelnear|dijit_form_Select
org.waterbear.core.widgets.dijit.Button=span|span|labelinside|dijit_form_Button
org.waterbear.core.widgets.dijit.ComboBox=div|textbox|labelnear|dijit_form_ComboBox
清單 2 展示了.wdef 文件的部分內(nèi)容。它是一純文本文件，每一行定義了一組映射關(guān)系。等號左邊是 Dojo 小部件映射的 Java 類名，等號右邊是頁面上 Dojo 小部件的屬性描述。其中，起關(guān)鍵作用的是是最后一個屬性，它是 widgetid 的前綴部分。一個 Dojo 小部件類可以關(guān)聯(lián)到多種頁面 Dojo 小部件，因為有些 Dojo 小部件雖然被擴展了，但是對 Web UI 自動化測試來說擴展的功能不會被涉及到，于是可以用同一個類表示。
IBM 框架
IBM 框架以前被稱作為 ITCL 框架，由質(zhì)量軟件工程（Quality Software Engineering） 和 IBM 中有經(jīng)驗的自動化團隊合作開發(fā)而成的。這個框架由三層架構(gòu)組成，架構(gòu)的實現(xiàn)貫穿了應用對象、任務和測試用例包（IBM 包）。
潛在于應用對象、任務和測試用例包之下的基本原理是：
層次化的體系架構(gòu)
將“做什么”與“如何做”分離開來
代碼重用
一致和清晰的組織結(jié)構(gòu)
快速增強的能力
迅速的調(diào)試
有效地組織文件
啟用協(xié)作
學習他人
下面是對應用對象、任務和測試用例的解釋說明：
應用對象：儲存有關(guān)你的應用程序中的 GUI 元素信息。同時在這里也可以編寫你的 Getter 方法，這些 Getter 方法可以返回對象，使調(diào)用者能夠?qū)@些 GUI 元素進行查詢和操作。一般情況下，這些方法在 Task 層中進行調(diào)用。
任務：在這里你將編寫可重用的方法，這些方法在你的應用程序中執(zhí)行通用功能。同時在這里，你將編寫可以處理和查詢復雜的特定應用程序控件的方法。在任務中的方法可以被測試用例調(diào)用。
測試用例：導航一個應用程序，驗證其狀態(tài)，并記錄其結(jié)果的方法。
這個理念應用到 Java 編程就是用不同“包”組織應用對象、任務和測試用例的類。無論具體的底層 Web UI 自動化測試框架是什么，用 IBM 框架的理念來架構(gòu)上層測試用例的類都是有幫助的。 采用 IBM 框架能夠有效地應對挑戰(zhàn) E，因為高重用性能夠?qū)⒋a改動控制在局部范圍，并且一處改動即可糾正所有引用的代碼。除了采用 IBM 框架，實際上如何合理地規(guī)劃任務方法的粒度也很關(guān)鍵。但，這與具體應用就十分相關(guān)了。
代碼生成
一般來說，編寫用來獲取界面元素的代碼（也就是應用對象層的代碼）在整個開發(fā)工作量中占據(jù)很大的比例。通常，它需要開發(fā)者先借助一些能夠顯示 DOM 樹結(jié)構(gòu)的工具（比如 Firebug）觀察元素的屬性，然后決定用什么屬性來定位元素比較合適。 另外，一些代碼又是比較“機械”或者模式化的，例如給界面元素賦值的操作。這樣的代碼應盡可能的通過一些自動化的方式生成，就可大大節(jié)省開發(fā)的時間。
在 Water Bear 中，針對以上的兩個問題，分別開發(fā)了兩種代碼生成工具。
一個工具叫 AppObjs CodeGen，它可以自動遍歷當前的 DOM 樹，從而生成應用對象層的代碼。它用 Sahi 腳本實現(xiàn)，將結(jié)果輸出在它的日志窗口中(如圖 4)。 開發(fā)者將代碼復制到自己的類文件中即可。盡管這些代碼仍可能需要一些手工修改，比如重命名以增強方法的可讀性，但較之完全用手工編碼已節(jié)省很多時間。
圖 4. AppObjs CodeGen 生成結(jié)果
第二個工具叫 Skeleton CodeGen。 它的輸入是應用對象層的類，輸出是任務和測試用例層的部分代碼。對于符合特定模式的以及界面有很多 UI 控件的 Dojo 應用，這個工具比較有效。生成代碼仍需要二次修改，因為有些邏輯無法自動生成。
測試數(shù)據(jù)的管理
最好能夠?qū)y試數(shù)據(jù)和測試用例代碼分離，這樣同樣一份測試用例代碼可以搭配 N 種不同的測試數(shù)據(jù)運行。另外，這種分離也可以輕松地做到為不同的測試環(huán)境定義不同的測試數(shù)據(jù) – 有時候，一些測試數(shù)據(jù)是有環(huán)境依賴的。
Water Bear 利用開源軟件 XStream 來實現(xiàn)測試數(shù)據(jù)與測試用例代碼的分離。首先，測試數(shù)據(jù)被定義在一個 HashMap 中。測試用例在第一次運行時會將 HashMap 通過 XStream 自動序列化成一個.xml 文件。當自動化腳本再次運行時，如果.xml 文件已經(jīng)存在，它就直接讀取已有文件并借助 XStream 把文件內(nèi)容反序列化成 HashMap。在之后的運行中，只要 HashMap 的數(shù)據(jù)結(jié)構(gòu)沒有變化，就無需重新生成.xml 文件。數(shù)據(jù)文件的存放目錄可以通過配置文件指定，因此對于不同的環(huán)境只要修改配置文件指向不同的路徑即可。
錄制與編碼
提高開發(fā)效率的另一個途徑是提供錄制功能。但是錄制功能通常有如下一些問題：
錄制生成的代碼通常是“過程化”的。“過程化”的代碼很難重用。即便是針對同一個頁面功能模塊錄制的不同的測試用例代碼也是孤立的。如果頁面功能發(fā)生變化，所有測試用例需要重新錄制。因此，表面上看錄制功能似乎大大減少了開發(fā)時間，但是當頁面發(fā)生變化的時候，它或許未必如我們想象的那么好。
錄制的代碼可讀性通常比較差。一般來說，錄制之后仍需要重命名變量以提高代碼可讀性。
所以，理想中的錄制功能生成的代碼應該是模塊化的，也就是按照應用對象、任務和測試用例這三個層次生成。這樣的代碼即便于二次修改，也便于與已有代碼集成。從使用的角度看，所有的測試用例代碼完全用錄制功能生成不太現(xiàn)實，較好的方式是只用錄制功能輔助開發(fā)應用對象層和任務層代碼。 當 UI 發(fā)生非功能性變化時，只需要重新錄制受影響的任務方法并更新應用對象層。理論上，測試用例層不需要修改（除非測試用例的邏輯不得不修改）。
Water Bear 目前僅支持“過程化”錄制功能。圖 5 展示的就是 Water Bear Recorder 生成的代碼。開發(fā)者把生成的代碼復制黏貼到自己的測試類中即可在 Water Bear 中直接運行。
圖 5. Water Bear Recorder
結(jié)束語
本文首先列舉了 Dojo 應用 UI 自動化測試面臨的諸多挑戰(zhàn)，之后從這些挑戰(zhàn)入手，結(jié)合個人的開發(fā)經(jīng)驗以及一個內(nèi)部使用的 Dojo 應用 UI 自動化測試框架，提出了八個在選取和設(shè)計 Dojo 應用 UI 自動化測試框架時需要考慮的原則。當然，每一點的重要性不盡相同。比如“隱式等待”是必須的，而錄制功能卻沒有那么重要。但是，若是這些原則都能符合，將大大提高 Dojo 應用 UI 自動化測試實施成功的可能性。