前言
又回到接口自动化测试上了，不用多说，接口测试的重要性，之前发布过一个工具，但是随着公司接口的增加，项目的增加，所有接口写在一起太难维护了，为了解决这问题，开发新的前端界面，来更好的维护接口自动化用例。
平台功能
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、执行其他用例
任务管理
最终通过执行任务管理中的任务执行测试用例
日志管理
日志中，支持查看每个任务执行详情，发送邮件报告
执行报告页
最好，我想说，接口自动化，难点还是在数据准备上，想要每次用例都通过，就得要每次数据是动态生成的，通过各种前后置处理生成我们想要的数据。
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 那样~
阿森
回复
我说 jenkins 是说一种模式，并不强调 jenkins 本身。因为一般基于 jenkins 构建体系，所有的东西都在代码里，所以要做数据准备也就是几个类的封装，起码不需要做前端的开发。 好吧，既然您的态度是这样，那交流可以停止了。
不开源的话可以写下思路和一些使用到的工具啥。
不然也只能看看
lyu
回复
我来说说吧，之前我也想过捣鼓一个类似这样的平台，但后面想想，其实还是要看项目和公司规模，人力有限情况下，我也是觉得没必要搞平台，当时想着就算弄出来了，维护成本先不说，做的事情也就都那样~ 与其自已造轮子不如把现有框架和工具玩熟，提升产品质量和效率，所以我还是蛮赞同你的观点。
能做出这种平台，也是能力的一种体现，楼主加油v^
冷月醉夕阳
回复
是这样。 我上面也再三说了，不是在说这东西不好。我只是在请教问题，想看一下别人是怎么解决我当初遇到的一些问题。
好的代码结构，好的封装同样可以避免所谓的重复劳作。目前我的那一套框架虽然没有一个 WEB UI，但是也只是维护数据和用例本身，不需要又去写什么重复的类，都是封装好的。这么说吧，我如果加一个 DB 把我的数据文件存起来，加个前端支持填写用例并把我们的数据和用例展示出来，那也和楼主这个平台差不多。不过这时候就会无端的多出很多开发成本。 正和你说的一样，人力有限的时候。这是灾难性的。楼主的团队规模大，所以上面是想请教我之前遇到的一些问题，看他们是否有解决方案吧。
担当不起，我只是想和大家分享交流，不谈这个，(o)/~
可以视为简化版的爬虫平台.
对于可进入接口自动化测试的阶段的项目/产品来说,测试结果的累计/对比的价值更高.
将版本的稳定性可视化对于开发和测试团队都有很大的激励作用.
谢谢分享
lyu
回复
也遇到这样的问题了， 想问下您现在有解决办法了吗， 我们目前是 rf 做的接口自动化， 大部分的接口为了造数据，以及对结果的正确性校验 需要调很多接口，目前用 RF 来维护想对比较稳定， 但是大佬们想找 postman 这种工具来替代，理由门槛低，但是我觉得 postman 对单个接口调试是很方便 的， 但是对业务流实现起来 受平台本身的一些限制 ，用例不能复用，那每次用到都要新写一个，这样后面维护起来应该会很麻烦，
看过不少接口自动化测试平台，但是都没能满足目前的需求
1、不支持针复杂逻辑的校验，比如对应答报文所有字段的校验，包括字段是否必须、类型校验、非空校验、格式校验，而且应答报文层次深，最多可达到 8 层
2、测试报告太简单，要么 pass 要么 fail，而且 fail 原因描述太简单。
3、项目多，各种各样的接口也多，请求参数如何准备，有些接口之间有依赖
作者有开源打算，让社区共同维护更强大
这个开源了吗