突然接到一个测试任务：埋点部分功能全面检查第一轮测试
咦？埋点是什么？问问旁边的两位同事，他们也没听说过埋点...
后来经过网上百度、问同事，终于弄明白了，在此做一下记录：
1、关于埋点
曾经有一个乐队在他们的演出条款中明确的写道：演出前，承办方必须提供巧克力豆，但绝对不许出现棕色豆；如有违反，乐队立即取消演出。
相信不少的同学在看到这个条款的时候第一反应都是，搞艺术的人怪癖真多！
真相是，多年后，这个乐队的主唱范·海伦在自传中揭晓这一霸王条款的来由：“乐队怎样检测承办方的重视程度？这似乎很难！而把棕色巧克力豆的条款夹在合同里，就是确认承办方是否认真阅读了所有条款的一个办法！在合同中巧妙‘布雷’，如果承办方不幸中招儿，那就没得谈！”事实上，这一条款出台后，乐队再没有为安全问题伤过脑筋。
上述这种Event Tracking的方式放在互联网应用中，俗称就是“埋点”。
从IT开发的角度出发，当应用系统（网站、App等）投入运营后，在做用户行为分析的时候需要去挖掘核心业务功能使用情况时，往往会需要在应用的代码中添加一些额外的代码来采集数据，这就是所谓的“埋点”。包括访问数（Visits），访客数（Visitor），停留时长（Time On Site），页面浏览数（Page Views）和跳出率（Bounce Rate）等。
这样的信息收集可以大致分为三大类目标数据：
1、行为数据：时间、地点、人物、交互、交互的内容；
2、质量数据：浏览器加载情况、错误异常等；
3、环境数据：浏览器相关的元数据以及地理、运营商等；
埋点的方法除了在产品研发的时候直接在程序里嵌入代码统计搭建自己的平台以供查询以外，也有利用第三方统计工具（如友盟、神策、GrowingIO、谷歌的Google Analytics等)。但是不管哪一种埋点方式也不管哪一种埋点机理，在数据埋点以后还需要做的非常关键的一件事情就是埋点测试，从测试人员的角度来看，更准确一点的说法为“埋点数据的测试”。
埋点测试只是数据采集的一种术语，而数据采集是提供给运营工作人员去了解手机app对于某些模块、场景的用户使用情况.进行的一个触发埋点，将埋点采集到的数据到的数据进行上报的过程。
采集数据只是起点，将数据进行分析、整理、汇总以及报表展示，最终得出用户对app普遍对使用行为，从而实现app面向用户的改良才是目的.
为了产品更好符合用户需求体验才是终点。
埋点数据的注意事项
埋点数据的一致性：埋点数据的值需要注意客户端和服务端的一致性，包括编码格式、大小写、全角半角、发送时机等。
编码格式：埋点数据的值为中文时，尤其要注意编码格式。为了避免服务端解析数据出错，一般情况下，客户端需要对发出的数据进行编码格式转化；
大小写：埋点数据的值在命名时要和服务端数据组同步命名规则，尤其是大小写；
全角半角：埋点数据的值为英文时，常常容易忽略全角半角的输入方式，有时候会因此产生无法接收的错误；
数据格式：埋点数据的数据格式在定义时要简单明了，尤其是非实时数据的发送机制，发出的数据量大且同一条埋点发出好多，需要整合；
发送时机：埋点数据发送往往是一个公共功能，且发送时机一般情况下分为两种：实时和非实时。因此将数据发送功能作为一个单独的模块存在，其他功能调用即可，避免所有模块在发送时各自处理，增加测试成本；
埋点数据的命名规则：埋点数据的规范化命名规则有利于数据的阅读和查看，比如页面点击的就用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，即可看到操作的日志，如图所示：
检查埋点是否正确，出现错误的情况一般是：
a)漏埋点
b)埋点和操作类型不对应，比如点击的是“下一步”，却上报了“返回”
c)埋点和操作频率不对应，比如只操作了一次，却上报了两次
2 测试要求&所提供材料：
测试要求&所提供材料：
1、在测试环境进行测试
2、检查点
检查相应的模块是否做了埋点处理
检查做埋点处理的模块的参数bpCode 是否正确
检查埋点接口服务端是否返回成功的消息
(result=true)
检查下埋点服务器的请求地址
测试环境：http://x.x.x.x:8680/hs-xh-buryingpoint-web/lbp/doLog
预发环境：http://x.x.x.x:8680/hs-xh-buryingpoint-web/lbp/doLog
生产环境：http://x.x.x.x:8680/hs-xh-buryingpoint-web/lbp/doLog
检查目前其他入参信息的准确性
(clickTime，appVersion等等)
针对目前全部会进行埋点的模块：
各个模块埋点编码的对应表： (此处是接口文档地址)
目前的埋点大部分只会在点击某个菜单的时候做埋点处理
3 测试步骤
1、测试使用工具：
fiddler 功能点：过滤
（https://blog.csdn.net/java2013liu/article/details/53337584fiddler）
或关于过滤成只查看x.x.x.x:8680/hs-xh-buryingpoint-web相关的内容
2、打开APP进行抓包。
2.1 首先抓取
http://x.x.x.x:8680/hs-xh-buryingpoint-web/lbp/doLog相关的内容
2.2 对各个模块或者功能点参照接口文档中的埋点模块进行一一核实，看所传的参数和响应结果是否有异常
3、有异常时可查看log信息：
tail -fn200 /data/ftp/log/xx.log
