接口测试 基于 Django 和 Vue 前后端分离接口自动化平台

谈又 · June 07, 2020 · Last by 快乐的码农 replied at August 01, 2020 · 8885 hits

基于Django和Vue前后端分离接口自动化平台

前言

写这个平台动力一方面源自于工作,每次发线上版本,回归场景太多,可能覆盖不全,导致一些觉得不会影响到的模块漏了出现问题;一方面之前写接口自动化和appUi自动化的框架,虽可稳定运行,但是用例一多,即使用文件管理,我都觉得不容易维护,操作麻烦,且不方便直接定位问题,所以萌生了一个想做一个多人可视化操作维护性强的平台;一方面也当做对自己进步的一个证明,2019年12月20日提交两端第一段代码,之后的3个月,白天的业务繁忙,晚上继续节奏感的敲,从数据库设计到页面设计再到页面实现再到后端的逻辑实现再到稳定运行,每一步都不易。

线上体验地址

http://aliyun.0cmm.cn:9527 (2020.07.09服务器压力有点大,目前先关闭,我调整一下,会尽快恢复;2020.07.11已经恢复访问)

选择的主要环境

Django 2.1.7
vue 2.9.6
python 3.6.3
vue-element-admin
Element 组件
Iconfont 图标库

实现功能

1、登录jwt鉴权
2、支持项目、接口、用例、环境、邮箱、任务等管理、添加和维护功能
3、支持接口请求数据结果动态获取
4、支持单接口用例调试、支持多接口业务调试
5、支持丰富的动态断言
6、支持定时任务,支持html邮件报告和平台报告生成、每个失败用例均可以快速定位和调试
7、支持用例执行不正确时候对应模块下分布式各个服务器微服务日志获取
8、支持不同项目接口独立环境地址运行
9、支持接口批量导入

项目功能更新

20200617 新增步骤中复制功能,可以用于一个用例中同一个接口步骤快速填写不同的请求参数
20200711 新增任务计划企业微信群机器人功能,可以通知多个企业微信群
20200720 1、用例新增json请求(这个功能只支持数据请求为json),支持参数化请求,字段填写如{"user":"$user$1$0$0"}(user是想要查找的字段;1是接口或者用例的id;0是下标;0是接口类型1是用例类型2是公共用例类型;);2、断言新增sql校验,sql填写了,就按照sql进行断言。3、新增数据库管理 4、接口新增必填项和描述,必填项会在添加用例步骤体现出来

层级关系

项目>模块>(接口=用例)

页面展示

首页记录了项目、接口、用例、任务计划的有效总数,点击均可以跳转到对应操作页面
操作小助手帮助操作者更好的了解使用流程

功能介绍

项目管理

项目管理页面实现项目和模块的增删改查功能,项目下包含模块(支持添加和查询),示意图如下

接口管理

接口列表

接口管理主要实现了接口的增删改查。

接口新增

1、接口关联项目和模块
2、请求方式目前添加了主流的两种,post和get
3、数据传输方式为json格式或者data
4、可以添加多个header和body,每个header字段或者data字段都有对应的类型可供选择,用于请求接口使用正确的值的类型。
5、接口地址,如果数据库已经保存了这个接口,则会提示“已经添加过该接口”,不会重复添加
6、支持签名,签名的规则需要后端写死
7、除了header和body以及描述可以不用填,其余的都得填写

接口批量导入

1、一次仅支持一个文件的导入
2、严格按照表格模块的格式进行填写,表格第二行是模板填写方式,不用删除,这行不会执行,会从第三行开始执行导入的顺序
3、如果表格中的接口已经存在在平台了,则会跳过,不会录入到数据库,避免接口重复添加
4、表格header和body以及描述可以不用填写,若填写header和body,请严格按照表格第二行进行操作

用例管理

用例列表

用例列表管理包含了基本的增删改查,以及运行功能

用例列表按照用例类型分有4个:全部用例、公共前置用例、单接口用例、业务用例

公共前置用例

这个用例类型比较特殊,执行计划的时候,一天只运行只运行一次(手动运行可以运行多次),且会优先执行,比如登录用例,结果中带token,这个运行一次后,后面用例需要引用这个token值,就不用再次执行一遍用例。

