请教：面试中遇到的一个问题，如何从技术手段，保障兼容性测试完整覆盖？
场景：在用户量级比较大的 app（比如上千万/上亿的日活的 app），按日活千万的 app 来说，即使是使用占比只有 1% 的机型也会有 10 万个用户，所以即使是用户占比比较低的机型也需要覆盖。在新需求功能迭代中，如何覆盖更全面的机型兼容测试？
我想到的是：使用一些第三方云真机平台，写一个新功能核心场景的 UI 自动化脚本，然后在几百台的机型上运行 UI 自动化脚本。但是这个方案，面试官说还是没有从技术上解决问题。
好奇具体的做法是什么？大家有好的想法或者方案可以探讨下吗？或者目前大厂的这个场景是怎么覆盖的？
想到的一些思路, 有没想到的欢迎补充:
编码阶段: 代码层面的预防, 比如: 静态扫描, AI 提示?; 结合 IDE 插件, CI 门禁...
测试阶段: 围绕 “选机型” 和 “选用例”, 可能有几种或多种结合 (执行时机和方式: 测试阶段/CI 门禁, 手动/自动, 本地/云平台): 1.针对性的测试,根据 code diff/开发沟通,选取可能影响的机型进行相关功能的最小测试; 2,防御性的测试, 在一定机型 (全量/剪枝), 跑高优用例/精准推荐用例; 3.随机测试, 在一定机型, 跑 monkey/UI 树遍历
发布阶段: 灰度, 报警监控...
反问他
兼容性怎么可能覆盖全量机型？
有一个思路，叫做负一屏测试（离屏渲染），在用户可见的界面之外，展示页面，然后对客户全量推送，但是本质上负一屏如果出问题，比如导致 app 闪退影响也很大。好的一点就是可以提前知道，展示效果。
你应该问他什么样的手段算得上是技术手段，怎么界定一个东西是不是技术手段，给个例子
有个想法不知道成不成立，分辨率归类，这里说的兼容性是分辨率的话
1、按比例，是否可以大致归类，让我这么想起来的就是抖音上传视频 9:16 之类的，这么去划分。
2、按横竖屏分辨率，横评相同为一类。
兼容性只有策略选择，哪有什么技术手段
从按市场分布取 top 机型（品牌、系统、CPU、分辨率等），按产品定位取 top 机型（高中低端用户画像，看人群）。
从技术角度看，大多数公司手头的测试机都不可能那么全，基本上就是手头的测试机覆盖、云真机服务覆盖
从放量上可以做一些 buffer，例如在客户端放量可以分阶段放，通过埋点上报尽早发现兼容性问题，也是能降低适配成本的方案
simple
回复
感谢大家的回复。我目前的公司（app 日活百万左右），就是这么做的 “从按市场分布取 top 机型”。但是如果用户量大的 app，还是会有问题。比如只选取 top50，那么 top51 的占有率虽然可能只有 1%，但是 1000w*1%=10w，是一个不少的用户量，如果在 top51 的机型没有覆盖到，有严重的兼容问题（比如非崩溃，卡顿的 UI 问题），就会有 10w 用户受影响。
通过埋点上报方式和卡顿崩溃监控 可以发现卡顿、崩溃问题，但是兼容问题可以通过埋点方式发现吗？
wind
回复
手机市场尾部应该没有这么大，TOP51 还能占 1%。如果只是从这个角度考虑，可以分析下数据先，再考虑有没有必要为这些尾部数据付出这么高的成本。
一个测试方案的评价需要结合成本和收益共同分析，在这个场景下，要求遍历全部兼容性设备能做到，必然需要付出巨额时间和人力成本。这是一个策略问题，可以结合长尾数据占比分析，联合灰度进行逐步放量覆盖，同步线上观测监控（需具备精细化监控能力）。这样可以在控制成本的前提下，降低兼容问题带来的用户影响
先说非技术上：
1、机型的选择：两个主要的途径，一个是主流机型，国内的像华为、荣耀、小米/红米、O/V 这些比较大的，而且每个品牌下面一般都有几个主流的产品线，以华为为例，有 Mate 系统、P 系列、Nova 系列等，如果条件允许的话，每个产品线都可以选择一个，如果能从一些数据渠道知道这些机型的分布最好，如果没有渠道，有个建议就是去 JD 看各个品牌下对应系列的销量，可以作为参考；另一个路径则是通过后台的数据拿到使用测试的 APP 的机型分布，比如友盟之类的。往往是这两种相结合，优选出一批 P0 的测试机来，同时每隔一段时间比如半年或者一年更新；选择机型这里，有时候也需要考虑研发使用的技术栈或者开发语言对于设备的特殊要求，比如视频类的 APP，可能需要对 GPU 这块有更多倾斜；再比如说 APP 用 Flutter 开发的话，我之前踩过的坑就是 OPPO Color14 系统 H5 页面后台再前台，H5 页面就死翘翘了；
2、系统的覆盖：兼容性的问题绝大部分时候都是系统兼容性的问题，先确保 Android 大的版本都能覆盖到，然后再是国内比较多的 ROM/OS 也有机型，比如鸿蒙 4.0/3.0、澎湃 OS、Color OS 等不同的版本，这个在友盟后台也是能够看到的；
3、灰度策略：上面有人提到灰度，这个是可以使用起来的，如果 APP 支持按照人群或者设备灰度，那就可以使用这个策略，如果 APP 目前还不支持按照这个维度的灰度策略，那就可以借鉴国内各大应用市场的分阶段发布来做灰度发布，大的渠道除了应用宝以外，比如华为、荣耀、OPPO（OPPO 灰度的配置跟其他不同，不支持灰度转全量，略坑）、VIVO、小米都是支持到小数点后一位的分阶段发布的，可以根据灰度期间的问题反馈及崩溃数据等来观察问题；
4、问题搜集及反馈：用户种子群，一般有用户运营通过企微来运营，我之前负责的 APP，我就在十来个微信群里猫着，还有就是后台的意见反馈等渠道；崩溃类的数据，则可以通过自研的上报平台，或者集成友盟、bugly 这些渠道来看。
技术上的，我做过的有这些：
5、崩溃类的问题，可以通过跑 Monkey 来做，没有条件的就使用 google 原生的 monkey 或者使用字节开源的 fastbot，有条件的话自己来开发一个遍历算法效率更高的框架来做；最好是全程自动化一条龙，我之前写过这样的一个框架：从 CI 上拉取指定分支最新的 APK-下载到电脑-ADB 安装 - 执行自研的 Monkey 自动化框架；一般下班前开始跑，第二天上班结束，运行分析的脚本：日志从测试机自动导出到电脑 - 分析其中的 Crash 和 ANR-去重并统计次数 - 对接 bug 系统自动化处理（新问题自动提单，已有问题更新状态或者添加备注）- 数据上报（运行时长、activity 覆盖率等数据），曾经负责测试的一个 APP 上累计提交过 1000+ 的 bug，累计崩溃次数 20000+，绝大部分都是 NPE 问题；
6、UI 自动化测试：UI 自动化测试 ROI 比较低，虽然都说用 PO 模式，但其实改动也比较多，看情况使用吧，不过对于核心的场景，还是建议写写的，发版前在组里有的测试机上都跑跑，能够节省一些时间，能够确保核心功能或者链路是没有问题的，其他不太重要的地方即使有一些小的兼容性问题也都还可以接受；如果技术能力具备的话，可以内部搭建一个设备管理的服务，可以参考 STF、ATX 这些技术了；
7、云测服务：如果组内 UI 自动化测试效果不太好，可以考虑云测；之前买过 testin 的服务，按照次数收费的，包括 Android 和 IOS，可以使用云测来对核心场景进行最多 600+ 机型的兼容性测试，我还有他们的联系方式，需要的话可以私信沟通。