我們生活在一個大多數人已經擁有智能手機的時代，觸手可及的互聯網接入。根據Statista的數據，去年移動流量超過桌面流量，佔全球流量的52％以上。在亞洲，這個數字超過65％，這是驚人的。
如今，大多數組織都瞭解移動設備的重要性，並投資於響應式網頁設計（RWD）和移動應用程序。許多人還採用了移動優先策略，優先考慮移動用戶體驗在桌面上的開發和優化。
在本文中，我們將關注移動網絡，以及仍然困擾提供這種最佳用戶體驗的一項挑戰 - 測試，尤其是大規模測試。大多數RWD測試仍然是手動的，僅在發佈主要新功能時執行。許多Web團隊發現很難創建，最重要的是，維護可信的自動化測試，涵蓋響應方案。因此，移動體驗的許多問題不被注意，侵蝕用戶信任並導致收入損失。
我們來探討一些RWD測試方法。
響應式網頁設計測試策略
在設計移動Web測試策略時，最好從實際使用模式分析數據。例如，來自Google Analytics等工具的數據可以告訴我們最常用的屏幕分辨率和瀏覽器與我們的網絡應用程序進行交互。
如果我們使用Google Analytics，我們可以查看技術（瀏覽器和操作系統）和移動受眾群體報告， 以確定iPhone是最頂級的移動設備，360px到640px是最受歡迎的移動設備屏幕分辨率。請注意，如果您無權訪問分析數據，則可以從Web或營銷團隊請求CSV或PDF格式的導出。
有了數據，我們現在可以開始制定計劃來測試最常見的移動用戶旅程和方案。以下是一些可能推動我們計劃設計的問題：
- 實用
- 所有頁面元素和圖像是否在每個目標分辨率下按預期顯示/調整大小/消失？
- 導航是否在所有視口中按預期運行？
- 小視圖端口的導航體驗是否直觀？
- 所有鏈接都有效嗎？
- 交互式元素和表單是否按預期工作？
- 是否可以在應用程序中完成所有常見的用戶旅程？
- 視覺
- 在較小的屏幕上呈現時，整體視覺體驗是否引人注目且“在品牌上”？
- 我們如何監控和檢測不需要的視覺變化？
- 在移動視口中呈現時，導航和其他全局元素是否直觀？
- 性能
- 從移動設備訪問時，頁面加載時間是否相同（或更好）？
- 主流瀏覽器（例如Chrome，Safari，Firefox）的移動體驗是否一致？
回答這些問題需要主觀（例如美學）和客觀探索（例如元素狀態，鏈接，輸入）。當然，這意味著您不能 - 也不應該 - 完全放棄手動測試。請記住，從長遠來看，手動測試最終比自動化更昂貴，目標應該是自動重複乏味，以便花更多時間手動測試真正需要人眼的應用部分。自動化測試還有助於我們確保在眾多移動方案中獲得最佳用戶體驗。
功能移動測試
對於此類測試，我們通常首先使用Chrome DevTools中的設備模擬器執行手動測試 。這有助於我們模擬響應式體驗並驗證事物是否按預期工作。在這裡，我們需要特別注意任何應該隱藏的頁面元素。測試設備的水平和垂直方向也是一種很好的做法，以確保在用戶擺弄手機時體驗不會中斷。
視口（分辨率）
我們現在可以將響應式視口大小設置為我們的360x640樣本分辨率，並測試用戶體驗是什麼樣的。將設備類型設置為“移動”以模擬觸摸體驗非常重要。
移動用戶代理（設備）
除了設置視口外，我們還可以選擇特定的移動設備（如iPhone X）進行測試。選擇設備將自動設置相應的視口和用戶代理（UA）字符串以模擬某些設備特徵。
在完成我們的初始手動測試後，我們已準備好在mabl的幫助下開始自動化操作，這使得無需編寫腳本即可輕鬆創建自動化測試。當UI發生變化時，mabl還可以自動修復測試並識別用戶體驗中的迴歸，包括視覺差異和性能異常。
mabl支持Viewport和移動用戶代理
我們使用 mabl Trainer（Chrome擴展程序）來訓練我們的測試，只需單擊Web應用程序並進行斷言即可。您訓練的測試將保存為mabl Journeys，它們在分配給mabl計劃時運行，該計劃指定執行環境和計劃等。
要訓練移動Web測試，最好切換到Chrome DevTools中的設備模式，並訪問DevTools面板中的mabl Trainer。我們可以在Trainer中設置我們的測試視口大小，並在Plan配置中指定移動用戶代理，如下圖所示。
一個生產力黑客是對現有的mabl Journeys進行桌面體驗培訓，並根據需要編輯複製的測試步驟來複制它們。菜單導航和懸停步驟是值得關注的。導航很可能會在漢堡包菜單中摺疊，這需要添加額外的點擊步驟來展開它。我們也不能將鼠標懸停在具有觸摸輸入設備的元素上，因此我們需要使用CSS / XPath選擇器將點擊或自定義查找替換為這些步驟。有關使用mabl進行移動Web測試的更多詳細信息，請參閱文檔。
可視移動測試
除了功能測試之外，監視應用程序中的視覺差異是非常有價值的，這樣我們就可以識別潛在的視覺迴歸，例如佈局和其他元素頁面更改。這通常通過捕獲屏幕截圖圖像並構建應用程序的基本可視模型來進行比較來完成。很難實現一種可靠地識別所有噪聲之間有意義的視覺差異的解決方案。這就是為什麼大多數功能測試自動化工具（如Selenium）不提供此類功能並需要與其他工具集成的原因。
幸運的是，mabl使用捕獲的屏幕截圖創建應用程序的基本可視化模型，該模型可以區分靜態內容區域和動態內容區域，並通知您重要的更改。下面是mabl如何在並排比較中突出顯示應用程序中的視覺變化的示例。您會注意到，只有顯著的更改（導航菜單中的項目）會突出顯示，而無意義的更改（廣告，產品訂單的更改）則不會。
查看有關更新mabl中可視化基線和模型的博客文章， 以瞭解有關幕後發生的更多信息。現在，讓我們把注意力轉向表現。
性能注意事項
加載時間對於每毫秒計數的移動體驗非常重要。大多數人遇到的最常見問題是為桌面重複使用相同的高分辨率圖像，只是為移動設備縮小它們。這是一個問題，因為這些圖像的大小很大，並且在移動互聯網連接上加載它們需要時間。解決此問題的最佳方法是擁有多個版本的映像，並根據設備類型和分辨率為相應的映像提供服務。Web開發框架和內容管理系統（如Sitecore，Sitefinity和Adobe Experience Manager）應該能夠為您處理此問題。您可以使用mabl仔細 檢查性能數據。
在性能方面，我們可以使用mabl通過檢查 測試行程的每個步驟的堆棧跟蹤數據來幫助我們識別大型圖像或其他是否會導致性能問題 。
Mabl還記錄了測試執行時間，並使用機器學習模型，該模型允許它預測下一個執行時間應該是多長。如果預測的mabl與實際執行時間之間存在差異，則會產生性能異常洞察，供您查看。例如，在下面的圖像圖像中，我們可以看到mabl如何可視化計劃運行持續時間併為我們提供正確的見解。
閱讀更多 愛碼農 的文章
