其实你的源码我看过……api_automation_test 的源码我也看过。
api_automation_test 不再维护了，我就多说几句好了……api_automation_test 的前端代码其实是比较烂的，同时我怀疑并不是一个人写的，更像是集大家之所长的作品，前端的风格我发现就有两种吧，具体表现是一会儿用 axios，一会儿换个界面就都是 ajax。相信你借鉴了也应该发现了。同时 api_automation_test 没有理解 vue 的组件化的思想，太多的前端代码都是重复的，怎么说呢，代码没有解耦。
你的代码我就不在这里评价了。说一下你提的二次开发吧。
在你这个平台上二次开发，我担心会不知不觉把 api_automation_test 已经实现的功能再自己实现了一遍。

有个 bug 吧，项目中我更新了用例，但是项目的最后更新时间竟然没变。
因为我看过原版的 automation_test 也是社区的开源项目吧，觉得你这个翻版的其实没超过原版的功能，或者还误删了几个原版很好的功能。
比如：

1. 同一个项目，不同的自动化测试用例，要复用同一个接口，原版是有接口选择界面的，或者选择到有的，或者新建接口。而你这里是只有新建接口，相当于抛弃了一个核心功能。
2. 分组功能被你删掉了。分组功能是一个很棒的左树右表的功能，是项目下的又一个层级。简单说吧，如果你要去掉分组功能，那么你都不用做一个项目列表，还要有一个什么 “回首页” 的按钮，直接左边项目名称树，右边自动化用例列表就可以了。原版的项目名称跳转超链接就是为了分组设计的，很明显你没 get 到。
3. 测试报告把 Echarts 图形也干掉了，但你也并没有拿出更好的方案。
4. 项目全景也干掉了。

当然你也增加了一下好的功能，可能主要是在断言的判断上吧。
我并不是说你这个平台不好，而是希望把原版的好的基础上再做优化，而不是直接把一些成熟的东西不知道为啥的就全抛弃掉。

postman 确实是个成功的产品。

这种思路很好，总的来说就是不要每次请求都要传数据，而是说 slave 先保存数据，测试结束之后走文件传输，例如 scp 把文件数据交给 master 整合。
其实这种方式我尝试过：

1. Jmeter 自带 diskstore 存储模式，就会将请求结果保存在本地文件。但是这种方式不行，文件保存路径是默认的在/tmp 下，文件名是随机的如 SerialisedSampleSender383066585222874452.ser 并没有地方能指定这个文件是哪个脚本文件的，这个文件名的前缀后缀是 Jmeter 定义的，但是中间的数字是 JDK 的方法 File.createTempFile("SerialisedSampleSender", ".ser"); 定义的。生成的 ser 文件，格式内容是 xml 的，文件比较大，同时默认是如果进程退出则文件删除，要不然也不会在 tmp 里，同时文件有分割，大概 113M 左右，就会被分割成一个子文件。
2. 如果是自己实现，slave 存储 jtl 或者 csv 文件，来传输给 master 再拼在一起，这种我试过，在某些字段如 99%，90% 这些，和 Jmeter 实时传输汇总的得到的测试报告不同，也就是说自己拼装的 和 Jmeter 源生的方式，得到的测试报告不一样，而 Jmeter 源生的测试报告业界更承认。 当然这种误差很小，不敏感的可以接受。

你这想的太多了，晋升的时候领导肯定都想到结局了，换句话说，领导早就放弃你了，你多虑了。
你可以继续待着，不过要改变工作方式，改变大家对你的印象（很难很难很难）。

直接改源码吧，改 maven 引用。

我没看懂你的问题。

打包 ios，玩 docker。
除了这俩，远不如同价位 windows。
个人意见。

写的真不错，已经收藏。向楼主学习。

说一下我怎么给 Jmeter 改动代码的吧：

1. 发现 Jmeter 解决不了我的问题。比如单进程内同时间生成多个测试报告。
2. 查报错日志位置，对源码进行 debug，看源码问题出现的位置。
3. 分析问题，大概了解了问题所在，如测试报告无法并发是因为公共变量的覆盖。
4. 尝试修改，是否 Jmeter 自身的 public 方法已经支持改动。这个例子是没有。
5. 一般我是拷贝 Jmeter 的源码出来，放到自己的环境里，然后改动，这个例子就是在最后生成测试报告在字节流的时候，才覆盖公共变量，而不是一开始就覆盖掉。
6. 调试，验证 OK。