单接口用例

这个用例类型,用例有且只有一个接口,无前置用例,比如app中的搜索,登录或者不登录都可以用

业务用例

这个用例包含了多个接口组成一个业务,允许有前置用例

用例单个运行

点击运行,出来选择环境的弹框,项目+环境

环境可以选择已经配置好的环境,或者自己填写一个环境运行,填写环境格式支持http和https如:http://192.168.1.1:8080

点击调试用例则有对应的运行结果弹框,这个用例有多少个接口运行了,则就有多少个接口的结果在运行弹框中

添加用例

添加用例是整个项目中的核心,功能最多,最灵活,后端逻辑也最复杂

这个当时做的时候就写了3个版本(┬_┬),父子组件之间的数据交换以及页面交互。

用例类型

1、单接口 用例类型:用例步骤中只有一个接口,步骤中无前置用例

2、多接口业务类型:用例步骤中,包含了多个接口,也允许每个步骤中有前置条件

3、公共前置用例类型:用例步骤中,可以有多个接口,如果需要这个类型的用例的值,一天只会被运行一次(比如一个计划计划中,登录运行一次就可以被其他用例都引用到,不需要重复执行)

添加接口,形成步骤

建立一个用例前,当然先选择一个接口,添加一个接口就会多一个步骤,步骤添加后会是折叠效果,一个接口支持多次添加

一个步骤中包含有5个组成部分

1、接口基本信息

2、前置条件,这里只支持添加单接口类型的用例,支持添加多个

3、接口请求信息,包含了两个部分,header和body(如果新增接口的时候已经填写了字段,则字段信息会带过来)

header或者body中的每一个字段都会有这几个信息:

​ ①字段名字:如果接口新增中填写了字段名字,选择完一个接口后则会直接同步
​ ②字段值:动态取某个接口运行的结果或者某个用例运行的结果写法 $token($为后端判断的特殊标识符),如 果不是动态的,则无需要加$
​ ③字段值的类型:如果接口新增中填写了字段类型,则会直接同步
​ 类型说明: str,表示这个值是string类型

​ int,表示这个值是整型

​ boolean,表示这个值是布尔类型,字段值则填写true或者false

​ float,表示这个值是浮点型

​ json,表示这个值是json串,字段值写法如{"test":"test"},当然如果json串里面有动态值则需要这样写{"test":"$test"},也是需要$作为特殊表示,实际场景中还有更加复杂的动态变量,一个key中的value值可能需要取多个接口中产生的结果值,于是就有了{"test":"$test$1$1"},第一个是要取的值,第二个表示从哪个接口id或者用例id中取,第3个表示取的下标,来应对复杂的动态取值。

​ list,表示字段值类型是个数组

​ 获取当前时间,字段值不需要填写

​ 签名,这个比较特殊,获取的是需要签名的接口请求,字段值不需要填写

​ null,字段值不需要填写

​ 空字符串,字段值不需要填写,表示 ‘’

​ ④是否取其他接口或者用例的值勾选框:勾选了,则表示这是一个动态的字段值

​ ⑤选择哪个接口或者哪个用例:
​ 接口id:步骤中基本信息会有接口id,可以取到那个步骤接口运行后的值
​ 用例id:非公共前置用例,取某个用例运行后的值,这里一般用于取前置用例的值
​ 公共前置用例id:取只运行一次的值,一般可以用于取登录后返回的token

​ ⑥ID:写接口ID或者用例ID或者公共前置用例id

​ ⑦下标:所需要的值可能在那个接口运行结果中存在多个,所以需要用下标取值,只有一个值,则下标为0

4、断言

​ 断言中的每一个字段都会有这几个信息:

​ ①实际结果字段,需要断言的结果字段

​ ②实际结果字段下标,该接口运行结果中可能会产生多个这个结果字段,所以需要取下标,只有一个值,则下标为0

​ ③比较符,实际结果和预期结果做比较

​ =,实际结果=预期结果

​ >,实际结果>预期结果

​ <,实际结果<预期结果

​ !=,实际结果!=预期结果

​ in,实际结果in预期结果

​ ④预期结果值,填写一个预期结果

