众所周知，APP兼容性覆盖测试一直以来被认为是一个高成本、耗时低效、耗人力的测试工作，且兼容性测试是一项必须要进行的测试项目，因为有不同的机型、系统平台、分辨率、网络、厂商、数据兼容以及不同兼容问题场景需要进行覆盖。本文章将通过本人测试经验围绕质量和测试效率进行阐述如何保证APP兼容测试覆盖，期望有更多童鞋在既能保证兼容质量的同时、又能高效地完成兼容性测试覆盖。
兼容性测试将验证软件与其所依赖的环境的依赖程度，包括对硬件平台的依赖和对软件平台依赖程度，即我们通常说的软件的可移植性 。
简单来说：
- 待测试项目在同一个操作系统平台的不同版本、不同的操作系统平台上是否能很好的运行
- 待测项目是否能与相关的其他软件和平共处，会不会有相互不良的影响
- 待测项目是否能在指定的硬件环境中正常运行，软件和硬件之间能否发挥很好的效率工作，会不会影响或导致系统的崩溃
- 待测项目是否能在不同的网络环境中正常运行
APP兼容测试即是移动端的手机客户端兼容测试。移动终端的碎片化特征使APP测试者为了保障不同系统及版本、不同网络制式、不同分辨率和厂商（不同深度定制的ROM）、不同版本都能够有很好的用户体验而面临巨大挑战，所以APP兼容性测试也是测试质量保障任务中的重要环节。
APP兼容测试具备测试点多，碎片化严重的特征，兼容测试一旦存在漏测，质量未得到保障就会导致线上用户的流失。
所以在移动开发中兼容性测试常常需要涉及到系统、厂商ROM、屏幕分辨率、网络、等其他众多维度。下面将详细展开介绍兼容测试需要覆盖的各个维度。
app系统兼容涉及Android和Ios系统，其中Android系统又分了不同的系统版本，Ios又分不同的系统版本。不同的系统、不同的系统版本都有不同的特征，不同的API，意味着都有可能产生各种各样的兼容问题，所以需要进行兼容覆盖。
其中Android系统具体分布及市场占有率如下表所示：
image
从表中数据可以得出，Android4.4以下市场占有率不到8%，份额小且适配难度高，越来越多的开发者选择了放弃对旧版本的支持,如果目前项目APP的开发者已不支持旧版本兼容尤其是Android2.3之前的，那么测试也可以选择放弃对该类型版本的兼容。
其中Ios不同的系统版本具体分布及市场占有率如下：
image
从表中数据可以得出，Ios8.X以下市场占有率不到2%，可以选择放弃8.X以下版本的兼容，重点覆盖8.X,11.X，10.X，9.X系统的覆盖。
Android和Ios都有不同的手机设备，苹果几乎每年会进行一次换代，目前换代到iphone X 。相比而言， Android 系统源码是开放的，只要遵从相应的协议，就可以对源码进行修改，国内各个厂商就把基于 Android 源码改造成自己对外发布的系统，比如我们熟悉的小米手机 Miui 系统、华为手机 EMUI 系统、Oppo 手机 ColorOS 系统等（只有谷歌Nexus和Pixel系列才是原生系统，但是目前国内很少人用。)由于每个厂商都修改过 Android 原生系统源码，这里面就会引发一个问题，那就是著名的Android 碎片化问题，本质就是不同 Android 系统的应用兼容性不同，哪怕是搭载完全相同的硬件，不同品牌的手机在运行速度、软件兼容上都会有区别的。
image
在不同分辨率、尺寸的设备上，很容易出现字体异常、UI样式异常、换行错位等UI问题，所以需要测试程序在不同尺寸和不同的分辨率下能否正常显示
目前市面上主流的分辨率为：1280x720、2560*1440、1920x1080等等，主流的尺寸是5.5，5.0和4.7。
image
image
保证各种网络环境能够覆盖，包括WiFi、3大运营商的2G和3G、4G网络、有鉴权的wifi和无鉴权的wifi.
按运营商分：电信、移动、联通
按网络模式分：2G、3G、4G、WiFi
按接入点分：wap、net
在目前4G，wifi盛行的时代在非视频游戏类APP测试中网络兼容显得没那么重要。
一般APP网络的兼容主要是针对IPV6网络兼容、弱网兼容、wap和net接入、不同地域（地理位置）的运营网络、有鉴权的wifi和无鉴权的wifi、代理类wifi。
数据兼容性（不同版本间的数据兼容）
蓝牙设备兼容性测试 （如果是一款使用蓝牙的应用）
存储卡兼容性测试（比如文件管理器）
第三方软件兼容冲突（比如输入法冲突）
从上一章节中可以看到，APP兼容性测试需要覆盖的维度就有那么多，每个维度可以继续分裂，兼容性测试关注点如此之多，不可能在测试阶段每个机型每个系统版本网络等进行逐个覆盖，那么怎么在既保证质量的同时，又提高测试效率呢？下面将会从测试需求阶段到上线监控阶段的测试全流程中，讲解每个测试环节应该制定怎样的测试策略来提升兼容性测试效率。
测试越早介入，测试的成本就越低，兼容性测试也是如此。
需求分析阶段，测试童鞋需要和开发、产品、设计师根据需求的场景、历史运营用户数据、市场占有率数据讨论及确定好当前版本需求兼容的系统、系统版本、厂商、屏幕分辨率、网络等的适配方案，这样测试童鞋在需求阶段确定好需要裁剪的系统，系统版本、分辨率兼容。
例如：
系统版本兼容覆盖上：如果Android4.4以下市场占有率不到8%，份额小且适配难度高，目前项目APP的开发者已不支持旧版本兼容Android4.4之前的，那么测试可以在需求阶段和产品、开发确认选择裁剪对该类型版本的兼容。
版本差异兼容覆盖上：需求阶段和产品、开发了解程序底层交互及接口调用，结合本次适配测试重点，就能知道着重检查哪些页面和交互，原则上如果版本之间差异无前端UI和交互变动，则可以裁剪该版本的兼容覆盖。
屏幕分辨率及尺寸：与开发or设计师讨论在不同的分辨率下系统的适配方案，对已不支持不适配的分辨率和尺寸进行裁剪
通过做一些调研，当前市场和线上运营用户的各系统版本、厂商的使用率，结合移动设备分辨率的特性，得出APP的兼容测试矩阵，减少用例的重复设计和冗余。
例如下表（参考）：APP兼容矩阵设计（仅供参考）
APP兼容矩阵设计（仅供参考）.png
兼容性测试关注点有很多，有效的方法是根据测试项或者系统版本的特点、场景实现角度可以对明显差异的内容选择性进行测试设计，减少不必要的兼容覆盖设计。
具体场景特征角度举例如下：
（1）类似图片上传、ocr识别、人脸识别这种与摄像头、手机相册与手机系统应用交互的场景需要考虑系统权限和系统厂商的特征兼容，所以如果有相关需求场景的在测试设计时需重点考虑厂商、系统版本的兼容
（2）类似UI元素密集或图片上传场景，则与分辨率强关联，在测试设计时该类需求需重点兼容屏幕分辨率维度
（3）类似视频播放、数据上传下载、需要实时进行数据刷新的场景则与网络强关联，网络的强弱会很影响用户体验，在测试设计时该类需求需重点考虑网络的兼容（与网络兼容强关联）
从功能实现角度举例如下：
（1）类似页面数据获取，按钮跳转不涉及网络请求后端服务的，直接从本地数据库获取数据来实现的功能则可以直接考虑裁剪网络兼容测试设计
（2）类似PUSH测试等无UI设计的功能则可以考虑直接裁剪屏幕分辨率、尺寸的兼容测试
（3）类似通过webview页面展示的功能，例如webview在Android4.4以后有http与https的安全认证方式的区别，默认不保存cookie的区别，那么针对类似用webview实现的页则需要重点考虑系统版本的兼容设计
从系统版本，厂商特征角度举例如下：
（1）android 6.0以上的部分危险权限需要通过运行时动态申请。所以涉及权限相关功能如定位功能、相机使用，相册调用功能、存储权限、读取通讯录、读取sd卡等功能运行使用时的权限对话框均需要进行系统6.0以下和6.0以上版本兼容测试设计
（2）android8.0通知栏的机制有较大的变化，需要特别留意通知栏、消息推送、通知弹窗、悬浮窗等的兼容测试设计
（3）ROM有特殊定制功能例如典型的三星，vivo和oppo的权限管理问题:
- 对于国外的手机比如三星，不询问权限直接调用，会直接崩溃，这符合android原生系统的权限管理策略。
- 对于国内手机，比如vivo，不询问相机权限，照样会给出弹窗，而且即使勾选“不在提醒”且拒绝权限，下次调用还是照样弹窗直到用户授权才能用，这是vivo系统定制的。
- 对于国内手机，魅族系列，不询问相机权限，依然可以使用相机。
所以不同手机rom和framework不一样都会导致兼容问题出现，测试童鞋需要去分析各个厂商ROM存在哪些不同以及系统在使用过程中的调用方式，对差异性进行评估，然后针对性去设计兼容测试场景。
（1）在开发阶段，可以推动开发同学在代码里面打埋点，从而去获取当前APP线上用户覆盖的top n款手机数据，为后续版本兼容测试设计提供数据依据。
（2）加强代码扫描：通过Lint、sonar工具进行静态代码扫描去提前发现因厂商、API不适配的兼容问题
（3）加强开发代码评审，包括基础框架的代码和各业务代码
由于在测试前期，我们已经做好兼容测试的部分裁剪确认工作和兼容测试设计工作、以及静态代码扫描工作，所以在SIT测试阶段，兼容性测试工作就会轻松不少。
到了SIT测试阶段，就是一个测试执行的过程，测试执行也有相应的测试策略。
（1）兼容测试执行只要开发提测准入通过了就可以开始进行，测试童鞋可以在测试过程中根据兼容测试矩阵在不同测试轮次中切换不同的测试机进行测试并记录
（2）根据二八原则，在做功能测试时先拿历史常出问题机型进行测试覆盖
（3）几轮测试下来，不停切换手机，安装测试包进行测试也是一件繁琐的事，另外测试机可能还存在非空闲情况，有条件的同学可以搭建STF平台进行组内测试机设备管理平台，所有兼容测试工作可以在PC端远程控制真机完成，省时又省力，还能做到测试组内手机共享使用，减少沟通成本。
（4）利用业内已有的云测平台进行兼容测试：
目前基本上大的云测平台都有推出首次免费或者日首次免费的随机安装启动标准兼容服务，免费的一般只能做50~100款机型。如果要做全面的机型覆盖和深度兼容则需要付费了，而且目前各大云测平台的收费较高，如果要全面覆盖所有机型的话，是笔不小的开销。
所以，什么时候用云测平台呢，这个要根据你测试的产品具体特征来考虑：
- 如果测试的app属于受众广泛，运营效果不错，月活过亿的，用户千万、亿级用户的比如微信，qq，支付宝类型的，那么就很有必要投入金钱或者组织人力搭建云测平台进行全面的机型覆盖。
- 如果测试的app受众用户只有不到万，日活月活很低的产品比如中小银行app、房产交易app,个人认为没有必要投入大量的金钱去兼容全部的机型。但是可以利用云测平台去复现线上用户个别未覆盖机型所遇到的bug，拿到日志和解决方案，这样投入的成本相对小且有针对性。
- 如果测试的app受众介于以上两者特征之间的，而且效益也不错，月活日活也能达到上万的例如一些理财产品APP、证券类app、电商app，则可以对目前app当前市场各版本和品牌的使用率，获取当前APP用户覆盖的top n款手机，在云测平台进行top n款手机的覆盖测试
通过组织UAT测试，利用用户或者业务人员的测试能力和测试资源，在短时间内完成大工作量的产品测试和体验，从用户体验的角度出发，反馈兼容Bug，并对产品提出改进建议。
(1)APP上线发布市场后，可以通过crash平台、bugly等监控平台收集因兼容问题导致的闪退和无法安装、运行的错误信息传到后台服务器端，然后开发根据错误日志进行定位，从而找出问题原因并解决。
(2)另外，测试童鞋应该对这次版本不管是测试过程中还是上线发布市场后发现的兼容问题，做问题分析总结，反馈补充兼容测试用例和测试场景，加强测试后续版本的测试手段。
(3)测试及开发童鞋需要对主流手机及ROM更新保持较高的质量敏感性，时刻关注厂商升级资讯和特性，一旦有更新，需要测试线上APP兼容适配情况，快速应变，及时适配到主流机型和ROM。
一切测试工作要围绕质量和效率来进行开展：对当前测试痛点的把握和分析，制定相应的测试策略、通过工具提高测试效率，归纳总结每一次测试的典型问题和疏漏点，指导我们后续的测试工作开展。
Android App兼容性测试是一个比较重要的App评价内容，实际上兼容性测试不仅仅和测试人员相关，在开发阶段就应当着重考虑，因为兼容性问题是除了实现App本身要求的功能后，必须要关注、而且至关重要的一个点。因此，App兼容性是否良好，首先要求App开发人员在开发阶段进行保障，有经验的Android工程师能够在开发过程中保证60%以上用户机型的兼容与适配，经验丰富的工程师几乎能够做到90%以上的兼容适配。
当然，由于市场上Android机型出新速度快，系统升级快，一味的追求在开发阶段的兼容适配保障，一方面延误开发进度，另一方面需要较高的开发投入，因此需要做好权衡，这也是后续Android兼容性测试这一关键测试阶段必要存在的原因。
再说到测试阶段，兼容性测试主要是对App在各类机型上的兼容、适配等情况进行测试。搞清楚这一阶段的测试重点后，因此，Android App在进行兼容性测试前，一定要做好其前序测试内容，否则兼容性测试效果将会较差，甚至出现无效测试。
兼容性测试如何展开
这是兼容性测试流程问题；另一个是为了兼容性测试，需要配置各类机型手机么，这是兼容性测试的设备基础问题。
机型配置问题
Android兼容测试一定要做到宽范围覆盖，如果做不到这个，那么就违背了兼容性测试的目标——测试App在各类机型、系统上的运行是否兼容、适配。
因此，兼容性测试必须要在各个机型、系统上对App进行运行、测试，查看相关UI是否适配、功能是否正常。所以，必须要为兼容性测试配备尽可能多的机型。这是不是意味着，你的公司要去购置各类机型设备？当然不是。对于一般的公司或者开发者，这将会是一大笔开销，为了节约资金而造成进行覆盖率较低的话，则失去了兼容性测试的意义。另外，这也是没必要的，因为往往你就一个或两三个App，为了这少量App测试，而去购置如此大量的设备，无疑是一种资源浪费。除此，还有一个原因，将在兼容性测试如何展开里去说。除此，机型量的多少也是一个权衡的过程，目前，通用的兼容性测试一般覆盖Top100-300的机型，对于实在是小量机型或者老旧机型，用户量非常小，在一定程度上，是否需要覆盖则需要权衡，总的来说，Top排名的手机基本足够。
再来说一下第一个问题，兼容性如何展开。
这是一个经验性的过程，可以去借鉴大型互联网公司的成熟App的测试方法。目前，无论是国际知名App，还是国内知名App，谷歌、Facebook，BAT等，他们都有大量的App对外推出，对于App兼容性要求非常高，因此，他们的做法是非常值得借鉴的。这些公司的兼容性测试，都有一个相同的解决方案，那就是自动化测试框架与平台的实现。通过浏览上述公司在各种大会公布的内容，或者通过论坛知识分享，都能看到，他们不仅有自己的测试实验室，拥有大量的手机，除此，还有一整套的自动化测试平台，来完成兼容性测试。这就是前面说的不用配置如此多的机型的另一个原因，即便是配置足够的机型，你还缺乏一套兼容性测试自动化平台，能养得起一大批测试人员和维护人员。因此，我们可以看到，兼容性测试目前大型互联网公司的做法，通常是采用自动化测试平台，搭建自己的测试实验室，完成如此多的机型测试。
针对个人开发者、初创公司，以及App比较单一的公司，实际上是不推荐效仿大型公司的做法，这种做法提高了App发布成本，另外还需要扩充开发团队，增加管理成本，最终落实到实际使用上又造成了较大的资源浪费。那如何去完成呢？实际上，目前很多的公司，已经提供了兼容性云测服务，例如TestIn、TestBird，除此，大型公司也对外推出自己的测试工具，比如谷歌、腾讯WeTest、百度MTC、阿里MQC等等，这些平台，我都有去体验使用过，其实不乏一些付费项目。
链接：https://blog.csdn.net/FlyPigYe/article/details/92834962
