測試匠談 | 微信 H5 相容性測試理論和實踐經驗

「測試匠談」欄目由優測傾心打造，彙集騰訊明星產品團隊頂尖的技術專家，傾囊相授測試領域的知識技能與實踐！

本期嘉賓介紹
Iris Du，騰訊微信事業群研發工程師，擔任微信商戶產品的開發工作，曾參與微信 AI 智慧客服、生物識別硬體產品等多個技術創新專案。

摘要：截至目前，移動端對比桌面、平板的市場使用份額已經達到 52.92%。在微信生態專案中，大部分 H5 頁面都是執行在微信內（即微信內建瀏覽器），使用者使用的移動端裝置、系統版本、微信版本五花八門。本期文章將詳細介紹微信 H5 相容性測試的理論、方法和實際案例。

現狀與挑戰

開發人員通常會像常規 Web 開發一樣開發 H5，並在自己的手機上進行測試。產品上線前同組組員進行體驗測試，有什麼手機就測什麼手機，無法保證測到了市面上的多少裝置。

還有一種測試方法是測更多的手機型號，很多自動化測試平臺就是採用這種策略，但這種策略是否適合微信 H5 測試呢?

為什麼微信 H5 相容性測試困難？

① 移動端裝置複雜

Android 的裝置情況：

OpenSignal 在 2015 年 8 月釋出的基礎統計資料可以看到 Android 的裝置複雜度。到了 2024 年，如今裝置的複雜度肯定只增不減。

Android 裝置碎片化

Android 螢幕尺寸碎片化（圖片來自 OpenSignal "Android Fragmentation 2015"報告）

iOS 的裝置情況：

根據維基百科顯示，截至 2024 年 9 月，蘋果公司已推出 46 款 iPhone 型號。

（圖片來源維基百科 iPhone 詞條）

②移動端瀏覽器多

常見的瀏覽器包括 Chrome、Firefox、Firefox Focus、Opera、Microsoft Edge、Yandex Browser、Safari、QQ 瀏覽器、百度瀏覽器、UC 瀏覽器、世界之窗瀏覽器、夸克、Via 等。

③微信 H5 測試複雜

微信到目前為止已經到了 8.0 版本，如果想在 8.0 版本的手機上測 7.0 版本比較困難，需要把微信刪了再重新裝一個。

如果用雲真機來測試微信 H5，面臨的問題是需要進行一系列複雜的微信登入操作，然後再進行測試，微信在新手機上的整個登入流程還是比較複雜的。

微信 H5 的測試要從何下手呢? 困難的點在於我們不可能把每個機型、瀏覽器、微信版本都測一遍，常見情況我們只會測到 5-10 臺手機，都是組內的自用裝置。有沒有辦法透過最小化測試完成 99% 以上裝置的 CSS、JS API 測試呢?

測試方法與實踐

做在測試之前

首先，不指望測試階段解決所有的問題，在開發時就需要考慮相容性。

可以檢視相容性的網站有：

