京东埋点测试平台建设实践
截至目前，京东零售集团拥有超过4.174亿活跃用户，是全球2600多家超亿元品牌和数十万个第三方商家的最大增量场。为了研究业务模块功能是否满足用户的期望，业务团队通常会在应用程序中预先设置埋点数据。若用户在使用应用程序的过程中，触发预先设置了埋点的功能模块，应用程序会发送相应的埋点数据到服务器，如下图。通过处理埋点数据以及进一步的分析，能够推测出应用程序功能是否被用户广泛使用，并可根据埋点数据结果对应用程序进行调整或改善，从而更好的满足用户需求，提高用户体验。
为了保证埋点数据分析结果的正确性，通常在应用程序发版之前，测试人员需要对埋点数据进行测试。现有技术中，埋点测试方法一般如下：应用程序在设置埋点数据后，测试人员通过抓包工具（Fiddler、Whistle等）截获网络传输的数据包，并在数据包中提取出埋点数据进行校验。具体的校验方法：应用程序上报的埋点数据与预先规定的埋点数据需求文档是否一致，一致则测试通过，否则应用程序需要重新设置埋点数据，测试人员重新触发埋点进行验证。
1、早期的埋点测试方法通常是：测试人员通过抓包工具（Fiddler、Whistle等）截获网络数据包，抽取出埋点数据，然后和埋点数据需求文档人工进行一一对比；当埋点数量较多时，测试人员需要频繁的通过抓包工具获取埋点数据，步骤较多，成本较高，测试效率较低；人工对埋点数据进行对比验证，容易出错，漏测率较高。
' fill='%23FFFFFF'%3E%3Crect x='249' y='126' width='1' height='1'%3E%3C/rect%3E%3C/g%3E%3C/g%3E%3C/svg%3E)
手工抓包测试埋点缺点：
京东APP埋点加密，无法直接在抓包工具里查看
阻碍开发自测
大量埋点上报时，人工肉眼查看成本高，漏测率较高
手工记录结果，费时费力
当老埋点数据在应用程序升级过程中被修改出问题时，由于测试人员精力有限且主要集中在新埋点的测试中，导致老埋点数据问题遗留到线上环境
2、部分团队通过运行UI自动化用例触发埋点数据上报，并和埋点数据需求文档自动进行对比分析，减少了繁琐的手工触发和肉眼对比的操作，从而降低了成本。
UI自动化测试埋点缺点：
应用程序迭代较快，UI控件布局变化频繁，导致UI自动化用例稳定性差、失败率高，维护成本高
学习编写UI自动化用例门槛较高，不利于广泛推广使用
1、为了方便测试人员、开发人员、产品人员高效快速的测试验收埋点，我们自主研发了track埋点测试平台。结构图如下：
其中几个关键点：
代理支持：通过对Fiddler开发自定义插件、Whistle进行二次开发，track平台能够无缝衔接抓包工具（Fiddler、Whistle等），实现了无侵入的收集应用程序的埋点数据，减少了获取埋点数据的步骤，节约了测试时间；
APP扫码上报埋点：无需连接代理，APP扫描二维码便可上报埋点到track平台，且能够实时查看埋点数据。解决了产品人员、开发人员等因没有安装代理环境或不会使用代理工具等因素，而无法验收、自测埋点的问题；
漏报性检测：检测埋点是否漏报；
规则自动对比：根据埋点数据的需求文档生成动态的规则库，自动对应用程序上报的埋点数据进行实时、快速的一致性检测，降低了验证埋点的成本，提高了埋点测试的准确性；
历史埋点数据：进行持久化存储，方便追溯历史数据；
埋点方案规范性检测：活动上报的埋点数据必须满足一定的规范，才能保证埋点提数的正确性，以及活动运营数据评估的准确性。在埋点测试之前，对埋点方案进行规范化检查，能够尽早揭露问题，实现了测试左移；
特点：
无痕获取埋点数据
自动和埋点方案对比测试，失败时高亮提示
记录埋点测试过程数据、一键生成报告
丰富多样的规则库，能灵活配置，维护成本低
图表功能直观展示，可查看实时、历史埋点数据
2、track平台埋点测试流程如下图所示，抓包工具（Fiddler、Whistle等）包含一个自定义插件，当测试人员使用APP扫码或者连接抓包工具并触发应用程序时，会无感知的收集埋点数据并上报到服务器。服务器包含一个动态规则库：通用规则和自定义规则，根据动态规则库自动检测埋点数据是否正确，并生成测试报告。
基于track平台的埋点测试的详细流程如下描述：
（1）抓包工具（Fiddler、Whistle等）安装自定义插件，无感知的获取应用程序的埋点数据。自定义插件的具体实现方法如下：1）监听抓包工具传输的所有网络数据包的域名（HostName）；2）当网络数据包的域名（HostName）和应用程序的埋点上报的域名一致时，拷贝网络数据包的请求内容（RequestBody），并发送到服务器；
自定义插件只需开发实现一份，可重复利用，测试人员不需要进行额外的操作，学习成本低，有利于推广使用；自定义插件自动监听埋点数据并发送到服务器，不需要对被测应用进行二次改造，达到了无侵入、无感知的收集埋点数据的目的。
（2）如图所示，服务器收到埋点数据后，根据动态规则库对埋点数据进行自动检测，并生成测试报告。动态规则库包括通用规则和自定义规则。
通用规则的实现方法具体如下：需求文档中埋点数据的固有属性抽象成通用规则，例如：埋点数据的类型（点击、PV、曝光）；埋点数据的字段是否为空；埋点数据字段的拼接个数等。因通用规则具有普遍性，适用性广，所以只需生成一份，可重复使用，实现成本比较低。
自定义规则的实现方法具体如下：需求文档中的埋点数据，因触发应用程序的场景不同，导致实际上报的埋点数据存在差异性时，需对埋点数据的字段采用正则表达式生成自定义规则。因自定义规则是针对某个具体埋点数据实现的，满足了个性化的需求。
当埋点数据量比较庞大时，优先生成并使用通用规则，只有埋点数据的格式存在不确定性时，才利用正则表达式生成自定义规则。所以该动态规则库既节约了成本，同时具有灵活性、多样性的特点。
3、track平台埋点测试功能使用场景如下图：
功能测试期间：当用户（测试、开发、产品）触发业务模块功能时，会实时推送埋点数据到track平台，且实时地、自动地进行规则检查；track平台会提取埋点的关键字进行单独显示，能快速方便的找到埋点测试的要点，节约时间成本。
回归测试期间：采用通用规则和自定义规则，定时自动地对一级模块的核心埋点进行回归检测，防止因合并代码或模块功能的改动影响到核心埋点的正确性。回归测试检测报告部分内容如下图。
测试成本对比：
以单个埋点为例，埋点测试节约时间成本如下：
以单个埋点为例，查看历史版本节约时间成本如下：
埋点测试track平台通过自定义插件、扫码等方式，无感知、无侵入的收集应用程序的埋点数据。且能够根据动态规则库自动检测出异常的埋点数据，节约人力时间成本，提高了埋点测试的准确性。
track平台在若干个月内，便可收集千万条数据。通过对埋点数据提取特征值，并对大量的已被测试标注为是否正确的埋点数据进行训练分析，建立模型，定义一个清晰的决策边界，从而找出与正常埋点数据集差异较大的离群点，智能化分析出异常埋点数据。
