软件测试回顾(8)

性能测试，七个主题，完善性能测试知识体系

28章：软件性能与性能指标

终端用户眼中的软件性能

• 系统响应时间
  • 应用系统处理时间
  • 数据库处理时间
  • 网络传输时间
• 前端展现时间，取决于用户端的处理能力。

系统运维人员眼中的软件性能

大量用户并发访问时的负载，以及可能的更大负载情况下的系统健康状态、并发处理能力、当前部署的系统容量、可能的系统瓶颈、系统配置层面的调优、数据库的调优，以及长时间运行稳定性和可扩展性。

系统运维人员必须在最大并发用户数和系统响应时间之间进行权衡取舍。

目前，有些系统为了能够承载更多的并发用户，往往会牺牲等待时间而引入预期的等待机制。比如，火车票购票网站，就在处理极大并发用户时采用了排队机制，以尽可能提高系统容量，但却增加了用户实际感受到的响应时间。

软件设计开发人员眼中的软件性能

在软件设计开发人员眼中，软件性能通常会包含算法设计、架构设计、性能最佳实践、数据库相关、软件性能的可测试性这五大方面。

• 算法设计
  • 核心算法的设计与实现是否高效
  • 设计上是否采用buffer机制以提高性能，降低I/O；
  • 是否存在潜在的内存泄露；
  • 是否存在不合理的资源竞争。
  • 是否存在并发环境下的线程安全问题
• 架构设计
  • 是否可以方便地进行系统容量和性能扩展；
  • 应用集群的可扩展性是否经过测试和验证；
  • 缓存集群的可扩展性是否经过测试和验证；
  • 数据库的可扩展性是否经过测试和验证。
• 性能最佳实践
  • 代码实现是否遵守开发语言的性能最佳实践；
  • 关键代码是否在白盒级别进行性能测试；
  • 是否考虑前端性能的优化；
  • 必要的时候是否采用数据压缩传输；
  • 对于既要压缩又要加密的场景，是否采用先压缩后加密的顺序。
• 数据库相关
  • 数据库表设计是否高效；
  • 是否引入必要的索引；
  • SQL语句的执行计划是否合理；
  • SQL语句除了功能是否要考虑性能要求；
  • 数据库是否需要引入读写分离机制；
  • 系统冷启动后，缓存大量不命中的时候，数据库承载的压力是否超负荷。
• 软件性能
  • 是否为性能分析（Profiler）提供必要的接口支持；
  • 是否支持高并发场景下的性能打点；
  • 是否支持全链路的性能分析。

性能测试人员眼中的软件性能

一个优秀的性能测试工程师，一般需要具有以下技能：

• 性能需求的总结和抽象能力；
• 根据性能测试目标，精准的性能测试场景设计和计算能力；
• 性能测试场景和性能测试脚本的开发和执行能力；
• 测试性能报告的分析解读能力；
• 性能瓶颈的快速排查和定位能力；
• 性能测试数据的设计和实现能力；
• 面对互联网产品，全链路压测的设计与执行能力，能够和系统架构师一起处理流量标记、影子数据库等的技术设计能力；
• 深入理解性能测试工具的内部实现原理，当性能测试工具有限制时，可以进行扩展二次开发；
• 极其宽广的知识面，既要有“面”的知识，比如系统架构、存储架构、网络架构等全局的知识，还要有大量“点”的知识积累，比如数据库SQL语句的执行计划调优、JVM垃圾回收（GC）机制、多线程常见问题等等。

衡量软件性能的三个常用指标

并发用户数、响应时间，以及系统吞吐量。

并发用户数

并发用户数，是性能需求与测试最常用，也是最重要的指标之一。它包含了业务层面和后端服务器层面的两层含义。

• 业务层面的并发用户数，指的是实际使用系统的用户总数。但是，单靠这个指标并不能反映系统实际承载的压力，我们还要结合用户行为模型才能得到系统实际承载的压力。
• 后端服务器层面的并发用户数，指的是“同时向服务器发送请求的数量”，直接反映了系统实际承载的压力。

为了让你更好地理解这两层含义之间的区别，我们先一起来看一个实例：一个已经投入运行的ERP系统，该系统所在企业共有5000名员工并都拥有账号，也就是说这个系统有5000个潜在用户。

根据系统日志分析得知，该系统最大在线用户数是2500人，那么从宏观角度来看，2500就是这个系统的最大并发用户数。但是，2500这个数据仅仅是说在最高峰时段有2500个用户登录了系统，而服务器所承受的压力取决于登录用户的行为，所以它并不能准确表现服务器此时此刻正在承受的压力。

假设在某一时间点上，这2500个用户中，30%用户处于页面浏览状态（对服务器没有发起请求），20%用户在填写订单（也没有对服务器发起请求），5%用户在递交订单，15%用户在查询订单，而另外的30%用户没有进行任何操作。那么此时，这2500个“并发用户”中真正对服务器产生压力的只有500个用户（（5%+15%）*2500=500）。

在这个例子中，5000是最大的“系统潜在用户数”，2500是最大的“业务并发用户数”，500则是某个时间点上的“实际并发用户数”。而此时这500个用户同时执行业务操作所实际触发的服务器端的所有调用，叫作“服务器并发请求数”。

从这个例子可以看出，在系统运行期间的某个时间点上，有一个指标叫作“同时向服务器发送请求的数量”，这个“同时向服务器发送请求的数量”就是服务器层面的并发用户数，这个指标同时取决于业务并发用户数和用户行为模式，而且用户行为模式占的比重较大。

因此，分析得到准确的用户行为模式，是性能测试中的关键一环。但，获得精准的用户行为模式，是除了获取性能需求外，最困难的工作。

目前，获取用户行为模式的方法，主要分为两种：

• 对于已经上线的系统来说，往往采用系统日志分析法获取用户行为统计和峰值并发量等重要信息；
• 而对于未上线的全新系统来说，通常的做法是参考行业中类似系统的统计信息来建模，然后分析。

响应时间

一般来讲，响应时间反映了完成某个操作所需要的时间，其标准定义是“应用系统从请求发出开始，到客户端接收到最后一个字节数据所消耗的时间”，是用户视角软件性能的主要体现。

系统响应时间，又可以进一步划分为Web服务器时间、应用服务器时间、数据库时间，以及各服务器间通信的网络时间。

软件的性能测试一般更关注服务器端。但是，服务器端响应时间的概念非常清晰、直接，就是指从发出请求起到处理完成的时间

响应时间应该包含两层含义：技术层面的标准定义和基于用户主观感受时间的定义。而在性能测试过程中，我们应该使用哪个层面的含义将取决于性能测试的类型。

对于软件服务器端的性能测试肯定要采用标准定义，而对于前端性能评估，则应该采用用户主观感受时间的定义。

系统吞吐量

系统吞吐量，是最能直接体现软件系统负载承受能力的指标。所有对吞吐量的讨论都必须以“单位时间”作为基本前提。

把“Throughput”翻译成吞吐率更贴切，因为我们可以这样理解：吞吐率=吞吐量/单位时间。但既然国内很多资料已经翻译为了“吞吐量”，所以通常情况下我们不会刻意去区分吞吐量和吞吐率，统称为吞吐量。

对性能测试而言，通常用“Requests/Second”“Pages/Second”“Bytes/Second”来衡量吞吐量。当然，从业务的角度来讲，吞吐量也可以用单位时间的业务处理数量来衡量。

• “Bytes/Second”和“Pages/Second”表示的吞吐量(考察系统层面或网络层面)，主要受网络设置、服务器架构、应用服务器制约；
• “Requests/Second”表示的吞吐量(考察HTTP或者业务层面)，主要受应用服务器和应用本身实现的制约。

这里需要特别注意的是：虽说吞吐量可以反映服务器承受负载的情况，但在不同并发用户数的场景下，即使系统具有相近的吞吐量，但是得到的系统性能瓶颈也会相差甚远。

比如，某个测试场景中采用100个并发用户，每个用户每隔1秒发出一个Request，另外一个测试场景采用1000个并发用户，每个用户每隔10秒发出一个Request。显然这两个场景具有相同的吞吐量, 都是100 Requests/second，但是两种场景下的系统性能拐点肯定不同。因为，两个场景所占用的资源是不同的。

