赞👍！

你逗笑我了……文章作者是你吗……
好了，我严肃一些。
你的文章结论还行，一些我是赞成的。
爱用 locust 就去用，只不过我不推荐。
论单机的性能发起，去用 webbench。
复杂测试脚本，不嫌累就去用 locust，反正我不用。
逗笑我是因为，你认为 “个人感觉在报表方面，两个工具相差不是很大，都基本能满足工作需求”，有点儿搞笑，你如果能用 locust 实现出来和 Jmeter 性能测试报告相同实力的报表，真的，你就是业界翘楚，我为你单独写一篇，分析你写的源码报告。

还有在这挖坟的……我感觉你不是想怼我，而是自己对这些问题自己没有啥解决方案或者是知难而退了，借着回复我吐槽一下。
其实时代已经发展了……
了解一下阿里云效平台（测试管理部分，流水线部分）吧，你的想做的这些问题已经解决的差不多了，比如代码扫描，质量管理，报告自动化发送，消息推送，接口预警（卡点）都可以。bug 自动提交这东西不好做哈，毕竟还是需要人工确认一下，但是设置一个卡点是可以的。而这些，我认为云效平台结合 postman 都是可以做的……。而数据的可视化，是云效平台的卖点之一了。
可能你对测试要开发的平台没有太深入的思考吧，有些重要的平台是需要你说的 “有灵魂的编码” 的，不过你的举例不太好（具体啥平台我就不提了……不想替你思考）。
接口自动化测试平台就别再吭哧吭哧的自己研发了哈，比如一些这个社区内比较知名的开源的，好几个了吧，什么 httprunnerManager，Hitchhiker 之类的，都已经停止更新了哈，风向标比较明显。用些好用的开源的就行了（httprunner 是可用的我是支持的！）。

大家说的都挺好。
最近我发现测试的技术要求和开发的技术要求确实是真的不一样。
倒不是说我自己技术有多好多牛，而是说我在提升自己技术的路上，和开发提升自己的核心路线，不一样。
比如我最近接触了两种架构师，一种是倾向于框架各种使用的架构师，一种是研究底层的架构师。当然正常工作都是没问题的，就是人家的 “爱好” 不同，分享的东西不同。
而测试我自己的学习路线，相比之下，比较杂，比如我学过的（就是主动去了解的），或者测过的：网关，消息中间件，ES，数据埋点，监控平台数据上报，性能测试（工具使用和调优手段），项目管理，敏捷，技术管理，devOps，springboot，python，中台，秒杀系统等。
就说研究底层的吧，比如我知道 CPU 有寄存器和高速缓存，我知道大概是做什么的，但是区别我是真的不如人家了解，再比如我知道有虚拟内存和物理内存的区别，但是来龙去脉是什么，我没人家了解，或者 docker 的 namespace，cgroup 原理，这都是底层的，我真没人家了解。
就说研究架构的吧，人家要不说，我不知道 Apollo 是什么，或者 Nacos，或者 ETCD 和 zookeeper，或者 zookeeper 和 Eureka 的区别，或者 Druid 和 HikariCP，或者 sharding-sphere，或者 skywalker，可能我听都没听说过，名字我都要百度去查。
有些架构师是 C 语言出身的 Java，有些是 Java 和 Go 都会的，而我最多会个 Java 和 Python（人家 Python 也会），很尴尬。
那么我要测试这些东西，我听都没听说过，我还要评估人家的水平，那这活我是干不了的。
我越来越发现吧，测试工作做到上层，一个测试是要 “服务” 很多种类的架构师的，那么这时候你告诉我测试技术不重要……我真是有点儿呵呵了。
对于测试技术这事儿，我也很烦，因为我都不精，太杂了，技术栈不明确，唉唉。

这个纯前端的我也不了解哈~并且我也 2 年左右没看过这个项目了。
另外我不建议重构哈，除非你也是为了 KPI。

可能是 KPI 项目哈。有点儿可惜。

刘邦笑着问韩信：“依你看来，像我能带多少人马?”
“陛下能带十万。” 韩信回答。
刘邦又问：“那你呢?”
“对我来说，当然越多越好!”
刘邦笑着说：“你带兵多多益善，怎么会被我逮住呢?” 韩信知道自己说错了话，忙掩饰说：“陛下虽然带兵不多，但有驾驭将领的能力啊!”

韩信是兵神，是我的目前的管理思维的终极目标。
在招聘，我最看重的是技术能力，其他都是毛毛雨。
其实各大公司，早就这么干了。

“3、基于问题 1、2，测试人员每天花费太多的精力在一些基本功能、界面问题上，而没有较多的精力在测试技术提升、深度问题发掘上，长此以往，会让测试人员有种专业价值没得到体现的感觉，不利于团队的长久发展。”
这个问题其实是双向的，假如一个测试，懂的比较少技术弱，然后功能界面问题很少，那么他很容易没有存在感，或者绩效沟通没有说服力。那么这样问题的关键就会转移到，有了精力之后，到底测试技术能提升多少，能给他带来多少存在感或者安全感。这个是很难体现的。
再思考一下，其实这个问题有一些误区，因为技术提升&深度问题的发掘，靠的是个人的主观能动性，靠的不是公司提供的种种便利（就算大厂背景，也得能有能力进大厂是吧），或者直白一些，安于现状的，更需要的是工作量来实现的职场安全感。
我觉得，这个问题，应该着重于工作分工的科学化，工作协作的安排，让整体的工作节奏是一直处于可控的状态。而 leader 要做的，是发现那么真正主动提升自己能力的同事，然后安排他到适合的岗位上去，帮助他的学习成长。
还有，leader 的技术不能水，尤其是在创业公司。leader 能提出这种问题，本身就必须是一个主动的提升技术的人，要不然真没说服力。

