接口自动化测试平台之二——数据库设计

前言

基于公司都是使用JAVA开发，团队中的同事也是JAVA使用的多，所以使用JAVA作为主要开发语言。
笔者现在处于在实践中逐步摸索学习的过程中，文中如果有什么地方写的不对或者不合适的地方，还请各前辈大佬多多指正，共勉。

技术选型

后端：SpringBoot + Mysql + Redis + RabbitMq
前端： VUE + Element-UI

大概就是以上这些了，至于为什么这么选，公司内部开发的技术模式也是这些，能更好的契合我们的测试环境，交互更加方便，就好像，你说中文，我也说中文，我们沟通起来就没啥障碍。

数据库设计

实际上接口平台的表不止这些，先把相关度较高的放在里面，接下来介绍每张表的所存内容，以及关联关系

核心关键表 interface_cases

该表主要用来保存用例法人基本信息，包括请求头，请求BODY,执行账号主体，执行前置，总执行后置，用例执行后期望返回，执行接口依赖（url,GET|POST|PUT, JSON|IMG|PARAM）,是否参与CI,等信息

字段名称	字段描述
id	主键
name	用例名称
service_id	服务ID
interface_id	接口id
description	用例描述
json	当接口请求方式是post请求，json未请求内容
mobile	当前接口相关的手机号码，用来获取token
expect	期望值格式支持key1=value1key2-value2
sql_before	执行用例之前要执行的sql
sql_after	执行用例之后要执行的sql
case_type	用例类型
headers	text
operationTag	是否参与自动化运维
data_type	默认类型，1图片
isvalid	是否有效
remark	备注
update_time	更新时间
create_time	创建时间
creator	创建人

字段设计
下面的内容会有些枯燥乏味，字段设计这一块有通用设计，也有部分字段是结合了公司的特殊情况做的设计，仅供参考。

json请求体

• 1：POST请求，当接口的请求体类型为application/json时，接口请求时将整个json串提交
• 2：POST请求，当接口的请求体类型为form-data时，json格式为{“key1”:“value1”,“key2”:“value2”}，在请求时会自动解析json串，组装请求数据。
• 3：GET请求，且接口带参数，则解析json{“key1”:“value1”,“key2”:“value2”}，拼接url发起请求

mobile请求数据
这个字段主要是针对笔者所在公司的业务做的一个定制设计，mobile为非必填字段，因为在执行接口自动化测试的时候是独立运行的，而被测系统对安全要求较高，有加密和TOKEN校验，而加密和TOKEN的生成都是在登录之后才确定的，从而加大的接口测试的难度，为了解决接口层面的校验带来的配置难度，接口平台针对公司的系统做了一个兼容的操作，即支持纯手动配置TOKEN和自动获取TOKEN的操作，从而绕过校验达到真实测试的目的。

现在技术飞速发展，业务迭代变更，系统复杂提高，对系统安全性的要求也越来越高，一般系统都会做一些安全校验，每家公司都不一样，市面上开源的自动化框架往往为了做的更通用，便舍弃了一些灵活性，而直接应用这类工具，在实际工作当中往往让人觉得麻烦痛苦。简单一条，绕过本公司的安全校验就成为第一阻碍。当然，绕过接口校验直接做接口测试的方式有很多，要根据被测系统的实际逻辑来做设计，比如接口校验的token是通过秘钥计算生成，保存在本地缓存中，或者Redis缓存，或者数据库，或者是其他什么地方，又或者被测系统做一个开关来控制是否做请求校验。这样就需要开发工具了。

sql_before | sql_after请求前置后置
一个接口有多个测试场景，如果每个场景用一个账号来测试，那将要花费很多精力在准备测试数据上，而很多时候，同一个接口的不同场景，区别往往在于入参或者测试账号的相关数据，那么通过直接修改数据库的数据即可达到目的。
很多时候我们的被测系统，可能涉及不同厂家的数据库，这样就不仅要支持不同的数据库，还要支持不同种类的数据库，如：ORACLE, SQL_SERVER, KYSQL, POSTGRES等等。
拓展思考：在考虑用例前后置执行的时候，用例的前后置执行可能要：
1：执行一个用例；
2：发送一个MQ消息；
3：请求一个DUBBO接口；
4：执行多条数据库
5：从数据库中查询某个数据
6：或者是参数化调用某个SQL包并返回所需数据
能如数支持以上条件，才能用例做到更灵活，当然这样的用例设计复杂度增加了，系统的设计的复杂度也随之而上升。

headers|expect请求头|期望返回
headers的数据保存方式根据公司情况或者设计者习惯设计，没有说固定一定要以某种方式设计，最合适最习惯的才是最好的，笔者为了方便支持后续EXCEL批量导入和页面录入，支持以下三种格式的数据。
优点：录入灵活，兼容度高
缺点：数据格式不统一，加大维护难度

• KEY1=VALUE1&KEY2=VALUE2…
• KEY1=VALUE1,KEY2=VALUE2…
• {“key1”:“value1”,“key2”:“value2”}

未完待续……