“什么情况？我没看错吧？查询也能失败？”例行检查夜间自动化批跑结果时，突然看到一个意想不到的失败记录，我放下了端到嘴边的水杯，一脸懵逼。
“怎么了？出什么问题了吗？”坐我旁边工位的小伙子转了下椅子，伸了下头瞄了下我的电脑屏幕。
“没事，看到了个比较奇怪的记录。”说它奇怪，是因为失败的这条用例在我看来不应该失败，至少不应该是在现在版本已经稳定没什么代码改动的情况下突然失败。
小伙子也看到了我打开的这条失败记录，“哦，我之前也看到过这个，单独执行这条用例的时候没有失败过，我反复执行很多次都成功了，所以没怎么在意。”
但直觉告诉我，这里肯定有问题！
首先，夜间批跑的测试套中有几千条用例，失败的用例只有十几条，成功率已达到99%，基本可以断定非环境问题，不然成功率不可能这么高。
其次，这是一条查询接口的用例，根据接口传的订单号查询交易订单和这笔交易关联的支付订单信息。构造数据和调用接口的脚本不复杂，脚本的稳定性不存在问题。
再次，小伙子也说之前也看到过这条用例失败，那说明失败的概率不低；
偶现问题？
哈哈，这可少见！我的兴趣瞬间上来了。
我开始看这条失败记录的详细情况，发现了更有意思的事！
在这条用例的失败记录中，日志显示接口调用是成功的，但是接口响应的检查点检查失败。当前这笔交易订单是关联有两笔支付订单的，但是接口只返回了一笔支付订单。
接下来我根据接口传的订单号直接查了下数据库，发现数据库中的数据没有问题，直接写sql确实能关联查询出两条支付订单；
测试脚本没问题，数据也没问题，有意思！我离揪出这个BUG越来越近了！
快速进入服务器后台，找到夜间这条失败记录的接口日志以及DEBUG级别的运行日志。终于让我发现了一点端倪！接口日志无报错，唯一的异常就是本该返回两笔支付订单接口只返回了一笔支付订单；DEBUG日志也没有报错，但是在执行的sql中查询支付订单表的时候只传了一个支付订单号！
我同时查了下这条用例执行成功时候的debug日志，发现每次sql上都是传两个支付订单号。
问题应该就出现在这里了！
但奇怪的是为什么会出现有时候传两个订单号有时候传一个订单号的情况呢？
看日志是得不到更多的信息了，我试着再去看看这条用例的所有执行记录，发现这个用例执行了上千次，失败的情况只有几次。
等等！貌似发现规律了！
失败的几次执行时间有夜间0点多、早上9点多，而成功的全部都在上午10点至夜间12点之间！
跟时间有关系吗？
边思索边点了几次执行按钮，无一例外，这条用例每次都执行成功了。时间！时间！时间……知道了！订单号里的时间！
测试脚本是按照规范生成订单号的，而订单号中有一部分是取得订单创建时间。现在是上午十点多，时分秒的小时位是10，现在只需要验证下这个小时位改成09之类的就知道了。
在生成订单号的脚本里找到时间位置对应的片段，将获取当前时间改成固定值09开头的时间，重跑，果然失败了！改成00，还是失败！01，失败！
终于让我揪住了！
我再看了下另外一条用例，一笔交易订单至关联一笔支付订单的，发现没有失败记录，改了订单号中的时间也不影响结果。看来只有组合支付订单有这个问题！
“喂，，这个查询接口有个小BUG要跟你沟通下。在0-10点创建的组合支付单，查询的时候会少返回一笔支付单。”快速找到对应模块的开发，我迫不及待的要跟他沟通这个问题了。
“这不可能！这软件都运行这么久了，也没人说有啥问题啊？我今天还用过，也没问题。”还没说完，开发坚决不信。
哼哼，由不得你不信！
“来来来，我共享我的桌面给你看下。”我要开始表演了。
“首先，我们来看下数据，”我执行了sql，并展示了执行结果，“你看，数据库里现在是不是有一笔交易订单，并且关联了两笔支付订单？”
“嗯，数据没问题。”开发没意见。
“那我们来看接口响应，”我调了查询接口，“你看，接口响应中少了一笔支付订单。”
“嗯？”开发诧异了。
“另外我发现规律，订单号第位如果是0，并且一笔交易订单关联多笔支付订单的时候就会出现这个问题。简而言之，用户在0-10点创建的交易订单，如果还参加了营销活动进行组合支付的话就会出现这个问题。”
“这么奇怪？”开发也疑惑了。
“看看代码？”我提议道。
“好，共享我桌面吧！”开发同意了。“查询接口，找到了！看，这里进行订单号校验，然后根据订单号里的这几位计算分库，再根据订单号这几位判断查哪张表，接口传的是交易订单号，先拿这个订单查交易表，再查支付表……”
“等等，这一段是干啥的？”我们同时注意到了几行代码。
“哦，根据订单后第位判断订单是否是组合支付。这谁写的代码？这里不是时间的小时位吗？怎么能拿来判断是否组合支付？”开发抓狂了。
他开始翻找修改记录，发现这是一个离职的员工很久之前写的，而这段时间订单号规则发生了很大变化，在早期版本时，订单号第*位是用来标识支付单的笔数的，而新版订单号已经没有这个标志位了。
“我已经给你提单了哈，单号发你了，我一会儿让测试经理走单。”
“啥？好吧，我改！是提的提示单吧？”
“你猜！”
亲爱的测试同行，如果是你，这个问题单的严重程度你会设置什么级别呢？
这次BUG发现的时间其实比较晚了，离版本上限不到一周，不过在这个BUG分析定位的过程中也发现了测试活动中不少改进点。
一、自动化测试要尽可能参数化。数据不能写死，在这个案例当中如果订单号写死，那么这个问题被发现的概率为0；
二、参数值要尽可能分散。这条用例尽管已经参数化了，但是因为测试套夜间执行的时间设置在了晚上10点，这条用例大多数时候在0点之前已经执行完了，白天测试人员手工执行的时候也都是在10点左右开始，导致这个问题长时间没被发现；
三、偶现的问题大多数时候只是因为没有找到规律，耐心分析，实在不行找开发一起分析，你会发现大多数偶现的问题在满足条件后都是必现的。
网友评论