性能测试指南

1.类型介绍

说明： a点：性能期望值 b点：高于期望，系统资源处于临界点 c点：高于期望，性能处于拐点 d点：超过负载，资源不够用，系统处于崩溃 通过如上模型图中的情况，我们大致可以将当前性能测试分成如下4类：性能测试、负载测试、压力测试、稳定性测试 具体的特性以及描述如下： 性能测试 性能测试是指通过模拟生产运行的业务压力量和使用场景组合，测试系统的性能是否满足生产性能要求 目的：验证系统是否有其宣称具有的能力。特点：对系统性能已经有了解的前提，对需求有明确 关注产出：关注的是系统性能是否和具体的性能需求相一致，而当系统性能超过性能需求的时候，系统的表现并不是测试人员关心的重点 负载测试 是指对系统不断地增加压力或增加一定压力下的持续时间，直到系统的某项或多项性能指标达到安全临界值，例如某种资源已经达到饱和状态等 目的: 找到系统处理能力的极限。了解系统的性能容量，或是配合性能调优来使用。 得出线下系统最大TPS，得出线下系统最大TPS时系统资源利用率，得出线下系统极限并发数。 压力测试 压力测试是评估系统处于或超过预期负载时系统的运行情况。压力测试的关注点在于系统在峰值负载或超出最大载荷情况下的处理能力 目的：检查系统处于大压力下时，应用的表现，一般模拟负载的方法，是得系统资源使用达到较高水平。 得出系统奔溃点TPS，得出系统奔溃点的资源使用率，的出线下极限TPS 稳定性测试 在给系统加载一定业务压力的情况下，使系统运行一段时间，以此检测系统是否稳定 主要目的是验证是否支持长期稳定的运行 得出系统稳定状态下的资源利用、TPS、响应时间、数据库、中间件、应用服务指标数据

性能测试目的：

最大限度的满足用户的需求，为了验证以下需求以及目标进行性能测试 评估系统的能力 寻找系统的瓶颈 检查系统的在性能测试下的系统bug 验证稳定性、可靠性、扩展性、负载均衡 例如：如下的一些需求

性能测试指标介绍

1.注册用户数、在线用户数、并发用户数和TPS的概念 注册用户数指在系统中注册的用户即在数据库中存在的用户 在线用户数登录到系统的用户，不一定在任何时间都会对操作系统产生压力，例如用户只是登录了，然后不做任何操作对系统没有任何压力 并发用户数在系统中操作业务的用户数，工具中也成为Vuser,会对系统产生压力的用户 跟在线用户主要区别。 TPS 每秒事务数是性能测试中关键的性能指标 2.并发用户数与TPS用那个描述系统的处理能力？ 举一个测试为例子，如下 场景1： 在客户端设置10个用户并发执行，结果响应时间为0.1秒，处理能力为一秒处理100个请求 场景2： 在客户端设置100个用户并发执行，结果响应时间为1秒， 处理能力为一秒处理100个请求 从上面的例子可知，实际测试当中会出现并发数不同，但是处理能力差不多，是因为响应时间的不同导致，因此用并发用户数来描述服务端的处理能力需要考虑响应时间，意义不大。所有一般用TPS来描述服务端的处理能力。

性能测试指标介绍

性能测试需求分析

1.系统调研 系统类型 系统基本特征，如交易处理型、数据处理型 架构部署 系统的部署方式 技术信息 系统整体架构、系统架构图、中间件、数据库、以及之间的通信协议 与系统交互的第三方服务，为后面做mock准备 业务信息 支持的业务类型、业务范围与功能、与其它系统业务关系等 系统历史运行情况 目标TPS，用户数、PV等数据， 是否是首次做性能测试，如果首次做性能建议要做个压力测试找到系统的瓶颈 系统数据规模 了解数据规模，知道测试环境将要用到多少铺底数据，目的是保持测试环境与生产环境数据一直 2.业务调研 基本业务功能：系统的基本业务概念以及系统的业务种类与具体功能 关键业务逻辑处理流程：关键业务的业务流程、交易路径、交易数据、交易流程（准备一个表格模板） 交易列表：调查业务系统全部交易清单，了解交易的组合关系、执行顺序等 交易量信息：在不同时间粒度下统计单个交易处理量以及总交易量信息 业务目标/业务拓展计划：目前的生产业务量和用户数以及系统预期业务目标和本次测试预期业务指标，比如本次性能测试的业务量需要覆盖未来一年

