想要事半功倍地提高WEB自動化的開發和維護效率，解決實現page object模式過程中的各種問題才是首要考慮因素。
When?you?write?tests?against?a?web?page,?you?need?to?refer?to?elements?within?that?web?page?in?order?to?click?links?and?determine?what's?displayed.?However,?if?you?write?tests?that?manipulate?the?HTML?elements?directly?your?tests?will?be?brittle?to?changes?in?the?UI.?A?page?object?wraps?an?HTML?page,?or?fragment,?with?an?application-specific?API,?allowing?you?to?manipulate?page?elements?without?digging?around?in?the?HTML.
--Martin?Fowler
當我們試圖去測試一個WEB頁面時，不得不依賴頁面上的元素去進行交互并確認程序應用是否正常運行。然而當你的腳本試圖直接操作頁面上的HTML元素時，一旦有相關UI的變更，那測試將會變得十分脆弱。Page?object模式就是對HTML頁面以及元素細節的封裝，并對外提供應用級別的API，使你擺脫與HTML的糾纏。
--Martin?Fowler
處理繁雜冗長的元素交互
從上述代碼中可以看出，一個最簡單的登陸頁面，只接收用戶名、密碼兩個參數，剩下的就是與頁面上元素交互的細節了。
此處的問題在于，雖然已遵循了page?object模式，并將元素的細節進行了封裝，但是一個簡單的登陸動作，卻不得不用許多冗余的代碼去實現交互邏輯。
如下圖所示：
查找元素——>操作元素——>查找元素——>操作元素….
代碼行數隨著元素的增加而變得越來越冗長，更不用說為了保證與每個元素交互的穩定性問題而加入的異常處理和等待時間了，一旦UI層有較大的交互邏輯變更，將直接導致每個page?object的維護成本急劇上升，直至難以維護的地步。
因此，可以預見到隨著頁面以及元素交互越來越多，代碼會變得又臭又長。
統一的元素交互入口
我們不妨改變一下思路，以單個行為為單位將所有需要進行交互的元素一并打包進行統一處理。
優化后的代碼：
可以看到這里的元素交互遠比之前的登陸操作冗長且復雜得多，但代碼卻更簡潔了。這樣在頁面元素或交互邏輯有變更時（UI層的變化可謂家常便飯），只需適當修改元素的定位器和元素的傳入順序就行了，也就極大的降低了UI測試的維護成本。
然而要真正實現這樣的模式，還需要考慮以下幾點：
動態匹配元素類型以及對應的處理方式
這里需要注意的是除了支持標準的HTML元素操作外，還需要支持自定義的標簽。也就是說對于一個標準的button元素來說對它的操作只有click，然而對一個div來說可能支持所有的類型操作（click，input，drag?drop…等等）。
以可以進行拖拽操作的span為例，我們還需要對它的定位器進行重寫，這樣在程序處理此類元素時才能被正確處理。
統一的異常處理
為了保證UI自動化運行的穩定性，我們通常會在每個交互之間添加一些異常處理，也就是對元素的識別和交互進行等待和重試的過程，然而由于現代前端實現的復雜性和功能的多樣性使得對進行穩定的交互操作更加困難，以至于在page?object交互操作邏輯中的任意一個步驟都可能產生不能識別、不能操作等異常。通常的解決方式是直接在交互步驟中嵌入異常處理的代碼。但顯而易見的是這么做肯定會導致又臭又長甚至源源不絕的異常處理邏輯，同樣會導致無法維護的惡果。
使用代理模式攔截所有的異常并進行統一處理。
如此一來我們會發現，當在perform_actions中處理被代理元素對象時再也不用擔心訪問其屬性時出現異常而導致測試失敗了，不用添加額外代碼就能使測試穩定運行。
關于建模粒度
有時在對頁面進行建模時，除了創建page?object外，經常會遇到另外一個問題，那就是是否還需要對頁面上的元素進行建模呢？
答案是否定的。
原因是UI經常變化，而頁面元素則更易變，如果按照上圖方式對每個元素都進行建模，那肯定是事倍功半的，因為你很有可能會花絕大部分的時間在添加和刪除代碼文件上。
其實我們可以把存在于一個頁面中某些邏輯緊密的UI元素直接定義為若干個page?objects，這樣做可以大幅度減少不必要的關于元素代碼的文件產生，并且使原本看似十分松散凌亂的UI元素以更合理的結構呈現出來，弱化了元素間的耦合度。
結語
以上就是關于在實現page?object模式過程中遇到的一些實際問題。可以看出一旦處理好對頁面元素的交互與控制，將會極大提高WEB自動化的開發與維護效率。
本文編譯：錢俊杰?Chester?Qian（點融黑幫），現任點融網高級測試開發工程師。負責公司貸款業務應用質量保證，測試框架、工具開發與維護。
