之前公司招了一个BI，但是工作了几个月，好像没有预期的实际产出，再加上今年下半年所谓的“寒冬”，公司直接撤了这个岗位，然后公司就开始引进“数据埋点”了。这里水这么一篇博客，是因为我发现很多测试人员好像并不知道什么叫“数据埋点”以及它要怎么测，所以在此说说我的理解，仅供参考。
数据埋点，对于产品迭代而言，有很重要的指向意义。数据分析是产品获得需求的来源之一，通过对用户数据的对比，对数据趋势的分析，能发现哪些环节存在问题，哪些环节有提高空间。同时，数据分析也是检验功能是否有效，是否受欢迎的重要佐证等，数据埋点能让它们以一种非常直观的数据形式呈现出来。
怎么埋点呢(技术实施方案得问开发，我不懂(*^▽^*))，现在市面上有很多第三方平台，比如Growing IO、神策等。这些平台都提供了对应的接入方法（一般也提供了对应的测试方法），然后公司开发人员插入对应的代码就行。也有利用友商提供的SDK做的，我司是用Growing IO的，所以下面的说明就以这个为例了。
埋点的原理，说简单点就是，用户进行的操作，能通过特定的标识符记录下来，这些标识符汇总可以得到一个数据池，根据这些数据池，就可以监控用户的大概操作。比如首页的一个登录事件，开发设定标识符为login_success，类型为计数器(这个类型第三方平台设置)，那么用户每次登录成功(触发的条件是登录成功还是登录都可以在第三方平台设置)，login_success就会+1，通过数据汇总就能大致知道一段时间之内有多少用户进行了登录且成功。（额，大致是这个意思，好像举的例子不是很直白）
所以我们要测试的点就出来了，那就是：按照事件文档(一般找产品要)进行测试，遍历去点点点文档上的事件，看对应的标识符是否有反馈以及反馈是否正确。
下面是我司在Growing IO平台上设置的事件：
其中Growing IO提供了一个debug插件，可以实时看到前端的反馈，主要检查下图中红色框的四个字段对应第三方平台上面设置的内容即可（eg:有关联事件级变量的计数器类型场景）
后端事件的触发，从而查看标识符的反馈，我司采用的异步机制，所以需要跑定时任务之后一起发送数据至Growing IO，而Growing IO本身的数据显示也是有延时的（他们的客服告诉我是1-2小时），所以测起来就有点忧桑，此处略过。
---------------------------------------------------------------------------分割线-------------------------------------------------------------------
我知道数据埋点源于一本书，苏杰的《人人都是产品经理》，几年前老张推荐的，测试同学无聊看看打发时间还是可以的，可以理解产品的一些思维，平时测试的时候也会发现一些新的角度。数据埋点测试，可能要注意的就是页面的覆盖，因为前端界面很多，可能一个事件在七八个界面都有入口，务必做到全覆盖，最好让开发/产品给一个文档，说明改动了哪些界面（我司系统是这样的，不知道其他项目如何），因为数据分析涉及到产品的层次，所以务必做到精准，否则对于错误的数据进行分析得出的需求多半也是不行的，而一个产品的生死，可能会影响到整个公司的生死（可能言重了，2333）
可能点点点久了会比较心累，但是有些脏活累活，还是要测试干，因为这是我们功能测试的职责......