前言

基于公司都是使用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的操作,从而绕过校验达到真实测试的目的。

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”}

未完待续……

相关文章: