性能测试的工作三大部分

性能需求调研：
客户能接受的响应时间，每日单交易处理能力，系统资源利用率，系统环境搭建方式、并发用户数、日交易数量等。

确定业务模型：
根据需求调研，分析哪些交易是每日需要处理使用的功能，哪些交易是月底或者年底需要批量处理，来划分测试交易的等级。

确定测试方案：
测试方案的目的是确定此次系统测试的目的，定义一个性能测试的入口准则，出口准则，并确定测试的交易业务模型、业务指标、测试模型、测试指标，以及发起测试的测试策略、执行策略、监控分析策略、以及测试内容、测试环境、工具、数据、脚本的准备、测试风险策略等。

确定测试计划：
制定测试计划的目的是为了约束测试各个活动的起止时间，为性能测试的准备、执行、分析与报告、总结等环节给出合理时间估算。

建立测试环境：
建立测试环境主要是在需求调研后根据实际上线系统环境的网络拓扑结构搭建模拟测试环境，准备测试数据等。

准备测试工具、脚本及测试数据：
根据分析系统架构模式对自动化测试工具选型、对脚本的录制调试以及测试系统存量数据的准备。

准备测试监控工具：
在性能测试的开始前，需要配置完成监控工具，用于监控每个虚拟用户的状态，及时采集交易的响应时间、吞吐量，以及各主机的CPU、I/O和内存等硬件资源利用率信息。

测试环境预热：
环境预热就是在环境搭建完成后录制调试完脚本对录制好的脚本都执行一次，因为一些程序在服务器重启时期需要编译。

各个服务器参数化调整：
环境搭建好后根据硬件配置，软件配置对系统各个环境进行系统参数调整、WEB服务器参数调整、应用服务器参数调整、数据库服务器参数调整，并将调整好的参数进行备份。
（此处加入各环节参数配置建议值，并以此建立环境参数基线）

性能测试执行阶段

执行测试：
执行测试包括以下六个部分：单交易基准测试、单交易负载测试、混合场景测试、稳定性测试、异常测试、极限测试。

单交易基准测试（性能期望值）
测试原理：在测试环境经过确认，脚本预验证之后，针对每支选定的交易或操作，在系统无压力的情况下，单交易用户迭代若干次，获取每个交易或操作的平均响应时间，以此作为多用户并发测试的基准和参考。

测试方法：使用性能测试工具LR/Jmeter模拟客户端向目标系统发送交易请求，在系统无压力的情况下重复50-100次（或10分钟），每次迭代间等待1秒，获取交易的平均响应时间、TPS、点击率作为衡量指标。

单交易负载测试（高于期望，系统资源处于临界点）
测试原理：在完成单交易基准测试后，针对测试模型中的每一支交易或每一个操作，采用多个（5-10，是具体情况而定）虚拟用户数进行负载测试，获取业务处理性能和系统资源利用率等数据，并验证交易是否存在并发性问题。

测试方法：实用LR/Jmeter模拟客户端向目标用户发送业务请求，并接受返回结果的脚本。采用梯度发送的方式逐步增加系统请求的压力，每个梯度测试持续运行10-15分钟并记录测试相关数据，获取该交易最大处理能力，同时进行资源监控，问题定位测试结果分析。

混合场景：
测试原理：在既定的测试模型下，在给定的测试限制条件下，通过在被测试系统上逐步增加的并发用户数，梯度增加压力，获得系统响应时间、吞吐量、CPU和内存的使用等性能数据。确定在各种工作负载下系统的性能指标，直到突破限定条件。获取在不同压力下的性能表现，以及交易的TPS、响应时间、系统资源利用率等指标数据。经过测试分析获取应用系统在该测试环境下的最大处理能力。

测试方法:根据测试模型中的交易比例构成测试场景，使用LR/Jmeter模拟客户端向目标系统发起交易请求。按照并发梯度的方法，逐步提升并发用户数的压力，每组梯队运行15-20分钟。观察并收集应用系统的CPU、内存、磁盘的占用情况、交易响应情况、交易成功率等指标。直到系统出现容量拐点或瓶颈后结束测试。

稳定性测试（超过负载，系统崩溃）
测试原理：根据混合场景负载测试结果，采用系统容量峰值的60%-80%的压力负载，稳定运行8-12小时，检验应用系统在测试环境下的稳定运行能力，获取系统长时间运行的稳定性指标。根据应用系统的操作习惯或业务处理规律，必要时采用变化的交易压力的方式，进行稳定性测试。主要方式是随机和定时的变更交易压力，有益于根据业务运行规律模拟真实状况下的系统运行状况。

测试方法：根据单交易场景负载测试结果，结合生产实际业务量的统计，推算负载测试模型系统峰值的压力60-80%的并发压力。使用LR/Jmeter连续发起并发压力8-12小时，主要监控系统的CPU、内存、磁盘的占用情况和交易响应情况，主要是检查内存泄漏、网络处理能力、负载均衡等问题，检验系统在持续压力状况下的稳定运行能力。

异常测试：
测试原理：在单节点故障或者网络故障等问题发生时，系统的处理能力，数据的完整性

测试方法： 通过一定方法（如断开网线，停掉服务器）模拟服务中断、网络终端、硬件故障等异常情况，测试故障发生时对在线交易的影响。

极限测试（压力测试：高于期望，拐点）
测试原理：分为单交易极限负载测试和混合场景极限负载测试两类。在一定的测试环境中，获取单交易或混合场景在极限或苛刻的环境中系统的性能表现。关注系统在超越极限后的表现。测试过程中，不必严格按照梯度增加的方法。应用系统运行可以据此设置预案，软件开发可以按照此优化设计。

测试方法：上述两类测试方法基本相同，只是执行策略和测试目的略有不同。根据测试模型中的交易比例构建测试场景，即混合负载测试场景。使用LR/Jmeter模拟客户端向目标系统发起交易请求，以混合负载容器值所处的并发用户数为起点，较大幅度提升并发用户数压力，观察应用系统的CPU、内存、磁盘的占用情况，交易响应情况，交易成功率等指标。尝试找出使用上述指标出现异常的梯度，并运行15-30分钟，监控系统的性能表现。

测试的主要策略

测试模型的维护策略
测试模型由业务模型而来，是全部测试活动的逻辑基础，贯穿整个测试过程，务必保持模型相对稳定和交易配比的准确。对于测试模型的定义要关注TPS/HPS的区分。务必于应用系统用户关注目标统一。对于测试模型中的配比关系，首先源于生产的统计分析，务必重视统计口径和粒度；其次源于经验判断分析，必须遵循一般交易习惯和操作规律。

梯度并发的策略
在混合负载测试中，以预设的测试模型逐步增加并发用户数量，获得TPS等性能容量指标。对于获取最大并发用户数或接入能力的测试，以TPS/HPS为变化梯度。

极限/压力策略
在混合负载测试中，必须找出系统“瓶颈”和处理能力的“拐点”。可能情形：测试环境资源类某项性能指标达到了阀值，例如CPU，I/O，Memory等；应用系统某项设定的指标达到临界值，例如队列深度、并发进程数量等；交易或操作定义的限制条件，例如响应时间、交易处理成功率等。

冗余策略
在混合负载测试中，梯度增加是个不断尝试，反复调整的过程，即便找到了所谓的“拐点”或“瓶颈”，也须向前继续测试2-3个梯度，查看应用系统能够的性能表现。

“拐点”或“瓶颈”的判定策略
对于应用系统的性能容量，通常有3个限定条件：环境资源类，交易业务类，应用系统类。其应用策略如下：
环境资源类：例如I/O低于80%，如果超过此指标，或是核查原因或是中止测试。
交易业务类：除了受用户体验约束外，更多来源于经验判断，存在较大弹性误差，例如查询交易相应时间3s，5s，8s技术误差和感受误差都需要考虑。
应用系统类：应用系统类条件既包括应用系统本身，也包括OS（操作系统），DB（数据库）、中间件等，可以随时调配或优化。
综合系统性能测试指标

执行测试时，并发用户采取从小到大逐渐递增的方式，给系统施加压力，观察系统的吞吐量和交易响应时间随并发用户数和交易数增加的变化，如下图所示。

性能测试发起时，按照业务模型，通过LoadRunner压力测试软件，使用不同并发用户数，梯度发送交易请求压力，每次测试持续运行一定时间并记录测试相关性能数据，获取系统处理能力变化值，形成处理能力梯度变化曲线。

总结阶段：

测试结果记录和分析：
1)业务处理能力
2)交易响应时间
3)系统资源监控情况
4)瓶颈和拐点分析

测试结论
在测试环境下，根据响应时间、成功率、资源使用的各项指标等综合分析，得出目前系统的性能情况，并对仍然存在的性能问题进行说明，对可能存在的风险进行分析，并提出改善性能意见、规避风险策略。