1、兼容性测试方法
兼容性测试主要有手动测试、自动化测试和云平台测试三种方法。
1）手动测试
兼容性测试最简单的，就是在日常手工测试中，按照一定的策略进行测试。具体有哪些策略呢？
（ 1 ） TOP 机型覆盖。例如，在手机 QQ 浏览器（ Android ）测试中，通常笔者在 “ 迭代测试 ” 阶段采用当前 Android TOP 50 （数据来源：产品经理）机型。在 “ 上线前 ” 测试中，笔者缩小范围，采用 TOP20 机型进行测试；
（ 2 ）差异机型。先分析得出机器差异性在于 GPU ，再根据对 GPU 品牌型号的分析，做精准覆盖。例如：
a、高通 GPU 的机器可以主要覆盖 Adreno 200 和 Adreno 203 ，基本占高通总数的 60% ；
b、Imagnition ： GPU 的机器主要覆盖 SGX544+ 和 SGX531 ，约占该品牌总数的 65% ；
c、Mali ：覆盖 Mali-400MP ，占 72% ；
用上述 GPU 的机器，在测试中重点覆盖。
（ 3 ）已有 BUG 分析的机型覆盖。通过对现有 BUG 库中机型问题进行归纳汇总，归纳出重点测试机型。
2）自动化测试
现在业界主流机型兼容自动化思路，是利用多机型云平台海量的设备进行被测 App 的安装卸载、稳定性、功能测试等测试。本节主要介绍自动化实现部分，云平台使用部分在下一节介绍。
（1）安装卸载
通过在 Android 设备上安装被测应用 → 启动被测应用 → 卸载被测应用，来检验以下两方面内容：
a、安装包的安装兼容性
通过 adb （ Android Debug Bridge ）进行安装和卸载。例如：安装包 test.apk ，包名 com.sample.app ，启动 Activity 是 MainActivity 。
安装： adb install test.apk 。
启动： adb shell am start–n com.sample.app/.MainActivity 。
卸载： adb uninstall test.apk 。
覆盖安装： adb install–r test.apk 。
通过上述命令，进行 App 安装、启动、卸载。观察 console 输出，如果是 success 就是成功，反之就是失败。同时抓取 Logcat ，提供给开发人员。
b、通过启动被测应用，检测启动 crash 等低级致命问题
通过对 Logcat （ DDMS 中工具）打印内容进行监控，查找 Java 层和 Native 层 Crash 信息。
Java 层 Crash 信息如下：
E/AndroidRuntime( 1857): FATAL EXCEPTION: main
E/AndroidRuntime( 1857): java.lang.RuntimeException: Unable to create
service com.sample.app.internal.protocols.ProtocolsPackService: java.lang.
RuntimeException: Unable to register protocol, service is dead
E/AndroidRuntime( 1857): at android.app.ActivityThread.handleCreateService(Act
ivityThread.java:2373)
E/AndroidRuntime( 1857): at android.app.ActivityThread.access$1600
(ActivityThread.java:130)
Native 层 Crash 信息如下：
*** *** *** *** *** *** *** *** *** *** *** *** *** *** *** ***
Build fingerprint: 'XXXXXXXXX'
pid: 1658, tid: 13086 >>> com.sample.app <<<
signal 11 (SIGSEGV), code 1 (SEGV_MAPERR), fault addr 64696f7e
r0 00000000 r1 00000001 r2 ad12d1e8 r3 7373654d
r4 64696f72 r5 00000406 r6 00974130 r7 40d14008
r8 4b857b88 r9 4685adb4 10 00974130 fp 4b857ed8
ip 00000000 sp 4b857b50 lr afd11108 pc ad115ebc cpsr 20000030
如果 Crash 的 Trace 信息中包含被测 App 的包名（ com.sample.app ），那么这个 Crash 就是被测 App 引起的。
（2） 稳定性
为了测试 App 在各种不同机型上的稳定性，通过工具测试进行数小时测试，发现 Crash 问题。业界主要通过两种方法进行测试，具体如下：
a、控件遍历测试
现在业界测试实现方法基本包含以下几个步骤。
（ 1 ）获取当前被测 App 的所有控件方法见下表：
（ 2 ）采用某种算法遍历 App 中获取的控件，基于二叉树遍历算法改进而来。注意点击控件后，当前控件树发生变化。
（ 3 ）针对遍历到的控件进行相应操作，方法见下表：
b、 Monkey 随机测试
运行 Android 原生稳定性测试工具 Monkey ，通过 ADB （ Android Debug Bridge ）实现。
（3）功能测试
在手机 （ Android ）项目中，搭建了一套自动化工具。通过编写功能测试自动化脚本，在内部云平台设备上运行。自动化框架如下图所示：
当你面对下图这样的测试结果，如果仅仅通过文字判断，结果是完全正确的。但是，你能承认结果是正的吗？很显然不能。因为背景颜色发白，不符合预期。
问题的关键在于： 自动化无法验证复杂的界面颜色、布局、背景等元素。
如何破解呢 ？从投入产出比来看，采用自动化运行，人工验证结果（截图）的半自动化方式。
（4）开源自动化平台
https://mp.weixin.qq.com/s/JNHKJfnW74tDeVilIfnfMg
https://blog.csdn.net/addisonko/article/details/50912357
https://blog.csdn.net/budf01/article/details/53694177
https://testerhome.com/topics/7966
https://blog.csdn.net/yorkz0909/article/details/76523271
2、云平台
- 腾讯优测
http://utest.21kunpeng.com/
2.Testin
https://www.testin.cn/
3、百度云
http://mtc.baidu.com/
4、平台对比
图片.png
3、兼容性测试思考
UI 级别的自动化给人的印象一直就是 “ 变化太大，收益太低 ” 。一旦 UI 发生了较大变化，之前的自动化脚本就会有较大改动，投入高，收益低。
怎么破解这个难题？思路如下：
（1）降低建设成本：笔者以编写自动化脚本为例，首先，选择一个低学习成本而且高效率的框架很重要。其次，不断地累计公共函数，让脚本开发速度提升数倍。
（2）提高使用频率：自动化测试使用频率越高，收益就越高。同一套自动化脚本，在当前版本每次回归时都能使用；同样，经过简单修改后，在下个版本中也能发挥重要作用。
（3）以不变应万变： 自动化的模块还是优先选择 UI 相对变化较小的模块，这些是适合自动化的部分，能在未来减少变化带来的成本。
（4）发展多种经营： 自动化脚本的用途，绝对不只是在功能验证上这么简单。其他各种测试都可以用到，例如：覆盖安装、性能测试、安装包验证 …… 发更多的用途就会有更大的收益。
