性能测试之基准测试

一、基准测试 1、定义

通过设计合理的测试方法，选用合适的测试工具和被测系统，实现对某个特定目标场景的某项性能指标进行定量的和可对比的测试。 2、特质

①、可重复性：可进行重复性的测试，这样做有利于比较每次的测试结果，得到性能结果的长期变化趋势，为系统调优和上线前的容量规划做参考。 PS：这种特质是为了满足基准测试的日常轮询需要。

②、可观测性：通过全方位的监控（包括测试开始到结束，执行机、服务器、数据库），及时了解和分析测试过程发生了什么。

③、可展示性：相关人员可以直观明了的了解测试结果（web界面、仪表盘、折线图树状图等形式）。

④、真实性：测试的结果反映了客户体验到的真实的情况（真实准确的业务场景+与生产一致的配置+合理正确的测试方法）。

⑤、可执行性：相关人员可以快速的进行测试验证修改调优（可定位可分析）。 3、前置条件

基准测试一定要在可控的条件下进行。

面对日益复杂的系统和不断增长的用户数，以及性能测试可能涉及到的多个业务系统，只有做到基准测试所涉及的业务场景、系统架构、测试环境等在可控状态下， 才能得到相对准确的结果，为容量规划、缺陷定位、系统调优提供参考和依据。 4、意义

①、为容量规划确定系统和应用程序的极限； ②、为配置测试的参数和配置选项提供参考依据； ③、为验收测试确定系统是否具备自己所宣称的能力；

④、为性能基线的建立提供长期的数据统计来源以及比较基准； 5、前提

①、测试目的：明确测试的目的，测试什么？用什么测试方法、策略？ ②、测试环境：被测系统的环境是什么，SIT还是UAT活着PAT？ ③、测试限制：要执行测试有哪些限制因素，该如何解决？ ④、风险因素：测试可能存在哪些风险，解决方案是什么？

⑤、结果分析：对测试结果如何分析？测试产生的数据如何分析、定位？ 6、原则

①、测试策略：稳定且连续的工作负载，多次运行，看测试结果数据的正态分布趋势，尽量取平均值；

②、数据统计：真实环境下测试数据的平均值、峰值各是多少，取值的维度； ③、差异风险：明确存在哪些风险，风险对测试结果的影响，是否忽略；

④、特殊情况：有哪些特殊情况，是否有对应的解决方案（比如支付场景中的支付服务调用，是否采用挡板等）； 7、需要考虑的因素

交易配比：某些业务场景，一个流程包含多个事务，在模拟并发中，不同的事务各自的占比；

突发性的读写操作：某些特殊业务场景，会有短时的大流量冲击或者请求数量骤减，该如何模拟（浪涌测试）；

系统配置：不同环境的系统配置不同，测试结果如何换算、如何对比？ 测试时长：测试执行过程中，运行多长时间，不同交易运行的时间分配等； 结果展示类型：平均值、峰值、百分比值如何展示，如何对比？ 成功/失败占比：每次测试过程中，成功和失败的事务占比统计； 是否可重现：如测试过程中出现报错或某些异常情况，是否可以重现？

是否可对比：是否有其他测试工具或者测试结果进行对比（尽量多次执行测试，进行测试结果对比：标准方差、正太分布了解一下？）？ 8、简单可行的方法

逐渐增加系统负载是一个确定系统所能处理的最大吞吐量的简单办法，也是寻找系统性能拐点的可行策略（阶梯式加压测试）。 9、重点

基准测试的工作重点是统计分析：可以从以下几个维度去进行统计：

①、选择合适的测试工具，设定合理的测试方法以及需要确认的系统性能指标； ②、选择不同的测试工具，对测试结果进行对比，选择稳定且能反应系统真是性能表现的结果；

③、多次执行测试，收集大量的测试数据集和指标； ④、从不同维度解读分析数据，生成报告。

二、基准测试MVP方案 1、思维导图

