重客户端业务如何做好埋点测试提效

以下为作者观点：

什么是重客户端业务？

一般行业内会根据业务属性和侧重的不同，划分为重客户端业务和轻客户端业务。属于重客户端业务的有音视频剪辑、直播、修图、地图、游戏等，这些业务需要用户对客户端有大量的操作和互动。属于轻客户端业务的有新闻、商品浏览、交易等，这些业务一般偏重数据展示和轻量级的用户交互。

本文针对重客户端业务如何做好埋点测试提效展开讨论。

一、常见的客户端埋点测试流程和方法

如下图，埋点需求一般要经过需求、埋点设计、开发、测试、上线及数据回收几个阶段。

在经过需求和埋点设计阶段之后，在埋点开发阶段，一般会使用开发组件调用的方式进行埋点上报，埋点组件的封装可以减少人为的调用错误问题，导致上报失败或者异常。测试阶段会根据需求和技术方案的设计，设计出上报路径场景和场景，用作测试埋点数据上报。

常见测试手段有以下几种：

1.通过日志进行检查；

2.通过数据收集平台进行检查；

3.通过比对上报数据和数据库表数据进行检查。

以上的流程和方式，可以看出存在部分弊端和缺陷逃逸的概率，先提几个问题：

1.上述场景和用例设计，是否能够涵盖大部分用户的操作行为？

2.如何保障埋点上报代码在频繁迭代中不会被改错？

3.错误的埋点数据回收期长，业务的损失如何降低？

4.日志检查、平台数据检查和最终库表检查，耗费的资源和人力在降本增效的当下，如何优化？

5.同账号或者同设备的多人混合操作，如何保障数据和用例的唯一匹配性?

二、 埋点测试面临的一些问题

常见的埋点测试面临着以下问题：

1.测试耗时长：一个和核心功能相关的埋点需求，需要涵盖功能相关的全部用例，以及经过多重对比，才能保证上报字段的准确；

2.用户操作路径无法穷举：一个关键操作步骤的路径汇聚和分支错综复杂，测试用例难以穷举；

3.数据回收时效长：客户端埋点数据上报需要依赖客户端发布流程，埋点数据的产生和回收需要一至多周的周期；

4.效益回报周期长：一些数据是否能带来正向引导，需要漫长的周期来验证，相应的，投入的价值显现也需要漫长的时间。

5.字段上报有干扰：多个测试使用相同账号或者设备操作不同路径，部分公共点字段上报的唯一性难以确认。

三、轻客户端业务的埋点测试提效方式

说到客户端埋点提效，很多人第一时间会想到UI自动化，UI自动化是一种很好的提效方式。既可以随时触发验证，又可以解放测试人员双手，这种方式需要重点关注的是UI自动化测试用例的维护成本和用例的有效性。

在轻客户端业务模式下，客户端不会有复杂的交互和频繁的改版，并且大量数据依赖服务端的传递，所以在客户端架构和用例设计方式良好的前提下，UI自动化是很不错的选择。    

这种模式是否可以移植到重客户端业务？

不行，根据笔者的实践经验来看，这不是一个好的选择。我们试想一下，一个音视频剪辑业务，需要频繁的、开放性的用户操作才能剪辑出一个优秀的视频，如何保证UI自动化用例的路径全面？再或者，在短视频领域日新月异的今天，不久前某音刚刚推出AI视频生成功能，某书将智能模版生成移植到首页。面临快速改版和创新尝试的音视频软件，如何保证UI自动化用例的长久可用？

四、重客户端业务如何做好埋点测试提效？

那么重客户端业务如何做好解决上述问题又能提效呢？有以下两种方案：

方案一：

利用版本集成测试，根据数据分布发现问题

App新版本外发前都要经过版本集成测试，在确保版本集成测试用例覆盖度的前提下，对版本数据进行监测和分析。

每个版本打包的时候做包编号标记，仅集成测试使用这个包。由于每个版本基础用例几乎保持不变（占比85%），且版本用例会做适当的调整和新增（占比15%），所以埋点数据分布趋势需要监测多个版本的数据分布，做出一个合理的数据波动区间参照范围。

收集每个版本集成测试包的埋点数据分布情况，如在波动范围内，可以视为无高优数据异常，允许外发。如发现数据波动异常，则可以在外发前检查代码数据上报准确性。   

上述方案可以解决埋点代码被误篡改的情况，并且共用了集成测试资源，优化了人力损耗问题，在集成测试用例可信度较高的前提下，可以保障主要功能数据上报的准确性，及时监测埋点数据的异常。

有没有更好的办法，可以优化过程测试流程，并利用线上用户数据做路径回溯？继续看方案二。

方案二：

操作路径染色

如何做操作路径染色？以视频剪辑软件为例，首先需要定义起点和终点，梳理所有剪辑和直接投稿入口为起点，梳理有可能的结束和退出操作为终点（下面每一个步骤称之为节点），建立一个路径关系图。所有有可能继续下一步的操作为可能的结束节点，以无法进行下一步操作的节点为最终结束节点，确保路径预测图无环形操作。操作路径的结束节点属于上述梳理的节点集为一次操作结束。

在用户操作进入开始节点的时候，生成一次路径染色唯一id，追踪用户的操作路径，每一次路径结束后，都对比路径上报预期埋点数据和平台数据。如发现特殊路径，反向补充到预期用例集中。如发现结束路径不在路径关系图的结束节点中，则视为出现crash或者程序异常。对比操作可以预埋开关能力，测试阶段做自动校验，线上用户操作仅做追踪和预警。

上述便是方案二的大概思想，方案二可以很好的解决埋点数据校验准确性问题，并且可以提升人效，同时还可以利用线上用户量级，补充异常路径，提前发现问题。由于染色id的存在，也能帮助做数据回溯和确保数据无干扰。

最后：下方这份完整的软件测试视频教程已经整理上传完成，需要的朋友们可以自行领取【保100%免费】

软件测试面试文档

我们学习必然是为了找到高薪的工作，下面这些面试题是来自阿里、腾讯、字节等一线互联网大厂最新的面试资料，并且有字节大佬给出了权威的解答，刷完这一套面试资料相信大家都能找到满意的工作。