一个异常数据的追溯与数据测试的思索

本周没有什么太多要说的，就把我对一个异常数据追寻的过程写出来吧。

先说背景，我们要计算小时内支付宝笔单价的变化金额（字段名称是cnt_price_change），计算公式是cnt_price - before_act10_cnt_price，即用小时内的笔单价减去前10天内的平均笔单价。前10天内的笔单价是在另外一个张表中计算出来的。业务逻辑是该输出表（total）由日志表（browse）和交易表（trade）union后经过group by得来。

在trade表中cnt_price_change的计算公式为：sum(case when substr(gmt_receive_pay,0,13)='$cur_date $env.last_hour' then t2.total_fee end)/count(case when substr(gmt_receive_pay,0,13)='$cur_date $env.last_hour' then 1 end) - max(t1.before_act10_cnt_price) as cnt_price_change,即用小时内支付宝成交总额除以成交笔数得到笔单价再和前10天内的笔单价相减。

在browse表中cnt_price_change的设置为：‘’ as cnt_price_change,即把小时内的笔单价置空，后来经过macro的处理变成0（macro我们在下周的博客里面细说）

在total表中cnt_price_change的计算为：max(cnt_price_change) as cnt_price_change

以上就是几乎就是全部的源码逻辑，但是这儿有两个问题。第一，当小时内的笔单价变化金额为负数时（假设为-20），max(-20,0)=0，这样就把小时内笔单价变化金额为负数的的记录全部过滤掉了，显然这不符合pd的要求，第二，假如该小时内没有成交，那么sum()=null,count()=0,null/0还是null，null减去任何一个数仍旧是null，虽然这种情况在双十一的大活动不太多见，但是我们不排除存在的可能性，另外我用sql在线上去验证符合这种情况的记录有多少。

select count(1) from r_act_shops_total_hour where cast(cnt_price_change as int)=0 and pt='20111109200000';

708

select count(1) from r_act_shops_total_hour where pt='20111109200000';

2346

select count(1) from r_act_shops_total_hour where cast(cnt_price as int)=0 and pt='20111109200000';

559

select count(1) from r_act_shops_total_hour where cast(cnt_price as int)<>0 and cast(cnt_price_change as int)=0 and pt='20111109200000';

149

从数据上我们可以看出这种情况还是占有一定比例的，不容忽视。

这个bug给我们做功能测试的再次敲响警钟，一定要自己独立思考，不要跟着开发代码的思路走。但是事情上很多时候连pd都他自己的需求都不十分清楚，这时候我们只有通过开发的代码来了解业务逻辑，经过开发代码的先入为主后，一定要多想想其他情况，千万不要被他的代码把思维限制住了。这时候如果有前台数据将会对数据的验证起到很大的帮助，但是数据验证，数据测试我们都还在一个起步阶段，还有待开发，继续摸索。