性能测试实施流程

前言

说到性能测试，不同的小伙伴有不同的认知，并且在中国，一部分公司的性能测试的流程是这样子的：只说明要压测的接口，甚至连性能指标都没。然后测试人员使用工具添加必要的控件，压测，看工具自带的监控结果是否满足（问领导），满足，继续加，不满足，降低并发继续，实在不行了，让开发调优。测试人员等开发说调优好了，然后继续之前的流程。这种情况，造成了一些小伙伴认为性能测试就是写测试脚本，测试人员在性能测试中沦为了脚本编写和执行的工具人，可替代性更不必说了。
那么，什么样才是比较完善的性能测试实施流程呢？这篇内容就是讲述一种适用性较高的性能测试实施流程。

• 作用
  一套规范的性能测试实施流程能根据业务模型去摸底系统的线上能力，从技术上去评估线上系统的真实性能，更好地规避系统上线后的风险

---

一、业务模型

1.1、分析

一个系统中，往往有多个业务逻辑，而不同的业务逻辑在使用过程中，用户数量和所消耗的资源也是不一样的。业务种类、业务占比决定了系统的处理能力的侧重，更多会侧重于用户量多，使用时间久的业务。但是，也不能忽略一些业务占比较低，但是功能对系统而言较为重要的功能。因此，业务模型在性能测试中起到关键性的作用。

• 典型业务策略
  一般情况下是选取业务量高，使用率高，有增长趋势，有一定风险的业务来作为系统的典型业务
• 比如说多C 端的营销类系统，性能方面会更侧重于用户数据、活动营销相关的业务。场景1：多C端系统，活动是用户通过海报二维码扫描进入活动页面（简单引流），通过埋点数据监测用户的行为状态，并针对不同行为状态的用户，进行用户回捞行为。因为多C 端（涉及小程序、H5、公众号、App），需要对用户进行注册合并登录等操作，多用户进来时，对应的业务逻辑压力剧增；进入活动页面的接口；埋点数据的上传和处理；不同行为状态用户的回捞行为（涉及到用户分组处理，消息发送）；数据报表功能对这些营销数据的展示，运营人员会阶段性根据这些数据进行下一步的运营方案的策划（业务占比低，但是较为重要的功能）。

1.2、风险

上面例子是粗浅分析，具体需要和产品人员、运营人员一起讨论，并得出测试指标。因为如果分析的业务模型中的业务、业务占比和线上实际情况差距过大，会导致测试结果毫无参考价值，对系统的性能产生了误判，线上更容易出现性能问题。

1.3、线上系统参考

线上系统，一般是通过系统运行历史中，高峰时段的业务量和生产中出现的性能问题来进行评估

• 业务模型验证
  搜集线上环境时，高峰阶段项目的高频业务的用户量是否如业务模型的分析结果。如果有大的出入，需要再次进行业务模型分析。
• 生产问题
  搜集线上出现的跟性能相关的问题，比如说出现资源消耗过大的情况，那需要分析下是什么业务导致的，看是否是某些遗漏掉的业务导致的。在后续的性能测试中，需要补上。

1.4、未上线系统参考

未上线的系统，一般是通过多方调研和单次交易时所消耗的资源来进行评估

• 调研阶段
  1.确定高频率的业务和指标
  2.确定哪些业务存在“突变”的风险（存在突然用户量/数据暴增的情况）

二、系统环境

系统环境可概括分为生产环境和测试环境

2.1、生产环境

生产环境也就是项目线上运行环境。在生产环境上进行性能测试时，需要挑选在低峰时间段进行，避免影响生产环境的正常业务。

• 优点
  得到的结果更加准确，更具有参考价值
• 缺点
  创建数据时要考虑其完备性，并且在测试完成后，需要完全清理所产生的测试数据，可参考全链路压测

2.2、测试环境

