不要用 Jmeter 测试方法的性能，一般的方法如果是存计算逻辑，耗时很少 Jmeter 无法满足这种很低耗时的性能测试（它本身的测量误差都比方法耗时大）。能实现高精度性能测试的是 OpenJDK 开源的 JMH：https://github.com/openjdk/jmh

不建议去，你这个年龄和工作时间很尴尬，去大厂例如字节大概率 2-2，薪资估计也就 35，其实没多多少，但是风险和不确定性很大，工作强度也会大幅提高，完全不值这点涨幅。

你需要的是 web 自动化测试框架，例如 Playwright、 Cypress

对社区的付出真是有目共睹，respect！

我之前在育新住，离你说的地方挺近的，但是现在搬到人民大学这边了。你小时候训练过那有基本功呀，可以约一下～

试试这个：https://github.com/PaddlePaddle/PaddleOCR

举个例子，比如微信，可以聊天、朋友圈当做两个功能，拆分开。确实依赖于 app 的业务形式，有些比较适合，拆分相对来说是个低频操作，可以结合构建系统实现自动打包拆分包。

说一个思路：既然 app 太复杂，覆盖不完全，可以降低 app 的复杂度。在某些 app 功能相对独立的场景适用，把不同的功能模块分开打包测试，比较容易能完全覆盖。

如果是要这个功能，那基本上网关产品都有这个功能。
如果是面试题，高性能、高可用这要求不低呀。

歪个楼，正常人的发量在十万这个级别。

1. 如果后台代码对外部请求没有做配置化，直接改代码为 mock 地址，mock 服务可以分情况 mock 或者 proxy 到正常服务。
2. 如果配置化了，比如配置文件，就修改配置文件。
3. 更好一点的，现在服务框架可以根据请求 header 动态路由，这样就可以从前端控制请求是不是走 mock。

感谢社区，慷慨大气～

的确目前网络上还没有相关的资料。

指出一个问题：

性能测试工具功能对比：

这部分显示 Jmeter 不支持测试过程调整压力，其实是可以的，我们内部的性能测试平台就实现了这个功能，思路是压力设置的地方使用变量，Jmeter 开启 BeanShell 支持，beanshell 支持远程修改变量的值（当然能力远不止如此），就可以动态修改变量的值，实现灵活的压力控制策略。

locust 也是支持的，它自带了的 web 界面就提供了这个功能。

典型的 XY 提问法，建议看看提问的智慧手册。
回到你的问题，把参数放一起作为一个 dict，你原来的参数名字对应 dict 的 key。不管调用还是函数中使用都很方便。

也经历过新人阶段，认真回答一下：

1. 从软件工程理论的角度看测试是很重要的一环，因此不存在天花板低的情况。即使是现实世界中大部分人的职业生涯触还碰不到天花板。之所以有这种说法，那是因为质量对于大部分软件产品都不那么重要，所以对测试的资源投入不足。例如通信类、航天类质量至关重要的领域，测试就很重要，也很有技术含量。对于大部分从事的互联网行业，测试确实知识面比较杂，一个人精力有限，进一步的会感觉什么都不精。如果现在不知道从何下手，其实可以学习一些计算机专业基础知识，这些知识很长时间都不会过时，对你日后的工作、跳槽面试都很有帮助。
2. 自动化会涉及到投入产出比，工作中的事情其实都要考虑投入产出比，有些产品、或者有些产品的阶段就是不适合做自动化测试，不必强求。
3. 不要过分关注绩效，这个东西很大程度你是控制不了的，你的领导是什么样子的人，你在的团队，公司的成长阶段可能都比你的付出重要。至于领导给你解释的绩效理由，你听听就行，其实没什么意义，是先有结果再有解释。你的长期价值会在招聘市场中公允的体现出来。
4. 适合不适合自己，自己喜欢什么，这永远是你要问你自己的问题，也只有自己能探寻答案。不要太在意别人的肯定与否定。

挺好的分享，很多看法都有同感。
看完有个疑问，你对你文中列出来的点很多是否定的，那么你现在招人看重的点有哪些？

还没招到，欢迎大家投递简历～

详细说说？想了解一下那些算是 shell 里面的高级内容。

从内存占用优化考虑：用字典树。
从时间效率优化考虑：肯定要线性扫描一遍，不管在内存里面还是从磁盘读，扫一遍文本的时间是主要时间。
单拿 top 5 分析，5 这个常数太小了，没必要用堆，遍历 5 遍更快。
扩展到 topK 的问题，堆也不是最优的解法。

有一个疑问，怎么考察是不是精通 shell？

快发邮箱吧～

可以多个机器同时发。我们压测 Kafka 的只关注消息体大小，不用关注消息内容，所以用 Kafka 自带的压测工具，单机压不上去就多个机器机器同时压，能到十几万的 QPS。

这个跟你业务强相关的，你就直接对比一条裁剪之后和原来的消息字节数就能得到。在我们这个场景大约能减少 70%，但是没有什么参考价值。

对，你说的这个点是造成准确性难保证的一个原因。这个问题其实很难解决，在于出需求的人对需求的描述是自然语言，而开发的人用的是计算机语言，这个转换难以避免出现误解，所以一个方向就是降低写批处理/流处理的难度，设立数据产品经理（掌握一定的数据开发技能解决）需求方直接写，避免转换过程出现问题，也有一些前沿方向是自然语言到 hsql 的生成，但现在还很初级。

但是除去这个原因，假设研发/测试都正确的理解了数据需求，依然不能保证数据的正确性，这里面的原因多种多样，比如对数据的假设不成立/处理逻辑有 bug/大数据基础设施有问题。所以我说这个问题的根本在于人没法判断数据对或不对。

这个问题我思考了挺长时间了，也有一些想法和结果，有机会我单独写一写。