这就要求性能测试场景的指标，必然不是单个，需要根据实际情况组合并发用户数、响应时间这两个指标。

29章：性能测试基本方法

1.并发用户数、响应时间、系统吞吐量之间的关系

1. 当系统并发用户数较少时，系统的吞吐量也低，系统处于空闲状态，我们往往把这个阶段称为 “空闲区间”
2. 当系统整体负载并不是很大时，随着系统并发用户数的增长，系统的吞吐量也会随之呈线性增长，我们往往把这个阶段称为 “线性增长区间”。
3. 随着系统并发用户数的进一步增长，系统的处理能力逐渐趋于饱和，因此每个用户的响应时间会逐渐变长。相应地，系统的整体吞吐量并不会随着并发用户数的增长而继续呈线性增长。我们往往把这个阶段称为系统的“拐点”。
4. 随着系统并发用户数的增长，系统处理能力达到过饱和状态。此时，如果继续增加并发用户数，最终所有用户的响应时间会变得无限长。相应地，系统的整体吞吐量会降为零，系统处于被压垮的状态。我们往往把这个阶段称为“过饱和区间”。

2.常见7种性能测试方法

把常用的性能测试方法分为七大类：后端性能测试（Back-end Performance Test）、前端性能测试（Front-end Performance Test）、代码级性能测试（Code-level Performance Test）、压力测试（Load/Stress Test）、配置测试（Configuration Test）、并发测试（Concurrence Test），以及可靠性测试（Reliability Test）

1.后端性能测试

是通过性能测试工具模拟大量的并发用户请求，然后获取系统性能的各项指标，并且验证各项指标是否符合预期的性能需求的测试手段。

性能指标，除了包括并发用户数、响应时间和系统吞吐量外，还应该包括各类资源的使用率，比如系统级别的CPU占用率、内存使用率、磁盘I/O和网络I/O等，再比如应用级别以及JVM级别的各类资源使用率指标等。

后端性能测试的场景设计主要包括以下两种方式：

• 基于性能需求目标的测试验证；
• 探索系统的容量，并验证系统容量的可扩展性

2.前端性能测试

前端性能关注的是浏览器端的页面渲染时间、资源加载顺序、请求数量、前端缓存使用情况、资源压缩等内容，希望借此找到页面加载过程中比较耗时的操作和资源，然后进行有针对性的优化，最终达到优化终端用户在浏览器端使用体验的目的。

业界普遍采用的前端测试方法，是雅虎（Yahoo）前端团队总结的7大类35条前端优化规则，你可以通过雅虎网站查看这些规则，以及对各规则的详细解读。

• 减少http请求次数：
• 减少DNS查询次数：
• 避免页面跳转：面跳转相当于又打开一个新的页面，耗费的时间就会比较长，所以要尽量避免使用页面跳转；
• 使用内容分发网络（CDN）：
• Gzip压缩传输文件：

3.代码级性能测试

是指在单元测试阶段就对代码的时间性能和空间性能进行必要的测试和评估，以防止底层代码的效率问题在项目后期才被发现的尴尬。

如果你从事过性能测试相关的工作，一定遇到过这样的场景：系统级别的性能测试发现一个操作的响应时间很长，然后你要花费很多时间去逐级排查，最后却发现罪魁祸首是代码中某个实现低效的底层算法。这种自上而下的逐级排查定位的方法，效率通常都很低，代价也很高。

需要在项目早期，对一些关键算法进行代码级别的性能测试，以防止此类在代码层面就可以被发现的性能问题，遗留到最后的系统性能测试阶段才被发现。

码级性能测试并不存在严格意义上的测试工具，通常的做法是：改造现有的单元测试框架。

最常使用的改造方法是：

1. 将原本只会执行一次的单元测试用例连续执行n次，这个n的取值范围通常是2000~5000；
2. 统计执行n次的平均时间。如果这个平均时间比较长（也就是单次函数调用时间比较长）的话，比如已经达到了秒级，那么通常情况下这个被测函数的实现逻辑一定需要优化。

4.压力测试