性能模型设计

监控工具的选择 选择数据精准、成本低、历史数据可保留，有如下例子

监控设计：

性能执行的策略

场景分为四类：基准测试、单交易、容量、稳定性、异常每个场景都对应着不同的目标， 基准场景是为了找到系统中明显的配置及软件bug,同时也为容量场景提供可以对比的基准数据

性能执行的策略

1.单交易场景 单交易是容量测试的前奏分别验证测试模型中每支关键交易所对应应用服务是否存在并发性问题，同时获取最大的TPS，为将来容量场景的测试和性能分析提供参考，并验证单支交易是否满足业务需求，分析单个接口的瓶颈点在哪里，找到系统中明显的配置及软件bug,同时为容量常场景提供可对比的基准数据，如果TPS 没有超过要求TPS 需要调优。 获取单接口最大TPS 解决单接口基准场景中遇到的性能问题 为容量场景提供参考 验证是否满足业务需求

2容量场景 对于容量场景来说，最重要的就是业务比例 即业务模型，根据测试模型配比模拟高峰期实际业务操作验证系统在混合交易下是够满足业务需求，在达到指标要求后保证模型的前提下继续进行梯度加压，直到出现性能瓶颈为止，获取各项性能指标数据 最大TPS是最大稳定的TPS 找到系统瓶颈

3.稳定性场景 稳定性测试时间长度取决于系统上线后的运维周期，一段时间运维数据 稳定性场景需要的运行时间计算 稳定性使用的TPS量级的合理， 4.异常场景 针对系统的架构，先分析异常场景中的需求点，再设计相应的案例来覆盖 一般异常有两大类：1架构级的异常，2容量引起的性能异常 用50%压力进行异常性测试， 类似可靠性测试， 验证应用，数据库服务器再可靠性，容错性失效恢复能力， 测试方法： 1.容错性测试方法：依据测试模型发起50%的压力

性能分析与调优

性能分析与调优

1.性能调优 原则 确定清晰明确的性能目标是关键，保证调优后的程序运行正确，调优只是一个辅助手段，调优的结果 要反馈到后续的代码或者配置文件里面去 步骤 确认清晰的性能目标，按优先级排列 遵循调优的顺序：测试->找出瓶颈->假设照成瓶颈的因素->测试假设是否成立->修改应用-> 再次测试验证 确定影响性能的因素: CPU、内存、IO 找出主要的瓶颈，解决最容易的，重复测试 优化完成后，需要进行全面的系统测试

数据库架空指标

、需要测试的特性：处理能力 系统稳定性，响应时间 ， 批处理能力，负载均衡，横向扩展能力，可靠性

启动准则：

环境准备完毕，测试环境架构与生产一致，待测试版本定版，业务模型建立完毕

业务模型选取策略：

关键，典型交易  根据以往运营经验，使用频繁较高的交易，交易集中发生的，

按路径选取：

系统关联关系调查，根据系统架构 找出系统与周边系统功能定位，相互关系 进行不同聚到或者路径典型交易选取，  

路径分析与代表性交易选取：

1. 明确目标系统内不同的业务路径、分类；
2. 确定不同路径上的交易集，分析交易的业务功能（性能、瓶颈点或短板）与流程；

从交易集中选择本路径的代表交易。

测试指标：

业务处理能力：TPS 

响应时间：

系统处理正确性：0.3%

业务处理的稳定性：

系统资源： CPU<80%

批处理能力：

可靠性指标：

在某个节点宕机后，任然能处理交易负载

交易处理能力恢复后，交易处理能力恢复水平=恢复后/回复前=99%

平均失效恢复时间（MTTR）

故障节点修复后  系统是否有业务中断

故障后交易错误率