大家好~我是
米洛！
我正在从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，把变量放入变量池。
# 前端部分
至此，我们后端的改动就完成了。来看看前端的变化:
# 怎么使用呢
自从改写了数据驱动以后，我们还没有跑过一个完整的例子。接着我们来看看:
# 前置用例
前置用例是一个登录的case，里面的username和password都已经抽离出来，这个值要怎么传给它呢？这个依赖于我们数据驱动里面的数据。
# 前置SQL语句
为什么要做这步，是为了后面断言的考虑。
# 主体用例
主体用例的逻辑一目了然:
- 替换全局变量，把blog_url变为真实请求地址
- 执行前置用例->登录case，并把username和password传入
- 取到前置用例的SESSIONID
- 执行测试SQL，取到nickname like name的用户信息
- 请求查询用户接口
- 断言，看结果是不是和数据库查出来的数量一致
# 断言部分
断言里面把sql_data的count（数量）取出来，和response（提前知道返回一个json数组）的数量进行长度对比。
# 总结一下需要传入的变量
- username 登录用户名
- password 登录密码
- name 查询的用户
# 看看数据管理
# 执行用例
由于执行这块我们还没彻底修复，只修复了批量执行的，我们去批量执行一下。
看下报告:
看了下，断言里面预期结果应该是0，但实际结果有9条。
可以看到返回了很多数据，其实我查询的的name是一个我瞎编的，但这个接口还是返回了9条数据，也就是说测试失败了。
我们再看看数据库的执行记录:
可以看到变量已经灵活转变了。
再看看脑图部分:
总体来说，完整的流程已经走完了。在参数替换部分，确实出现了一些性能损耗，但没有关系，总体来说还是不算慢的。
今天的内容就分享到这里了，下一节介绍我们刚才没有提到的断言部分: 长度等于。