接口测试 自研接口自动化测试平台收集建议 (已更新 v1.2.1)

kong · 2019年08月02日 · 最后由 kong 回复于 2019年10月18日 · 1259 次阅读

作者想说

之前找过一些类似的开源项目,大部分都需要修改代码才能支持在复杂环境中做测试,然而这些开源项目都是 python!额。。。我并不怎么擅长,想了想,与其等着别人做出来,倒不如自己弄一个,把所有可能的场景都考虑到,还能为以后持续集成测试扩展打好基础,这一想,便开始埋头苦干!如今这货准备开始出去见人了!想收集一下建议,优化一波再放出去,如果各位有做接口测试的迫切需求,或有非常想要的功能可以留言!时间能力的允许下,我会在下次开源的时候加进去,顺便吐槽一句,前后端分离的情况下,solo 项目真心累,尤其是我这种前端渣渣,所以界面丑请多多包涵!

相关文章

开源篇:https://testerhome.com/topics/20155

环境

JAVA 1.8
MYSQL
测试管理平台为 war(Spring+SpringMVC+Maven)
定时执行为 jar(Spring+Maven)
ps:该项目测试管理平台(包括用例调试)与定时执行是分开的,可分开部署运行

项目介绍

环境管理

  • 增删查改测试环境地址

AutoTest_environment

接口管理

  • 增删查改接口 API 地址,并关联对应测试环境

AutoTest_interface

用例管理

  1. 增删查改用例信息
  2. 请求方法支持:get、post(form)、post(raw)
  3. 断言方法支持:等于、不等于、包含、不包含、正则匹配、以。。。开始,以。。。结束
  4. 请求头值、请求内容、断言信息、用例变量都支持系统给定或自定义扩展函数引入
  5. 支持用例内全局变量使用
  6. 支持手动执行用例并返回结果,可针对用例进行调试
  7. 支持复制用例

AutoTest_interfaceCase_list

AutoTest_interfaceCase_detail

AutoTest_interfaceCase_result

测试集管理

  1. 增删查改测试集信息
  2. 用例管理:
  3. 支持增删查改关联的测试用例及其他执行信息
  4. 支持为每个关联的用例信息绑定、引入测试集全局变量
  5. 支持手动执行测试集并返回结果,可针对测试集进行调试
  6. 支持复制测试集里面的用例信息到其他测试集里

AutoTest_testSuite_list

AutoTest_testSuiteWithCase

AutoTest_testSuite_bind

AutoTest_testSuite_result

产品项目管理

  1. 增删查改产品项目信息
  2. 测试集管理:增删查改关联的测试集,可批量添加测试集到指定任务里

ATest_productList

ATest_productWithSuite

任务管理

  1. 增删查改任务信息
  2. 测试集管理:增删查改关联的测试集
  3. 支持复制任务里面的测试集信息到其他任务里
  4. 支持设置前置任务,在执行任务前执行,并分享所有测试集变量值到本次测试任务里执行使用(注意变量名不要重复,否则会被覆盖)

AutoTest_task_list

AutoTest_task_result

替换管理

增删替换信息(替换环境地址、替换用例变量值)

ATest_replace

函数说明

编写接口用例、赋值测试集变量时可调用的关键字

AutoTest_function

共收到 36 条回复 时间 点赞
kong #1 · 2019年08月02日 Author

1、精髓是函数关键字(有些借鉴 jmeter 函数)
2、没做数据库操作这块,不知道各位做接口测试用数据库的多不多
3、校验的详细信息都有显示,就是界面。。。丑,完整的报告这版没做,不知道各位做接口测试的报告显示要求有没有硬性规定
4、这是第一版的功能,后期继续迭代

附加修改排版的断言显示:
result

测试管理平台为 war(Spring+SpringMVC+meavn)
定时执行为 jar(Spring+meavn)

感觉你说的忒乱呢……
Spring+SpringMVC+mybatis?
定时任务用 spring-quartz?
构建发布基于 maven 管理?

源码放出来学习下啊。大佬

和我做的挺像。java+spring+mysql 整体架构也很像。可以交流交流。

我的执行是用 jenkins,报告也是 jenkins 插件 allure 实现,没有自己写报告。用界面操控 jenkins

kong #6 · 2019年08月02日 Author
槽神 回复

这个项目分两个 project:
第一个就是图片中显示的(没用 mybatis,用 jdbc),接口测试平台,用于设计编写、调试、管理用例;
第二个是定时执行任务(ScheduledExecutorService),暂时没用框架,maven 打包 jar,相当于一个独立的执行器(前提是配好数据库连接)

