前言
無線產品線的很多模塊基本上都屬于前端類型，前端模塊一般具有如下幾個特征：接收處理用戶請求，本身不維護數據，從后端模塊獲取數據，進行build頁面后展示給用戶。
從圖示可以看到，針對前端測試，我們需要根據手機特性，針對用戶和前端的輸入輸出進行針對性的測試。
問題及解決方法分析
目前wap前端測試采用的方法有如下幾個：
對于build頁面的系統邏輯部分的case，采用自動化方式進行測試
對于頁面展示部分的case，使用能夠支持wml和xhtml頁面的pc瀏覽器（比如opera或者安裝了wmlbrowser的firefox）進行測試
對于前端頁面的重大調整，比如嘗試使用新的頁面元素，采用真機或手機模擬器的方式進行，但主要偏重于驗證是否由于新元素的使用引入了兼容性問題
由于真機測試的效率得不到很好的保證，且手機瀏覽器比pc瀏覽器種類紛繁復雜（包括手機內置瀏覽器及第三方開發的瀏覽器），難以依靠幾款手機或瀏覽器進行覆蓋，因而在wap前端測試中采用真機進行的比較少。測試中比較多的采用pc瀏覽器進行模擬，而手機和pc瀏覽器之間又存在較多的差異性，給wap的前端測試帶來了諸多bad case甚至bug。
從輸入角度
由于手機提交請求的差異性，比如部分手機提交不符合http協議規范的header，給無線的前端測試帶來了諸多的問題，典型示例如下：
發現由于某些手機提上來有key沒value的header字段而使web server拋出異常而處理失敗。
前端架構升級項目，web server上線過程中發現部分手機發送的get請求攜帶content-length=0，web server對于此類不符合http協議規范的請求直接拋棄而拒絕服務。
為了避免以后再出現類似問題，我們考慮的解決辦法是：收集并分析用戶請求的差異性，形成case庫及參考文檔，供以后測試參考。
從輸出角度
目前wap頁面包括wml和xhtml兩個版本，由于手機瀏覽器的兼容性沒有pc瀏覽器的兼容性好，經常可能會由于一些小的語法錯誤導致頁面無法正常顯示，典型示例如下：
頁面中url參數的&符未轉義
由于手誤，在從xhtml版本修改為wml版本時帶入了不支持的標簽
這種問題往往用pc瀏覽器比如ff不容易發現，而依靠真機或者手機模擬器測試又不夠高效。針對這一問題，我們的解決思路如下：首先保證我們的wap頁面是符合規范的；在我們符合規范的情況下盡可能的收集bad case并予以規避。
改進實踐
手機header數據倉庫
整個數據倉庫形成思路如下：
步驟1：首先不依賴于web server，編寫socket server，通過日志得到請求
步驟2：其次分析header的key類型，給出key集合，并對出現概率較高的header查閱資料給出解釋，形成參考文檔
步驟3：再次針對每種key，工具生成value取值集合，并結合含義給出等價類劃分，從而形成case庫
針對步驟2，收集用戶header，腳本分析得到不同的header集合。對于數量過萬的header集合，即在用戶請求中出現的比例大于1/1000的header，整理并形成參考文檔。
針對步驟3，對于步驟2整理出來的100中key，分析線上引流數據生成其value取值，去重后得到的value全集，見附錄。對于其中重要的key，劃分其等價類集合。
wap頁面規范性校驗庫
如何保證wap頁面是符合規范的，就需要按照標準wml和xhtml的規范進行頁面檢查。wap頁面規范性校驗庫包括如下兩個步驟：
步驟1：總結目前使用的頁面標準規范，形成參考文檔
步驟2：封裝開源xml校驗庫，集成到自動化框架中
針對步驟1，目前wap頁面包括wml和xhtml版本，wml基本上都是”wml_1.1.xml”，xhtml基本上都是”xhtml-mobile10.zip”，整理其相應的規范內容見下表。
針對步驟2，調研目前開源的xml語法校驗工具，比如http://validator.w3.org/，將開源的校驗庫封裝成工具，且集成到自動化框架中，方便的進行調用，提高測試效率和覆蓋率。目前實現為基于java語言，采用dom4j開發了wml&xhtml語法校驗庫，根據頁面申明的dtd進行檢查。之所以采用dom4j主要因為其是非常優秀的Java XML API。
另外由于wise頁面采用的dtd規范基本一致，例如wml基本上都是”wml_1.1.xml”，xhtml基本上都是”xhtml-mobile10.zip”，因而采用dtd本地保存的方法，加快執行速度。封裝到wise-test后，使用非常簡單，case中只需調用check_validation（url），即可實現對指定url的語法檢查。在升級項目中，對該工具進行了實踐檢驗，基本上每個頁面的自動化case都進行了語法檢查，發現了在兩個wml頁面引入xhtml標簽導致的頁面解析失敗問題。
?。ㄈ耐辏?/p>