​ ⑤预期结果值类型,填写预期结果值类型

5、步骤的操作

​ 1、删除图标,将这个步骤删除

​ 2、上移图标,将这个步骤上移

​ 3、下移,将这个步骤进行下移

用例调试

​ 考虑到一个用例中,存在多个接口,可能接口所属项目不一样,所以可以添加多个运行环境

​ 这里可以填写完步骤信息以后,就调试一波,可以用来写断言

任务计划管理

任务计划列表

任务计划列表管理包含了基本的增删改查,以及运行功能

运行是异步进行的,运行结束后,会生成报告,如果一个计划在运行

运行包含了3中状态

​ 未执行,一个计划刚创建的时候,会是这种状态

​ 执行中,只要有一个计划正在执行中的,点击其他计划会提示有计划正在执行中,防止执行接口时候,数据错乱

​ 执行结束,该计划执行结束

添加定时任务
是否启用

默认是关闭状态,关闭则不会定时执行这个计划,开启则会在选择的时间段内执行这个计划,启用后,一天只执行一次。

收件邮箱

需要在配置“邮箱管理”添加发件邮箱和收件邮箱,
1、发件邮箱用于发送邮件,不配置,则无法发送邮件,
2、收件邮箱用于定时任务结束后会产生报告,用于接收邮箱

项目环境

添加用例执行所需要的环境,选择环境需要在配置里“环境管理”添加环境,用于定时任务执行,当然也支持其他地址的填写

微服务日志

需要在配置“微服务日志”添加好微服务的信息,当执行的某个用例异常产生错误的时候,添加这个微服务日志用于开发快速定位问题

选择用例

选择用例有两钟方式,一种是按项目选择,选择项目,则会运行一整个项目的有效的用例;一个是选择所有的用例,手动添加想要执行的用例

报告

产生方式:

1、定时任务执行计划

​ 定时任务执行结束,会产生两种报告,一种是纯html写,用于发送邮件使用;另一种则在平台内,可视化,更详细,方便定位

2、手动跑任务计划

​ 只会产生平台测试报告
平台测试报告如下:

邮箱报告如下:

共收到 70 条回复 时间 点赞

代码可以看下吗

很贴近日常使用场景,赞👍

和我之前的想法非常一致😂

还以为开源了呢

还以为开源了呢

谈又 #6 · June 08, 2020 作者
zhouzm 回复

目前代码都在整理中,过一段时间,我再考虑开源吧😂

谈又 #7 · June 08, 2020 作者
paul 回复

都是基于平时的工作场景进行的设计,这说明我们的工作场景差不多

谈又 #8 · June 08, 2020 作者
Cvbnx 回复

目前代码在整理中,要整理的东西有点多,过一段时间我再考虑开源吧😀

谈又 #9 · June 08, 2020 作者
泰斯特test 回复

哈哈哈,不谋而合,源于工作😂

谈又 #10 · June 08, 2020 作者
paul 回复

感谢你的肯定 ❤ ,刚开始写前端也是坑坑洼洼😂

老哥 你现在搞的就是我现在学习的方向啊 我就是在学vue加 django的 希望以后能够开源

请问下用的unittest还是pytest?
期待大佬开源,自己写毫无设计思路,太菜了

谈又 #13 · June 08, 2020 作者

嗯共勉,我得好好整理整理😂

谈又 #14 · June 08, 2020 作者
LinZLin 回复

这两个都没有用,这两个用了,我感觉限制性比较大,就自己写了断言的逻辑😂 。很多设计确实费脑子。😂

看起来很不错啊,期待后续分享

点个赞,目前还在看vue方面的内容,等待开源向大佬学习一波。

谈又 #17 · June 09, 2020 作者
AilF 回复

vue我也是写这个项目的时候开始学习,大佬就算不上了,就自己够用😂 ,感谢你的肯定❤ ,vue我也在持续学习。

谈又 #18 · June 09, 2020 作者
雨夜狂奔 回复

感谢你的肯定❤ ,我得好好花时间整理😂

哈哈 我来瞻仰下 猜猜我是谁😂 😂 😂

学到了,希望早点开源😄

很赞啊,希望早点开源

谈又 #22 · June 12, 2020 作者
yanghp 回复

