67.玩转数据驱动

大家好~我是米洛

我在从0到1打造一个开源平台, 也在编写一套完整的接口测试平台系列教程,希望大家能够多多支持。

欢迎关注我的公众号测试开发坑货,获取最新文章教程!

🍦 上节回顾

上一节我们稍微撩了一下数据驱动,就马上去写基础Model了,这节我们就来仔细探讨下数据驱动的实现想法

先简单介绍一下数据驱动的概念,这里笔者找到了维基百科关于数据驱动的定义。

简单阐述一下就是三个特点:

  1. 将变化的东西和测试逻辑分离

什么意思呢?我们比如在测试用户登录的接口,会制造各种各样的输入条件,这些体现到测试数据上的变化就是用户名/密码的变化,我们需要把测试逻辑(校验是否能够登录成功)和测试数据(诸多账号密码)分开。

  1. 根据测试数据的不同执行不同的测试逻辑

通过不同的数据,去完成多组测试数据的测试。

以上面的例子来看,我们抽离用户登录数据和具体的输出(登录结果)的校验,数据越多,这样测试覆盖的场景就会越多,即覆盖率会得到提升。但对我们来说,仅仅只是多凑一些数据而已。

📒 Pity打算怎么做

pity本来还不想做这块功能,但由于环境各方面的关系,导致不得不提前准备好各个环境的测试数据,一来二去就不得已而为之了。

pity引入数据驱动也只是一个抛砖引玉的过程,只是支持用例多数据化,用相同的测试逻辑进行测试。

所以简单的讲,笔者只打算让用例支持多组数据,并根据多组数据去运行用例。

🍦 编写测试数据表的相关接口

📒 编写测试数据表单

app/models/schema/testcase_data.py
app/models/schema/testcase_data.py

表单接受case_id,name,json_data等参数,目前来看的话我们支持的数据都是以JSON为主,如果后续有文件等内容,我们可以接受文件的url地址进行测试。如果是form的内容,json也可以转换为KEY-VALUE的形式。

所以核心就是: json_dataname,这2块属于一组测试数据,name只是让不同的测试数据有一个标识

📒 编写增改方法

app/dao/test_case/TestcaseDataDao.py
app/dao/test_case/TestcaseDataDao.py

编写新增和修改方法,逻辑基本一致。

新增操作:

  1. 查找对应的数据,有则抛出数据已存在的异常(为了避免重复数据,双重防护,代码层+数据库唯一索引)
  2. 如果没有则直接插入
  3. 返回新插入的数据,避免二次查询数据列表

修改操作:

  1. 查找对应的数据,无则抛出数据不存在的异常(这样是为了防止数据已经被删除,而用户仍然在修改的情况)
  2. 如果有这条数据则更新之
  3. 返回修改后的数据

📒 编写查询方法

查询方法我们打算编写2个核心方法:

  • 通过case_id查询测试数据

    这个方法是给页面查询这个case在不同的环境下的所有测试数据用的。

  • 通过环境查询测试数据

    这个是给用例执行时,快速拿到用例对应环境下的测试数据用的。

    举个例子,我这时候在测试一个接口,如果以数据驱动的方式,我得快速找到这个接口对应的csv或者json文件,找到了以后还是会转换为Python数组,所以我们大概是这样的过程。

可以看到,二者的区别只是查询条件不同,前者未传入env,后者传入了env
可以看到,二者的区别只是查询条件不同,前者未传入env,后者传入了env

前者返回了一个下图这样的测试数据,后者返回的是对应环境的测试数据列表。

{"fat": [{"data""测试数据1"}]}

📒 编写删除方法

删除方法很简单,我们只需要把数据的deleted_at改为当前时间戳即可
删除方法很简单,我们只需要把数据的deleted_at改为当前时间戳即可

📒 编写接口

这边只有增删改的接口
这边只有增删改的接口

查询接口我们把它放入查询用例接口里面:

因为用例是一个整体,我们需要对整体进行数据返回,故没有开放专门的查询接口,后续有需要我们可以再放开
因为用例是一个整体,我们需要对整体进行数据返回,故没有开放专门的查询接口,后续有需要我们可以再放开

🍦 前端改动

前端的改动比较简单,即在用例tab页加入数据管理功能,并在最左侧加上环境tab(根据自己配置的环境),右侧则为对应的测试数据表格

关于数据驱动的增删改查编写就到此结束了,由于数据驱动有一些改造,所以下期我们会讲如何适配数据驱动的影响。