最后:这才发现 maven 我居然拼错了。。。。😂

kong #7 · 2019年08月02日 Author
王十三 回复

会放的,这几天先修修 bug,优化一下自己没想到的场景问题,没什么要追加功能的话,就打算下星期放出来(身为渣渣,我也瑟瑟发抖😂

kong #8 · 2019年08月02日 Author
徐汪成 回复

看了一下,菜单功能真的好像!!!我都吓到了,还好仔细一看,有些东西不同,不然我真以为我从哪 copy 了一个项目过来。。。
首先你的界面比我好看多了,看来以后真的要花点时间在这界面上了😂 我的项目可能更注重用例设计这块,从函数说明能看出来,为了能适应我们公司的超级变态又不规范的环境,不择手段!哈哈哈哈~~~
不过,像我们这种中小型公司的测试,很少人懂技术类东西,稍微复杂一点的系统,跟业务无关的,连看一眼的几率都很低,所以做这平台的初衷也是为了降低学习成本,操作能简单就简单,不然自动化这东西,就只能嘴上说说,完全推不起来,唉~

kong 回复

我这个是很多年前做的了,技术栈还是很早之前的 ssh 框架 + jquery。

现在基本很少弄了。
不过还好这东西在公司的好几个部门和项目都用起来了。

kong #10 · 2019年08月02日 Author
极风 回复

哈哈,之前我也考虑要不要用 testng 的,但想想还是先把核心问题解决,等之后版本再弄,感谢推荐神器,搜了一下,感觉比 testng 方便,尤其以后集成 jenkins!

kong #11 · 2019年08月02日 Author
徐汪成 回复

真好,公司能推的起自动化,那就是对自己最大的鼓励了

功能做得挺全的,基本上大部分核心功能都有了。但个人比较好奇,这个平台的相比其它已有平台,独特的点是什么?或者说哪个点其它平台没满足,而这个平台可以满足?

后续周边功能方面的建议(仅供参考,具体还得看公司实际需要):
1、和持续集成的对接(如支持通过调用指定接口触发测试任务执行、支持自动发送测试结果到邮件/钉钉)
2、对流程类用例更友好的支持。从介绍上看,一次接口调用为一个用例,那对于流程类用例(调用多个接口的),是怎么处理?如果用用例集管理,那 3 个核心流程的用例要变成一个用例集一次性执行,是否可以配置?
3、对于多项目的支持(每个项目有自己的独立的环境配置、用例集、定时任务等)
4、数据报表(如趋势图、饼图)。这个领导会比较关注

另外,通过平台降低技术要求是一个挺好的切入点,但如果要把自动化坚持下来,逐步让测试关注技术、推动规范统一还是需要的,要不维护用例会累死,自动化发现不了什么问题也会导致大家不认可。

陈恒捷 回复

大佬说的很不错。我最近也在思考这方面的东西。

  1. 前端项目首页要炫,这也是各个收费的平台共性吧。
  2. 接口设置操作要和 postman 主流靠拢,包括断言的设置(postman 是直接写脚本断言)。
  3. 接口要有清晰的层级关系,比如大佬所述的用例集(这部分平台内好几个开源的接口测试平台已经有所实现,且实现的不错),这部分其实 postman 也有,叫 collections。
  4. 要有历史数据或者日志,这部分 postman 也有,eolinker 也有历史数据,日志的话见仁见智。
  5. 能进行简单的性能测试,postman 也有,部分平台内的开源平台也有。
  6. 要有上传下载工作,并且最好格式和 postman 对接,或者和 httprunner 对接,最好不要自创一套规范(成本高)。
  7. 接口测试报告要炫(allure 貌似不错)。性能测试报告另算。
  8. 要和公司内部员工数据对接,如登录使用域账号(钉钉),邮件发送配置公司邮箱。
  9. 权限划分,这个比较基础了。
  10. Jenkins 的集成。

postman 是一个标杆,比如它还有切换 workSpace 的功能(eolinker 也有),都非常值得借鉴。还比如 postman 能自动记录接口请求返回的 response 的 cookie 数据,这些细节令我深思。

另外,专业和优秀的一套 UI 真的很重要。

kong #14 · 2019年08月03日 Author
陈恒捷 回复

不同点其实是有考虑的,目前这个基础版可能不怎么能看出来,毕竟基础问题大家都是有考虑到的,剩下比的大概就是附加功能了

看的开源系统不是很多,以下问题是之前看过的系统在不修改代码的情况下是没法解决,也不知道其他系统能不能解决:
1、针对跨域拿身份认证问题,这系统在设计用例时就关联在接口下面,所以用例集添加用例时便可任意请求,无需担心跨域问题,并且在用例集里加了变量,每个用例返回的信息可以赋值到变量里,就可以使测试集里其他用例也可以调用,后期考虑要不要搞个封装功能,方便管理
2、针对返回格式不统一且未知格式情况下的问题,特地加了截取函数来针对这问题,尤其是一些关键信息需要在 html 里面获取。。。
3、针对用例维护成本问题,我把一个接口用例拆分三部分管理,一个是环境(域名),一个是接口(api),一个用例信息(请求头、请求参数、断言),域名、api 这块维护成本没什么问题,主要是用例信息这块,目前在用例里面变量这功能,不仅为了灵活,还为了减少测试数据的冗余,降低数据的维护成本,因为经验不足,还不知道在维护接口用例这块各位还有什么痛点,希望能提供建议,后期考虑优化进去
4、针对系统学习成本这块,我主要是做减法操作:没必要的管理尽量不单独弄个页面,也尽量不分开操作;能重复利用的数据就利用,没必要操作冗余,尽可能让人在设计用例有连续性(我也是很讨厌在我写用例的时候被打断的),例如,这个系统在用例设计界面,一个页面就可以解决,有什么特殊赋值的就拿函数解决(函数说明提供),不用去设置什么东西

看了一下你的建议,其实大部分是我后期打算做的
1、持续集成方面的对接,我把执行器独立出去就是为了后期分布式啊,集成 jenkins 啊,等等做准备,这也是我暂时不用框架的原因,在满足现有功能的情况下,减少没必要的负重
2、流程问题主要是在用例集解决,用例集有执行优先级设置、用例集变量设置,如果你想引用其他用例集信息,也可以使用复制功能,直接把其他用例集里面用例信息弄过来就行了,至于多个用例集一起运行,任务里面就可以添加(忘记截图了),整个系统的关联是:任务下有多个用例集,用例集下有多个用例,每个用例关联 api,api 关联域名
3、在设计这系统的时候,是有设计过产品、项目的,不过。。。最近工作比较忙(其实是懒),先弄个核心功能就好了,其他的下版本再弄,哈哈
4、同上。。。

最后,维护用例成本也是我考虑的重点问题,推动规范统一自然是最好的选择,但现实是残酷的,理想永远在书本上,不能把希望完全寄托在外部(开发、产品、运营、老板等)身上,在做好自身时,降低外部因素对用例成本的影响,才是做这系统的初衷(也不知道能不能成功,当个实验)

kong #15 · 2019年08月03日 Author
zyanycall 回复

1、前端真的是我弱到不能在弱的点,jquery 还是为了做这个项目才接触的,打算后面自己慢慢弄,反正不急,我这项目本身就是开源的,没打算商业化,哈哈哈
2、断言我有 7 个方法:等于、不等于、包含、不包含、正则匹配、以。。。开始,以。。。结束,也不知道够不够用,不够用后面再加
3、整个平台的关联是:任务下有多个用例集,用例集下有多个用例,每个用例关联 api,api 关联域名,层级关系必须得有,不然怎么管理
4、历史测试数据我一直有保存,就是不知道该怎么处理好,存太久了又占地方,不存着有浪费,反正这一版任务结果里面都是有历史数据的,具体优化等后面再说,日志目前没弄,我都把报错抛到控制台里,后期再看要不要弄个
5、性能测试啊,嗯,我是有考虑过,但并不打算在平台做性能测试,利用平台里面的用例数据生成性能测试脚本,倒是我想做的,毕竟不浪费用例数据是我目的之一,我不知道其他平台目的是为了啥,我做接口自动话测试平台最初始的目的是为了开发提交代码后,能自动执行接口用例,来达到回归测试,所以还是交给更好的工具去处理吧,我就不造轮子了
6-10:都是考虑过的,后期会慢慢加上去,一个人利用空闲时间 solo 项目有点慢的,而且还要保证不能猝死的,慢慢来慢慢来。。。

最后,关于独立的设计与共享这个问题是在设计系统的时候考虑过很久,有些东西不是照搬就好了,还要考虑实际应用场景,唉,很头痛,先放着(懒!)至于自动记录返回的 cookie,是不错的思考点,毕竟比起人工赋值,自动总是方便许多!(唉,又要加个需求了,泪奔~)

  • 有两个不明白的地方请教下:
  • function a() 这里是怎么实现的?
  • 关于任务调度这块是如何实现的?一个测试集包含多个测试场景,一个测试场景包含多个场景和用例,一个用例可能又会关联另外一个用例。
  • 关于功能建议:
  • 可以拆分数据维度,比如以项目拆分数据。
  • 每个项目都有自己的加密方式,对于加密这块平台如何统一处理?
  • 系统是否支持回调第三方应用。
  • 有些系统访问接口需要切换绑定不同 host,这个平台如何解决?

同在构思改造方案,向大佬学习

kong #18 · 2019年08月06日 Author
shandongdong 回复

不好意思,因为这星期准备开源,这两天忙着优化、补注释、写 readme,各种头痛的组织语言,现在才回复你

关于问题
1、function a() 这里是怎么实现的?
答:截图里面,那 v1 变量值是 js 内容,我用来做测试的数据,可以用 ${_Js(${VAR(v1)})}执行取值
2、关于任务调度这块是如何实现的?
答:
1)因为是刚开始,这版需求核心不是任务调度这块,所以还没研究框架,先用 ScheduledExecutorService 过渡一下,之后版本再迭代
2)先说明一下这个平台的关联:一个任务下关联多个用例集,一个用例集关联有多个用例,每个用例关联 api,api 关联域名,测试场景和用例间的关联,可以通过测试集执行优先级及测试集变量解决,所以我没增加其他流程(或者有具体测试场景问题,欢迎讨论,我看看能不能解决)
3)因此定时执行的东西也很简单,先找出符合条件的任务 list,遍历任务 list 开线程找关联的测试集 list,遍历测试集 list 开线程找关联的用例信息 list,用例信息 list 根据优先级遍历执行请求和断言并保存信息(不知道这种方式有什么弊端,欢迎讨论学习)

