写给程序员的JMeter教程（三）：一个性能测试的五大基本要素

非常抱歉，本以为这周可以进入实操，发现还是得继续讲一些理念的东西。

当然，我认为有时候学习一个技术，理解理念的东西可能更重要。因为这是『知其然，知其所以然』的一个必须的过程。

如果我们只就技术学习它如何使用，不去思考与理解它背后的一些东西，这样在技术频繁更新的今天，应付技术的更新就会变得非常吃力。

本周，继续写给程序员的JMeter教程系列，这是第四篇，本系列其它文章为：

1. 写给程序员的JMeter教程（序）：程序员需要掌握的能力
2. 写给程序员的JMeter教程（一）：理解性能测试的常用指标
3. 写给程序员的JMeter教程（二）：JMeter与LoadRunner的简要对比

如何构建一个性能测试

想要构建一个性能测试，其中有五大要素是一定得具备的，它们是一个完整的性能测试都不可或缺的一部分。

这五个要素分别是：

1. 服务环境考量
2. 用户模拟
3. 测试业务点
4. 断言
5. 数据与结论

当然，一个性能测试可以设计的更复杂，但就算是最简单的性能测试，比如单个接口的性能测试，都不得不包含这五大要素。

因此，在开始一个性能测试之前，你就得思考这几个要素如何配置与实现。

1. 服务环境考量

我们都知道，服务的部署环境及方式可谓多种多样，如单机部署，集群部署，分布式部署等。

而部署的服务器的包括操作系统，CPU以及内存等都可以灵活搭配。

因此，我们在开始一个性能测试前，我们第一个要关注的就是：

测试的服务的环境应该如何配置

是应该将服务部署为单体模式或集群模式？使用较好的服务器配置或是一般的？

当然，这个问题并没有一个万能的答案，这依赖于你测试的目标而定。

比如我们想测试接口的性能如何，那就可以部署为单机模式，选用一个较中的服务器配置就好，我们可以通过这个环境下测试的结论来大致推测集群模式下的性能。

又比如你测试的是架构的稳定性，那单体就不太合适了，

2. 用户模拟

性能测试与单元测试的一个较大的区别就是：单元测试只关注单个并发下的结论，而性能性能是关注大并发下的结论。

要有大并发，必要的用户模拟就必不可少了。

当然，这里我说的用户模拟，不是它字面上的用户的意思，它是一个统称，比如对于接口，那就是指的请求接口数，对于数据库可能是连接查询数据数等。

JMeter对于用户模拟，支持几个维度的设置，包括：

1. 每次测试产生多少线程（多少个请求）
2. 这些线程在多少时间内产生？（压测机性能是有限的，每秒内产生的线程是有上限的）
3. 测试多少次，一次？还是循环测试多少次，抑或一直测试直至用户主动停止
4. 产生线程的算法是怎么样的，平均产生，还是按某种曲线或随机来产生。

对于用户模拟，需要关注的就是：

压测机可能性能并不足够，不足在短时间内以产生非常多的线程数

比如你期望一秒内产生1万个并发，这在大多数机器上可能都不切实际。

3. 测试业务点

业务点是性能测试的重点，我们性能测试关注的业务点在哪？

业务点可以是单个场景或复杂场景，这依赖于你的目标而定。

在复杂场景中，又可能存在后一个步骤依赖前一个步骤的结果等，都是需要特别去设计的。

比如登录这个操作，如果仅关注登录这个接口，不关注后续其它操作，那这就是一个单个场景。如果关注的是登录成功后，拿到Token，还要确认Token是否正确，这就涉及前后的步骤了，这就是一个复杂场景。

当然，业务的场景可以非常复杂。但简单复杂与否还是在于你这一次测试的目标所定。

4. 断言

断言是对测试业务的是否成功的判断。

做性能测试不可能只关注业务请求而不关注业务结果，对吧。所以基本上每个业务点，我们还要考虑如何对它做断言。

还是拿登录来说，怎么能在性能测试中识别登录是否成功或失败？

当然，这依据你的设计来定。

对于接口，我们可以认为2XX响应就是成功，这也是JMeter对于HTTP请求的默认断言。当然这不一定正确，有些服务不管业务成功还是失败，都响应为2XX，这时候我们需要进一步明确如何断言。

比如通过响应结果中的特定字段来识别业务是否成功，如响应结果中会有error字段，0表示成功，其它表示失败，那我们的断言就得根据这个来做。

我们得在这个业务点中加入这个断言。

这就是断言，它也是必不可少的一部分。

5. 数据与结论

测试是需要有数据与结论的，不然性能测试就没有意义。

如同我在前面的文章中所述，我们需要关注的一些数据就是：

• Thread
• TPS
• KO
• Average/Min/Max
• 90th pct/95th pct/99th pct

当然，工具肯定为我们帮好这一切了，JMeter也是，只要你需要，它会为你生成一份详细的数据报告。这份报告中包含上述数据。

所以，你还得学会看这份报告，当然这个很简单的，更重要的是通过数据来能出结论。

比如，代码是否符合性能要求，或架构的稳定性是否满足等。

如果不符合，要能根据数据分析与判断问题在哪，然后有所对应的优化它。再次测试，走到数据满足你的期望为止。

我们的第一个JMeter性能测试

当然，并不是说只有这几个要素，一个性能测试可以设计的足够复杂，但这五个要素是必不可少的。

下一周，我们就正式开始编写我们的第一个性能测试，按照本文所述，我们的第一个性能测试场景也会完整的包含上述五大要素。具体会在下一篇中再说。

下一篇，写给程序员的JMeter教程（四）：程序员的第一个JMeter性能测试

---

关注【微言码道】公众号或访问【微言码道】官网 https://taoofcode.cc : 用我们微小的力量传播编码之道

访问【myddd-全栈式领域驱动】官网: https://myddd.org