---

前言

性能基准测试，会基于固定的硬件环境和部署架构（比如专用的服务器、固定的专用网络环境、固定大小的集群规模、相同的系统配置、相同的数据库背景数据等），通过执行固定的性能测试场景得到系统的性能测试报告，然后与上一版本发布时的指标进行对比，如果发现指标有“恶化”的趋势，就需要进一步排查。

"恶化"趋势
主要表现在以下几个方面：

同一事务的响应时间变慢了。比如，上一版本中，用户登录的响应时间是 2 s，但是在最新的被测版本中这个响应时间变成了 4 s；

系统资源的占用率变高了。比如，上一版本中，平均 CPU 占用率是 15%，但是在最新的被测版本中平均 CPU 占用率变成了 30%；

网络带宽的使用量变高了。比如，上一版本中，发送总字节数是 20 MB，接收总字节数是 200 MB，但是在最新的被测版本中发送总字节数变成了 25 MB，接收总字节数变成了 250 MB。

这里需要注意的是，这些“恶化”趋势的前提是：完全相同的环境以及测试负载。不同“恶化”指标的排查，有不同的方法。我以最常见的事务响应时间变慢为例，和你说明一下排查方法。

假设，通过性能基准测试的比较结果得知，用户登录的响应时间从 2 s 变成了 4 s。那么，我们首先要做的是验证在单用户的情况下，是否会出现响应时间变长的问题。具体做法是，将用户登录的虚拟用户脚本单独拿出来，建立一个单用户运行的性能测试场景并执行，观察用户登录的响应时间是否变慢。

如果变慢了，就说明这是单用户登录场景就可重现的性能问题，后续的处理也相对简单了。

解决方法是：分析单用户登录的后端日志文件，看看完成登录操作的时间具体都花在了哪些步骤上，相比之前哪些步骤花费的时间变长了，或者是多出了哪些额外的步骤。

如果没有变慢，则说明我们必须尝试在有压力的情况下重现这个性能问题。为此，我们要基于用户登录的虚拟用户脚本构建并发测试的场景，但是我们并不清楚在这个场景设计中到底应该采用多少并发用户、加入多长的思考时间。

这时，通常的做法是，直接采用性能基准测试中的并发用户数和思考时间，去尝试重现问题。如果无法重现，我们可以适当地逐步加大测试负载，并观察响应时间的变化趋势。

这里需要注意的是，千万不要使用过大的测试负载。因为测试负载过大的话，系统资源也会成为性能瓶颈，一定会使响应时间变长。但这时，响应时间变长主要是由资源瓶颈造成的，而不是你开始要找的那个原因。

如果此时可以重现问题，那就可以进一步去分析并发场景下，用户登录操作的时间切片，找到具体的原因。如果此时还是不能重现问题的话，情况就比较复杂了，也就是登录操作的性能可能和其他的业务操作存在依赖，或者某种资源竞争关系，这就要具体问题具体分析了。

一般来说，当定位到性能“恶化”的原因并修复后，我们还会再执行一轮性能基准测试，以确保系统对外发布前的性能基准测试指标没有“变坏”。

可以说，通过对每个预发布版本的性能基准测试，我们可以保证新发布系统的整体性能不会下降，这也就是性能基准测试最终要达到的目的。

需要特别注意以下三点：

1、性能基准测试中虚拟用户脚本的选择以及配比，需要尽可能地匹配实际的负载情况；

2、总体的负载设计不宜过高，通常被测系统的各类占用率指标需要控制在 30% 以内，尽量避免由于资源瓶颈引入的操作延时；

3、每次性能基准测试前，一般需要对系统资源以及网络资源做一轮快速的基准测试，以保证每次被测环境的一致性，同时也要保证数据库的数据量在同一个级别上。总之，你需要采用一切可能的手段，来确保多次性能基准测试之间的环境一致性。

稳定性测试

稳定性测试，又称可靠性测试，主要是通过长时间（7*24 小时）模拟被测系统的测试负载，来观察系统在长期运行过程中是否有潜在的问题。通过对系统指标的监控，稳定性测试可以发现诸如内存泄漏、资源非法占用等问题。

很多企业级的服务器端产品，在发布前往往都要进行稳定性测试。稳定性测试，通常直接采用性能基准测试中的虚拟用户脚本，但是性能测试场景的设计和性能基准测试场景会有很大不同：

一般是采用“波浪式”的测试负载，比如先逐渐加大测试负载，在高负载情况下持续 10 多个小时，然后再逐渐降低负载，这样就构成了一个“波浪”，整个稳定性测试将由很多个这样的波浪连续组成。

稳定性测试成功完成的标志，主要有以下三项：
系统资源的所有监控指标不存在“不可逆转”的上升趋势；
事务的响应时间不存在逐渐变慢的趋势；
事务的错误率不超过 1%。

实际工程项目中，由于稳定性测试执行的时间成本很高，往往需要花费 3~7 天的时间，所以我们一般是在其他所有测试都已经完成，并且所有问题都已经修复之后才开始稳定性测试。

另外，有些企业为了缩短稳定性测试的执行时间，往往还会采用“时间轴压缩”的方法，具体的做法就是：在加大测试负载的前提下，适当缩短每个“波浪”的时间，从而减少整体的测试执行时间。

最后，需要强调的一点是，虽然很多时候，尤其是产品版本已经逐渐走向成熟期时，稳定性测试并不会发现问题，但是千万不要小看稳定性测试带来的价值。因为稳定性测试一旦发现问题，那么这些问题都是很严重而且非常隐蔽的大问题。

所以，很多大型的企业级软件企业都会执行严格的稳定性测试，并把稳定性测试的结果作为产品是否可以发布的硬性要求。比如，我曾经工作过的 HP 软件研发中心，它每次产品发布前都会由专门的性能测试团队完成严格的稳定性测试，并以此来决定是否要发布这个产品。

并发测试

并发测试，是在高并发情况下验证单一业务功能的正确性以及性能的测试手段。高并发测试一般使用思考时间为零的虚拟用户脚本来发起具有“集合点”的测试。

并发测试，往往被当作功能测试的补充，主要用于发现诸如多线程、资源竞争、资源死锁之类的错误。要执行并发测试，就需要加入“集合点”，所以往往需要修改虚拟用户脚本。

加入“集合点”一般有两种做法：
1、在虚拟用户脚本的录制过程中直接添加；
2、在虚拟用户脚本中，通过加入 lr_rendezvous() 函数添加。

下面是我整理的2023年最全的软件测试工程师学习知识架构体系图

一、Python编程入门到精通

二、接口自动化项目实战

三、Web自动化项目实战

四、App自动化项目实战

五、一线大厂简历

六、测试开发DevOps体系

七、常用自动化测试工具

八、JMeter性能测试

九、总结（尾部小惊喜）

只有不断地努力和奋斗，才能实现自己的梦想。无论遇到多大的困难和挑战，都要坚持下去，因为成功就在前方等待着你。让每一天都变得更加充实和有意义，把握每一次机会，勇往直前，不放弃！

在人生的道路上，每一个脚印都是向前的力量。只要坚定目标、不断努力，即使路途再远，终究能到达成功的彼岸。相信自己，坚持奋斗，让我们一起迎接更美好的未来！

每一份努力都不会被辜负，每一个追梦者都值得尊敬。不要害怕失败，因为失败只是通向成功的必经之路。只有勇往直前，才能让生命的价值得到最大的实现。让我们一起奋斗，成为自己想成为的人。