相对于生产环境，在测试环境上进行性能测试时，因为不会影响到生产环境，所以风险更加可控。
由于测试环境搭建成本问题，一般都会考虑等比构建的方法：按照系统环境的1/2，1/4，1/8等比例进行搭建测试环境，比如：系统资源、应用实例等进行等比例搭建。甚至会采用部分应用/服务独立部署测试集群，数据库共用，比如：需要测试客户档案服务的性能，之前可能该应用和其它应用部署在同一台服务器上，那么此时就是给客户档案服务按照系统环境或等比例，再添加对应台数的服务器建立集群；数据库共用这里没接触过，个人认为可能指的是测试服和其它服务（比如渠道服务）进行数据库共用，一般指的是机器或同库共用。（这里如果有知道的同学，望评论指点）

• 数据
  测试环境的基础数据，最好是导入生产环境脱敏后的数据，并且保留数据整体的完备性（比如一个用户相关的所有数据），至于数据的量，需要看具体需求来决定。数据的真实性，对于测试结果的影响较大。

• 风险
  测试环境的风险主要是体现在和生产环境的差异程度上。如果和生产环境的差异过大，那么测试数据可以说毫无价值，甚至造成反作用。

• 环境调研
  在搭建测试环境之前，需要先调用生产环境一些内容：
  1、操作系统
  操作系统平台类型和版本号
  2、系统架构
  主要是了解系统组成的各个层级功能，以及层级之间的关系，比如说核心基础服务层有客户档案基础服务，比如业务胶水层的各个服务，或多或少对核心基础服务层有所依赖。
  了解层级功能和层级关系，主要是为了后面进行性能瓶颈分析和生产环境的性能评估。
  3、中间件
  中间件的范围有点广，常用的中间件有：Tomcat、Apache、Nginx、MQ、Dubbo、Kafka、Kylin等。需要对中间件进行监控，以便于后期的性能瓶颈分析
  4、数据库
  数据库和版本号，比如mysql、es、ClickHouse等。同样，需要对其进行监控，以便于后期的性能瓶颈分析
  5、应用
  应用需要开启多少个实例，启动命令中的参数都有哪些。这些在后期的性能瓶颈分析中需要用到
  6、服务器对应的服务
  需要知道哪台服务器中搭建了哪些服务，比如说基础服务、外网访问服务、Dubbo服务、API与路由服务、ES集群服务等。以便快速查看到想要看到的服务监控数据和服务器资源数据。

• 测试环境搭建
  测试环境的搭建，尽可能满足下面的规范：
  1、测试环境架构和生产环境架构完全相同
  2、测试环境服务器机型和生产环境服务器机型尽量相同；如果是云服务器，那么需要是同种规格的ECS或者容器
  3、测试环境的软件版本和生产环境的软件版本完全相同，一般是：操作系统、中间件、数据库、应用等
  4、测试环境的参数配置和生产环境的参数配置完全相同，一般是：操作系统、中间件、数据库、应用等
  5、测试环境的基础数据量和生产环境的基础数据量需要在同个量级上，比如说千万级，亿级。
  6、当按照生产环境等比例搭建测试环境时，需要等比例减少全部服务的机器台数，而不是单单减少某个服务的机器台数；并且应用、连接数等配置项这些也需要等比例减少

三、测试类型

在服务端性能测试中提过，个人认为，最常用的性能测试类型有三种：基准测试、负载测试、压力测试。具体细分如下所述：

• 单交易基准测试（可选）
  在测试环境部署好后，对确定下来的业务流程中的接口，依次进行单用户、单交易/接口的基准测试，从而为以后的性能测试得到性能基准和参考值。
  例子：jmeter中，设置单并发，测试单个接口，持续10分钟，每次请求间隔1秒。进行完毕后，获取平均响应时间、TPS等数据，以及服务器的资源消耗为性能基准参考值。

• 单交易负载测试（大概率）
  对确定下来的业务中的接口，执行多用户、单交易的负载测试，也就是通过不断增大负载（并发）来测试出单个接口的最大负载，从而暴露出性能问题，进行调优。
  例子：jmeter中，逐步增加并发数，对单个接口进行测试，同时监控服务器的资源消耗（施压机和服务器）

