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

大家好，我是米洛，一个测试开发博主，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/

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

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