埋点测试
- 开发完了以后、在测试工具上去做数据的验证，检查数据的完整性、准确性、及时性。
埋点测试内容
- 模块是否做了埋点处理
- 埋点是否被正常触发
- 埋点是否回传成功
- 触发时机是否正确
- 报送内容（埋点模块回传的参数）是否准确、完整
- 验收是否多报
- 验收是否少报
- 验收是否缺参数上报
- 验收上报参数是否符合预期
- 空日志
- 验收上报为空日志的比例
- 异常上报
- 验收上报不符合预期日志的比例
- 数据落表是否准确、完整
测试中常见的问题
- 是否使用了最新版本的 SDK（有些功能所需数据只有新版本SDK才会上报）
- AppKey 是否填写正确
- 上报地址是否配置正确，尤其是小程序数据的上报
- 数据是否能正常发送
- 是否选择了合适的 SDK，比如有些事件更适合在服务端上报
- 是否覆盖了所有涉及到的页面
- 是否覆盖了位于不同页面的相同事件
- 是否因为页面跳转导致有些事件不能完全上报
埋点测试关注点
- 埋点测试的过程有两个比较重要的环节，埋点上报和埋点落库。
- 埋点上报：
- 无论是前端埋点还是后端埋点，是否正常按照相关规则进行上报，相关的事件名、属性值都是否完整正确上报。
- 埋点落库：
- 埋点上报完的数据，需要存储到数据库当中，再进行相关的数据统计、分析、归类等等，除了检查埋点上报，还要看最终数据是否正常落库，相关数据字段是否正常。
测试流程
测试方法
埋点校验方式
- 前端校验
- debugger 断点
- 后端校验
- 数据库验证
测试时间点
- 开发中测试
- 上线前测试
- 上线后测试
测试方法
- 手工测试
- 自动化测试
手工测试
手工测试方法
- 最原始的就是去做人肉的 review，在开发工位旁边去看一下这个代码，开发触发、测试看数据。
- 另外有 Kibana 之类的查询工具，可以协助快速的做埋点日志的查询，提供简单的可视化展示。
手工抓包测试缺点
- 如果 APP 埋点加密，无法直接在抓包工具里查看；
- 阻碍开发人员自测；
- 大量埋点上报时，人工肉眼查看成本高，漏测率较高；
- 手工记录结果，费时费力；
- 老埋点数据问题遗留
- 当老埋点数据在应用程序升级过程中被修改出问题时，由于测试人员精力有限且主要集中在新埋点的测试中，导致老埋点数据问题遗留到线上环境；
测试工具
- fiddler
- Android Studio
- Charles
自动化测试
自动化测试方法
- 用户应用层框架
- 移动端 Appium，web 端 selenium，主要是模拟用户正常的业务操作；
- 数据 mock & 上报数据收集
- 通过构造测试数据给到用户应用层使用，并且通过代理抓包收集上报数据，进行上报数据校验（jsonschema 校验）；
- 服务端上报及落库查询
- 通过链接数据数据库或使用相关 API，查询测试上报数据是否落库；
- Jenkins CI/CD
- 结合 Jenkins 进行持续集成，每天或每次发版前对所有埋点进行回归测试。
UI自动化测试埋点缺点：
- 应用程序迭代较快，UI控件布局变化频繁，导致UI自动化用例稳定性差、失败率高，维护成本高；
- 学习编写UI自动化用例门槛较高，不利于广泛推广使用；
