51Testing软件测试论坛

标题: 我在数据库数字比较上栽了一个坑 [打印本页]

作者: lsekfe    时间: 2021-4-26 15:13
标题: 我在数据库数字比较上栽了一个坑
说起这个数字比较,这是我这几年测试生涯中踩的第一个坑,至今印象深刻,使得从那以后在遇到数字比较的测试,我都会特别关注这个点,记得那还是第一次接触数据库数字比较的测试,按照设计测试用例的惯例,进行了用例设计。
记得当时这个需求的背景是这样的:
业务要求做一个这样的功能:
根据版本号,比较产品中的两个参数的大小,暂时我们就给它叫做参数1和参数2吧,当版本号满足大于给定的版本号‘32’时,比较参数1和参数2的大小,当参数1大于等于参数2时,就把这个产品的相关信息发送邮件给相关的业务人员,给出警示,大致功能流程图如下:
[attach]132554[/attach]
开发实现的方案是:版本号由前台数值传到后台接收,然后代码直接进行比较,参数1和参数2,分别对应数据库表1中的字段1和字段3,当版本号大于32时,就直接从数据库表1中取字段1和字段3的值,进行比较,值取不到的为空不做比较,不发送邮件。
根据业务需求和开发实现方案,测试用例分析设计如下:
根据边界值及实际业务场景值及后台实现方案分析:
1. 版本的取值只是整数,不会有负数,所以取值只有四种情况,大于32的版本号,小于32的版本号,等于32的版本号,版本号为空,由前台传值,只要能接收到就可以,其他有效性问题由前台保证。
2. 参数1和参数2的取值,只是正整数,没有字母和特殊字符,不存在字段值为空的场景,所以在符合条件的情况下就比较参数1和参数2的数值大小即可,那么这样的场景也有四种情况:
1)参数1大于参数2,发送邮件通知到相关人员。
2)参数1等于参数2,发送邮件通知到相关人员。
3)参数1小于参数2,不发送邮件通知到相关人员。
4)历史数据原因导致参数1或参数2丢失的场景。
根据以上两个条件的分析,组合出以下测试场景:
[attach]132555[/attach]

根据组合出的场景输出测试用例,执行测试,把所有的场景完整的覆盖了三次,心想这么简单的一个数字比较应该不会出现问题了吧,然而往往事与愿违,这个功能刚上线不久,业务就跑来找我说这个功能实现的有点问题,应该发邮件的没有发邮件,当时我听到这个消息都懵了,我都反复验证了三次所有的场景,哪里出问题了?
  带着迷惑和不解,请业务小哥把它出问题的那单数据发了过来再次进行了测试,果然是
不发送邮件,然后我就根据两个条件结合日志逐一查找原因,因为日志比较少,最后还连了代码进行了打断点测试,终于找到原因,原来是参数1和参数2的值比较结果不对,参数1取到的值为12,参数2取到的值为9,按道理,这样比较出来的结果应该是参数1大于参数2,需要发送邮件的。
  然而通过打断点跟踪代码发现,参数1与参数2的比较结果是参数1小于参数2,直接跳过发邮件环节。
问题点找到了,但为何会这样就不能理解了,剩下的就交给开发小哥哥分析原因修改了。
开发小哥哥经过一翻分析最后得出的结论是程序没有对数字做处理,oracle数据库返回给程序代码的值是当前数值的ASCII值,现在的参数1和参数2分别为1299ASCII值比12的大,所以返回的结果是参数1和参数2,听到这个结论,我赶紧去查一下数据库存储数值的ASCII,果然是912大。
[attach]132556[/attach]
然后通过反复的查询还发现,这样直接返回的ASCII值,多位数的时候返回的都是前面一位数的ASCII值,也就是说如果两个数值最高位相同,相同高位,不同个位数的,两个数值,返回的ASCII是同一个!
[attach]132557[/attach]
如果不做处理直接拿来比较就得到的结果可能就不是我们想要的,看到这里我禁不住为自己默默的抹了一汗。
   等开发小哥哥修复以后,我专门找了这样的数据来验证,果然问题解决了,
   经过这一次深刻的经验教训后,在测试类似种数字的比较,特别是从数据库取值的,我都会特别设计一条这样特殊的测试用例:
   “构造两个参于比较的数字ABA为一位数,B为两位数,且B的十位数小于A,或构造两个相同位数的多位数AB,且AB的高位相同,个位数不同,执行比较,查看比较结果是否正确。”
    那么这个问题是否在所有的数据库返回值中都存在呢,带着这个疑问,我在接下来的测试工作中关注了另一个数据库,也就是一个用了PG数据库的项目,在此项目测试类似数字比较中复现了问题,那么别的数据库是否有这个问题,还有待验证,期待你的参与。





作者: Miss_love    时间: 2021-4-28 08:50
收藏




欢迎光临 51Testing软件测试论坛 (http://bbs.51testing.com/) Powered by Discuz! X3.2