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