按查询数据库方式不同设计接口测试方案

Posted 2021-04-24 自动化测试笔记

概述

最近梳理了一下不同功能的接口测试方法，概括来说，按对数据库的查询方式可以分为以下四类：复杂查询类的接口、简单查询类的接口、复杂提交类的接口、简单提交类的接口，前两种主要是get类型接口，后两种主要是post类型接口。

1

复杂查询类的接口

描述

通过传入简单的参数查询出一个复杂的数据结构，接口读取的数据库中的表结构复杂，通常依赖3张表以上，且表中的数据来源使用业务链条过长，不能通过简单的sql制造，例如：查询某城市某状态的经销商，查询某城市下某车系的最低报价，经销商数据的构造和车型车系的数据由于是从上游业务产生，自行通过sql构造比较复杂和数据失真。此类接口的实现方式一般代码逻辑简单，但是会有很复杂的连接查询sql语句

测试方法

该接口的测试方案首先要审查开发写出的sql语句，并且通过更改数据库中现有的数据，或者手工操作业务系统新增测试数据进行测试，sql语句无误后，将该sql添加到自动化测试用例。并且将测试数据通过程序维护起来（保证数据库中有sql条件语句中过滤掉和未过滤掉的数据，如果测试数据被修改可以使用脚本程序进行改正，或者抛出异常提示等待人工进行维护）

断言

以返回结果中的最小字典或列表单元为实际结果，通过审查无误的sql语句生成预期结果，进行全量比对断言。

2

简单查询类的接口

描述

此类接口和“复杂查询类”接口的区别就是接口读取的数据库中的表数量少，表中的数据来源使用的业务链条非常短，可以通过sql语句直接制造

测试方法

针对该接口依赖的表创建数据库模型，通过数据驱动（dbdriven）方法驱动数据模型制造测试数据。

断言

第一条case要对接口的返回结果（json）进行全量断言，其余case无需全量断言，只断言关键字段

3

复杂提交类的接口

描述

该类接口通过传入一个复杂的数据结构（一般是json），接口会使用该数据结构中的某些字段通过查询其他数据明细后再写到若干个表，例如下单接口，创建活动接口。

测试方法

参考“复杂查询类”接口制造该接口所依赖的测试数据，以传入参数的数据结构中的最小字典创建接口参数模型，在参数模型类中可以添加针对该模型对象的fake方法，fake方法最好配对创建，其中一个方法来fake接口模型的各字段的值，另一个方法fake接口模型提交到数据库的数据库对象。在用例文件中的setUp或suitSetUp中生成参数模型的对象，在测试用例中使用setUp中的参数对象组装成传入的数据结构。

断言

第一条case要对数据库中的字段做全量断言，其余case无需全量断言，只需断言数据库中的关键字段

4

简单提交类的接口

描述

参考前三类接口，在此不在赘述。

总结

通过对接口的逻辑行为进行分类，对于不同种类的接口使用不同的测试方案。测试方案应尽量简单，测试用例的实现应该尽可能的简单，不应该有复杂的逻辑判断分支、循环、嵌套调用。测试数据过于复杂时不需要自动化制造，使用人工通过业务系统创建即可，然后每次执行自动化测试时使用自动化程序检测该数据是否可用于本次自动化测试，如果检查到异常就应该报出case执行失败，由人介入维护。