写给程序员的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

{{o.name}}


{{m.name}}

原创文章,作者:kepupublish,如若转载,请注明出处:https://blog.ytso.com/97430.html

(0)
上一篇 2021年8月20日 11:03
下一篇 2021年8月20日 11:03

相关推荐

发表回复

登录后才能评论