大家好~我是
米洛！
我在从0到1打造一个开源平台, 也在编写一套完整的接口测试平台系列教程，希望大家能够多多支持。
欢迎关注我的龚仲浩测试开发坑货，获取最新文章教程!
上节回顾
上一节我们稍微撩了一下数据驱动，就马上去写基础Model了，这节我们就来仔细探讨下数据驱动的实现想法。
先简单介绍一下数据驱动的概念，这里笔者找到了维基百科关于数据驱动的定义。
image
简单阐述一下就是三个特点:
- 将变化的东西和测试逻辑分离
什么意思呢？我们比如在测试用户登录的接口，会制造各种各样的输入条件，这些体现到测试数据上的变化就是用户名/密码的变化，我们需要把测试逻辑（校验是否能够登录成功）和测试数据（诸多账号密码）分开。
- 根据测试数据的不同执行不同的测试逻辑
通过不同的数据，去完成多组测试数据的测试。
以上面的例子来看，我们抽离用户登录数据和具体的输出（登录结果）的校验，数据越多，这样测试覆盖的场景就会越多，即覆盖率会得到提升。但对我们来说，仅仅只是多凑一些数据而已。
Pity打算怎么做
pity本来还不想做这块功能，但由于环境各方面的关系，导致不得不提前准备好各个环境的测试数据，一来二去就不得已而为之了。
但pity引入数据驱动也只是一个抛砖引玉的过程，只是支持用例多数据化，用相同的测试逻辑进行测试。
所以简单的讲，笔者只打算让用例支持多组数据，并根据多组数据去运行用例。
编写测试数据表的相关接口
编写测试数据表单
app/models/schema/testcase_data.py
表单接受case_id，name，json_data等参数，目前来看的话我们支持的数据都是以JSON为主，如果后续有文件等内容，我们可以接受文件的url地址进行测试。如果是form的内容，json也可以转换为KEY-VALUE的形式。
所以核心就是: json_data和name，这2块属于一组测试数据，name只是让不同的测试数据有一个标识。
编写增改方法
app/dao/test_case/TestcaseDataDao.py
编写新增和修改方法，逻辑基本一致。
新增操作:
- 查找对应的数据，有则抛出数据已存在的异常(为了避免重复数据，双重防护，代码层+数据库唯一索引)
- 如果没有则直接插入
- 返回新插入的数据，避免二次查询数据列表
修改操作:
- 查找对应的数据，无则抛出
数据不存在的异常(这样是为了防止数据已经被删除，而用户仍然在修改的情况) - 如果有这条数据则更新之
- 返回修改后的数据
编写查询方法
查询方法我们打算编写2个核心方法:
-
通过case_id查询测试数据
这个方法是给
页面查询这个case在不同的环境下的所有测试数据用的。 -
通过环境查询测试数据
这个是给用例执行时，快速拿到用例对应环境下的测试数据用的。
举个例子，我这时候在测试一个接口，如果以数据驱动的方式，我得快速找到这个接口对应的
csv或者json文件，找到了以后还是会转换为Python数组，所以我们大概是这样的过程。
可以看到，二者的区别只是查询条件不同，前者未传入env，后者传入了env
前者返回了一个下图这样的测试数据，后者返回的是对应环境的测试数据列表。
{"fat": [{"data": "测试数据1"}]}
编写删除方法
删除方法很简单，我们只需要把数据的deleted_at改为当前时间戳即可
编写接口
这边只有增删改的接口
查询接口我们把它放入查询用例接口里面:
因为用例是一个整体，我们需要对整体进行数据返回，故没有开放专门的查询接口，后续有需要我们可以再放开
前端改动
image
前端的改动比较简单，即在用例tab页加入数据管理功能，并在最左侧加上环境tab（根据自己配置的环境），右侧则为对应的测试数据表格。
image
关于数据驱动的增删改查编写就到此结束了，由于数据驱动有一些改造，所以下期我们会讲如何适配数据驱动的影响。
网友评论