42.编写数据构造器功能（下）

大家好，我是米洛，一个测试开发博主！

如果阅读完毕后想和作者有更多交流，可以点击阅读原文找到底部评论区，给作者留言啦！

欢迎大家关注我的公众号: 测试开发坑货。

上篇已经编写了添加数据构造器的相关方法，现在我们就来运动到用例中去。

不为别的，因为我们如果判断case有数据构造数据，那我们就要获取到这个数据呀！

还记得之前我们全局变量替换变量的内容吗？当时是只替换headers，body等内容，其实不太全面。

一个TestCase类，里面有太多字段了。我们取数据以后，每个字段都需要check一遍，所以这里遍历一个testcase的所有字段，去里面挖掘变量，这样会最全面。（效率也会比较低，但是由于我们的数据构造器只告诉了返回，并没告诉具体在哪用，所以这样的过程是有必要的）

这里有个特例，request_header我们本身已经是处理为json字符串了，所以里面的数据天然是字符串，我们不需要进行一次序列化。

可以看到，目前构造器只支持了type == 0也就是测试用例类型。如果是case类型，那么Executor会再次生成一个，去执行用例中的用例，最终拿到result信息，并根据我们设定的value，把case执行的数据全部塞给传递进来的params字典。

这个过程就记录了所有构造条件里面的数据，为将来取数据做好了铺垫。

新增了3个参数，分别是params_pool，request_param和path。

解释一下:

params_pool

这个是总体的全局的数据池，从第一个用例开始积累，所以我们约定，不要填写重复的返回值。

比如构造器1返回变量value1，构造器2返回变量value2，那最终这个params_pool的内容会是:

{
  "value1": value1返回数据,
  "value2": value2返回数据
}

request_param

在上一篇漏掉了个内容，我们有一个动态参数的字段。因为我们用例参数如果写死会很难用，所以我们要让用例动起来，而不是死数据，但又不是全局变量那么刻板。

所以我们需要让用例能接受对应的数据去执行，比如一个登录用例，里面写了用户名是abc，这里我传入我这个场景需要的用户woody就可以达到通过参数修改用例的目的。