• Can I use (https://caniuse.com)
• MDN Web Docs (https://developer.mozilla.org/zh-CN)

同時也可以利用一些工具做相容:

• AutoPrefixer
• Babel
• Browsers (在這檢視各個瀏覽器的使用分佈)

https://browsersl.ist/#q=cover+99%25ion=alt-as®

管理測試預期

有次同事問我，他們最近有個 H5 專案在 Mac 和 iOS 上的 UI 還原都可以，但是到了 Android 上字型就不一樣了。（這裡的原因是因為設計指定的是蘋方字型，Android 上並沒有內建該字型，正確的解決方案是在不同的系統上用不同的內建字型）

這種情況是否可以說是 UI 還原低呢?
是否要專注於 100% 還原?

這裡首先明確一個的概念 - 跨瀏覽器使用。我們應該確保網站或者 Web 應用能在可接受數量的瀏覽器上正常使用，在不同的瀏覽器中提供可接受的使用者體驗。

概念解釋：跨瀏覽器使用（working cross browser）是指網站或 Web 應用能在可接受數量的瀏覽器（across an acceptable
number of web browsers）提供可接受的使用者體驗。

- *引用來自 MDN*

雖然無法在所有瀏覽器上提供相同的體驗，但確保核心功能使用順暢就算可以。比如在現代瀏覽器上，能顯示動畫、3D 或閃光效果，而在較舊的瀏覽器上，可以呈現出相同資訊的平面圖片。只要網站主滿意，你的工作就算完成了。

我們管理好大家測試的預期（在不同瀏覽器中提供可接受的使用者體驗）)，測試的覆蓋範圍則是因業務而定。

移動端相容性測試常用方法

① 螢幕尺寸相容性測試

使用瀏覽器的開發者工具或專門的響應式測試工具（如 Responsive
Design Mode）來模擬不同裝置的螢幕尺寸和方向，確保網頁在不同裝置上呈現良好 (本文不重點介紹)。

② 真機或模擬器測試

這類測試是 CSS、JS API 相容性測試的重點。

• 使用真實裝置：將網頁載入到不同型別的裝置上進行測試，例如桌面電腦、膝上型電腦、平板電腦和智慧手機等。
• 使用模擬器和模擬器：利用模擬器或模擬器來模擬不同裝置的環境，並進行測試。常用的模擬器包括 Android Studio 自帶的模擬器和 Xcode 中的 iOS 模擬器。

透過雲真機可以用各類裝置進行相容性測試，這是常規測試 CSS、JS API 相容性的方式。

③ 自動化測試工具

可以透過編寫測試用例的方式，然後在跨平臺、跨瀏覽器在各個真機上進行模擬測試，比如以下這些：

Selenium：Selenium 是一個流行的自動化測試框架，用於模擬使用者在不同瀏覽器上的互動。它支援多種程式語言，並提供了豐富的 API 和工具，使開發者可以編寫功能測試、迴歸測試和跨瀏覽器相容性測試。

TestCafe：TestCafe 是一款基於 JavaScript 的自動化測試工具，用於跨瀏覽器測試。它不需要額外的外掛或驅動程式，能夠在真實的瀏覽器中執行測試，並支援多個瀏覽器和平臺。

Cypress：Cypress 是另一個流行的自動化測試工具，專注於現代 Web 應用的端到端測試。它提供了簡單易用的 API，允許開發者在多個瀏覽器中執行測試，並具有強大的除錯和互動功能。

BrowserStack：BrowserStack 是一個雲端跨瀏覽器測試平臺，提供了大量真實瀏覽器和移動裝置進行測試。它允許開發者在不同瀏覽器上同時執行測試，以檢測網頁在不同環境中的相容性問題。

優測雲服務平臺：優測 WebUI 自動化是騰訊旗下的一個自研測試工具，可以在頁面操作錄製生成自動化測試用例，在自測的同時，同步完成用例錄製，生成測試指令碼程式碼。

這裡面臨的問題是，用以上的自動化測試可能需要寫各式的測試用例，且測試用例的複雜度和頁面複雜度呈正相關，手動真機測試更復雜，那麼多裝置、微信版本怎麼測?

如果用自動化測試微信 H5，怎麼在那麼多裝置上登入微信呢? 測試策略又是什麼?

影響相容性的主要因素

因為頁面是承載在瀏覽器上的，影響相容性的因素有以下幾點:

• 螢幕尺寸
• 螢幕解析度
• 瀏覽器核心

螢幕尺寸和螢幕解析度會影響頁面的排版樣式，但是瀏覽器核心才會影響 CSS、JS API 的相容性。

從 CSS、JS API 瀏覽器相容性也可以看出，一個屬性的相容性只和瀏覽器和瀏覽器版本相關，根本原因是因為瀏覽器核心不同。

（圖片來自 MDN Web Docs）

微信內建瀏覽器核心和測試方法

瀏覽器核心包括瀏覽器的渲染引擎、JS 引擎，渲染引擎決定了瀏覽器如何顯示網頁的內容以及頁面的格式資訊，不同的瀏覽器核心對網頁編寫語法的解釋也有不同。

因此，同一網頁在不同的核心的瀏覽器裡的渲染（顯示）效果也可能不同，這也是網頁編寫者需要在不同核心的瀏覽器中測試網頁顯示效果的原因。

所以想要測試 CSS、JS API 的相容性，我們需要知道在微信瀏覽器的核心。好在微信內建瀏覽器渲染核心比較統一、不像 Anroid 瀏覽器的核心一樣五花八門。

我們的測試目標是，透過最少的測試組合，完成 95% 移動裝置的 CSS、JS API 相容性測試。

_	瀏覽器核心
Android 瀏覽器	基本都是基於 WebKit（4.4 前）或 Chrome（Blink）核心開發的核心（4.4 後基於 Chromium）注：1. UC 瀏覽器：基於 WebKit 核心開發的 U3 核心【增加雲端架構 (實現壓縮流量、加速載入功能】2. QQ 瀏覽器等微信瀏覽服務：基於 WebKit 核心開發的 X5 核心（現已升級至 Blink）3. 360 瀏覽器：基於 Chrome 核心開發的 G5 核心 4.百度瀏覽器：基於 WebKit 核心開發的 T5 核心。
iOS 瀏覽器	Webkit
Android 微信內建瀏覽器	微信 5.4 之前沒有內建瀏覽器 微信 5.4-6.1 (安裝了 QQ 瀏覽器使用 X5，未安裝瀏覽器使用系統核心) 騰訊 TBS X5、微信自研 XWeb（自 2020 年，現在大部分是這個)
iOS 微信內建瀏覽器	UIWebView、WKWebView（2017年3月1日前逐步升級）

iOS 微信內建瀏覽器

①核心背景

iOS 微信內建瀏覽器只有 2 種，UIWebView 和 WKWebView。WKWebView (微信2017年3月1日前逐步升級為 WKWebView) 是蘋果在 iOS 8 中引入的新元件，目的是提供一個現代的支援最新 Webkit 功能的網頁瀏覽控制元件，擺脫過去 UIWebView 的老、舊、笨，特別是記憶體佔用量巨大的問題。它使用與 Safari 中一樣的 Nitro JavaScript 引擎，大大提高了頁面 JS 執行速度。

切換為 WKWebview 後，微信中的 Webview 行為和 Safari 中保持高度一致，唯一的區別是微信 Webview 中會注入微信 JSBridge 相關的指令碼。

蘋果在 iOS 13 上，要求開發者必須用 WKWebView 替代 UIWebView，按照蘋果2019年12月13日的文件 Updating Apps that Use WebViews 裡給出的時間要求是：

• 2020 年 4 月，新應用必須使用 WKWebView 代替 UIWebView
• 2020 年 12 月，應用更新必須使用 WKWebView 代替 UIWebView

所以微信 6.5.8（2017-05-17）之後的版本由 WKWebView 支援，且 iOS 13 即之後的所有蘋果應用只支援 WKWebView。

參考：iOS WKWebview 網頁開發適配指南

https://developers.weixin.qq.com/doc/offiaccount/OA_Web_Apps/iOS_WKWebview.html

② 測試方法

由於微信內建瀏覽器使用的是蘋果的 UIWebView 和 WKWebView，所以瀏覽器核心只和 iOS 版本有關。

以下是市場使用率排前 20 的 iOS 裝置（資料來源於 statecounter），總和佔比為 97.26%，且所有的版本均 > iOS 13，所以用的都是 WKWebview。如果只測其中的小版本我們只需要測試 6 個 iOS 版本即可完成 iOS 微信 97.26% 的 CSS、JS API 相容性測試。

如果能拿到其它的統計資料，比如微信中 iOS 使用者使用佔比，也可以用同樣的分析方式進行計算，算出佔比靠前的 iOS 版本。

iOS Version	市場份額%（2023 年 9 月)	小版本
iOS 16.6	56.58	_
iOS 16.1	5.59	_
iOS 17.0	5.09	Y
iOS 16.3	5.08	_
iOS 15.7	4.71	_
iOS 16.5	3.51	_
iOS 16.0	3.06	Y
iOS 16.2	2.76	_
iOS 15.6	2.45	_
iOS 16.4	1.19	_
iOS 13.3	1.15	Y
iOS 15.5	1.08	_
iOS 16.7	1.03	_
iOS 12.5	0.89	Y
iOS 15.4	0.78	_
iOS 14.8	0.63	_
iOS 14.7	0.46	_
iOS 14.4	0.45	_
iOS 15.3	0.4	Y
iOS 14.6	0.37	Y