压力测试，通常指的是后端压力测试，不断对系统施加压力，并验证系统化处于或长期处于临界饱和阶段的稳定性以及性能指标，并试图找到系统处于临界状态时的主要瓶颈点。所以，压力测试往往被用于系统容量规划的测试。

5.配置测试

配置测试，主要用于观察系统在不同配置下的性能表现，通常使用后端性能测试的方法：

6.并发测试

并发测试，指的是在同一时间，同时调用后端服务，期间观察被调用服务在并发情况下的行为表现，旨在发现诸如资源竞争、资源死锁之类的问题。

“集合点并发”：为了达到准确控制后端服务并发数的目的，我们需要让某些并发用户到达该集合点时，先处于等待状态，直到参与该集合的全部并发用户都到达时，再一起向后端服务发起请求。简单地说，就是先到的并发用户要等着，等所有并发用户都到了以后，再集中向后端服务发起请求。

在实际项目中，我建议在要求的并发数上进行适当放大，比如要求的并发数是100，那我们集合点并发数可以设置为120。

7.可靠性测试

可靠性测试，是验证系统在常规负载模式下长期运行的稳定性。虽然可靠性测试在不同公司的叫法不同，但其本质就是通过长时间模拟真实的系统负载来发现系统潜在的内存泄漏、链接池回收等问题

真实环境下的实际负载，会有高峰和低谷的交替变化，我们会每12小时模拟一个高峰负载，两个高峰负载中间会模拟一个低峰负载，依次循环3-7天，形成一个类似于“波浪形”的系统测试负载曲线。同样地，可靠性测试也会持续3-7天。

3.性能测试的四大应用领域

• 能力验证
• 能力规划
• 性能调优
• 缺陷发现

30章：后端性能测试工具及原理

1.后端性能测试与后端性能测试工具的关系

千万不要简单地把使用后端性能测试工具等同于后端性能测试，它只是后端性能测试中的一个必要步骤而已。

完整的后端性能测试应该包括性能需求获取、性能场景设计、性能测试脚本开发、性能场景实现、性能测试执行、性能结果报告分析、性能优化和再验证。

使用性能测试工具获得性能测试报告只是性能测试过程中的一个必要步骤而已，而得出报告的目的是让性能测试工程师去做进一步的分析，以得出最终结论，并给出性能优化的措施。

2.后端性能测试工具和GUI自动化测试工具最大的区别

• 模拟用户行为的方式。
  • GUI：模拟的是用户的界面操作
  • 性能：模拟的是用户的客户端与服务器之间的通信协议和数据
• 测试的执行方式
  • GUI：单用户执行并验证功能结果
  • 性能：模拟大量的并发用户

3.后端性能测试原理？

名词解释：

1.我们把这些基于协议模拟用户行为的脚本称为虚拟用户脚本，而把开发和产生这些脚本的工具称为虚拟用户脚本生成器。

2.我们把实际发起测试负载的机器称为压力产生器。

3.有了多台压力产生器，那就需要一个专门的控制器来统一管理与协调这些压力产生器，我们把这个专门的控制器称为压力控制器。

4.后端性能测试工具需要监控应用服务器、数据库服务器、消息队列服务器、缓存服务器等各种资源的占用率。我们通常把完成监控和数据收集的模块称为系统监控器。

5.后端性能测试工具通常能够基于该报告生成各类指标的各种图表，还能将多个指标关联在一起进行综合分析来找出各个指标之间的关联性。我们把完成这部分工作的模块称为测试结果分析器。

首先，后端性能测试工具会基于客户端与服务器端的通信协议，构建模拟业务操作的虚拟用户脚本。

然后，开发完成了虚拟用户脚本之后，后端性能测试工具会以多线程或多进程的方式并发执行虚拟用户脚本，来模拟大量并发用户的同时访问，从而对服务器施加测试负载。

接着，在施加测试负载的整个过程中，后端性能测试工具除了需要监控和收集被测系统的各种性能数据以外，还需要监控被测系统各个服务器的各种软硬件资源。

最后，测试执行完成后，后端性能测试工具会将系统监控器收集的所有信息汇总为完整测试报告。