呵呵了。你能说一个框架是你心目中完美的框架吗，它就没有缺点吗？
“如果框架都无法实现，工具和平台就更不能。” 为什么我不能改框架的源码来实现自己的需求呢？为什么我不能组合多个框架的优点来达到自己的目的呢？
框架总有缺点，而我做工具或者平台，就是组合各个框架的优点，让其合并在一起。相信各位做平台的也是这个目的。
“工具和平台解决的是 不让你写代码做接口测试 ！” 就比如接口测试的断言部分吧，postman 都是写脚本的形式来断言的，用我截图给你吗？是叫 Javascript ，

怎么了，你要告诉我 postman 不行，它不是一个成功的工具，是因为它让我写代码了，让我写了代码才能做接口测试了。那你的工具超过 postman 了吗？
不是说想怼你，你怼别人的时候最好想想自己说的是啥，你到底想清楚问题没有。

等你发现测试框架无法满足你的时候，你就会想写一个工具来满足你的要求了，写完工具会想何不共享一下？这就做成了一个平台。

你这个报错是 Jmeter 自己报的，建议查一下配置。
之前我也说过，Jmeter 对分布式节点 slave 的管理很弱，这是源生的弊端。不过正常都会自动停止的。分布式停不下来建议直接重启节点没关系的。
调试报告仅仅是调试，我还没想分布式那么远，有点儿太复杂了。

建议你仔细了解一下 Jmeter 的自有的压力分布的实现。平台对 Jmeter 的压力分布实现原理配置等没有做任何修改，做的仅是优化。
节点机的压力负载调节也是在改动原 jmx 文件在内存中对象的方式来实现的。

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

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 真的很重要。

是的。
但是目前平台支持压力机压力负载配置，比如可以把两个压力机承担的都是原脚本压力的 50% ，这样加起来就是 100 了。
可以调大或者调小压力。
源生的 Jmeter 的分布式节点机的坑还是不少的，建议压测前重启。

在重写 + 重构 + 改写这个项目。
UI 设计，产品设计的挺棒的。

集群的控制是 Jmeter 自带的，你如果看 Jmeter 源码就知道了。
平台只是调用 Jmeter 的 API，如果配置了集群就会使用集群。

学习了。
《Java 开发手册》是一本比较神的书，我精读的是 1.3 版本的，对写代码帮助很大。
这五道题其实还好吧，如果是经常刷题的，这种难度级别的题，能找出来不下 500 道。当然我是被虐的习惯了。

支持

感谢对我发言的肯定。

最近在面试，也在探索这方面的知识。补充一些这里没有的吧，个人浅见。

1. 面试问题要搞清楚，面试节奏要紧促一些，别面试官思考时间太长，到时间了问不了几个方面的问题，不全面。
2. 岗位述求要搞清楚，也就是岗位要求技能的权重要搞清楚，权重低的问题少一些，权重高的问题多一些。
3. 不要太考虑这个人的性价比，比如水平超过要的钱很多，但是要的特别少的那种，不要过多考虑，不是说省钱都不要，而是岗位的匹配是第一位的。
4. 及时送走不符合的候选人，不要浪费其他面试官的时间（扎心抱歉）。
5. 如果招的是自己组内的人，自己要带的人，那么无论自己是几面，都是第一责任人，就是说这个人的决定权必然在自己手里，候选人的去留自己一定要有数，不能说自己没看上，希望别人再帮忙鉴定一下，帮自己看一下。自己组内的人必须自己决定，别人的眼光只是辅助。
6. 越后面的面试官越责任越重，当然这个在公司内可能说法很多，比如领导面说过了，然后你说不过可能不太好。但是宗旨是相同的，越后面的面试官责任越重，越后面的面试官越要有自己独到的见解，独到的考察点。
7. 几轮面试应该有侧重，就比如 HR 面的是挑战 + 证实一样，我理解是一面全面基础，二面细化，三面行业/岗位格局。当然各个公司情况不同，可能一面就全问了也没啥（时间要控制）。
8. 面试不代表一切，也是看缘分，我挂掉过很多人，也并不是完全客观，也不是说她/他来了肯定不行。我一直在检讨。信任需要建立，互相信任是合作的基础。

是有这个类的。

可以尝试生成一个比较稳定的自动化脚本模板。未来的迭代都是向这个模板添加特定的需求。可以生成一批不同接口的 jmx 文件，让其成为素材，每次添加即可。当然这需要双开或者多开 Jmeter 来编辑。
建议每一个迭代都要保存好 jmx 文件，这样面对新的迭代可以参考历史文件，让工作量降低。
同时要写好每一个请求的注释，要能真正区分 sampler 的作用和特点。
Jmeter 是有一些缺点无法避免的，比如是一个本地工具无法和线上文档匹配，本身是脚本文件本地保存查找等，麻烦是必然的。需要结合其它工具来使用。

正常 JVM 环境中是有这个类的。你用的 Jmeter 是 5.1.1 吗。