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

2022/6/13 测试平台接口测试FastApiPythonReact

大家好,我是米洛,一个测试开发博主!

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

欢迎大家关注我的公众号: 米洛的测开日记

# 回顾

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

# 编写根据case_id查询所有构造器方法

这里是为了找出我要运行的case的所有数据构造方法

# 编写查找数据构造器方法

  • ConstructorDao添加static方法

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

# 改造Executor类

  • 新增解析参数的方法

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

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

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

  • 尽管装饰器自动生成了不少日志,但是还是不够

我们需要可以手动写入日志的功能,于是封装了append方法

  • 新增获取构造数据和执行构造数据方法

可以看到,目前构造器只支持了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返回数据
}
1
2
3
4
  • request_param

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

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

  • path

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

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

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

# 回到最初的例子

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

我们应该怎么做呢?

  1. 编写一个登录用例

编写用例基本信息

header信息

body信息

测试一下:

测试成功,能够正常登录

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

  2. 取数据

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

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

看看效果:

成功拿到response

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

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

故意写错SESSIONID

可以看到变量替换失败了

登录凭证没有获取到,自然就登录失败了!

在线演示地址: http://47.112.32.195/ (opens new window)

前端代码仓库: https://github.com/wuranxu/pityWeb (opens new window)

后端代码仓库: https://github.com/wuranxu/pity (opens new window)