HtmlUnit在本地化測試中的使用

最近在review l10n測試用例時發現大量如下場景。

1. 開啟xx page，驗證該頁面被localize，同時沒有layout問題

2. 配置一堆前置條件，目的不過是驅動某些error message，同時驗證message body + header被localize，同時沒有layout問題

面對這樣的情形，不禁唏噓，這樣的毫無技術含量的重複性工作真的有意義麼？即便對於業務或市場來說，它是如此的不可或缺，那為何不能使用程式進行驗證，非要耗費測試人員的寶貴時間於此呢？這時有人宣稱，對於國際化的某些問題，自動化指令碼確實是可以覆蓋的；但對於本地化，必須上人啊！甚至還有人跳將出來，說什麼restful api不是為了國際化設計的，不支援本地化內容的獲取……呵呵，且不說乙個純前端的東西跟restful api扯上哪門子關係，就說這api，又真的有那個是為國際化而生的呢？

再來品讀這兩個「海量」用例，仔細思索後發現二者其實有著不同的技術背景。先說後者，假設這些error都是popup的message，那麼一定每個彈出視窗都有其控制代碼嘍，只要我們拿到這個控制代碼，直接invoke它就是了。再也不用配置繁複的前提條件，畢竟我們關注的不過是message本身的翻譯情況，不是麼？即便為了考慮周全，引入了變數concatenate問題，那最多再加一層資料stub即可，不過這不是本文的重點，不展開描述。

現在回到本文的重點，來說說我們面對的第一類問題吧，為了驗證某個page是否被localized，我的做法是引入類似htmlunit的靜態頁面測試框架，對本地化後的頁面內容進行斷言，示意**如下。

public class htmlunitl10ntest
}//ja-jp
@test
public void homepagejatest() throws exception 
}}

為了演示簡單，示意**中將需要斷言的部分作了硬編碼，真正的測試中完全可以從resource檔案中讀取，但至於要遍歷還是抽樣，自責負責人完全可以自行決斷。

細心的同學一定注意到上述示意測試**僅針對頁面是否本地話進行了驗證，並未涉及layout！確實如此，筆者堅持認為，對於重要業務流中的layout問題（例如遮擋住了「下一步」按鈕，導致功能無法繼續），在et中一定會被測試人員提到發現，而其餘邊邊角角的layout問題，皆可忽略，竊以為這是上策。不過凡事總有例外，一旦面對layout要求很高的需求時，筆者會選擇一種半自動的辦法，使用我們自主研發的ui sniffer進行ui嗅探，在瀏覽器中直接呼叫機器翻譯對字元進行替換，雖有高射炮打蚊子之嫌，但很負責任的說，面對layout問題，該工具的確相當的鋒利（不過至今仍未開源，僅於內部使用），這算是中策吧。而如今這種海量用例，配以孜孜以求之的人海戰術，不得不說是下策啦。

HtmlUnit在本地化測試中的使用

本地化測試

本地化測試

本地化測試

相關推薦