自动化工具 接口自动化测试平台

阿森 · 2018年11月06日 · 最后由 阿森 回复于 2018年11月15日 · 4087 次阅读

前言

又回到接口自动化测试上了,不用多说,接口测试的重要性,之前发布过一个工具,但是随着公司接口的增加,项目的增加,所有接口写在一起太难维护了,为了解决这问题,开发新的前端界面,来更好的维护接口自动化用例。

平台功能

1、接口管理,添加和维护功能。
2、支持接口的用例添加、维护、调试功能。
3、更丰富的断言类型。
4、支持定时任务,在任务管理中集成执行我想要执行的所有接口用例,这些接口用例是在用例管理中加入进去的。
5、更漂亮的报告展示,快速发现失败接口用例。
6、一些接口参数很难获取的,可以在参数管理中,通过查数据库、调其他接口、java反射(动态调用java方法)等获取。
7、新增业务测试功能-多接口实现一个业务流程。

整体架构

整个平台后端使用java开发,前端使用vue框架,采用前后端分离,完全脱离我们自动化测试中jenkins、testNG工具

应用 工具
服务端 springmvc + mybatis + mysql
前端 vue+vuex+axios+vue-router+element
发送请求及断言 rest-assured
报告 reportNG改版

界面功能展示

1、整个界面功能 分为项目管理-接口管理-用例管理-参数管理-任务管理-日志管理,先添加项目,在项目基础上添加接口,在接口上面添加用例,然后就是在任务管理里边执行我查询的所有用例,最后生成报告

接口管理

首页

项目管理页

接口管理页,通过选择项目跳转到接口管理,这些接口都是通过业务分组管理的。

接口详情、编辑页

接口调试页,根据公司内部接口特点,能够接口更方面的接口调试,免去各种加密方式,让开发和测试人员都能使用

用例管理

用例管理页,和以前其实没区别的,只是样式修改,能够同事执行单条或者多条用例,能够做前后置处理操作

用例管理编辑、调试、添加页,他能够调试用例,成功之后再添加,能够通过前置处理生成想要的参数,保证用例是动态值,能够像jmeter那样,正则表达式提取器那样,提取想要的参数,保存到参数管理里边,其他用例如果需要该参数可以直接获取,还有更丰富的断言类型。

参数管理

参数管理目的就是动态获取接口参数值,保证用例每次执行时都能成功,这里参数的取值方式总共分为:1、直接赋值,2、通过调用接口,3、数据库查询,4、通过java反射调用java方法 5、执行其他用例

任务管理

最终通过执行任务管理中的任务执行测试用例

日志管理

日志中,支持查看每个任务执行详情,发送邮件报告

执行报告页

最好,我想说,接口自动化,难点还是在数据准备上,想要每次用例都通过,就得要每次数据是动态生成的,通过各种前后置处理生成我们想要的数据。

共收到 26 条回复 时间 点赞

code是否可以开源?

期待开源😀

我就想请教一点,通过你这样一个自己造的轮子,做数据维护不会增加成本? 我举个例子,我要测试一个电商用户Coupon的查询接口getCoupon,并且测试查询“已使用Coupon的情况”。那么我需要的条件如下 -

#1 新建一个用户
#2 为新建用户领取一个coupon
#3 下一个订单,并且使用这个Coupon
接下来才可以来到target本身执行测试逻辑

那么通过你这个平台,如何实现No coding的测试数据准备?

lyu 回复

如果依赖不复杂,我们可以通过前后置处理就能解决,前置可以查数据库、调接口、查缓存、执行别的用例把数据保存到参数管理里边,别的用例用的话直接去拿就行, jmeter怎么用我们就能怎么用,也许会问为啥不用jmeter,因为他不好维护,不好管理,不好二次开发
如果依赖复杂,我们有业务测试功能,多接口实现一个业务功能,接口与接口的关联还是通过前后置来关联上的。

阿森 回复

意思就是你们这个平台还从Web端提供了前后置方法的入口? 比如创建一个Case的时候,有提供一个前置条件的表单,可以傻瓜式的选择“执行SQL”或者“调用用例id=15”这样的操作?

