这个bug有多坑

   接到一个测试任务,乍听起来超级简单,触发三个事件,该事件数后台统计加一,然后这个数会存入mysql,哇!我基本觉得简直3分钟就能搞定!其实,我也确实是3分钟就宣布没啥问题,上线吧,亲!

  上线后,开发给我说,让我验证一下,本来我都懒得验了,但是本着负责的态度,还是验了,早上造了些数据,测着没问题,午饭后,打算把数据库关掉了,结果!就在我要关掉mysql的时候,发现早上的测试数据没有了,全变0了!我的天!难道是我眼花了吗?什么情况!?于是我又造了一些数据,然后发现数据统计和入库均没有问题,一脸蒙B的我,左右抓狂了都!就在分析不出问题的时候,不小心刷新了一下数据表,结果,下午入库的数据也变成0了,这个时候,我心里大概有了点普,难道这是程序设置了什么时间吗?然后我把这个问题反馈给了开发,开发查了一下,说,确实有问题,一个应该被注释掉的代码没被注释掉,结果每20分钟都会去按时间戳抓取数据,而新增的字段的时间戳在有老的其他字段的数据过来时,没有同步更新,所以每20分钟就会被清0,虽然这个问题最终解决了,我很开心,但是也不禁冒一身冷汗啊!这种bug,你让人怎么说呢,辛亏是20分钟,要是小时级别的,那这个问题就太难被发现了,测试真是高危行业啊!这种隐坑,你们遇到过吗?

描述   在 LIT 综教楼后有一个深,关于这个的来历,有很多种不同的说法。其中一种说法是,在很多年以前,这个就已经在那里了。这种说法也被大多数人认可,这是因为该有一种特别的结构,想要人工建造是有相当困难的。   从横截面图来看,底成阶梯状,由从左至右的 1..N 个的平面构成(其中 1 ≤ N ≤ 100,000),如图:    *            * :    *            * :    *            * 8    *    **      * 7    *    **      * 6    *    **      * 5    *    ********* 4 <- 高度    *    ********* 3    ************** 2    ************** 1 平面 |  1  |2|   3    | 每个平面 i 可以用两个数字来描述,即它的宽度 Wi 和高度 Hi,其中 1 ≤ Wi ≤ 1,000、1 ≤ Hi ≤ 1,000,000,而这个最特别的地方在于底每个平面的高度都是不同的。每到夏天,雨水会把填满,而在其它的季节,则需要通过人工灌水的方式把填满。灌水点设在底位置最低的那个平面,每分钟灌水量为一个单位(即高度和宽度均为 1)。随着水位的增长,水自然会向其它平面扩散,当水将某平面覆盖且水高达到一个单位时,就认为该平面被水覆盖了。   请你计算每个平面被水覆盖的时间。    灌水 水满后自动扩散 | | * | * * | * * * * V * * V * * * * * * .... * *~~~~~~~~~~~~* * ** * *~~~~** : * *~~~~**~~~~~~* * ** * *~~~~** : * *~~~~**~~~~~~* * ** * *~~~~**~~~~~~* *~~~~**~~~~~~* * ********* *~~~~********* *~~~~********* *~~~~********* *~~~~********* *~~~~********* ************** ************** ************** ************** ************** **************    4 分钟后    26 分钟后        50 分钟后    平面 1 被水覆盖     平面 3 被水覆盖    平面 2 被水覆盖输入   输入的第一行是一个整数 N,表示平面的数量。从第二行开始的 N 行上分别有两个整数,分别表示平面的宽度和高度。 输出   输出每个平面被水覆盖的时间。
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值