• 单交易压力测试（可选）
  对单接口进行压力测试，也就是在高负载（高并发、大数据量）下进行长时间的测试，查看是否能够持久稳定运行

• 混合交易负载测试（必须）、混合交易压力测试（可选）
  混合交易：指的是根据业务模型分析出来的结果（业务的比例），多并发对多个交易/接口进行施压。
  比如：jmeter中，一个计划设置多个线程组（对应业务），然后每个线程组的并发数按照业务的比例进行设置，最后在测试报告“聚合报告”获取到平均响应时间、TPS等数据，以及对服务器进行监控，获取到服务器的资源消耗为性能基准参考值。（或者使用逻辑控制器来进行并发数控制）这种混合交易类型的测试，最贴切线上生产环境
  具体的负载测试和压力测试，如单交易所述

四、测试指标

详细的性能指标可以看性能测试常见指标，这里按照测试的时候会关注，或者分析的时候需要关注的指标来进行分类：

• 业务指标
  比如：并发数、TPS、响应时间、成功率等
• 资源指标
  比如：CPU使用率、内存利用率、磁盘I/O、网络I/O等
• 另外监控的指标
  比如：数据库连接数、函数/第三方API耗时、空闲线程数等
• 前端指标
  比如：网络时间（DNS+TCP连接+传输）、页面加载时间

4.1、必要性

不同系统，不同业务，不同的用户，对性能指标的要求都不同。在进行性能测试之前，需要进行调研，并获取到性能指标，一般来说有用户数、响应时间、TPS、成功率、服务器资源消耗上限等。
如果在执行性能测试时，没有明确的性能指标，那么会导致性能测试毫无目标，得到的结果很有可能是无效的。

4.2、业务指标

详情看性能测试常见指标

4.3、资源指标

服务器资源指标一般会有上限指标，因为需要给系统预留“容错空间”。比如说：CPU资源利用率<=80%，内存无SWAP之类的指标。
性能测试理想情况下是业务指标上不去的时候，服务器资源是瓶颈的原因，这种情况，只要加服务器资源，那么业务指标就能上去了；但是实际情况，大部分时候业务指标上不去时，服务器资源还是很充裕的，是其它原因造成的性能瓶颈。
详情看性能测试常见指标
PS.施压机的资源也需要监控

4.4、另外监控的指标

归类到这里的指标，就需要结合业务和后端代码设计来分析需要监控哪些指标。这类的指标，一般都需要后端在代码中进行对应的日志记录来采集，或者运维人员进行监控。在测试完毕后，业务指标值、资源指标值和这里监控的值结合分析，看造成性能瓶颈的具体原因在哪。
比如说：一个接口，需要在mysql进行写入操作，同时需要经过mq消费写入到es。那么就需要监控mysql的连接数（使用和释放情况）、写入速度（关系到锁）、mq的消费速度等可能是原因的地方。

五、数据量

性能测试的数据量，可以分成两种：基础数据量、参数化数据量。

5.1、作用

数据量在性能测试中的作用很重要。在数据库中仅有几条记录，和有上千万上亿条记录的情况下，所进行的性能测试所得到的性能结果是差距很大的，特别是查询相关的。我们在进行性能测试时，应该是在尽可能模拟线上生产环境的情况下进行，这样得到的结果才具有参考价值。
在生产环境中插入测试数据的方式，需要考虑数据的完备性（贴切真实数据）、如何清理测试数据等问题，具体了解：全链路压测

5.2、基础数据量

在测试环境时，数据量需要和生产环境的数据量保持同量级，具体考虑多久，得结合系统的预计生命周期来评估，一般都是年为单位，比如说2年后的数据量，这里需要考虑到数据量的增长速度
基础数据量不单只考虑到数据的“量”，还需要考虑到数据的“类型”，比如说用户基础数据、活动的数据、埋点的数据；
可能还考虑数据的“新旧”，比如说多少数据会是“死”数据，也就是不活跃的数据，多少数据会是“老用户”数据，“新用户”数据等。这种类型的数据比较难预估，而且不同“新旧”的数据，其关联的数据量也是不一样的。