关于建议
1、哈哈,很多人都讲过,我前面也有说到,后面会有的
2、加密方法可以自定义函数,我弄了个类,用 java 反射机制,动态调用里面的方法,也可以用 JavaScript 文本,或者脚本文件,java 自定义类和 JavaScript 脚本只支持线下更改内容并放到服务器里
3、额。。。不知道你具体指的是什么,如果是请求断言异步回调的话,这个问题倒是值得好好思考,如果是发送回调的话。。。就不太明白想要断言或处理什么东西了,如果是扩展第三方功能的话,之前有说过,后面会有的(如果有其他问题,可是具体说明一下)
4、这个场景也不太明白,如果指跨域请求访问的话,可以看看平台关联,测试集里面支持不同 host 请求,如果是要支持测试任务里有相同 api 不同域名的请求的话,可以建两个相同的 api 和用例,api 分别关联不同的 host 就好了,如果是要换域名,直接去环境里面改就好了,如果是要同时使用多套测试环境且又不想重复建用例,那就只好等后期版本迭代啦~

19楼 已删除
20楼 已删除
kong #21 · 2019年08月06日 Author
守望@天空~ 回复

加油,希望能给你带来灵感!向大佬学习 +1

仅楼主可见

不知道大佬们对测试环境切换有没有什么好主意,现在一直纠结怎么在多环境下能节省接口 case 的维护成本

