大数据测试常见缺陷

1. 数据更新不及时

上游任务每小时调度，ads每天只调度一次，导致指标更新不及时。

2. 数据范围限制错误

昨日新增没有限制首单日期是昨日，本月新增没有限制首单日期是本月，导致输出指标结果偏大。

3. 数据重复、指标膨胀

一般是join导致的，测试的时候需要关注join左右的字段是否唯一。

4. 指标口径不准确

合作方今日待办，(活动)7日内将到期商品数，没有按需求限制状态为【审核通过】。导致结果偏大。

多关联或者少关联了一些表也会导致数据范围不正确。

过程数据总数接口-按员工和按部门查的时候口径不一致，导致员工创建的达人不等于部门创建的达人之和。

5. 函数使用不当

count（case when 条件满足 then order_Id else 0）：此处的else 0导致结果偏大1，应该用else null。

rank() row_number() dense_rank()

udf函数需要做根据函数编写逻辑 对不同入参做场景覆盖

6. 分区入参不对

部分指标计算的时候应该取哪个分区有讲究

近实时的数据关联离线表取值的时候入参没有往前推一天，导致离线表的信息没有取到

7. id过大用bigint存不下导致的失真

2表join的时候关联字段数据类型不一致（string bigint），导致部分合作方指标计算错误

8. 作业依赖关系不当

任务调度时间和依赖关系问题导致 待交作业数、作业完成率 没有正确写入mysql。

9. 精度丢失

销售数据-精度丢失导致服务费为0.001的订单绿色gmv算成了0，4996543044102920039。

10. 临界值问题

0906分区的数据，8月30号有过动销行为，算不算近7天有过动销行为的用户？

现有代码是算进去了，我觉得不应该算

11. 标签定义优先级问题

用户既同时满足“核心”和“引入”的定义，应该标记为核心用户而不是引入用户。

12. 兜底逻辑缺失

实际工作往往会遇到一些意料之外的脏数据，所以在做数据清洗、指标计算的时候要有兜底逻辑。

ck一般不允许存null 值

13. 表结构定义不当

维度过细、维度缺失、指标漏统计

14. 业务逻辑理解不透彻导致的缺陷。

计算一小时内司机的在线时长，（在线时长=下线时间-开始服务时间），某一个小时内的没有开始服务时间，时计算错误。

审核通过时间没有取首次认证审核通过时间。

没有成单记录的用户错误的算成了成单新用户

redis数据存储排行榜信息的时候缺少落榜删除逻辑

司机变更加盟商导致a加盟商的在线时长算在了b加盟商下

2人同时扫码支付一个订单时订单收入流水表多算了一笔