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

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

大家好,我是米洛,一个测试开发博主,world很大, 你应该去看看!

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

这篇文章阅读需要一定的耐心,如果看的不爽可以点个赞提醒一下博主。

# 回顾

上篇已经找到了一个可测的项目,但是遇到了需要登录的问题。正常来说,我们如果写代码的话,肯定很方便,在setUp这类方法里咔咔咔登录一下,存储对应的JSESSIONID,然后测试函数就能够用JSESSIONID畅通无阻访问项目了。

# 找个例子

下面我们来看一个简单的例子:

由于这个项目很老了,很多图片过期了都

如图所示,我想测试一个获取用户列表的接口,对应这个页面。因为我们暂时没有整理出对应的接口文档,只能自己看代码或者抓包去了解这个请求。

好在这个请求比较简单,是个GET,并且接受一个nickname字段。根据经验,这个接口可以根据对应的用户名查询对应的用户信息。

可以看到这个接口是需要登录的

# 平台化思路

那么平台化的话,应该怎么做呢?我们刚才梳理了具体的过程。

  1. 设计用例
  2. 调用login接口,获取到凭据(token/cookie等)
  3. 根据凭据请求获取用户列表接口
  4. 根据对应的用例制造不同的请求参数(nickname)
  5. 根据用例编写对应的断言信息

熟悉Python+excel的朋友,可能会在excel添加了好多条测试数据和期望结果了,其实平台化也是类似。

我们只需要关心一个用例的真正执行过程:

  1. 登录获取凭据
  2. 通过凭据请求接口

明白这点的话,我们就开始改造我们的Executor类了。所以我们要做的就是先执行登录用例,再执行测试用例。换句话说,登录用例是该测试用例的前置条件(setUp/初始化数据操作),我这里给他取了个名儿: 数据构造器,因为我们常说的接口之间的依赖,常常是数据引起,如果登录后能拿到凭据,那么我们对登录的依赖就被解决了。

我们执行用例的时候,是这样的顺序,如果用例有数据构造器,那么我们先执行数据构造器方法,目的就是把依赖数据拿到。

# Constructor表

表设计

id,deleted_at,created_at,create_user,update_user这些字段都是老生常谈了,不赘述了。

  • type

    我们的数据可能来自一次http请求,redis操作,sql查询,其它测试用例等等。我暂时定了3个最常见的:

    # 0: testcase 1: sql 2: redis

    其他的我们后续遇到再补充,肯定会有的,比如py脚本等等

  • name:构造器的描述

  • enable: 是否开启

    比如某天你暂时不需要进行这个操作了,你可以临时关闭,后续可以打开。

  • public: 是否公开,不公开就只能你自己舒服别人不能舒服

  • case_id: 这个构造器所属的case_id

  • value: 构造器的返回值

    这个大家能理解吧,我构造了数据,是为了让自己再取出来。比如我set woody="帅哥",后续我是要用这个帅哥的,那么此时的woody就是value了,或者叫return_value更方便理解。

  • constructor_json: 构造json

    由于我们不同的数据,对应不同的数据格式。举个例子,如果我是个sql类型,我可能需要jdbcUrl(数据库连接地址),sql等关键信息,其实这种情况我们用mongo当数据库会更舒服。只不过为了降低系统复杂度,尽量少引入新的组件,能忍就忍了。

# 定义造数器请求参数

基本上没有什么大的区别

# 编写新增数据构造器功能

修改和删除的暂时还没完成

# 页面操作

  1. 为对应的用例添加构造器

  1. 选择测试用例类型

提前准备好了一个正常登录的用例

最后的效果就是,查询所有用户列表用例拥有了一个用户正常登录的数据构造器。

这期的内容就到这里了,太多了我自己都消化不良。

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

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

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