接口表
主要保存了接口的主要信息，说明：
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 编码之后以字符串的方式保存在数据库里面的，没有保存在服务器上，因为我们的后台服务是部署在容器里面，存取路径不好找，且容器销毁后文件就不存在了，其次，没有分配云服务器，所以选择存库。

图片接口

图片用例