性能测试的测试方法

性能测试这块，我接触得挺久的，真的有点小经验了。记得我第一次搞性能测试是 2010 年的时候，那会儿在一个大公司，我们那时候负责的是一款特别火的在线游戏。
当时啊，我就跟团队说：“咱们得测测这款游戏在高峰时段的稳定性和响应速度。”咱们那时候就用了几个方法，现在回想起来，还挺经典的。
首先嘛，我们就做了负载测试，就是模拟了 10 万个玩家同时在线的场景，看看服务器能不能hold住。那时候的测试结果，简直了，服务器差点崩溃，内存消耗爆表，我们那叫一个手忙脚乱啊。
然后呢，我们做了压力测试，就是不断增加用户量，看服务器到什么时候开始崩溃。这回好一点，服务器撑了 2 个小时才挂，算是有点韧性。
最后，我们做了性能测试，就是观察程序运行时的内存、CPU、网络等资源使用情况。那时候我们用了个叫JMeter的工具，记得那会儿我们用JMeter模拟了 5 万个并发用户，结果发现数据库读写性能是个瓶颈。
总结一下，我那时候常用的方法有三种：

1. 负载测试：模拟用户数量，看系统表现。
2. 压力测试：不断增加用户，直到系统崩溃，看看极限是多少。
3. 性能测试：监测系统运行时的资源使用情况。
   这三种方法嘛，基本上能覆盖性能测试的方方面面了。当然啦，具体用哪个方法，还得看项目需求和个人经验了。这块我就没碰过分布式系统性能测试，不敢乱讲。哈给你分享点亲身踩过的坑，希望对你有点帮助吧！

性能测试的测试方法其实很简单，但复杂在它需要综合考虑多个维度。先说最重要的，性能测试主要分为压力测试、负载测试、容量测试和稳定性测试。
另外一点，压力测试是用来检测系统在极端负载下的表现，比如去年我们跑的那个项目，我们模拟了大概3000量级的并发用户，结果发现系统的响应时间在高峰时段有明显的增长。
还有个细节挺关键的，很多人没注意到，性能测试不仅要关注速度，还要关注资源消耗，比如CPU、内存和磁盘I/O。我一开始也以为只要响应时间达标就OK，后来发现不对，资源消耗过高也会导致系统崩溃。
等等，还有个事，性能测试通常需要用到专门的工具，比如JMeter、LoadRunner等，这些工具可以帮助你模拟真实用户行为，收集性能数据。
最后提醒一个容易踩的坑，就是不要只关注测试结果，而忽略了测试过程。测试过程中可能出现的异常情况，往往能给你提供更多关于系统性能的洞见。我觉得值得试试，在测试前先制定详细的测试计划和预期目标。

单线程测试，2021年发现一个Web应用在处理高并发请求时崩溃。
负载测试，2022年测试发现某电商平台在高峰时段处理能力不足，平均响应时间超过2秒。
压力测试，2020年某游戏服务器在高负载下崩溃，导致玩家游戏体验极差。
稳定性测试，2023年发现某移动应用在长时间运行后出现卡顿现象。
并发测试，2019年测试发现某社交平台在并发用户达到5000时，服务器出现频繁崩溃。
别在高峰时段测试，否则结果不准，这就是坑。