大家好~我是米洛！


我在从0到1打造一个开源平台, 也在编写一套完整的接口测试平台系列教程，希望大家能够多多支持。



欢迎关注我的公众号测试开发坑货，获取最新文章教程!

回顾

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

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

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

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

SQL构造器

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

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

编写获取sql配置的方法

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

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

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

编写执行sql的方法

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

改造执行前置条件方法

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

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

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

拿到database（数据库名）和sql（sql语句），接着执行sql，把变量放入变量池。

前端部分

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

怎么使用呢

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

前置用例

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

前置SQL语句

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

主体用例

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

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

断言部分

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

总结一下需要传入的变量

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

看看数据管理

执行用例

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

看下报告:

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

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

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

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

再看看脑图部分:

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

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