也很高兴给你有所帮助😂

谈又 #23 · June 12, 2020 作者
活到自由 回复

感谢肯定,一步一步来😄

24Floor has been deleted
谈又 回复

楼主加油,等待开源的第5天

期待开源。但看截图有些晕。有个疑问:添加用例里的多接口模式是怎么样的?有2种场景需要用到多接口,第一种是同个接口不同的请求参数,比如测试登录的接口,需要测试已注册、未注册账号,正确密码、错误密码等情况,但这些其实都可以归为同一条用例,也就是我在一条登录的用例里多次请求登录的接口,但传不同的参数;第二种是前后接口依赖,比如需要先请求第一个接口拿到返回值传给第二个接口,看到介绍好像有提取为全局变量,但很多时候提取的返回值的使用频率很低,只在该用例里用的到,支不支持在同个用例里的多个接口中把前面接口的返回值提取出来传给后面的接口?最后导入接口希望可以加入导入swagger的功能

谈又 #27 · June 16, 2020 作者
lldxwn 回复

第一个场景(测试登录):同一个接口,不同的参数,一个用例中可以有多个步骤(步骤即为一个接口),假设你的登录只调用一个接口,每个步骤填写不同参数即可组成一个用例就好,但是我觉得这个方式虽然可以实现,但还不太好,我有考虑加一个数据驱动的模块,然而实际场景一个app登录业务却不止掉了一个接口(有是否注册,请求验证码,登录等),所以针对不同参数话的话,目前只能是一个接口,多接口不同参数话,太复杂了设计起来;

第二个场景,这个我是支持的,无论你是哪个接口,只要在这个接口在同一个用例中,我都可以取到值,比如第4个步骤接口body中bookId,想要第1个步骤接口的返回值的中的同字段的值,写法就是第一输入框就是bookId,第二个输入框填$bookId,选择这个字段的类型(这里假设int),勾选取值框,选择接口ID,填写第1个步骤接口的接口ID,选择下标(因为可能第1个接口步骤产生的取到bookId有多个结果,我这里结果都是List的类型,所以通过下标取对应的bookId)
第三个点:导入swagger,目前我们公司没有这个场景,我可能不太会开发这个。
最后,也感谢你看完后提出的疑问。

谈又 #28 · June 16, 2020 作者
yanghp 回复

谢谢😂 ,这个月因为一些事情,需要处理尘埃落定后,才有心思整理😭

之前也用过一些接口平台我觉得有两点感觉可以增加一下:
1.上传接口文档后,自动生成接口,如果一个个填太费时间了;
2.对非空参数可以自动生成非空检查的用例,对Int参数生成输入string的用例..

谈又 #30 · June 17, 2020 作者
穷疯了 回复

谢谢你的建议😀
1、关于第一点,接口一个一个添加麻烦,这一点我有涉及到,就是有一个接口批量导入的功能
2、关于第二点,不是很明白;非空参数这一点,就拿我工作环境来说,其实大多数在开发的时候,接口文档定义不明确,很多时候依赖抓包去看字段,所以我这里在添加接口的功能中没有添加非空参数的一个判断。

K · #31 · June 17, 2020
Author only

感谢回复。数据驱动确实有必要,还有类似的就是自定义函数功能,比如类似于注册这种功能,自己定义一个函数功能,每次执行用例时随机生成一个新的手机号取注册。swagger文档导入这个功能并不难,现在用swagger的公司挺多的,后端给接口都是直接给swagger,做个一键导入就很方便,可以了解下。那个模块功能我觉得把它独立到菜单栏和’项目管理‘、’接口管理‘、’用例管理‘并列会更方便,然后在’接口管理‘、’用例管理‘页面上的搜索做个过滤筛选,加两个下拉选框’所属项目‘、’所属模块‘,这样会更方便些。

谈又 #33 · June 17, 2020 作者
lldxwn 回复

数据驱动,我在设计这个平台的初始的时候,就考虑上,只不过一直没有好好设计;自定义函数,如果需求量少的话,可以配合请求参数的类型用;swagger这个主要我的工作环境,我接手的时候没有规范的文档,所以也没有swagger导入的需求,导入规则匹配上应该不难;接口管理、用例管理,侧标栏有个全部项目,展开其实就是项目和模块,可以通过这个筛选。

