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

2024-03-25 14:10:16

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

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

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

回顾

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

找个例子

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

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

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

平台化思路

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

设计用例
调用login接口，获取到凭据（token/cookie等）
根据凭据请求获取用户列表接口
根据对应的用例制造不同的请求参数（nickname）
根据用例编写对应的断言信息

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

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

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

明白这点的话，我们就开始改造我们的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当数据库会更舒服。只不过为了降低系统复杂度，尽量少引入新的组件，能忍就忍了。