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

可以考虑开源

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

不好意思，因为这星期准备开源，这两天忙着优化、补注释、写 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 就好了，如果是要换域名，直接去环境里面改就好了，如果是要同时使用多套测试环境且又不想重复建用例，那就只好等后期版本迭代啦～

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

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

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

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

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

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

看了一下你的建议，其实大部分是我后期打算做的
1、持续集成方面的对接，我把执行器独立出去就是为了后期分布式啊，集成 jenkins 啊，等等做准备，这也是我暂时不用框架的原因，在满足现有功能的情况下，减少没必要的负重
2、流程问题主要是在用例集解决，用例集有执行优先级设置、用例集变量设置，如果你想引用其他用例集信息，也可以使用复制功能，直接把其他用例集里面用例信息弄过来就行了，至于多个用例集一起运行，任务里面就可以添加（忘记截图了），整个系统的关联是：任务下有多个用例集，用例集下有多个用例，每个用例关联 api，api 关联域名
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 真的很重要。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

附加修改排版的断言显示：