测试平台系列(42) 编写数据构造器功能（下）

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

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

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

回顾

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

编写根据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返回数据
}

• request_param

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

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

• path

  这个很好理解，我的case路径。比如我是A用例，在执行A的构造条件1->B用例，那么为了不让我凌乱，我会给出一个path:

  A->B， 这样就会比较好区分。

  再讲讲用例的细节，我们按照step（注释有写）将用例过程拆分，这样思路就很清晰了。

回到最初的例子

我们还是得先登录，再通过JSESSIONID去请求获取用户列表接口的。

我们应该怎么做呢？

1. 编写一个登录用例

测试一下:

2. 把登录用例添加为查询所有用户列表的数据构造器

3. 取数据

我们登录后，需要用到cookie里面的JSESSIONID。

注意这里，我们把登录后的变量设置为了blog_login，通过cookies.JSESSIONID拿到对应的数据，并传递给当前用例。

看看效果:

由于日志不太友好，后续还得改造。断言也没有添加，还需努力呀！

如果修改或者写错这个变量:

在线演示地址: http://test.pity.fun/

前端代码仓库: https://github.com/wuranxu/pityWeb

后端代码仓库: https://github.com/wuranxu/pity