5.3、参数化数据量

1.参数化数据量尽可能的多，必要的情况下，可以清除缓存或者用写代码的方式提供参数化。
2.参数化数据分布，如果业务有明显的地域等分布的特征，需要考虑数据分布的情况。

5.4、创建数据量的方法

造数据需要尽可能真实，比如说创建的用户名都有“测试”两个字，然后执行查询接口的性能测试时，keyword是性能，这样测试结果毫无意义，因为使用了缓存。
1、从生产数据库中导入（最优）
2、脚本直接写入数据库（数据库不仅mysql，还包括es等）
3、压测工具，比如jmeter进行生产（执行写入操作的接口测试时，也会生成测试数据，这些数据也需要尽可能真实）

六、压测场景和串联链路

这两个名词，是引用的阿里性能测试PTS的说法（PTS需付费），来让我们更清晰了解到压测场景配置相关的知识。阿里性能测试PTS

6.1、压测场景

要发起一次性能压测，首先需要创建一个压测场景。个人觉得把场景看成一个对业务/串联链路的分组更容易理解。
一个压测场景包含一个或多个并行的业务（即串联链路），每个业务包含一个或多个串行的请求（即 API）。
API 是场景压测中的必需元素，用来定义串联链路中每个阶段 URL 的具体信息。API 是由用户行为触发的一条端上请求。例如，电商网站的登录、查询商品详情、提交订单等，分别对应一次用户行为中的多个请求 API。

• 并发数
  在测试过程中，各个业务的并发数应该和生产环境中业务占比一致（业务模型）。
  那么如何计算业务之间的并发数的比例呢？比如：
  A和B两种业务的占比是1 : 5，响应时间分别是1ms : 100ms，传统的并发模式，A和B的并发数比例应该是1 : 500。如果使用阿里PTS压测特有的RPS模式（Requests per second/直接测试吞吐能力），那么则是1:5。详情看并发虚拟用户、RPS、TPS的解读

创建PTS施压场景-施压配置-传统模式
创建PTS施压场景-施压配置-RPS模式

。

6.2、串联链路（引用阿里PTS的说法）

串联链路一组压测 API 的有序集合（类似于事务），是用来模拟用户的实际业务操作的，具有业务含义。一个压测场景下可以有一个或多个串联链路。
比如说淘宝网需要压测两个业务，要求两个业务同时进行：

• 业务 A：浏览产品 A，只有一个请求
• 业务 B：购买产品 B，包含四个请求，要求四个请求按照先后顺序发起：
  请求 1：登录
  请求 2：浏览产品 B
  请求 3：加入购物车
  请求 4：提交订单

• 风险
  串联链路对实际业务的模拟场景，和生产环境中用户的实际业务流程的差距大小，直接影响到测试结果的参考价值。十分依赖于前面所说的业务模型。

• 规范
  1、API的执行顺序，需要和实际业务场景中的顺序一样
  2、数据尽量参数化，并且数据量尽可能多
  3、需要在每个API上添加必要的断言，以确保业务的确执行成功

七、监控

监控的目的是为了对测试结果进行分析。完善的系统监控，会在针对瓶颈定位中起到事半功倍的效果。监控的范围包括但不仅限于：操作系统的资源、中间件、数据库、应用等。每种类型的监控方向需要尽可能全面。
如果没有完善的监控体系，会导致在进行性能瓶颈分析时无从下手，只能看着那仅有的几个指标值干瞪眼，瞎猜。找不到性能瓶颈的，更谈不上性能调优了。

7.1、监控维度

监控的对象和维度一般如下：

• 操作系统
  CPU利用率、内存利用率、磁盘I/O、网络I/O等

