曾经有一个乐队在他们的演出条款中明确的写道：演出前，承办方必须提供巧克力豆，但绝对不许出现棕色豆；如有违反，乐队立即取消演出。

相信不少的同学在看到这个条款的时候第一反应都是，搞艺术的人怪癖真多！！！

真相是，多年后，这个乐队的主唱范·海伦在自传中揭晓这一霸王条款的来由：“乐队怎样检测承办方的重视程度？这似乎很难！而把棕色巧克力豆的条款夹在合同里，就是确认承办方是否认真阅读了所有条款的一个办法！在合同中巧妙‘布雷’，如果承办方不幸中招儿，那就没得谈！”事实上，这一条款出台后，乐队再没有为安全问题伤过脑筋。

上述这种Event Tracking的方式放在互联网应用中，俗称就是“埋点”。

从IT开发的角度出发，当应用系统（网站、App等）投入运营后，在做用户行为分析的时候需要去挖掘核心业务功能使用情况时，往往会需要在应用的代码中添加一些额外的代码来采集数据，这就是所谓的“埋点”。包括访问数（Visits），访客数（Visitor），停留时长（Time On Site），页面浏览数（Page Views）和跳出率（Bounce Rate）等。

这样的信息收集可以大致分为三大类目标数据：

1、行为数据：时间、地点、人物、交互、交互的内容； 

2、质量数据：浏览器加载情况、错误异常等； 

3、环境数据：浏览器相关的元数据以及地理、运营商等；

埋点的方法除了在产品研发的时候直接在程序里嵌入代码统计搭建自己的平台以供查询以外，也有利用第三方统计工具（如友盟、神策、GrowingIO、谷歌的Google Analytics等)。但是不管哪一种埋点方式也不管哪一种埋点机理，在数据埋点以后还需要做的非常关键的一件事情就是埋点测试，从测试人员的角度来看，更准确一点的说法为“埋点数据的测试”。

以下为网上盛传的知乎埋点测试的流程图，从图中可以看出测试人员主要是依据埋点需求进行数据的测试，也就是通常我们说的Checking而非Testing。

知乎埋点测试流程.jpg

埋点数据的注意事项

• 埋点数据的一致性：埋点数据的值需要注意客户端和服务端的一致性，包括编码格式、大小写、全角半角、发送时机等。

• 编码格式：埋点数据的值为中文时，尤其要注意编码格式。为了避免服务端解析数据出错，一般情况下，客户端需要对发出的数据进行编码格式转化；

• 大小写：埋点数据的值在命名时要和服务端数据组同步命名规则，尤其是大小写；

• 全角半角：埋点数据的值为英文时，常常容易忽略全角半角的输入方式，有时候会因此产生无法接收的错误；

• 数据格式：埋点数据的数据格式在定义时要简单明了，尤其是非实时数据的发送机制，发出的数据量大且同一条埋点发出好多，需要整合；

• 发送时机：埋点数据发送往往是一个公共功能，且发送时机一般情况下分为两种：实时和非实时。因此将数据发送功能作为一个单独的模块存在，其他功能调用即可，避免所有模块在发送时各自处理，增加测试成本；

• 埋点数据的命名规则：埋点数据的规范化命名规则有利于数据的阅读和查看，比如页面点击的就用Page开头，区域的用Label开头作为前缀；

在规范化埋点数据的一致性后，还需要针对埋点数据的正确性进行检验。埋点数据又可以分为四个类型：展现类、点击类、状态类和计数类。

• 展现类的埋点。最关键的在于避免重复统计。比如在某宝搜索“华为手机”时，当用户输入了“华为MATE10手机”和“华为MATE10”出来的效果几乎是一样的，失去了统计的意义。

• 点击类的埋点。关键在于避免服务器超时的情况下连续点击导致的重复统计。

• 状态类埋点。关键在于避免统计默认状态。并且状态类埋点统计的一定是最终的状态。例如，由开切换到关，那么最后发出的状态数据一定是关闭的状态。

• 计数类埋点。关键在于避免遗漏。一般情况下，非实时发送的计数埋点容易出现遗漏情况，因为涉及到数据库的读写。因此在测试时要格外留意。

因此，大家可以看出埋点数据的正确性更多的是需要在埋点设计的前期就对需求进行正确性、合理性的考虑，埋点数据的一致性更多体现在实现的技术上对数据一致性的校验。

另外，还有一些特别的注意事项：

• 网页缓存：对于web页面的埋点统计，要考虑到web页缓存的问题。例如，资讯详情页有停留时长的统计，当进入资讯详情页时开始计时统计，不在该页面时结束统计，那么此时我们就要考虑到在前后台相互切换时是否存在多发的情况，之前浏览器遇到的问题就是将缓存页的时长页做了统计一并发送到了服务器。

• 网络环境：当网络特别差的时候，客户端发送埋点失败，这种情况下应该将发送失败的数据保存在本地，等下次条件满足的时候一并发出。避免出现丢掉数据的情况。

• 覆盖安装：产品升级之后，升级之前的埋点不能被删除掉，应该保存在本地，待升级之后满足条件一并发出。

• 服务端压力：数据发送有实时和非实时两种，当实时数据量特别大时容易给服务器造成压力，因此在测试时要特别留意。

举一个小例子，拿经常使用埋点的移动端平台来说，比如我们需要查看Android平台的埋点是否有效时，前提准备是有Android平台的ddms环境（可以使用androidstudio，或者直接使用android sdk里带的monitor）和埋点字段表（这是开发埋点的依据，以及产品分析的标准）

测试方法为： 

1、调起monitor之后，连接移动设备 

2、设置logcat的filter，填写包名即可 

3、取已埋点的安装包并且输出app埋点的日志 

4、查看埋点字段表，执行对应有埋点的操作

比如埋点字段表中，需要监测的埋点为点击首页中的“下一步”时

埋点字段表

5、进入手机上的app，点击 下一步

6、查看ddms的logcat，即可看到操作的日志，如图所示：

logcat的日志

7、检查埋点是否正确，出现错误的情况一般是：

a)漏埋点

b)埋点和操作类型不对应，比如点击的是“下一步”，却上报了“返回”

c)埋点和操作频率不对应，比如只操作了一次，却上报了两次

关于埋点测试也可以做自动化的考虑，知乎，阿里等公司都出了对应于自己公司的埋点自动化测试工具，后续同学们要有兴趣也可以继续的八一八。

以上是关于埋点测试的一些归纳总结和思考，若有做埋点测试的同学也欢迎大家一起来讨论和分享。

版权声明：本文出自51Testing原创，51Testing软件测试网及相关内容提供者拥有内容的全部版权，未经明确的书面许可，任何人或单位不得对本网站内容复制、转载或进行镜像，否则将追究法律责任。