我在数据库数字比较上栽了一个坑

lsekfe

说起这个数字比较，这是我这几年测试生涯中踩的第一个坑，至今印象深刻，使得从那以后在遇到数字比较的测试，我都会特别关注这个点，记得那还是第一次接触数据库数字比较的测试，按照设计测试用例的惯例，进行了用例设计。

记得当时这个需求的背景是这样的：

业务要求做一个这样的功能：

根据版本号，比较产品中的两个参数的大小，暂时我们就给它叫做参数1和参数2吧，当版本号满足大于给定的版本号‘32’时，比较参数1和参数2的大小，当参数1大于等于参数2时，就把这个产品的相关信息发送邮件给相关的业务人员，给出警示，大致功能流程图如下：

开发实现的方案是：版本号由前台数值传到后台接收，然后代码直接进行比较，参数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丢失的场景。

根据以上两个条件的分析，组合出以下测试场景：

根据组合出的场景输出测试用例，执行测试，把所有的场景完整的覆盖了三次，心想这么简单的一个数字比较应该不会出现问题了吧，然而往往事与愿违，这个功能刚上线不久，业务就跑来找我说这个功能实现的有点问题，应该发邮件的没有发邮件，当时我听到这个消息都懵了，我都反复验证了三次所有的场景，哪里出问题了？

  带着迷惑和不解，请业务小哥把它出问题的那单数据发了过来再次进行了测试，果然是

不发送邮件，然后我就根据两个条件结合日志逐一查找原因，因为日志比较少，最后还连了代码进行了打断点测试，终于找到原因，原来是参数1和参数2的值比较结果不对，参数1取到的值为12，参数2取到的值为9，按道理，这样比较出来的结果应该是参数1大于参数2，需要发送邮件的。

  然而通过打断点跟踪代码发现，参数1与参数2的比较结果是参数1小于参数2，直接跳过发邮件环节。

问题点找到了，但为何会这样就不能理解了，剩下的就交给开发小哥哥分析原因修改了。

开发小哥哥经过一翻分析最后得出的结论是程序没有对数字做处理，oracle数据库返回给程序代码的值是当前数值的ASCII值，现在的参数1和参数2分别为12和9，9的ASCII值比12的大，所以返回的结果是参数1和参数2，听到这个结论，我赶紧去查一下数据库存储数值的ASCII，果然是9比12大。

然后通过反复的查询还发现，这样直接返回的ASCII值，多位数的时候返回的都是前面一位数的ASCII值，也就是说如果两个数值最高位相同，相同高位，不同个位数的，两个数值，返回的ASCII是同一个!

如果不做处理直接拿来比较就得到的结果可能就不是我们想要的，看到这里我禁不住为自己默默的抹了一汗。

   等开发小哥哥修复以后，我专门找了这样的数据来验证，果然问题解决了，

   经过这一次深刻的经验教训后，在测试类似种数字的比较，特别是从数据库取值的，我都会特别设计一条这样特殊的测试用例:

   “构造两个参于比较的数字A，B，A为一位数，B为两位数，且B的十位数小于A，或构造两个相同位数的多位数A，B，且A，B的高位相同，个位数不同，执行比较，查看比较结果是否正确。”

    那么这个问题是否在所有的数据库返回值中都存在呢，带着这个疑问，我在接下来的测试工作中关注了另一个数据库，也就是一个用了PG数据库的项目，在此项目测试类似数字比较中复现了问题，那么别的数据库是否有这个问题，还有待验证，期待你的参与。

Miss_love

收藏