测试平台系列(69) 数据构造器支持sql语句.md

2022/6/13 测试平台接口测试FastApiPythonReact

大家好~我是米洛
我正在从0到1打造一个开源的接口测试平台, 也在编写一套与之对应的完整教程,希望大家多多支持。
欢迎关注我的公众号米洛的测开日记,获取最新文章教程!

# 回顾

上节内容我们编写了非常恶心的数据驱动部分,而且有些东西笔者还讲的不清不楚的。接下来我们就来让数据构造器支持sql。

先看看之前的数据构造器:

画了许多饼,要支持的大概是这么多

  • 测试用例
  • sql
  • redis
  • http
  • python方法

目前我们还只支持一种呢~所以我们要尽快支持起来,保证造数的丰富性

# SQL构造器

其实sql构造器比较简单,我们之前的文章也已经写好了sql构造器的核心方法,详情可以看在线执行sql的文章。

那我们今天只需要稍微来点改造即可。

# 编写获取sql配置的方法

之前我们编写的获取sql配置的方法,都是根据id来获取的,但因为我们存在多环境的情况。举个例子:

fat uat
id 1 2
数据库名 blog blog

这样的数据,名称都是blog,但环境不同导致会有多条数据。我们的用例要支持多环境运行, 如果指定了id为1,那么就不能访问到uat下的blog了。

所以我们打算用环境+数据库名确定一个配置,这样当env发生变化的时候,我们的配置也会跟着变化。

所以我们编写通过环境和名字查询数据库配置的方法

# 编写执行sql的方法

这里和在线执行有所不同,主要体现在获取配置那块。并且把查询结果序列化为json字符串,方便进行变量替换。

# 改造执行前置条件方法

执行前置条件的时候会判断前置条件类型,如果现在类型为1,说明是sql类型。

我们先反序列化数据,拿到对应的数据库名称配置信息。

注意,这里的反序列化是因为我们的前置条件表是用了一个TEXT字段存放所有类型的数据,由于用例和sql数据格式都不一致,所以我们需要反序列化为字典进一步取值。

# 拿到database(数据库名)和sql(sql语句),接着执行sql,把变量放入变量池

# 前端部分

至此,我们后端的改动就完成了。来看看前端的变化:

数据编写页面

左侧菜单可以切换编辑和调试模式,调试模式则是引入了在线执行sql的页面

可以看到明显的类型区分

# 怎么使用呢

自从改写了数据驱动以后,我们还没有跑过一个完整的例子。接着我们来看看:

# 前置用例

先看看前置用例

前置用例是一个登录的case,里面的username和password都已经抽离出来,这个值要怎么传给它呢?这个依赖于我们数据驱动里面的数据。

# 前置SQL语句

前置sql里面查询了昵称like name(这个是个变量)的数据

为什么要做这步,是为了后面断言的考虑。

# 主体用例

主体用例的逻辑一目了然:

  1. 替换全局变量,把blog_url变为真实请求地址
  2. 执行前置用例->登录case,并把username和password传入
  3. 取到前置用例的SESSIONID
  4. 执行测试SQL,取到nickname like name的用户信息
  5. 请求查询用户接口
  6. 断言,看结果是不是和数据库查出来的数量一致

# 断言部分

断言里面把sql_data的count(数量)取出来,和response(提前知道返回一个json数组)的数量进行长度对比

# 总结一下需要传入的变量

  • username 登录用户名
  • password 登录密码
  • name 查询的用户

# 看看数据管理

可以看到这些数据都已经在数据驱动配置好了

# 执行用例

由于执行这块我们还没彻底修复,只修复了批量执行的,我们去批量执行一下。

这里执行的是指定的fat环境,后续会提供选项选择执行什么环境的case

看下报告:

都报错了,看看日志

看看断言信息

看了下,断言里面预期结果应该是0,但实际结果有9条。

可以看到返回了很多数据,其实我查询的的name是一个我瞎编的,但这个接口还是返回了9条数据,也就是说测试失败了。

我们再看看数据库的执行记录:

可以看到变量已经灵活转变了。

再看看脑图部分:

总体来说,完整的流程已经走完了。在参数替换部分,确实出现了一些性能损耗,但没有关系,总体来说还是不算慢的。

今天的内容就分享到这里了,下一节介绍我们刚才没有提到的断言部分: 长度等于