能速成的东西，都不值钱

花钱报班

你要是为了面试，拿出去唬人的，比如有些招聘要求要熟悉性能测试，自动化测试，平台开发啥的，但实际找你过去当个高级点点，那么你就网上找些别人做过的案例，死记硬背下来，面试时秀些特有名词，讲别人做过的例子，记一些常用的查看服务器资源的命令。这个或许就是你想要的快速 “学会”。但这个在一些重大厂专职性能测试岗位面试上肯定会露馅的。

说实话不是找专门的性能测试岗位，其实你的方法我就觉得够了， 一般吧大公司有专门的性能测试，也轮不到你，小公司么压根不需要压测。点点点，顶多再能写个造数平台就够了

测试分析东西可多了，你不了解全局架构，以及一些底层的东西，你分析不出来啥

确实

在有经验的同事的指导下，自己完整参与执行一次性能测试

如果公司没有相关经验的同事，让你去开展性能测试这种要怎么做。用 jmeter5 个线程运行，看到那占用 99% 的 CPU 束手无策

熟悉计算机组成原理、操作系统、计算机网络。在网上熟悉常用的中间件以及工作原理有助于快速了解架构，以及产品架构是否合理。至于写脚本那都是次要的，光学不练还是没用。

以前我也这么想过，后来觉得我都懂这么多了，拿测试工资好亏，就算了

是金子早饭都会发光，不让你发光你就给他上点手段

学习性能测试不是一朝一夕的事情，别人给你一套说辞你也未必用的起来。做好性能测试所需的知识面很广，像 centos、微服务、中间件、mysql、redis、k8s、jvm、业务模型抽取、压测场景制定、压测策略、监控计数器分析等等概念和反复实践理论后的融会贯通，这个过程需要很长时间实践和反复打磨才能掌握。

知道性能测试你就速成了

如果没有，那就先从使用工具开始，因为这是迈出去的第一步。

其实性能测试含金量是整个测试计划的制定、指标设计、数据分析以及问题定位的过程，工具可以随便选，只要达到发压目标，能收集到想要的数据就行。

【用 jmeter5 个线程运行，看到那占用 99% 的 CPU 束手无策😂】比如这种，就是在没有思路的情况下直接去操作，你要想想你去性能测试是为了什么。是为了发现系统的性能瓶颈或性能转折点？还是验证系统能否达到预期的性能？带着这两个问题再去想怎么办。我给两种建议：

1. 如果目标是前者，那应该降低线程数再压，直到 cpu 不再打满，找到那个边界。然后按照这个压力去评估当前系统的表现是否合理，是因为有 bug 或劣化点导致性能问题，还是说这个系统确实就是这样的性能很合理。
2. 如果目标是后者，那原本的性能预期是多少，现在的数据究竟符不符合要求。

不要把思路局限在怎么用好 jmeter 上，也许今天是 jmeter，明天 jmeter 没落没人维护了就换成其他工具，所以花太多时间在上面没意义，把各种报告 ui 性质的东西配满做得花里胡哨也没有意义，因为你或许根本就没在做一个正确的性能测试。

应该是让我验证系统能否达到预期的性能吧，但是公司并没有给我相对应的要求什么的，就跟我说进行性能测试，我就不知道该怎么办。我直接验证一下极限在哪里，怎么调优，因为什么原因导致 CPU 占用这么高我没有相关的技能

如果是什么都没传达，可以考虑一下这么做，我这里假设你关注的指标是接口 QPS

1. 找研发和产品要系统的历史线上性能峰值，比如业务高峰期最大 QPS 等类似的概念；如果研发和产品都给不了，那就看看有没有历史线上的数据监控，也可以拿来参考
2. 拿到这个业务峰值后，你的压测预期至少要高于这个峰值，一般来说是性能是峰值的 1.5~2 倍，具体倍率就看公司的资源，你验证到数据之后就和产研对齐是否符合预期即可。

好

做个好梦比较快

如果想快速学会性能测试，最好是直接跟做过性能测试的同学一块做个项目就能很快入门，但是如果想做好性能测试，那不仅需要对计算机网络有足够了解，你还需要熟悉各种中间件，现在很多应用后台都是微服务架构，上了各种各样中间件，你需要熟悉每个中间件的特点，了解它的优势与不足，除此之外你还要能看懂被测服务架构图，根据架构图能识别到系统可能有哪些瓶颈点，然后针对性测试。