Android 內建瀏覽器

①核心背景

好在微信 Android 內建瀏覽器一開始就沒有完全採用使用系統核心的渲染方式、而是選用了 TBS 的 X5 核心，2020 年後使用的是微信 XWEB 核心。

X5 核心同時也在手機 QQ、QQ 瀏覽器中使用，UserAgent 如下：

Mozilla/5.0 (Linux;
Android 12; OXF-AN10 Build/HUAWEIOXF-AN10; wv) AppleWebKit/537.36 (KHTML，like Gecko)
Version/4.0 Chrome/89.0.4389.72 MQQBrowser/6.2 TBS/046247 Mobile
Safari/537.36 MOA/6.1.0(133) HarmonyOS 3.0.0 Language/zh_CN

微信自研 XWEB 核心的 UserAgent 如下：

Mozilla/5.0 (Linux; Android 11; PCAM10
Build/RP1A.200720.011; wv) AppleWebKit/537.36 (KHTML， like Gecko) Version/4.0 Chrome/111.0.5563.116 Mobile
Safari/537.36 XWEB/5279 MMWEBSDK/20230805
MMWEBID/7778 MicroMessenger/8.0.42.2460(0x28002A3B) WeChat/arm64 Weixin
NetType/WIFI Language/zh_CN ABI/arm64

在業務中實際撈出 UserAgent 的上報資料並進行統計，2023年10月08日到2023年10月14日（未對同一裝置/使用者去重），使用 XWEB 的微信 H5 頁面上報資料有 12387 條，使用 X5 核心的微信 H5 上報資料有 9 條，所以在實際環境中，大部分 Android 使用者都已在使用 XWEB 核心。

