基于接口的性能测试入门（Jmeter）

导读

好久没发文了，今天聊一下性能测试。
这是一篇关于性能测试的入门文章，没有涉及到高大上的全链路压测等等，纯粹是给刚上手性能测试的小白一个简单的了解。当然对于一些用户量不大、没有做过性能测试的产品，这些入门的方法完全可以填补上性能测试这个空白。

基本概念

我们首先了解下关于性能测试的几种测试场景：

• 基准测试：对某个需测试的场景进行定量（并发数）测试，并为后续的对比试验建立数据基础。个人理解，其实就是我们先针对某个场景建立一个基础并发数据，当有代码改动（当然是比较大的代码改动）时，并发数据没有明显变化，若指标下降，则表明代码有缺陷。
• 单场景测试：这个比较好理解，单纯代表一个场景，比如登录。相对来讲，多场景就是指并发请求来自多个场景。以Jmeter为例，单场景就是一个线程组代表一个场景，各个场景之间的并发数都是独立的。多场景就是一个线程组涉及多个场景，所有场景共享一个线程组的并发数。
• 负载测试：不同负载（并发数）情况下系统的性能指标。
• 压力测试：和负载测试不同，压力测试是随着负载的增加，系统数据指标处于失效状态时系统的响应，这里指的是系统性能指标直线下降的节点。。
• 容量测试：主要是获取系统所能获取的最大负载量，当然是指系统指标正常情况下，这里指的是响应时间、系统CPU、MEM等在正常范围内。
• 恢复性测试：系统的自主恢复能力
• 稳定性测试：系统的稳定运行能力

实践

一般来说，对于一个新系统的性能测试会通过容量测试来体现当前我们的系统到底能撑多少的并发，也算给领导一个交代，当然这只是性能测试的开始，先把这一关扛过去。
容量测试可以按照以下步骤执行：

1. 选取需要测试的功能模块，一般测试需要跟开发共同商定哪些功能对性能有要求，特别是那些常用的，比如登录、首页展示等等。
2. 选取完功能模块后划分一下每个模块的业务比例，这个对后续的单场景和多场景有帮助。在多场景测试时可以根据业务占比分配对应比例的并发数，尽可能接近跟真实场景。
3. 针对每个场景梳理相关接口及接口所需要的数据。比如说我要测试登录接口的并发，最好不要用一个账号和密码，而是尽量使用不同的账号密码，这样更接近现实场景。当然如果代码里边已经处理了同一账号跟不同账号的登录逻辑相同，则可以用一个账号代替。创建数据的时候写个脚本，要不然手工创建会把你累死，登录并发一般都要用几十万的账号，一个一个的账号创建啥时候能完成。。。所以学点脚本对平时的工作还是很有用处的。
4. 选择性能测试工具：一般使用Jmeter，不要问我为啥，开源、免费的东西就是香 😃 怎么使用Jmeter我就不在这里说了，已经有很多类似的文章，不过针对大并发使用分布式压测机的场景我会在另外一篇文章里分享。
5. 生成测试数据：我们应该先从小的并发数开始不断的增加，建议从50开始，再使用100、150、180、200等，越到最后并发数间隔越小，使得到的并发数越准确。每个并发我们都要记录以下数据：
   接口、并发用户数、吞吐量、评价响应时间、90%Line、95%Line、99%Line、错误率、CPU%、Mem%，这样就生成了不同并发数下的数据，很直观，一目了然。根据数据做一个总结，比如错误率或者cpu、mem突然变好的转折点就是系统的并发容量。
6. 最后再追加一个总的结论，对整个系统的各个模块进行评价。

以上是一个简单的容量测试的步骤，步骤只是一个参考，我们执行的意义也不在于展示数据，主要还是解决影响性能的问题。在做性能测试过程中，需要多跟开发沟通，尤其是复现问题的时候看一下log，这样也比较有目标性。

后续计划

这算是一个性能测试的开端吧，主要是帮助没有做过性能测试的小伙伴开扩一下思路，后面会顺着这个思路讲一下：

1. 记录接口响应时间的相关工具
2. Jmeter分布式并发
3. 一些真实的性能测试案例
   。。。