kong #24 · 2019年08月07日 Author
chenyouan 回复

首先对图片内容赞一个,我最初全凭一个数据库关系表格设计系统,灵感一来,需要实现什么功能,直接一个 txt 记着,后来慢慢的,功能越来越多,如今这几天就开始还债的慢慢长路,开始整理功能图了😭 😭 😭

对于兼容其他工具的问题,其实有打算后面版本加导出 Jmeter 脚本的功能,不过 swagger 我倒不太想做导出它,根据它进行导入测试数据倒是我想做的,因为在我看来,swagger 是属于接口测试的上层活动,毕竟接口测试还是基于接口 api 文档的,如果反过来约束,反而不太适合,就算是 ttd,也是从最基本的单元测试起步,中间插一脚反而觉得会拖慢脚步(没怎么用过 swagger,也不知道接口测试数据导出给 swagger 有没别的什么用处?)

最后,关于在接口自动化平台加执行性能测试这个问题,我的看法是不要,性能测试最重要的是策略及分析,至于写脚本,在现有的工具下,基本上可以不用写代码就可以解决问题;就算要搞个全方面测试,完全可以集成个工具,没必要给自己增加麻烦,还不如花时间做好接口自动化核心的功能,当然啦,一般接口测试是性能测试的上层活动,利用测试数据导出性能测试脚本也是不错的思考点

