项目上线之后，产品质量的衡量标准一般考虑两个方面：用户反馈和埋点数据。而埋点数据是产品最直接的“镜子”。
今天我们要介绍的是，作为测试，如何理解埋点数据，并且测试中的注意事项。
埋点数据的意义
产品的晴雨表。埋点数据可以直观展现产品各个功能的用户反馈，对于后续的产品规划和功能优化有很大的指导作用。
优化排期和指导工作量调配。从测试角度，我们希望发现的所有问题都得到完美的解决，但事与愿违，当项目很急时，我们可以通过埋点数据查看该问题的影响范围，从而为推进问题解决提供依据。
埋点数据的内涵
埋点数据一般分为：展现，点击，状态，计数四种类型。不同的类型代表着产品不同方面的需要。
展现。某个功能逻辑实现之后展现在用户面前的数据量。例如，资讯信息流的广告，当滑动资讯信息流展现广告时，此时发送广告的展现埋点数据，一般命名“XXXShow”；
点击。人为操作之后发出的数据量。这种埋点数据较为单一，正常控件元素点击，一般命名“XXXClick”；
状态。某个功能逻辑实现之后的状态。一般指的是开或关，登录与非登录等，一般命名“XXXStatus”；
计数。通常指的是一个功能点击了多少次，切换了多少次等，一般命名“XXXCount”；
此外，点击类埋点在一定的条件下可以转化为计数类埋点，当遇到需求时，从埋点的作用角度思考合理性。若是单纯统计某个元素或者控件的点击量，此时应该定义为conut类型；若是为了统计某种状态下元素或者控件的点击效果，此时应该定义为click类型。
埋点数据的注意事项
编码格式。埋点数据的value值为中文时，尤其要注意编码格式。为了避免服务端解析数据出错，一般情况下，客户端需要对发出的数据进行编码格式转化；
大小写。埋点数据的key值在命名时要和服务端数据组同步命名规则，尤其是大小写，一般情况下数据组在过滤收集数据时是不考虑大小写的，但是也有例外。例如，之前在测试SDK时，客户端改变了命名规则，而服务端限制了大写，导致线上数据出现异常；
数据格式。埋点数据的数据格式在定义时要简单明了，尤其是非实时数据的发送机制，此时发出的数据很多，往往同一条埋点发出好多，此时我们要整合一下数据格式。
发送时机。埋点数据发送往往是一个公共功能，且发送时机一般情况下分为两种：实时和非实时。因此将数据发送功能作为一个单独的模块存在，其他功能调用即可，避免所有模块在发送时各自处理，不然会增加测试成本。此外，在发送自测case时（注释：自测case是指开发提测之前，衡量是否能提测的主路径测试用例）要标记清楚。例如：“数据发送有独立的接口，请直接调用即可”这样的提示，以免新来的同学不了解逻辑而单独处理。
预置数据。埋点数据往往需要云端的配置文件支持，此时我们就要留意在配置文件下发之前可能产生的逻辑，这部分逻辑的数据埋点要在云端和本地同时存放，即本地要有预置数据。
埋点命名规则。在测试中要和产品形成一种隐含的规则，双方都要遵守。此外，埋点命名首字母要大写，这些细节不是强制性的，但是有利于数据阅读和查看。
埋点数据的合理性
埋点的准确性和合理性。例如，浏览器的分享web页功能，开发一开始将埋点放在点击分享按钮之后；即下图中蓝色按钮之后，但是这种情况忽略了一个问题，如果单纯的统计分享按钮的点击次数，这种逻辑是正常的，但是如果要统计web页信息分享之后的数据，应该将埋点设在下图红色框内的按钮点击分享成功之后。否则如果用户点击了分享按钮但是没有触发具体的分享操作，那么此时数据就会出现误差。
针对埋点数据的四种类型，我们逐个举例分析。
展现埋点。最关键的在于避免重复统计。例如，浏览器有搜索VR功能，需要统计不同的搜索展现的VR的数据。例如下图中“快乐大本营”是搜索出来的VR，但是由“快乐”变化到“快乐大”的过程中虽然从逻辑上重新做了处理，但是对于用户来说，连续输入看到的始终是搜索VR---“快乐大本营”，因此多次统计就没有产品意义。
点击埋点。关键在于避免服务器超时的情况下连续点击导致的重复统计。例如，资讯信息流的刷新统计埋点，当服务器超时的情况下，连续多次的点击，此时如果客户端发出的请求，统计刷新数据是没有问题的，但是请求如果没有发出，那么此时统计多条就是不正常的。
状态埋点。关键在于避免统计默认状态。并且状态埋点统计的一定是最终的状态。例如，由开切换到关，那么最后发出的状态数据一定是关闭的状态。此外，例如，浏览器的网页护眼色（如下图）。浏览器网页护眼色默认状态是无护眼色，因此，我们在关注护眼色的状态时就要验证在调起工具栏的同时，护眼色的默认状态是否发送了数据，如果发送了就是错误的，或者发送的为空，都是没有意义的。
计数埋点。关键在于避免遗漏。一般情况下，非实时发送的计数埋点容易出现遗漏情况，因为涉及到数据库的读写。因此在测试时要格外留意。
埋点数据的注意事项
网页缓存。对于web页面的埋点统计，要考虑到web页缓存的问题。例如，资讯详情页有停留时长的统计，当进入资讯详情页时开始计时统计，不在该页面时结束统计，那么此时我们就要考虑到在前后台相互切换时是否存在多发的情况，之前浏览器遇到的问题就是将缓存页的时长页做了统计一并发送到了服务器。
网络环境。当网络特别差的时候，客户端发送埋点失败，这种情况下应该将发送失败的数据保存在本地，等下次条件满足的时候一并发出。避免出现丢掉数据的情况。
覆盖安装。产品升级之后，升级之前的埋点不能被删除掉，应该保存在本地，待升级之后满足条件一并发出。
服务端压力。数据发送有实时和非实时两种，当实时数据量特别大时容易给服务器造成压力，因此在测试时要特别留意。