只是想交流一下,因为我之前也捣鼓过类似的平台,只是在资源(特别是人力资源)有限的情况下,我深深体会到这样还不如纯coding来基于jenkins做持续集成。 因为一旦项目有新的诉求,如果我采用自建轮子的模式,需要从后端开始将新的feature implement到前端,而且有可能会遇到很折腾的问题; 如果是以jenkins为中心的构建模式,要省去很多维护时间,从而把精力集中到测试用例本身。

再次强调,没有贬低的意思,只是交流。

楼主说的对,像JMeter那样~

lyu 回复

你用jenkins 就不需要造数据了,jenkins跟数据准备有毛关系啊,我不明白集个成有那么难吗

阿森 回复

我说jenkins是说一种模式,并不强调jenkins本身。因为一般基于jenkins构建体系,所有的东西都在代码里,所以要做数据准备也就是几个类的封装,起码不需要做前端的开发。 好吧,既然您的态度是这样,那交流可以停止了。

lyu 回复

你如果自动化只是你自个用的话,你可以写代码,一个接口写个类,相同的代码写无数遍,我们要的是所有测试人员都能够使用

阿森 回复

他可能也是所有测试人员都用,然而可能你们有几十几百人,他们只有2、3个人,这就是对平台作用的理解不同的原因了

仅楼主可见
阿森 #12 · 2018年11月07日 作者
Eward 回复

暂时不能开源的

不开源的话可以写下思路和一些使用到的工具啥。
不然也只能看看

阿森 #14 · 2018年11月08日 作者
徐汪成 回复

当你了解 rest-assured后,可能你也迫切想开发个工具,来代替天天写那些相同的脚本,除了数据不一样而已

lyu 回复

我来说说吧,之前我也想过捣鼓一个类似这样的平台,但后面想想,其实还是要看项目和公司规模,人力有限情况下,我也是觉得没必要搞平台,当时想着就算弄出来了,维护成本先不说,做的事情也就都那样~ 与其自已造轮子不如把现有框架和工具玩熟,提升产品质量和效率,所以我还是蛮赞同你的观点。

能做出这种平台,也是能力的一种体现,楼主加油^v^

Aaron 回复

是这样。 我上面也再三说了,不是在说这东西不好。我只是在请教问题,想看一下别人是怎么解决我当初遇到的一些问题。
好的代码结构,好的封装同样可以避免所谓的重复劳作。目前我的那一套框架虽然没有一个WEB UI,但是也只是维护数据和用例本身,不需要又去写什么重复的类,都是封装好的。这么说吧,我如果加一个DB把我的数据文件存起来,加个前端支持填写用例并把我们的数据和用例展示出来,那也和楼主这个平台差不多。不过这时候就会无端的多出很多开发成本。 正和你说的一样,人力有限的时候。这是灾难性的。楼主的团队规模大,所以上面是想请教我之前遇到的一些问题,看他们是否有解决方案吧。

阿森 #18 · 2018年11月08日 作者
lyu 回复

👍 👍 👍

lyu 回复

嗯,大家多多交流,彼此互相学习

槽神 回复

https://docs.asura.pro/ 这个是开源的,了解一下

欧几里喵 回复

谢谢,设计思路我清楚
我是看楼主这个技术栈跟我的平台一模一样,想着直接集成

阿森 #22 · 2018年11月12日 作者
槽神 回复

一样,咱们可以共同交流,开源的话暂时不会的

楼主P7吗?

阿森 #25 · 2018年11月13日 作者
小萨 回复

担当不起,我只是想和大家分享交流,不谈这个,(^o^)/~

可以视为简化版的爬虫平台.
对于可进入接口自动化测试的阶段的项目/产品来说,测试结果的累计/对比的价值更高.
将版本的稳定性可视化对于开发和测试团队都有很大的激励作用.

阿森 #27 · 2018年11月15日 作者
一路漂泊 回复

提高整个测试团队的效率这是最重要的,方法有很多,一味的追求自动化有时会死的很惨

需要 登录 后方可回复, 如果你还没有账号请点击这里 注册