大家好，我是米洛，一个
测试开发博主，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当数据库会更舒服。只不过为了降低系统复杂度，尽量少引入新的组件，能忍就忍了。
定义造数器请求参数
编写新增数据构造器功能
页面操作
- 为对应的用例添加构造器
- 选择测试用例类型
最后的效果就是，查询所有用户列表用例拥有了一个用户正常登录的数据构造器。
这期的内容就到这里了，太多了我自己都消化不良。
在线演示地址: http://test.pity.fun/
前端代码仓库: https://github.com/wuranxu/pityWeb
后端代码仓库: https://github.com/wuranxu/pity