「测试匠谈」栏目由优测倾心打造，汇集腾讯明星产品团队顶尖的技术专家，倾囊相授测试领域的知识技能与实践！

本期嘉宾介绍
Iris Du，腾讯微信事业群研发工程师，担任微信商户产品的开发工作，曾参与微信AI智能客服、生物识别硬件产品等多个技术创新项目。

摘要：截至目前，移动端对比桌面、平板的市场使用份额已经达到52.92%。在微信生态项目中，大部分H5页面都是运行在微信内（即微信内置浏览器），用户使用的移动端设备、系统版本、微信版本五花八门。本期文章将详细介绍微信H5兼容性测试的理论、方法和实际案例。

现状与挑战

开发人员通常会像常规Web开发一样开发H5，并在自己的手机上进行测试。产品上线前同组组员进行体验测试，有什么手机就测什么手机，无法保证测到了市面上的多少设备。

还有一种测试方法是测更多的手机型号，很多自动化测试平台就是采用这种策略，但这种策略是否适合微信H5测试呢?

为什么微信H5兼容性测试困难？

① 移动端设备复杂

Android的设备情况：

OpenSignal 在 2015 年 8 月发布的基础统计数据可以看到Android的设备复杂度。到了2024年，如今设备的复杂度肯定只增不减。

iOS的设备情况：

根据维基百科显示，截至2024年9月，苹果公司已推出46款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%25®ion=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 浏览器兼容性也可以看出，一个属性的兼容性只和浏览器和浏览器版本相关，根本原因是因为浏览器内核不同。

微信内置浏览器内核和测试方法

浏览器内核包括浏览器的渲染引擎、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的复杂兼容性测试挑战，开发团队需充分理解各设备、系统版本、微信版本及浏览器内核的多样性。

精心策划的测试策略，结合自动化测试工具与真机测试，能够高效地覆盖大部分目标用户场景，确保应用的核心功能和用户体验达到可接受的兼容性标准。