我做巡检的目标是：用户可见即可用，也就是用户打开 APP，从各个页面能够看到的那些数据，都是尽可能正确的。以其让用户来反馈我们问题，还不如我们自己主动去发现问题。举个例子，电商 APP，比如 JD 这种，用户打开 APP 会在首页看到很多的内容，但基础的可能就是像活动、商品这些基本元素，那我的目标就是通过接口自动化的方法，拿到用户看到的这些数据，然后去调用对应的接口比如活动详情页的接口，商品详情页的接口等等去拿到实际在端上显示的内容，然后去做检查，比如商品，那就可以去检查商品图、商品描述、规格、优惠券、促销这些信息，如果配置上存在一些问题，那么从接口层面就能够巡检出来。。但线上数据可能很多，所以这里就需要用数据库把测试过的数据及结果存到表里，这样就不用重复测试，而且像商品这种，价格是很敏感的，首页看到的价格和商详中的价格如果不一致，用户是完全可以去投诉的，这种我之前做电商业务的时候经常遇到反馈，后面就是通过这种方式巡检查到某些商品 sku 促销或者秒杀等情况下系统处理有问题导致价格不一致的问题，发现问题就通知研发或者产运去改好了。再比如视频的项目，视频的封面、描述、封面图（第 I 帧可能会是黑屏）、音轨、字幕、视频流这些都是可以作为基础元素去做巡检的。

我的做法是：有点像数据驱动的方式，先通过接口抓到用户可能看到的数据，比如首页这种，然后针对每种基础元素可能会去调用其详情页的接口，这里用到了我写的一个方法，能够将抓取到的数据自动转成自动化的测试用例，然后去执行，最后再做断言。我用的还是传统的 unitest 框架，自动将数据转成自动化测试用例用到的是 setattr 这个方法，比如我从首页抓到了 100 个活动和 300 个商品，那么这一轮测试就可以动态生成 400 条的测试用例，测试报告用的是中文版的 htmltestrunner，测试报告里面能够看到每一条 case 以及测试结果，失败的 case 也可以通过对接飞书发送提醒啥的。资源异常类的 case，我单独拉了个产运的群，失败的 case 都会推送到飞书群并 at 到对应的人员进行跟进，目前看效果还可以。

我现在的团队不多，只有 3-4 个外包同学。不过你的感觉是对的，后面我这边基本上也很难招正式的测试了。

使用三方 SDK 的这种，我之前的项目都没用到，这个确实没有实践过。

关于埋点

我们这边的埋点没有接比如神策这种的第三方，是通过服务端提供的单独的接口进行上报的，同时会写一份数据到阿里云上，那么对于我们来说，之前的测试方式就是客户端手动触发，然后去阿里云的后台查看，通过一些关键字进行查找，但这种方法比较好测试出来有没有漏报，但重复上报也勉强能看，但比如多上报了其他不应该上报的埋点这个就不太方便了，另外就是我们的业务场景要统计某个埋点在一段时间多次上报的累计数值，这个后台完全没办法，只能自己一个个记录下来然后去算，效率也很差，结果也往往不准。

怎么做

有几个思路，第一是客户端调用埋点上报，第二是服务端接口处理，第三是落库数据查询，第四是阿里云埋点数据分析，这几个方法都是可以去尝试的，除了第三种（这个生产环境的数据库权限比较敏感），我都有尝试过，这里都可以给大家大概说下。

1. 先说第四种：这个就是手动把一段时间内的埋点按照要求查询并导出一份数据，阿里云支持 csv 的，然后就可以用代码来解析，也可以用 pandas 来。但这个一般适用于线上所有用户下的某些埋点或者针对某些特定用户的埋点数据进行异常检查，比如核心埋点 A，有 N 个枚举值，你在测试过程中可能覆盖不全，或者生产上可能会出现完全意想不到的异常情况，那么这个就可以派上用场了，我一般会定期的来分析一些特定的埋点，给研发提一些埋点上的问题。举个例子，埋点上报了某个异常，那就可以通过这种数据分析的方法来判断是不是某些资源出了问题，因为如果是资源的问题，那就会比较集中在某些资源上。
2. 再说第二种，这种可以通过中间人代理的方式来做，有个工具 mitmproxy，大家可以研究下。这个其实跟 charles 这些抓包工具类似，不同点在于可以通过 python 代码来把抓到的接口请求和返回数据做处理，去分析里面是不是有重复上报的问题，去计算某些埋点统计数据的问题，这些都是可以做的。工具很强大，也能支持 MOCK。之前我们 APP 做合规自动化测试的时候我用的这个，一边跑 MONKEY，一边把所有的接口数据都抓到，然后看接口的 header、data、cookie 里面有没有像 androidID，经纬度之类的一些敏感的字段，以满足合规方面的要求。埋点的数据也是如此，不过因为一直要连着代理，略微麻烦一些，而且像支付类的接口不能代理，会测试不到。
3. 再说第一种，也是我现在用的。客户端调用接口上报埋点成功的时候，将埋点的数据通过 tag 的方式，把日志打印到 console 端，然后 Android 借助 adb logcat，IOS 借助 tidevice syslog 就可以抓取到所有的日志，然后通过 tag 的方式进行过滤拿到所有上报的埋点数据，然后去解析埋点的 event name 和 event info。这样连着数据线测试，一边操作，电脑终端就实时显示埋点信息，也非常方便，比如进入某个页面，上报了一堆埋点，能够很明显看出哪些埋点是不需要上报的，这个用之前的方式是很难测到的。重复性判断也简单，

def checkDuplicate(self, tsp, eventName, eventExtra):
    # 检查当前埋点是否重复上报，并输出上报的次数
    key = f'{eventName}---{eventExtra}'
    if key in self.eventsDict:
        self.eventsDict[key][1] += 1
        print(Fore.RED + f"{self.eventsDict[key][2]}！！！请注意：{eventName} 检测到有{self.eventsDict[key][1]}次重复上报：{eventExtra}" + Style.RESET_ALL)
    else:
        self.eventsDict[key] = [eventExtra, 1, tsp]

eventInfo 是可以转成 json 的，所以你可以很方便的提取出来里面的数据，然后进行累加计算这种（这个解决了我们测试的一个难点问题，我们要统计某个埋点上报的时长字段，需要多次操作触发这个埋点然后计算总数），而且也可以校验某些字段是否缺失，某些字段的值是否异常（举个简单例子，一个上报时长的字段，研发之前异常处理有问题，上报了一个很大的时间戳数值之类的）。至于 tag 和打印到 console 端的日志，这个就和研发这边沟通好就行，需要注意的是，Android 一般只能在 debug 包上测试（跟环境无关，测试和生产均可），iOS 一般也是在 debug 包进行测试，release 的包一般不打印日志的。

先说非技术上：
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+ 机型的兼容性测试，我还有他们的联系方式，需要的话可以私信沟通。

还有一个关键的问题在于，做这种基于 UI 的自动化，其实际的意义能有多大？框架本身无可厚非，技术学习也非常重要，但结合到项目实践中，通过这种 UI 的自动化，我们的投资产出比能有多少呢？如果楼主在某个 app 项目中持续做下去的话，最后希望能用这个项目的实际数据来为我们解惑。