Leo · #34 · June 17, 2020
Author only

为什么总是无止境的搬来搬去。 是为了绩效嘛、麻烦多做点创新的东西。low!!!!!!!!!!!!!!!!!

谈又 #37 · June 19, 2020 作者
水乡人 回复

你好,不知道你处于什么而说的这些话,这些东西做的过程中都是自己亲自设计,很多细节都是都是自己使用时改良,花了很多心血和不计其数的熬夜,没有理由你上来就否定一个人努力的过程,不知道你处于什么目的;抱着学习的心情我欢迎,抱着恶语的态度,我也祝你生活愉快。

很实用,期待大佬开源

大佬,业务用例里, 接口之间的参数传递是如何做的呢

liya678 回复

把每个接口产生的结果保存好,通过接口id去取值,$用来标识字段,通过这个字段找到对应接口的结果字段

谈又 回复

你这里说的是公共前置用例吗, 如果我们每个用例 断言时, 都会调用另一个接口来验证, 比如 注册接口, 断言注册接口返回的值后,我们会调用登录接口来辅助验证 是否是注册成功 , 这种情况 支持吗,

大赞一个,业务很类似。似乎当业务用例里面涉及多个接口请求去取前置数据时还是有一定的局限性,比如我要从其他接口取一组数据用于另一个接口测试,但是有可能我取不到,我就会去做新建数据操作给自己造数据测试,这时感觉局限性就出来了不能做判断走分支控制测试流程?然后断言部分,我们的业务可能会涉及根据请求的入参类型,去断言得到具有特征的response(或者其中某个字段),不单单是断言数据,还有可能断言数据逻辑,似乎看起来也不能很好支持?有过这方便的拓展想法么?

谈又 #43 · June 22, 2020 作者
liya678 回复

首先断言是针对单个接口执行结果的断言,如你所举例的,注册流程,只要你在一个用例中在增加一个登录接口步骤,就可以验证是否注册成功。我支持用例id和接口id,也就是说公共用例执行结果我也会进行保存,只要填写上对应的id就可以取到这个结果。

谈又 #44 · June 22, 2020 作者
Tarng 回复

感谢你的肯定😀 , 在一个用例中,每一个步骤的前置用例(我这里的前置用例必须是一个单接口的用例,因为如果一个用例里面套了前置,多起来,我没法溯源按照顺序执行,有尝试过树,但是太复杂了),只要填写了,我都会运行,可以拿到你想要的结果值,通过【用例id】去取,这里的局限性你方便举个栗子吗,你大致意思我能明白,但是实际栗子我更能准确回答;断言,我明白你说的意思,一般数据逻辑可以通过其他场景去验证,比如我下完单了,可以在收货那边查看是否下单成功这个逻辑;我这里设计的时候,考虑的是对单个接口的结果断言,我有想过接口返回值和数据库sql语句查的值做对比,拓展就是不好把控前端的显示(内容太多,显示设计真的不好看😂 ),后端加个逻辑是没有问题。

谈又 回复

确实,你的校验到当前接口的返回就为止了,而我们可能还会调用其他接口去验证当前接口的结果,做一个业务闭环。其实最主要的问题还是数据驱动的引入,不能一个接口只写一个断言去处理当前接口所有的测试场景,得一种场景写一个断言。如果中途能引入一些自定义函数或支持插入自定义步骤,比如随机数,字典、列表等数据二次处理再组装就更好了。

谈又 #46 · June 22, 2020 作者
Tarng 回复

接口A;接口B;接口C
那我可以理解为你的意思就在接口A的断言部分某b字段运行了接口B当预期,某c字段运行了接口C当预期,然后填充了这个预期值;如果你在断言里面加一个接口,是不是也要在那个接口中加断言,这样子的逻辑会显得复杂,前端也不好规划,不易呈现;换个思路,就是多加了一个或者多个接口其实也可以达到闭环的效果,本质是运行接口。
随机数这种自定义函数,需求量不大的话,可以在接口的某个字段选择一下这个类型,后端处理这个类型逻辑就好了。

