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中，然后进行校验

图3

图4

PS：dict是无序的，因此上面图中dict4故意先把key2放前面，但dict3和dict4还是相等的。

2）把多余的字段从预期结果、实际结果中移除，然后对比剩下的值

图5

这里我们先通过Copy Dictionary复制一下dict1、2，不去动原dict，然后移除dict3、4中的id、createtime，然后做对比，看一下结果

图6

上面展示了数据一致的情况，我们改一下数据，看一下数据不同时，脚本的提示，先改掉预期结果中key2对应的value

图7

执行结果如下图，可以看到问题定位很清晰

图8

2、结果只有一张表，多条数据，容易排序

数据格式：因为返回的是dicts_list的格式，因为是可以排序的，所以预期、实际结果的数据顺序可以一致，假设都为[dict1,dict2……]

先仿照下结果：

图9

图10

其中dict部分同单条数据，也是要校验其中录入的数据部分。

分别处理预期、实际结果中的dict，处理思路同单条数据，这里只拿一种来说明

图11

结果如下

图12

断言，因为是list，所以可以用Lists Should Be Equal

图13

数据一致，case执行通过

图14

我们也一样改一下数据，看下遇到不一致时的提示，先给实际结果加一条数据，即实际数据比预期数据多一条

图15

结果如下图，提示还是比较清楚

图16

再试下一样的条数，但是其中数据不一致的情况，如下图，把dict实际_2的key2的值改成了test3

图17

执行结果如下图，发现提示了错误，但是提示定位不够清晰，可以想象，如果字段数到了10几，20几，就很难找到哪里错了。如果可以像1中，提示具体是哪个字段错就比较好了。

图18

我们修改下判断，先分别获取两个list的长度，判断长度是否一致，然后在for循环遍历list，对dict进行判断

图19

结果如下图，发现成功定位了哪个字段不同，但是又有个问题，看不出来是哪条数据的这个字段不等

图20

在断言前面，加个index的log看下

图21

结果如下，定位比较清晰了

图22

3、结果只有一张表，多条数据，数据乱序，难排序，但是可以获取到他们id间的关联关系

先构造下场景，如下图，预期_1的数据对应实际_2，预期_2的数据对应实际_1，他们之间通过id关联

图23

1）依然考虑排序

因为list是有序的，因此用2中的方法，执行后报如下错

图24

我们做下调整（下面实现方法比较笨，如果有好的方法，请大佬们指教）

先把预期、实际结果改成{id1:dict1,id2:dict2……}格式的dict

图25

结果如下图

图26

然后根据预期、实际结果的关联关系，即${dict_预期_实际_关联}，对数据做下排序

图27

排序后则判断方式同2，结果如下

图28

2）不考虑排序

for循环遍历其中一个list，若值在另一个list中，则两个list都移除该值，则两个list留下的都是对方没有的值。

图29

两个list有值不等时，结果如下

图30

4、多表多数据，这里就不细分不能排序的场景了，同3，当做全部都是正常排序

1）第一种方式：分别对各张表对比，则同1、2、3

2）第二种方式：把所有数据组成复杂json，一起判断（多层json嵌套，递归的方式详细判断完整json，该方式也适合接口返回的json串全量判断），考虑内容有点多，再分一篇写。

上一篇　　8、大型项目的接口自动化实践记录----DB分别获取预期结果、实际结果

下一篇　　9-2、大型项目的接口自动化实践记录----递归判断两个json串是否相等