大家好，我是米洛，一个
测试开发博主！
如果阅读完毕后想和作者有更多交流，可以点击阅读原文找到底部评论区，给作者留言啦！
欢迎大家关注我的公众号: 米洛的测开日记。
# 回顾
上篇已经编写了添加数据构造器的相关方法，现在我们就来运动到用例中去。
# 编写根据case_id查询所有构造器方法
# 编写查找数据构造器方法
- ConstructorDao添加static方法
不为别的，因为我们如果判断case有数据构造数据，那我们就要获取到这个数据呀！
# 改造Executor类
- 新增解析参数的方法
还记得之前我们全局变量替换变量的内容吗？当时是只替换headers，body等内容，其实不太全面。
一个TestCase类，里面有太多字段了。我们取数据以后，每个字段都需要check一遍，所以这里遍历一个testcase的所有字段，去里面挖掘变量，这样会最全面。（效率也会比较低，但是由于我们的数据构造器只告诉了返回，并没告诉具体在哪用，所以这样的过程是有必要的）
这里有个特例，request_header我们本身已经是处理为json字符串了，所以里面的数据天然是字符串，我们不需要进行一次序列化。
- 尽管装饰器自动生成了不少日志，但是还是不够
- 新增获取构造数据和执行构造数据方法
可以看到，目前构造器只支持了type == 0也就是测试用例类型。如果是case类型，那么Executor会再次生成一个，去执行用例中的用例，最终拿到result信息，并根据我们设定的value，把case执行的数据全部塞给传递进来的params字典。
这个过程就记录了所有构造条件里面的数据，为将来取数据做好了铺垫。
# 改造run方法
新增了3个参数，分别是params_pool，request_param和path。
解释一下:
params_pool
这个是总体的全局的数据池，从第一个用例开始积累，所以我们约定，不要填写重复的
返回值。比如构造器1返回变量value1，构造器2返回变量value2，那最终这个params_pool的内容会是:
{
"value1": value1返回数据,
"value2": value2返回数据
}
2
3
4
request_param
在上一篇漏掉了个内容，我们有一个动态参数的字段。因为我们用例参数如果写死会很难用，所以我们要让用例动起来，而不是死数据，但又不是
全局变量那么刻板。所以我们需要让用例能接受对应的数据去执行，比如一个登录用例，里面写了用户名是abc，这里我传入我这个场景需要的用户woody就可以达到
通过参数修改用例的目的。
path
这个很好理解，我的case路径。比如我是A用例，在执行A的构造条件1->B用例，那么为了不让我凌乱，我会给出一个path:
A->B， 这样就会比较好区分。
再讲讲用例的细节，我们按照step（注释有写）将用例过程拆分，这样思路就很清晰了。
# 回到最初的例子
我们还是得先登录，再通过JSESSIONID去请求获取用户列表接口的。
我们应该怎么做呢？
- 编写一个登录用例
测试一下:
把登录用例添加为查询所有用户列表的
数据构造器取数据
我们登录后，需要用到cookie里面的JSESSIONID。
注意这里，我们把登录后的变量设置为了blog_login，通过cookies.JSESSIONID拿到对应的数据，并传递给当前用例。
看看效果:
由于日志不太友好，后续还得改造。断言也没有添加，还需努力呀！
如果修改或者写错这个变量:
在线演示地址: http://47.112.32.195/ (opens new window)
前端代码仓库: https://github.com/wuranxu/pityWeb (opens new window)