4.后端性能测试场景设计会涉及哪些内容？

• 并发数多少？
• 测试刚开始时，以什么样的速率来添加并发用户？(爬坡的速度是多少？)
• 达到最大并发数维持多久？(保持多长时间？)
• 测试结束，以什么样的速率来减少并发用户？(下坡的速度是多少？)
• 压测需要包含的业务？各个业务操作的占比是多少？(需要压测的业务流量占比)
• 一轮结束、间隔多久进行下一轮？
• 同一虚拟用户，业务操作间隔多久？(思考时间)
• 需要监控被测服务器哪些指标？
• 出错处理的方式是什么？
• 需要多少台压力发生器？

5.后端主流性能压测工具？

LoadRunne 和JMeter

LoadRunner:

​ 传统软件企业采用，(按照并发用户数收费的，并发用户数越高收费也越贵）

传统软件企业，需要测试的并发用户数并不会太高，通常是在几百到十几万这个数量级，

LoadRunner对海量并发的测试支持并不太好；

JMeter

​ 互联网企业的并发用户请求数量很高，很多软件都会达到百万，甚至是千万的级别。

​ 开源的JMeter中，用户完全可以根据需求进行扩展

31章：前端性能测试工具及原理

WebPagetest

这块我不做关注，略

32+33章：LoadRunner实战

阶段一：性能需求收集及负载计划制定

• 系统整体的并发用户数。比如，高峰时段会有10万用户同时在线；
• 并发用户业务操作的分布情况。比如，20%的用户在做登录操作，30%的用户在做订单操作，其他50%的用户在做搜索操作；
• 单一业务操作的用户行为模式。比如，两个操作之间的典型停留时间，完成同一业务的不同操作路径等；
• 并发用户高峰期的时间分布规律。比如，早上8点会有大量用户登录系统，晚上6点后用户逐渐退出；
• 达到最高峰负载的时间长度。比如，并发用户从0增长到10万花费的总时间；
• …

获取这些测试需求时性能测试中最难的两个工作之一。另一个最难的工作是，测试结果分析与性能问题定位。而其他类似性能测试脚本开发、场景设计等工作看起来很有技术含量，但实际都是一些相对机械性的重复工作。

对于性能测试设计人员来说，到底如何获得这个明确的性能需求呢？

你可以采用80/20原则对高峰时段的用户负载进行建模

性能测试需求的定义与计划非常复杂，牵涉到项目的方方面面，不可能通过阅读一两篇文章就快速掌握这一技能，需要不断地沉淀在实战中获得的经验。

从宏观角度，我把整个性能测试过程划分成了五个阶段：性能需求收集以及负载计划制定、录制并增强虚拟用户脚本、创建并定义性能测试场景、执行性能测试场景，以及分析测试报告。

在我看来，这五个阶段最难的两部分工作分别是：明确具体的性能测试需求，以及测试结果分析与性能问题定位。因为这两部分工作，要大量依赖于测试工程师的能力以及经验积累。所以，就像一名优秀的医生一样，优秀的测试工程师，需要在实际的工程项目中不断积累和总结经验。

阶段二：录制增强虚拟用户脚本

LoadRunner开发虚拟用户脚本主要包括以下四个步骤：

1. 识别被测应用使用的协议；
2. 录制脚本；
3. 完善录制得到的脚本；
4. 验证脚本的正确性。

1.识别被测应用使用的协议

如果已经知道被测系统采用的协议，则可以跳过这个步骤。

2.录制脚本

要将这些操作步骤在虚拟用户脚本中封装成“事务”（Transaction）。

封装为“事务”的目的是统计响应时间，因为LoadRunner中的响应时间都是以“事务”为单位的。

在录制脚本的过程中，我强烈建议直接对发起后端调用的操作添加事务定义，而不要等到脚本生成后再添加。因为LoadRunner脚本的可读性并不好，在录制完的脚本中添加事务定义的难度会很大。

在录制过程中，直接添加事务操作也很简单，主要包括如下三步：

1. 在开始执行GUI操作前，先点击图2中的“事务开始”按钮并填写事务名称；
2. 执行GUI操作；
3. 操作完成后，点击图2中的“事务结束”按钮。

这样你刚才执行GUI操作的脚本就会被lr_start_transaction(“事务名称”)和lr_end_transaction(“事务名称”，LR_AUTO)包围起来，也就完成了添加事务的定义。

3.完善录制的脚本

录制的脚本不能直接使用，我们还需要对录制的脚本做以下处理：

• 在两个事务之间加入思考时间（Think Time）；
• 对界面输入的数据做参数化（Parameterization）操作；
• 完成脚本的关联（Correlation）操作；
• 加入检查点（Check Point）。

1.两个事务之间的思考时间？

思考时间：两次发起请求之间往往会有一个时间的间隔。(了让虚拟用户脚本能够更真实地模拟实际用户的行为，我们就需要在两个事务之间加入一定的等待时间。)

在实际项目中，一般先粗略估计一个值（比如15 s），然后在实际执行负载场景的过程中，再根据系统吞吐量调整。

调整思考时间时，无需逐行修改虚拟用户脚本代码，可以在Run-time Settings（运行时设置）中很方便地完成。

2.输入数据的参数化

凡是参数文件中使用的测试数据都需要在执行性能测试前，在被测系统中事先准备好

3.脚本关联操作

关联的主要作用是，取出前序调用返回结果中的某些动态值，传递给后续的调用。

LoadRunner提供了功能强大的关联函数web_reg_save_param()。这个关联函数支持多种动态值的获取方式，用得最多的是基于“前序字符串匹配”加上“后续字符串匹配”的方式。其中，字符串匹配，支持正则表达式。

需要特别注意的是web_reg_save_param()函数是注册型函数，必须放在获取动态值所属的请求前面，相当于先声明，后调用。

4.加入检查点

性能测试脚本，不像功能测试脚本那样需要加入很多的断言，往往只在一些关键步骤后加入很少量的检查点即可。这些检查点的主要作用是，保证脚本按照原本设计的路径执行。

最常用的检查点函数是web_reg_find()，它的作用是通过指定左右边界的方式“在页面中查找相应的内容”。

4.验证脚本正确性

1. 以单用户的方式，在有思考时间的情况下执行脚本，确保脚本能够顺利执行，并且验证脚本行为以及执行结果是否正确；
2. 以单用户的方式，在思考时间为零的情况下执行脚本，确保脚本能够顺利执行，并且验证脚本行为以及执行结果是否正确；
3. 以并发用户的方式，在有思考时间的情况下执行脚本，确保脚本能够顺利执行，并且验证脚本行为以及执行结果是否正确；
4. 以并发用户的方式，在思考时间为零的情况下执行脚本，确保脚本能够顺利执行，并且验证脚本行为以及执行结果是否正确。

只有上述四个测试全部通过，虚拟用户脚本才算顺利完成

阶段三：创建并定义性能测试场景

根据前面的测试场景，进行图形操作即可

阶段四：执行性能测试场景

点击执行即可，还可以监控测试执行的过程

阶段五：分析测试报告

性能测试报告的解读，需要丰富的系统架构、性能理论以及大量实战经验的积累。这个话题已经超出了我今天要分享的范围，所以我也就不再继续展开了。

这里有留言推荐 wrk测试工具的，先记录下来

34章：企业级性能测试案例与经验分享

• 性能基准测试；
• 稳定性测试；
• 并发测试；
• 容量规划测试

1.性能基准测试

性能基准测试，通常被称为Performance Benchmark Test，是每次对外发布产品版本前必须要完成的测试类型。通过执行固定的性能测试场景得到系统的性能测试报告，然后与上一版本发布时的指标进行对比，如果发现指标有“恶化”的趋势，就需要进一步排查。

恶化趋势表现：

• 同一事务的响应时间变慢了
• 系统资源的占用率变高了
• 网络带宽的使用量变高了，比如，上一版本中，发送总字节数是20 MB，接收总字节数是200 MB，但是在最新的被测版本中发送总字节数变成了25 MB，接收总字节数变成了250 MB。

以最常见的事务响应时间变慢为例，和你说明一下排查方法。

假设，通过性能基准测试的比较结果得知，用户登录的响应时间从2 s变成了4 s。

1. 首先要做的是验证在单用户的情况下，是否会出现响应时间变长的问题.
   1. 将用户登录的虚拟用户脚本单独拿出来，建立一个单用户运行的性能测试场景并执行，观察用户登录的响应时间是否变慢。
   2. 如果变慢了，就说明这是单用户登录场景就可重现的性能问题，后续的处理也相对简单了。解决方法是：分析单用户登录的后端日志文件，看看完成登录操作的时间具体都花在了哪些步骤上，相比之前哪些步骤花费的时间变长了，或者是多出了哪些额外的步骤。
   3. 如果没有变慢，则说明我们必须尝试在有压力的情况下重现这个性能问题。为此，我们要基于用户登录的虚拟用户脚本构建并发测试的场景，但是我们并不清楚在这个场景设计中到底应该采用多少并发用户、加入多长的思考时间。这时，通常的做法是，直接采用性能基准测试中的并发用户数和思考时间，去尝试重现问题。如果无法重现，我们可以适当地逐步加大测试负载，并观察响应时间的变化趋势
   4. 这里需要注意的是，千万不要使用过大的测试负载。因为测试负载过大的话，系统资源也会成为性能瓶颈，一定会使响应时间变长。但这时，响应时间变长主要是由资源瓶颈造成的，而不是你开始要找的那个原因。

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

从性能基准测试的设计角度来看，你需要特别注意以下三点：

1. 性能基准测试中虚拟用户脚本的选择以及配比，需要尽可能地匹配实际的负载情况；
2. 总体的负载设计不宜过高，通常被测系统的各类占用率指标需要控制在30%以内，尽量避免由于资源瓶颈引入的操作延时；
3. 每次性能基准测试前，一般需要对系统资源以及网络资源做一轮快速的基准测试，以保证每次被测环境的一致性，同时也要保证数据库的数据量在同一个级别上。总之，你需要采用一切可能的手段，来确保多次性能基准测试之间的环境一致性。

2.稳定性测试

稳定性测试，又称可靠性测试，主要是通过长时间（7*24小时）模拟被测系统的测试负载，来观察系统在长期运行过程中是否有潜在的问题。

稳定性测试，通常直接采用性能基准测试中的虚拟用户脚本，但是性能测试场景的设计和性能基准测试场景会有很大不同：

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

稳定性测试成功完成的标志，主要有以下三项：

• 系统资源的所有监控指标不存在“不可逆转”的上升趋势；
• 事务的响应时间不存在逐渐变慢的趋势；
• 事务的错误率不超过1%。

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

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

3.并发测试

并发测试，是在高并发情况下验证单一业务功能的正确性以及性能的测试手段。

高并发测试一般使用思考时间为零的虚拟用户脚本来发起具有“集合点”的测试。

并发测试，往往被当作功能测试的补充，主要用于发现诸如多线程、资源竞争、资源死锁之类的错误。

加入“集合点”一般有两种做法：

1. 在虚拟用户脚本的录制过程中直接添加；
2. 在虚拟用户脚本中，通过加入lr_rendezvous()函数添加。

4.容量规划测试

容量规划测试，是为了完成容量规划而设计执行的测试。

容量规划的主要目的是，解决当系统负载将要达到极限处理能力时，我们应该如何通过垂直扩展（增加单机的硬件资源）和水平扩展（增加集群中的机器数量）增加系统整体的负载处理能力的问题。

容量规划测试具体要怎么做呢？

使用性能基准测试中的虚拟用户脚本，以及各个业务操作脚本的百分比，压测单机部署的被测系统。我们会采用人工的方式不断增加测试负载直到单机系统的吞吐量指标到达临界值，由此就可以知道单台机器的处理能力。

理论上讲，整个集群的处理能力将等于单台机器的处理能力乘以集群的机器数，但是实际情况并不是这样。实际的集群整体处理能力一定小于这个值，但具体小多少就是要靠实际的测试验证了。

补充性能测试工具wrk，goreplay

附上华为云的性能测试策略与指标分析

1.性能测试曲线模型

2. 性能测试流程

测试报告解读