2、测试策略 策略名称 运行时间 阈值 性能指标 基线 注释 并发测试 CPU75%+ Error0.01% 10-30min 并发数、TPS、RT、内存占比 并发数、TPS、RT、内存占比 并发数、TPS、RT、内存占比 并发基线 并发测试得到的结果可以作为 实际生产环境峰值流量下的性能表现 容量测试 CPU＜100%+ Error0.01% CPU＜100%+ Error0.01% 10-30min 容量基线 一般来说90%即可作为阈值 双节点测试 10-30min 负载均衡基线 应考虑随着服务节点的增加，性能的 递减效应，一般每增加1个节点，理论 上性能递减2-5%（以实际测试结果为准） 稳定性测试 CPU75%+ Error0.01% 并发数、≥12h TPS、RT、内存占比 稳定性基线 稳定性的运行时间根据具体情况调整， 一般不能低于12h 3、系统配置 nCnG：性能测试可能涉及多个系统，每个系统的服务器配置存在不同，因此要明确不同系统的硬件配置，这样也方便针对性的设定测试策略以及分析性能指标。 内存分配：这里主要指的是堆内存分配，需要根据具体的服务器配置进行分配，当然，最好针对性的进行配置测试来确定内存的合理分配。 应用版本：以JDK为例，每个版本都有不同的改进和优化，且被测系统环境应与实际生产环境保持一致的版本。 线程池：线程池数量，也是一个需要重视的问题（我本人就遇到过由于线程耗尽最终导致的OOM）。 最大连接数：容器、DB的最大连接数，消息队列的消费者数量，也是一个需要考虑的因素。 缓存策略：为了提高系统应对大流量冲击以及提高可用性，缓存是离不开的一种方法，这里需要关注的是缓存命中以及缓存穿透的问题。 4、环境选型 SIT：一般来说很少在SIT环境进行基准测试，原因很多，比如：交叉影响、稳定性、配置不一致甚至多个项目部署在同一个SIT环境等。 UAT：大多数时候，性能测试都是在UAT环境下进行，因为UAT相比SIT稳定性更好，已经通过了系统测试阶段，且进行性能测试的成本相比生产环境更低。 PAT：在生产环境进行性能测试，测试结果的准确性是最高的，但也需要考虑到这几点因素：数据污染、隔离、改造成本、不能影响实际生产业务运行、测试时间等。 5、执行方式 稳定施压：上面提到的并发、容量、双节点、稳定性测试一般都是基于一个固定的并发数来模拟负载进行测试，具体的并发数值需要根据实际的用户数、使用频次、业务场景考虑。 浪涌测试：在实际生产环境中，有时候存在这种情况：短时间内有很高的流量冲击，比如限时秒杀等场景。

阶梯式加压：阶梯式加压是寻找系统拐点的最有效的方式。 6、风险预估

在进行基准测试前，要考虑到以当前的环境、业务模型、系统配置可能存在哪些影响测试的因素，以及影响程度、应对策略，比如：网络延时、网络波动、交叉影响等。 7、业务模型

基准测试的业务模型选择，无论是从实施难易程度或者成本考虑，一般都以以下三种类型出发：

核心业务：一般来说核心业务的重要性和使用频次都是优先级最高的，比如支付、订单。 高频次业务：查询、更新等高频操作场景，也是需要重点关注的场景。

日常轮询业务：基准测试的实施前提就是可重复执行和长时间进行测试，这样才可以进行对比和统计，来分析长期的系统性能基线变化。 8、工具选型

性能测试过程中，需要借助的工具很多，使用占比最高的为以下几种： 负载生成工具：比如Jmeter、Loadrunner、Locust、Gatling、Artillery。 应用监控工具：主要用来监控服务端的各项指标，比如Nmon、Skywalking。 代码分析工具：比如SonarQube、Codacy，一般结合持续集成工具来进行。 日志分析工具：比如现在最常用的ELK。 DB监控工具：比如Zabbix、DBMonitor。 9、异常处理

在性能测试过程中，经常会遇到一些异常情况，比如超时、失败、接口依赖、敏感数据等情况，针对这些情况，设计合理可行的解决方案。 10、统计维度 测试的结果一定要方便从各个层次、维度进行统计，这样可以为后续的分析提供更可靠的数据来源，以响应时间来说，一般从以下几个维度统计： 维度 峰值 极值 平均值 百分比值 举例 取系统CPU在75%左右的表现进行多次统计，加权平均计算 取系统CPU＜100%的表现进行多次统计，加权平均计算 平均值的统计，比较适用于响应时间波动不大的情况 对于服务集群部署或者分布式部署的系统，百分比值，更能反映系统的性能表现 适用测试策略 并发测试 容量测试 双节点测试 稳定性测试 11、查询展示 上篇博客介绍过，基准测试的结果一定要便于统计展示，可以明了直观的展示给相关人员，一般来说，可以从不同维度，粒度从大到小的形式进行查询展示，比如： 维度 说明 比如默认展示最近一个月的基准变化，也可以设置根据时间来查询不同时间范围内的基准表现 对于涉及对个业务系统的情况，可以根据系统名称进行查询 从核心业务、高频次业务、日常轮询业务等维度，进行展示 时间范围 系统名称 业务模型 测试策略 根据基准测试的策略，从并发、容量、双节点、稳定性等角度进行查询展示 可以通过web页面、仪表盘、折线图、树状图等形式，进行不同角度的系统基准表现展示，具体如何设计，可以进行需求调研，然后针对性的设计。