9-1、大型项目的接口自动化实践记录----数据库结果、JSON对比
上一篇写了如何从DB获取预期、实际结果,这一篇分别对不同情况说下怎么进行对比。
PS:这部分在JSON对比中也适用。
1、结果只有一张表,只有一条数据
数据格式:因为返回的是dicts_list的格式,因此一条数据时,格式为[dict],可以通过list[0]的方式取到dict,也可以for循环遍历list取dict。
预期结果:id_预期 + 录入的数据 + 代码自动生成的:如createtime
实际结果:id_实际 + 录入的数据 + 代码自动生成的:如createtime
很显然,录入的数据部分是要校验的内容,那么在实现上可以有两种思路:
PS:下面dict1、dict2假设为取到的预期、实际结果
1)新建两个dict,要校验哪些字段,分别从预期结果、实际结果中取那些字段,分别塞入两个dict中,然后进行校验
PS:dict是无序的,因此上面图中dict4故意先把key2放前面,但dict3和dict4还是相等的。
2)把多余的字段从预期结果、实际结果中移除,然后对比剩下的值
这里我们先通过Copy Dictionary复制一下dict1、2,不去动原dict,然后移除dict3、4中的id、createtime,然后做对比,看一下结果
上面展示了数据一致的情况,我们改一下数据,看一下数据不同时,脚本的提示,先改掉预期结果中key2对应的value
执行结果如下图,可以看到问题定位很清晰
2、结果只有一张表,多条数据,容易排序
数据格式:因为返回的是dicts_list的格式,因为是可以排序的,所以预期、实际结果的数据顺序可以一致,假设都为[dict1,dict2……]
先仿照下结果:
其中dict部分同单条数据,也是要校验其中录入的数据部分。
分别处理预期、实际结果中的dict,处理思路同单条数据,这里只拿一种来说明
结果如下
断言,因为是list,所以可以用Lists Should Be Equal
数据一致,case执行通过
我们也一样改一下数据,看下遇到不一致时的提示,先给实际结果加一条数据,即实际数据比预期数据多一条
结果如下图,提示还是比较清楚
再试下一样的条数,但是其中数据不一致的情况,如下图,把dict实际_2的key2的值改成了test3
执行结果如下图,发现提示了错误,但是提示定位不够清晰,可以想象,如果字段数到了10几,20几,就很难找到哪里错了。如果可以像1中,提示具体是哪个字段错就比较好了。
我们修改下判断,先分别获取两个list的长度,判断长度是否一致,然后在for循环遍历list,对dict进行判断
结果如下图,发现成功定位了哪个字段不同,但是又有个问题,看不出来是哪条数据的这个字段不等
在断言前面,加个index的log看下
结果如下,定位比较清晰了
3、结果只有一张表,多条数据,数据乱序,难排序,但是可以获取到他们id间的关联关系
先构造下场景,如下图,预期_1的数据对应实际_2,预期_2的数据对应实际_1,他们之间通过id关联
1)依然考虑排序
因为list是有序的,因此用2中的方法,执行后报如下错
我们做下调整(下面实现方法比较笨,如果有好的方法,请大佬们指教)
先把预期、实际结果改成{id1:dict1,id2:dict2……}格式的dict
结果如下图
然后根据预期、实际结果的关联关系,即${dict_预期_实际_关联},对数据做下排序
排序后则判断方式同2,结果如下
2)不考虑排序
for循环遍历其中一个list,若值在另一个list中,则两个list都移除该值,则两个list留下的都是对方没有的值。
两个list有值不等时,结果如下
4、多表多数据,这里就不细分不能排序的场景了,同3,当做全部都是正常排序
1)第一种方式:分别对各张表对比,则同1、2、3
2)第二种方式:把所有数据组成复杂json,一起判断(多层json嵌套,递归的方式详细判断完整json,该方式也适合接口返回的json串全量判断),考虑内容有点多,再分一篇写。
作者:慢慢走的测试
出处:https://www.cnblogs.com/walkingtester/
交流群:636090586(备注博客园)
本文版权归作者和博客园共有,欢迎转载,但未经作者同意必须保留此段声明,且在文章页面明显位置给出原文连接,否则保留追究法律责任的权利。
如果喜欢我的文章,请关注我的公众号