② 測試方法

在實際業務中，幾乎沒有使用者反饋 Android 微信內建瀏覽器的相容問題，很多 iOS 表現不好的 API，在 Android 上卻表現的非常優秀和正常，但我們還是要做相關的測試。

從瀏覽器核心的角度出發，Android 瀏覽器核心和微信版本有關，所以應該按照 Android 微信版本來進行測試。

但其實 XWeb 和 iOS 的渲染核心更新機制不同，XWeb 是動態更新的。新下載的微信客戶端存在兩種可能：第一種是還未下載 XWeb，所以使用系統內建的瀏覽器核心；第二種是下載最新的 XWeb 版本。

舊微信客戶端也存在兩種可能：第一種是近期更新過，使用的新版 XWeb；第二種是近期未更新過，使用的是舊版 XWeb。但微信客戶端很難讓所有的使用者都更新到最新版本，版本更新的情況可看下圖的資料分佈。

出現問題時快速復現/驗證

相較於盲目的拿各型號手機測試，現在我們可以按照系統和使用者上報資訊快速復現 CSS、JS API 相容性問題。

• iOS 根據使用者 iOS 系統版本復現
• Android 根據使用者的瀏覽器核心/微信客戶端版本復現

系統版本和微信客戶端版本（MicroMessenger）在 UserAgent 中都有，如下所示:

Mozilla/5.0 (iPhone; CPU iPhone OS 17_0_3 like
Mac OS X) AppleWebKit/605.1.15 (KHTML, like Gecko) Mobile/15E148 MicroMessenger /8.0.42(0x18002a2a) NetType/WIFI
Language/zh_CN

覆蓋率更高的相容性測試

前面我們定的目標是透過最少的測試組合，完成 95% 移動裝置的 CSS、JS 相容性測試，有沒有可能達到更高以至於到 100%，有下面這兩個思路。

一：把所有的瀏覽器核心都窮舉出來，但代價會非常高，目前可以查到的資料有微信 Android
7.0.15 佔比是 0.01%, 假設微信 Android
5.4 - 6.1 的佔比也為 0.01%, 5.4 - 6.1 包含 4 個微信版本，需要測試 4 * Android 端所有的瀏覽器核心，如果是手動測試的話成本非常高，如果是自動化測試除了要編寫測試指令碼還要考慮如何模擬這樣的裝置環境。

二：如果能明確自己業務使用者的微信版本/iOS 版本, 那麼想要做到 100% 就變容易了，只要把已知範圍的使用者裝置進行統計排序，然後決策自己要測多少。

如果前期不能確定自己的業務使用者裝置範圍，可以本文參考中的測試策略。

實際案例

案例一：iOS 中記憶體使用過高

問題表現：

開啟後頁面不斷的自動重新整理

出現問題的版本：

iOS 微信內建瀏覽器、iOS 微信小程式 web-view

問題原因:

我們在頁面中用到了騰訊地圖的熱力圖、渲染部分熱力圖時騰訊地圖記憶體使用過高導致頁面會不斷重新整理，但在其他瀏覽器中無該問題。社群相似問題。

總結:

後續修改為騰訊地圖新版本解決了記憶體問題，正常來說 iOS 內所有的 webview 應該表現相同，但是這個案例跳出了這個框架，說明在記憶體的使用上會存在一些差異，但是依然可以相信 iOS 中微信 Webview 行為和 Safari 中的保持高度一致。

案例二：iOS 中音訊無法成功播放

問題表現：

每次鬆手傳送語音後應該播放一個音效、但卻沒有播放。

出現問題的版本（包括但不限）：

iOS 15.4.1、iOS
14.3 下的微信內建瀏覽器和其他瀏覽器。

問題原因:

此處使用了 Video 元件、在移動端必須有 touchstart、click 觸發後才可對音訊進行播放，否則會有如下報錯 Unhandled Promise Rejection: NotAllowedError，所以此處鬆開 (touchend) 無法直接呼叫 video.play()。

我們在 touchstart 時讓 video 進行靜音迴圈播放，touchend 時將音訊的播放時間設定到 0 並取消靜音迴圈，達到了鬆手播放的效果，但是這種 “另類” 的操作可能就無法保證相容性了。

總結：

透過定位 iOS 的版本，快速進行了問題復現，雖然無法解決但是問題定位方式是有效的。

綜上所述，面對移動端尤其是微信 H5 的複雜相容性測試挑戰，開發團隊需充分理解各裝置、系統版本、微信版本及瀏覽器核心的多樣性。

精心策劃的測試策略，結合自動化測試工具與真機測試，能夠高效地覆蓋大部分目標使用者場景，確保應用的核心功能和使用者體驗達到可接受的相容性標準。

---