• 中间件
  线程池、jdbc连接池、JVM（GC/FULL GC/堆大小）、MQ的消费速率、KifKa的消费速率等

• 数据库
  大量使用的SQL、效率比较底下的SQL、锁、缓存、进程数、会话等

• 应用
  应用中函数的耗时、缓存、缓冲、同步和异步（缓存和缓冲的区别）

7.2、监控工具

监控工具一般都是由运维人员部署，但测试人员也需要了解以及入门，毕竟不是所有公司都有运维人员。
常用服务器监控工具：htop命令或运维监控工具，比如zabbix、nmon等
对中间件、数据库、应用层面的监控以及问题工具定位工具：APM工具（开源APM工具），阿里云ARMS

ARMS示意图

八、瓶颈分析

瓶颈分析依赖于测试报告和监控数据，而瓶颈分析又是为了系统调优做准备，系统的性能瓶颈主要分布在：服务器操作系统资源、中间件参数配置、数据库、代码问题等。我们进行瓶颈分析，定位到具体原因，那么调优就可以有的放矢地进行。

8.1、必要性

如果瓶颈问题不能定位出来，那么生产环境的业务就一直处于“埋雷”状态，存在风险。并且新业务的迭代添加，可能会扩大这个风险。会导致生产环境中，业务高峰期时，系统性能变差，用户体验差，甚至可能系统崩溃。

8.1、分析维度

瓶颈分析时，需要结合业务指标数据（TPS、成功率、响应时间等）和监控数据来进行分析。瓶颈分析维度和监控的维度差不多

• 操作系统
  CPU利用率、内存利用率、磁盘I/O、网络I/O等

• 中间件
  线程池、jdbc连接池、JVM（GC/FULL GC/堆大小）、MQ的消费速率、KafKa的消费速率等

• 数据库
  大量使用的SQL、效率比较底下的SQL、锁、缓存、进程数、会话等

• 应用
  应用中函数的耗时、缓存、缓冲、同步和异步

• 压力机资源消耗
  如果是使用虚拟服务器，或者个人机器充当压力机，那么压力机的资源可能会成为性能瓶颈。如果使用阿里PTS压力机，由于有保护机制和调度机制，这个可能性则很小。

九、调优

调优一般是在实际性能指标达不到预期的性能指标的情况下进行的，目的是为了提高系统的性能，方法是针对性能瓶颈点进行对症下药，验证是通过再次的性能测试进行，看调优后的系统性能如何、涨幅如何。

9.1、调优方向

• 操作系统
  一般情况下，系统资源不够用，并不是真的“不够用”，可能是因为应用的配置问题所导致的。而如果真的是系统资源不够用，则需要视情况添加资源，增加机器数量或者提高机器的资源。

• 中间件
  一般情况下，中间件是参数配置导致的，比如说线程数/连接数的配置不合理，MQ配置，JVM配置等原因（具体调优方式得具体分析而定，比如MQ如果只是加实例，就是敷衍的做法）

• 数据库
  效率低下的SQL修改、死锁、所等待、缓存命中率、连接数等

• 应用
  应用中函数的耗时、缓存、缓冲、同步和异步、算法等

X、总结

性能测试流程

• 前期准备
  根据业务模型、测试指标、测试类型、数据量、系统环境等制定测试方案
• 脚本准备
  制定压测场景、串联链路、并发数比率，编写成脚本，具体使用什么工具看个人以及公司情况，jmeter、loadrunner、PTS都可，不过后面两个付费才能用于实际项目，否则
• 执行过程
  执行前，需要对需要监控的地方做好监控准备（打点日志、工具等），然后执行过程进行监控
• 调优过程
  根据测试结果中的业务指标数据和监控数据，看是否符合性能指标，看是否需要调优。如果需要，则进一步进行调优。
• 循环
  调优完毕后，循环执行过程和调优过程，期间会进行诸如改变测试方法、修改并发数之类的，这些根据实际情况自行决定