kong #25 · 2019年08月07日 Author
CleverMing 回复

1、对于 case 的处理,我的做法是把一个 case 所有组成元素全都拆开分析,复用率高的统一抽出来管理,这样,只要数据一改,就可以动全部相关联(当然,细节问题还要根据实际情况进行思考)

2、对于多环境的问题,我的做法是最后节点进行确定(测试任务设置),目前还没实现,有个想法是,测试任务设置的时候可以根据环境地址进行替换,否则使用默认环境地址

仅楼主可见
kong 回复

第一点似懂非懂 0.0
1.所有组成元素是指 case 里面的每一条接口请求,还是说接口里的每一个字段参数化
2.对复用率高的抽出来管理,不知道具体是怎么管理,是把大流程里的小流程抽出来,组成 case 嵌套的形式?
3.其实多环境场景下,主要是数据不一致的问题,感觉目前多数也只能是一套环境一套数据,不知道有没有多环境同步数据做的很好的案例

kong 自研接口自动化测试平台开源篇 中提及了此贴 08月09日 14:48
kong #29 · 2019年08月12日 Author
CleverMing 回复

1、以最小单位来分解元素,例如最小单位是接口请求的话,就有请求域名、api、请求头、请求参数等,看看哪个可以统一管理
2、复用率高的有请求的元素,也有常用请求流程(如:登录),元素管理可以参考上一条,流程式管理具体管理要根据你系统设计来思考
3、目前想到两种:
1)准备多套测试数据,取值用参数化,执行的时候,根据选择的环境来决定用哪套测试环境数据
2)把测试环境的数据同步一下

kong #30 · 2019年08月12日 Author
chenyouan 回复

已经开源了,初始 beta 版,欢迎试用提建议~

kong 回复

测试集里面支持不同 host 请求? 这句话没明白,接口测试服务器如何支持相同接口域名访问不同的环境?

比如现在业务测试的时候会通过切换本机 host 来实现访问不同环境,那么接口平台服务器如何在运行期间绑定不同 hosts?
如果修改服务器 hosts 肯定也不行,一旦有并发的话就没法运行了

kong #32 · 2019年08月19日 Author
shandongdong 回复

哦,可能我的叫法跟你不一样,我用 jmeter 的界面来跟你解释一下我的环境(域名、host)、接口(api)的分别,不过大概明白你指的是什么了,如果是相同域名切换不同服务器 ip 的话目前这个平台还没支持,如果测试必须的话,建议使用 ip 来代替域名访问,或者弄个转发服务器,通过转发规则配置来实现切换(这里涉及到运维部署的活了,详细的我也不是很清楚,有兴趣的话可以百度一下)

kong #33 · 2019年08月29日 Author

新增功能
平台:
替换信息:替换对应环境地址或替换对应用例的用例变量值(包括任务前置里面的用例)(常用使用场景:测试环境切换)
产品项目管理:按对应产品项目名管理测试集

执行器:
增加按任务名执行开启循环的任务

kong #34 · 2019年10月10日 Author

如果比较的话,建议用 postman、jmeter、robotframework 这三个工具做接口测试进行比较,看看你的平台还欠缺哪些比较好的功能需要补足,顺便可以思考一下自己的平台比这些免费产品又多了什么更吸引用户使用的功能,然后再考虑一下安全隐私性问题

楼主收徒弟吗?我真的想跟着写,有代码基础学了 1 年的开发,现在转测试了

kong #36 · 2019年10月18日 Author
Terrydgl 回复

这个不用拜师啥的,按照软件工程的步骤,先调研收集问题定好需求,然后开始拆功能,设计整体架构、数据库等,然后开始计划,先做啥再做啥,最后一个模块一个模块的功能完成拼起来就好了,具体功能实现的思路还是需要多做项目多思考多总结才会有感觉!
如果刚开始做开发,就咬着牙继续走下去,测试往深的走,不比开发简单,但往往比开发地位低!
题外话,我从学校就开始接触 java,基本保持每年至少有个自己写的小工具或项目,一直到现在差不多 6 年了,因为断断续续的,不是从事开发,所以至今感觉仍在基础徘徊,学 1 年的开发,应该只能算是踏入这个门,还是多做些小项目练练感觉,一下子整大了会吃不消

可以考虑开源

kong #38 · 2019年10月18日 Author
大奇 回复

已经开源了,在另一篇开源篇里面有详细说明

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