DDT在接口测试中的应用 -实战篇

Posted 2021-04-24 安吉的测试人生

点击蓝字

对于测试来讲，接口测试是重要的测试项之一。接口测试的内容很多，其中参数测试部分的用例就相当多，比如参数缺失、参数边界值等。那有没有好的办法来自动生成用例来完成这部分工作呢？答案是肯定的。工具名称ddt_param（我自己命名的），下面我来介绍下我们是怎么做的。

一

为什么做这件事

17年上半年测试需求的时候，新增了不少接口，发现做参数异常测试非常繁琐，需要：

1、对应缺失字段或者多余字段得新增资源

2、每种参数异常得新增一个自动化用例

3、构造大包请求或者边界值数据相当麻烦

当时我就在琢磨怎么解决以上这些繁琐并影响效率的自动化测试。经过各种尝试，比如用unittest做接口测试，还比如直接手工发包；再后来，我发现用ddt结合现有自动化平台，能比较好的解决这个问题。下面是实际的操作效果：

第一步、维护每个接口的测试数据,如：

第二步、把这个文件上传到系统：

第三步、执行用例并查看结果

首先在现有自动化平台上选择用例，再复制或者应用到自己的业务用例中，然后把变量script_data_file改成自己在第二步上传的文件名（文件名必须一致）。执行后再下载详细结果，如下：

二

具体实现及好处

通过上面的介绍，大家应该了解大致的操作步骤；我写这个工具的主要目的是解决接口参数异常测试自动化问题，同时还可以辅助接口功能测试。下面我具体介绍下这个工具的功能以及带来的好处。

实现方案

1、采用unittest+ddt实现技术实现自动生成用例；数据方案到csv文件中，然后把文件上传到系统

2、用例管理使用现有的自动化平台，业务可以为每个模块维护一个用例+一个csv数据文件就好（一个模块多接口）

3、用例执行完成自动生成测试报告，用htmlTestRunner实现。

 四大功能

一 支持多种协议

目前支持的协议有：

6种业务强相关协议

http协议

二 支持多种测试类型

1、empty 协议字段位空

2、Lack 协议字段缺少

3、special_character  协议字段乱码

4、Boundary 边界值

    边界值支持string和number两种类型，包括字段类型和长度，用等号连接如：

    string=65表示字段为string类型，需要构造65位

     又如：

    number=65表示字段为数字类型，需要构造65位

    多个用英文冒号隔开，如：

    string=65:number=65

5、Bigpackage 大包 56k

6、Normal 正常请求

三 预期结果检查多样

支持多项返回结果检查,用|隔开

支持数据库sql检查

四 依赖字段处理

需要定制某个字段的值

如需要指定卡号字段card_num为：DSFADFADFDAAFDFAFAS,则填：card_num=DSFADFADFDAAFDFAFAS

需要只读多个字段，则用英文冒号隔开，如card_num1=DSFADFADFDAAFDFAFAS:card_num2=3242342342

注意1：先构造异常再替换依赖参数

注意2：如果是要替换当前时间，则填sp_now_time

如 fmodify_time=sp_now_time

注意3：如果是要替换当前时间的单号，在填sp_now_listid_x(x表示某类单号)

sp_now_listid_1：交易单

sp_now_listid_2：充值单

sp_now_listid_3：提现单

sp_now_listid_4：转账单

sp_now_listid_5：冻结单

.........

如 flistid=sp_now_listid_5

如果有多个单号，用英文竖线隔开

flistid=sp_now_listid_3|flistid_trans=sp_now_listid_5

优点

1、结合现有平台资源，不用额外维护数据

2、测试用例报告输出

3、可视化操作方便

三

不足及后期规划

Ddt_param目前能满足我们大部分的参数异常测试，但还是有不足之处，主要有两方面：

1、数据库检查还不够智能

解决方案：可以通过后台调用现有平台的api实现

2、公共API少，目前只有自动生成当前时间、单号、和固定值

解决方案：可以通过后台调用现有平台的api实现，也可封装一些常用的api

四

总结

Ddt_param能解决接口测试中参数异常测试的痛点；具有4大功能，分别是支持多种协议、支持多种测试类型、预期结果检查多样、依赖字段处理；有3方面的优点：首先是结合现有平台资源，不用额外维护数据，然后是自动生成测试报告，还是全过程可视化操作。当然，工具也有不足的地方，后面还会继续优化。

五

附录

名词解释

1、数据驱动：

数据驱动测试的概念

数据驱动测试是从数据文件（excel 文本文件 XML 文件 或者数据库）中读取测试数据，然后通过变量传入脚本中，既可以当测试数据的输入 也可以当输出数据的验证。测试数据在文件中， 测试脚本负责逻辑业务过程、测试状态以及数据文件读取

数据驱动的测试适用于对相同流程进行大数据量测试且测试结果可被预期的情况

数据驱动测试技术的特点

（1）数据与测试脚本分离，从而可以在不修改测试脚本的情况下通过更新测试数据完成对测试用例的增加、更改和删除。

（2）通过变量的参数化，将测试数据传入测试脚本，不同的数据文件对应不同的测试用例

（3）提高了测试脚本的灵活性，增加测试覆盖面，以及提高应对测试对象变更的能力。

 2、DDT：

DDT是 “Data-Driven Tests”的缩写。

     ddt.ddt：装饰类，也就是继承自TestCase的类。

     ddt.data：装饰测试方法。参数是一系列的值。

     ddt.file_data：装饰测试方法。参数是文件名。文件可以是json 或者 yaml类型。

     ddt.unpack：传递的是复杂的数据结构时使用。比如使用元组或者列表，添加unpack之后，ddt会自动把元组或者列表对应到多个参数上。字典也可以这样处理。

     官网下载安装

     http://ddt.readthedocs.io/en/latest/

     https://github.com/txels/ddt