确实很充实，做的工作很专，赞👍！

如果能量化，就是优秀的。

也是分情况的，如上面说的，要详细的问一下场景如何，才能做判断。
不过一般的，很简单的给查询结果做一个缓存，基本是没啥问题的。现在各家公司也都知道 redis 集群是提高性能的主要手段，带宽，集群方案，内存容量，隔离切分都是没啥问题的，公司层面就会注意这些基础设施的建设，redis 集群的支撑能力到几百万的 QPS 没啥问题。
你回答中也提到了，可能存在偶发的高峰，那么面对削峰，MQ 也是一种方案。MQ 比如 kafka，性能更是厉害了，几千万的 QPS。你们开发在技术架构选型的时候，相信已经思考了相关的取舍，建议你和开发仔细探讨一下，会有收获。

redis 缓存的核心问题是数据双写，其它细节可能是大 key，带宽消耗，失效时间设置，命中率，如果都没有问题，就是很正常的优化。

如果要给 Jmeter 写插件，可以去看一下 jmeter-plugins-for-apache-dubbo 源码即可，还是挺有借鉴意义的。当然直接看其他的插件源码也可。
如果是要给 Jmeter 修复 bug，比如，拓展其核心的能力，这个需要看 Jmeter 的源码。
如果是要给 Jmeter 修修补补，但是不想改 Jmeter 的源码，可以看我的开源实现方式。

性能测试分两种，容量测试和压力测试。（当然高楼是说性能测试其实就一种，不用分那么多，我这么说是便于理解）
你的问题，看起来你是把这两者混在一起了。细看你的要求更接近压力测试。
我遇到的 90% 吧，Jmeter 的的范畴，剩下的，最应该用流量回放的方式搞，但是还是使用了 Jmeter 搞定。

那测试到底还需不需要做功能测试？可能在很长一段时间内仍然是需要的，但那一定只是日常工作中很小一部分。
不评论了，学习了。

已经是老回复了，我也是复习了一下前因后果之后，很费时间。
我之前确实理解错了。
19 年 8 月的时候，我还是支持自研接口自动化平台的（当时我也在写这些），而到今天，我几乎是反对自研接口自动化平台了（主要是性价比不高，同时测试有其他更重要的自研工作）。
我的立场已经变了。
希望虫师未来能分享更多的知识，感谢。

优秀的产品经理，比如周鸿祎，乔布斯这就不说了，已经是传奇了。网上比较火的可能是张小龙，俞军，姚晓光（游戏不知道算不算），这些有访谈记录。然后一些接地气的，比如苏杰。去看看这些人的东西，你会对产品经理有比较多的认识。
普通人眼中的好的产品需求文档，和产品人眼中的好的产品需求文档，标准是不一样的（不排除有捧臭脚的）。同时产品经理的工作是很长的一段链条（产品的生命周期），有很多工作，你不能只看其中的一部分就否定人家的能力。
或者说，优秀的产品经理，已经上升到决策层，你想遇到，可能也自己也够不到那个层次。
就别和普通人聊什么增长了……你找错人了。

赞👍！

你逗笑我了……文章作者是你吗……
好了，我严肃一些。
你的文章结论还行，一些我是赞成的。
爱用 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 个问题 “昨天完成了什么”，“今天要做什么”，“明天干什么”，每个人撸一遍。
站会要开。
但是效果不好的站会，就不要浪费时间，不用开。这是两个事情。

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