我写过一个页面的，rest-assured allure2 vue2 JDK11 elementUI Mysql 或者迁移到 H2 的。不过不开源，哈哈。

感觉，clean 一下，重新引用一下，就会没问题呢。

Jmeter 默认 master 和 slave 之间，是需要 SSL 通信的，即加密通信。但是这个可以关掉。
因为我们一般都是内网，不存在窃取请求内容等安全性问题，还有 SSL 加密解密的过程会带来性能损耗。
所以一般都是关闭的。具体关闭的方式，日志中已经提示：server.rmi.ssl.disable is set to 'true' 这个配置在 master 的 jmeter.properties 文件中，slave 中也有一个。 改成 true 即可。

哪写的 24 岁呀？

我也推广过，发现自己研发的，也不是推不动吧，而是后面自己也不愿意推动了
本身开发自己就需要接口的文档平台，比如 RAP，YAPI 等。这类平台本身就支持一些接口测试，mock 之类的，开发在上面改，测试也在上面改，双方的工作成果是加成的，不需要平台切换，很方便。
自研平台本身的功能，并没有业内知名的强大。比如 YAPI，Postman 就很强大，Jmeter 更是全家桶。
出去面试，自研平台的使用，不是加分项，相反可能是减分项。自研平台的使用，对薪资的提高很弱，难有动力。
接口测试是测试同事少有的能接触代码的机会，这个也要剥夺，不太仁义。
知名平台也相对美观，更容易接受。
例子：httprunnerManager 已经停止维护，接近 1000 star 的都停止维护了？不知道是什么原因吧，但这是个风向标。

如果是我，我会直接推广 Jmeter，YAPI，真的不太需要自研平台。
那么我一定要搞自研的 API 自动化平台呢？？
我是有一些想法，但没有证实或者动力，总的来说，还是投入和产出比太弱。靠一个人来做，时间会很长。
就比如我把 Allure2 测试报告结合到 API 自动化测试报告中来了（类似 Yapi 生成的报告是 Allure2 的，希望能懂），形式上是个创新吧，但是这个功能我写了差不多一个月。（有时间就写写那种）

那么测开要做什么呢？
我认为测开还是要和测试同事们站在一起，什么东西是测试同事高频使用的，就要提高这些高频使用的效率，给这些添砖加瓦。
要让测试同事们的工作可度量，接着持续改进，让度量更科学，提高效率。
测开不是要让大家的工作越来越忙，而是要让大家越来越闲，把多余的时间，放到提高个人的幸福感上来，生活上的，或者技术上的，或者工作上的。这是我个人的愿景，谁特别忙，我都会想办法让他/她闲下来。可能是因为我是搞过性能调优的 。
其他工具上，直接用开源就好。除非开源解决不了问题，那也是给开源写插件来搞定（如 dubbo sampler 多棒👍）。如果再搞不定，才要自研。

2020 年来了，都 5.2.1 版本了

站会是项目管理的一部分。核心宗旨是让每一个人都真心参与到项目中来，了解目前的项目状态，及时调整修复自己的工作计划，群策群力，把项目的风险降低。所以站会不要求每个人都发言，也不要求固定的主持人。站会也不要求问题的长短，有兴趣的人都可以参加到问题讨论中来。甚至站会也不要求时间，解决问题为准。甚至联络感情插科打诨我也不觉得是问题，能真正让所有人参与到项目中，为项目进度出谋划策，就行。甚至以游戏的形式开站会都行（业内应该有这么做的）。
站会不仅仅是 3 个问题 “昨天完成了什么”，“今天要做什么”，“明天干什么”，每个人撸一遍。
站会要开。
但是效果不好的站会，就不要浪费时间，不用开。这是两个事情。

写的不错。
就是焦虑是技术，但是看的书和技术貌似没啥关系。

2020，如果能完成自己的目标，就买个 Tesla，奖励自己。
膜拜大佬。

当初面试了四五家公司，只有一家公司可以提供相符的薪资。
预计未来还会比较忙的。

收到邮件了，问题我还没有复现（工作 ing）。
希望把问题提到 issue 上去，这样比较方便追踪（gmail 国内上稍微费劲）。
初步的直觉的判断，我觉得不太可能，因为纯粹是源生的 Jmeter 来驱动运行的，不太应该。但是你提到了吞吐率控制器，可能另有玄机。

虽然没看代码，但是技术栈就很不错，赞。

444104595@qq.com
qq:97891996

就用 Jmeter（+ant+jenkins）吧，水桶工具。

https 的能支持吗？

我正在写自己的测试平台，但我之前没接触过 yapi，然后今天看到 yapi 的时候，我都惊呆了，难道我真的造了个轮子吗
后面仔细看了下，还好还好，我的平台还好有自己的特色啊（比如集成了 Allure2 的测试报告吧，这需要我自己在代码中定制它，并不是直接使用 testNg 的集成之类的，而是相当于重新实现了一个集成依赖。当然这不是炫技，而是 Allure2 确实在测试报告领域，是未来，是趋势）。
yapi 是一个成功的产品，很多经验值得借鉴呀（导入导出不说了，主要是 wiki（稍微单薄）和每个接口的备注，公共的环境配置，还有楼主写的这一段和 Jenkins 集成的方式，整体的格式和提示消息都非常棒）。
yapi 也有一些不太好的地方，我就不说了。
yapi 也有一些接口测试常用的，却没有支持的，我也就不说了，毕竟是我自己平台的特性……
yapi 很成功，值得学习。

年薪百万是测试负责人。好好看看职业描述吧。下面的小兵（高级工具人高潜）不是这个价位的。