兼容性测试主要有手动测试、自动化测试和云平台测试三种方法。
现在业界主流机型兼容自动化思路，是利用多机型云平台海量的设备进行被测 App 的安装卸载、稳定性、功能测试等测试。本节主要介绍自动化实现部分，云平台使用部分在下一节介绍。
通过在 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 信息如下：
Native 层 Crash 信息如下：
如果 Crash 的 Trace 信息中包含被测 App 的包名（ com.sample.app ），那么这个 Crash 就是被测 App 引起的。
为了测试 App 在各种不同机型上的稳定性，通过工具测试进行数小时测试，发现 Crash 问题。业界主要通过两种方法进行测试，具体如下：
a、控件遍历测试
现在业界测试实现方法基本包含以下几个步骤。
（ 1 ）获取当前被测 App 的所有控件方法见下表：
在手机 （ Android ）项目中，搭建了一套自动化工具。通过编写功能测试自动化脚本，在内部云平台设备上运行。自动化框架如下图所示：
当你面对下图这样的测试结果，如果仅仅通过文字判断，结果是完全正确的。但是，你能承认结果是正的吗？很显然不能。因为背景颜色发白，不符合预期。
问题的关键在于： 自动化无法验证复杂的界面颜色、布局、背景等元素。
如何破解呢 ？从投入产出比来看，采用自动化运行，人工验证结果（截图）的半自动化方式。
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
UI 级别的自动化给人的印象一直就是 “ 变化太大，收益太低 ” 。一旦 UI 发生了较大变化，之前的自动化脚本就会有较大改动，投入高，收益低。
怎么破解这个难题？思路如下：
（1）降低建设成本： 笔者以编写自动化脚本为例，首先，选择一个低学习成本而且高效率的框架很重要。其次，不断地累计公共函数，让脚本开发速度提升数倍。
（2）提高使用频率： 自动化测试使用频率越高，收益就越高。同一套自动化脚本，在当前版本每次回归时都能使用；同样，经过简单修改后，在下个版本中也能发挥重要作用。
（3）以不变应万变： 自动化的模块还是优先选择 UI 相对变化较小的模块，这些是适合自动化的部分，能在未来减少变化带来的成本。
（4）发展多种经营： 自动化脚本的用途，绝对不只是在功能验证上这么简单。其他各种测试都可以用到，例如：覆盖安装、性能测试、安装包验证 …… 发更多的用途就会有更大的收益。