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

　　上一篇实现数据分离升级版--从DB获取数据，以及对应的请求实现，作为一个case，还缺少了预期结果与实际结果的获取及对比。因为前面的文章已经说过接口返回值的获取及对比，所以这篇不说这块了，这篇说一下DB存储部分的获取。    

　　上一篇有提过如何从服务器获取mysql二进制日志获取操作涉及到哪些DB变化。我们手工新增后，可以看到对应的数据库结果，其中主要分三块：①手工输入的内容；②数据库自己生成的内容，如自动生成的递增id；③被测代码生成的内容，如uuid、版本信息。其中①的部分是我们主要要校验的，②、③用于关联①的内容。

　　上一篇中我们获得了接口请求要用的数据，预期结果获取同理，且不需要对数据再做处理。

　　下面对不同的场景说明下怎么获取实际结果。

　　PS：如果可以，还是尽可能早的与开发沟通做好，这样自动化测试、性能测试等都相对容易开展

　　1、结果只有一张表，只有一条数据，且接口有返回id

　　在前面3开放API练习中有说过怎么取接口返回值中指定key的value，假设我们已经通过该方式取到了id，则通过id就可以取到实际结果，如下图

　　　　　　　　　　　　　　　　　　　　　　　　　　　　图1

　　2、结果只有一张表，只有一条数据，但是接口未返回id，id是数据库自增的

　　1）接口请求后，查询最大id，获取对应data

　　　　　　　　　　　　　　　　　　　　　　　　　　　　图2

　　2）通过数据特性（如某个字段值唯一、多个字段关联值唯一、create time），查询id，获取对应data，下图为xxkey字段唯一

　　　　　　　　　　　　　　　　　　　　　　　　　　图3

　　3、结果只有一张表，只有一条数据，但是接口未返回id，id为uuid

　　uuid组成：当前日期和时间+时钟序列+全局唯一的IEEE机器识别号

　　因为uuid的特性，所以max（id）的方式不适用，只能通过数据特性来查询。

　　4、结果只有一张表，有多条数据（一般是主单下的明细），id为数据库自增的

　　PS：因为id为数据库自增的，所以查询结果数据的顺序与新增的顺序一致

　　　　　　　　　　　　　　　　　　　　　　　　　　图4

　　5、结果只有一张表，有多条数据，id为uuid，接口有返回ids

　　PS：因为是uuid，所以若用4中的方法，查询结果数据的顺序不一定与新增顺序一致（因为新增的数据取自预期结果的数据，因此顺序与预期结果一致，所以就导致实际结果！=预期结果）

　　　　　　　　　　　　　　　　　　　　　　　　　　图5

　　6、结果只有一张表，有多条数据，id为uuid，接口未返回ids

　　　　1）一般情况下，这种新增明细，新增完前端会自动请求另外一个接口，查询明细列表，前端显示为列示明细信息，接口返回值为xml，如下图

　　　　　　　　　　　　　　　　　　　　　　　　　　图6

　　先import XML

　　　　　　　　　　　　　　　　　　　　　　　　　　图7--import库XML

　　可以在执行完新增明细接口后，执行查询明细列表的接口，获取对应的ids，该顺序会与新增的顺序一致，后面查询数据与5的情况一致

　　　　　　　　　　　　　　　　　　　　　　　　　　图8

　　2）根据数据特性分别查询明细id，而后查询结果data，2与5结合

　　7、结果涉及多张表，都只有一条数据，如下图，B、C表通过A_id与A关联

　　　　　　　　　　　　　　　　　　　　图9

　　分别通过A_id查询A、B、C，赋值给dict${result_dicts_list_dict}，返回

　　　　　　　　　　　　　　　　　　　　　　　　　　图10

　　8、结果涉及多张表，关联表中有的数据有多条，如下图B

　　PS：数据量比较大，一般只会返回主表id，即下图中的A_id

　　　　　　　　　　　　　　图11

　　若B_id为数据库自增，则同7

　　若B_id为uuid，则7+6

上一篇　　7、大型项目的接口自动化实践记录----数据分离升级版

下一篇　　9-1、大型项目的接口自动化实践记录----数据库结果、JSON对比