我是这么做的,都去除空格,转成utf8字符串,用jsonpath的语法匹配断言

谈又 #49 · June 22, 2020 作者
Eden 回复

我这边的断言一部分逻辑是预期值需要填写类型,后端这部分逻辑如下

能具体些的写一下用到了哪些框架吗,比如请求接口用的什么,希望大佬能开源👍

谈又 #51 · June 27, 2020 作者
SuperYang 回复

框架就是标题写道的两个前后端框架,你想问我python用了哪些库是吧😂

你那个断言方式的话比较损耗性能,一个是字符串判断本身比较损耗性能,第二个是进入到最下面的断言的时候,需要走上面的判断,都走一遍。(另外第三个断言写错了“<”)

另外还要断言还需要考虑数据类型不一致的场景,所以我这边做的是都转为字符串形式,并且比较的断言为utf-8的字符集,防止中间因为json解析出现编码问题导致断言出错。
所以考虑的场景是:不同系统的响应给的编码,还有数据类型是需要考虑的,因为==判断符是判断值相等,如果一个是int数据类型,一个写在数据库里面的是字符串(数据库存储断言值),会出现断言出错。

谈又 #54 · June 28, 2020 作者
Eden 回复

感谢指正,已修复上线,我这边设计是这样的,只有断言通过,我才会把服务端返回的结果保存,所以比较的是实时的,而不是取保存后的结果去比较;
1、性能这一块,实际使用中,感觉不大,原因 1可能数据量没达到一定的量,2单线程跑用例(这一步主要防止数据污染),
2、[进入到最下面的断言的时候,需要走上面的判断,都走一遍]这个不就是把你需要断言的字段进行判断吗
3、数据类型你是担心服务端在我这边反序列化类型错误是吗,这一点我在封装请求服务端的这一层,加了一层,就是防止服务端的数据不规范,只要是规范的,就能反序列化,才有接下来的比较;"=="这一点我比较的就是两个值是否相等,预期值会转换成前端填写的类型,两个类型不一致也是断言失败的,这一步前端填写的原因,而不是往实际结果类型转的原因,我是考虑到有的场景就是想要他类型不相等。

落地效果咋样呢?

插眼,期待开源

谈又 #57 · June 30, 2020 作者
小酷 回复

这个问题,让我有种自卖自夸的感觉😂 ,你可以好好自己感受下,哈哈

支持一下!!!!!!!!

谈又 回复

我去体验了下,理性上来讲,基本功能是有了,只是比较粗糙;我最抗拒的一点是用例要一条条自己填数据进去,这个太浪费时间了,如果要在项目中使用这个平台,我想我是拒绝的😂

谈又 #60 · July 01, 2020 作者
小酷 回复

感谢体验,能否讲一下使用过程中你感觉粗糙得点,罗列一下,我这边可以看一下优化,每个人都有自己不同的操作习惯;
若这个用例只有一个接口,我可以弄数据驱动的方式,这样的话还可以增加导入功能;用例一个个填进去,这个是因为考虑到业务用例复杂性,多接口多操作,都是动态取值得;
用例不太好能做导入操作,不过也有用例复制功能;

谈又 #61 · July 01, 2020 作者
往事随风 回复

感谢支持,一起加油😀

请问楼主,Framework中有用到Django Rest吗?

谈又 #63 · July 04, 2020 作者
Joeylu 回复

没,INSTALLED_APPS如下

哈哈哈,似曾相识啊,点个赞~

等一手开源

排队等开源

大佬,定时任务怎么实现的?为什么不用crontab格式呢?感觉更实用一些

谈又 #70 · August 01, 2020 作者
test_ray 回复

实用这个根据你得真实环境来的,像我在得团队人数不多,怎么简单怎么来,怎么开发落地快怎么来;当时看了几个定时任务框架,我觉得实在搭建太麻烦了,给后续得同学,学习成本也高,不符合我当前得环境;所以就自己写了专门得定时任务,项目启动得时候这个time服务(我把这叫time服务)也会随着项目启动,时间自己设置多久检查一次,我设置了30秒检查一次;

大佬开源吗?跪求开源~自己设计毫无思路

需要 Sign In 后方可回复, 如果你还没有账号请点击这里 Sign Up