接口测试 (六)接口自动化测试平台——接口测试数据库表设计(1)

李佳慧 · 2021年06月15日 · 最后由 李佳慧 回复于 2021年06月18日 · 1040 次阅读

接口表
主要保存了接口的主要信息,说明:
1:接口表支持保存 HTTP 接口,也支持保存 DUBBO 接口,通过 interface_category 区分
2:HTTP 接口的请求类型通过 request_type 区分,DUBBO 接口不使用该参数;
3:address 字段,当接口类型是 HTTP 接口的时候,支持完整的 http url 链接,也可以不是完整的 url 链接,默认添加测试环境的域名,当接口类型是 DUBBO 接口的时候,则是类名.方法名;
4:sign_type 指定了接口请求的时候的加密方式,跟不同的第三方对接,加密方式不一样,且请求完成之后,对响应内容进行解密,方便解密后用例断言。
5:图片上传相关接口需要将接口标识为图片类型,字段为 data_type,后台进行特殊处理,配合 upload_type 字段使用,有的图片上传是转了 base64 字符串上传给接口,有的是直接字段流上传的,这里需要区分;
6:接口下的用例执行汇总统计信息,本应该重新建一张表,当时偷懒了,只存上一次执行统计信息;
7:标识弃用的字段,是一开始设计,后来没有用上的字段;


HTTP 接口编辑页面

DUBBO 接口编辑页面

测试集合表
描述:
首先忽略这个名字,就理解为测试集合的概念就 OK 了,之所以以 services 命名,是一开始的时候想以服务的维度来做一张表,来管理接口和用例,目的是对接运维系统,做自动化,当服务发布的时候,先调用测试平台的服务接口测试,通过率达到多少则允许发布,未达到,则回滚至上一个版本。
该表最主要的几个字段是主键和名称。
用例在执行的时候,其实还会需要一些附加的信息,全部都放在一张表里面会不好维护,比如图片上传接口的图片内容,接口前后置执行的 sql,主要是这两个。

HTTP 接口用例

DUBBO 接口用例

用例表
用例表是很重要的一张表,关于这个用例的参数信息,测试场景信息,都保存在这个表中,可以简单理解为测试场景。
用例请求的时候,会从数据库去除用例的配置信息,结合接口配置,组装一个 HTTP|DUBBO 请求。


用例 SQL 表
跟用例相关的,一条记录对应一条 sql(其实可以优化,一条记录多条 SQL),每一条 SQL 执行目标数据库 ID,这条 SQL 是在用例执行之前操作还是用例执行之后操作,等等。


用例图片相关表
这张表占内存比较大,一般不会批量去查询这张表,速度会很慢,而是当请求之前,发现用例要用到某张图片的时候,再去把图片查询出来。图片是以 base64 编码之后以字符串的方式保存在数据库里面的,没有保存在服务器上,因为我们的后台服务是部署在容器里面,存取路径不好找,且容器销毁后文件就不存在了,其次,没有分配云服务器,所以选择存库。

图片接口

图片用例

共收到 11 条回复 时间 点赞

表字段太多的时候,尤其有 text、blob 这种类型,最好还是拆一下,分成基本信息和额外信息

槽神 回复

的确👍

大佬,缺小弟吗

我感觉很多平台都没有加入版本的概念,是不是可以加一下😂 😂 😂

Kevin.zhao 回复

我想问一下哈,加这个版本的概念,目的是什么呢?🌹

挺好的。就是感觉目前来说,很多平台操作还是太繁琐了,需要填的内容太多,很难维护,感觉平台的用处也不大,但是呢又必须得学这玩意儿

用带 json 的数据库哈,主要字段和其它字段分开来

李佳慧 回复

很多时候都是多版本运行啊,自动化测试可能会要支持多个版本,最好再加一个任务模块,让我知道你这个版本要改些接口,我是这么觉得的

是啊,繁琐和难以维护是大问题,又必须要解决,解决了,解决的好,就能省很多时间和人力了🌷

Kevin.zhao 回复

我懂你意思了,你指的是被测程序的版本号,这个想法很棒👍 👍 👍 👍 👍 👍 👍 👍 👍

Jacky 回复

👍 👍 👍 👍 👍 回头我去研究研究😀 😊

需要 登录 后方可回复, 如果你还没有账号请点击这里 注册