典型问题总结

工作中遇到的问题总结:

1、对账数据上报成功之后没有在规定的时间内删除，导致流量暴增

场景：对账数据记录的是某两个小时之内的埋点上报的成功、失败、请求等的信息，本质也可理解为埋点数据

对账数据的上报机制：

将一天24小时分为12分，每分2小时，对账数据记录每两小时内埋点的上报情况。超过两小时会写对账埋点到数据库中。该埋点会跟随普通埋点的上报而上报到服务端，上报成功后被删除。

用例场景：

1、在当前时间段【两小时】内新增普通埋点【产生对账数据】，满足两小时小时之后，继续上报普通埋点数据，该两小时内产生的对账数据被成功上报，查看数据库，确认对账数据被成功删除

2、在当前时间段【两小时】内新增普通埋点【产生对账数据】，不满足两小时，继续上报普通埋点数据，该两小时内产生的对账数据的字段数会变化，不会上报服务端
依旧缓存在本地数据库

3、在当前时间段【两小时】内新增普通埋点【产生对账数据】，将时间调整到三小时之前，继续上报普通埋点，对账数据不会被上报，此时只有时间调整到当前时间段两小时后，才会
随普通埋点的上报而上报对账埋点

2、数据库加密之后，新旧数据未做兼容性测试，导致埋点上报失败

数据库结构发生变化【升级测试】

用例场景：新增埋点数据库加密的需求

问题：测试过程中没有做新老数据的兼容测试，导致读取旧数据时发生死循环，导致CPU占用过高，手机发热

测试方法：

1、在就旧版本的demo中新增埋点数据，不上报。

2、覆