性能测试流程

目 录
一.文档介绍 3
1.1文档目的 3
1.2适用对象 3
二.性能测试简介 3
2.1 性能测试概念 3
2.2 常用性能指标 4
2.3常用性能测试工具 5
三. 性能测试流程 6
3.1 性能测试流程图 6
3.2 性能测试流程详解 6
3.2.1需求分析 6
3.2.2制定性能测试计划 7
3.2.3环境准备 8
3.2.4脚本设计 8
3.2.5场景设计 9
3.2.6数据准备 9
3.2.7测试执行 10
3.2.8结果分析 10
3.2.9性能调优 15
3.2.10回归测试 18
3.2.11发布性能测试报告 19

一.文档介绍
1.1文档目的
规范性能测试流程，明确性能测试各阶段应该完成的工作，指导性能测试人员正确、有序的开展性能测试工作，提高性能测试效率。

1.2适用对象
测试人员、开发人员、架构师、运维、DBA、项目管理者、质量管理人员和需要阅读本报告的负责人。

二.性能测试简介

2.1 性能测试概念
（1）负载：业务操作对服务器造成的压力。
（2）性能测试：模拟用户负载来测试系统在负载情况下，系统的响应时间、吞吐量等指标是否满足性能要求。
（3）基准测试： 对业务模型中的业务做单独的测试，获取单用户运行时的各项性能指标，为多用户并发测试和混合场景测试等性能分析提供参考依据
（4）配置测试：为了合理调配资源，提高系统运行效率，通过测试手段来获取、验证、调整配置信息的过程。通过这个过程我们可以收集到不同配置反映出来的不同性能，从而为设备选择、设备配置提供参考。
（5）负载测试：在一定软硬件环境下，通过不断加大负载来确定在满足性能指标情况下能够承受的最大用户数。它可以帮我们对系统进行定容定量，找出系统性能的拐点，给予生成环境规划建议。
（6）压力测试：在一定软硬件条件下，通过高负载的手段使服务器资源(强调服务器资源、硬件资源)处于极限状态，测试系统在极限状态下长时间运行是否稳定。
（7）稳定性测试：在一定软硬件条件下，长时间运行一定负载，确定系统在满足性能指标的前提下运行是否稳定。一般我们会在满足性能要求的负载情况下加大1.5到2倍的负载量进行测试。
（8）大数据量测试：针对某些系统的存储、传输、统计查询等业务在数据量比较大情况下进行测试，确定响应时间等是否满足性能要求。

2.2 常用性能指标
 并发用户数：同一时刻向系统提交请求的用户数。
 响应时间：系统处理事务的时间。事务的响应时间是从客户端提交服务请求到客户端接收到服务器响应所消耗的时间。响应时间包括平均响应时间、50%用户响应时间、90%用户响应时间、99%用户响应时间等。
 每秒事务数(TPS)：每秒钟系统能够处理的事务的数量。它是衡量系统处理能力的重要指标
 事务成功率：指在一次性能测试过程中成功事务百分比。
 吞吐量：Loadrunner中指在性能测试过程中网络上传输的数据量的总和, 是从网络角度阐述。在Jmeter的聚合报告中表示指单位时间内系统处理用户的请求数，是从业务角度阐述。
 每秒点击次数：每秒钟用户向Web服务器提交的HTTP请求数。
 PV(Page View)：每秒访问页面数，用来分析平均每秒有多少个用户访问页面
 UV(User View)：一天内访问用户数；
备注；一天内同一访客访问网站多次只计算1个访客
 CPU使用率：指用户进程与系统进程消耗的CPU时间百分比，长时间情况下，一般可接受上限不超过85%，建议控制在75%以内。
 内存利用率：内存利用率=（1-空闲内存/总内存大小）*100%，一般至少有10%可用内存，内存使用率可接受上限为85%，建议控制在75%以内。
 磁盘I/O: 磁盘主要用于存取数据，因此当说到IO操作的时候，就会存在两种相对应的操作，存数据的时候对应的是写IO操作，取数据的时候对应的是是读IO操作，一般使用% Disk Time度量磁盘读写性能。

2.3常用性能测试工具
（1）HttpWatch HttpWatch是强大的网页数据分析工具，集成在IE浏览器中，能够收集并显示HTTP协议交互的深层信息。在网页下面可详细的显示出每个服务请求的响应时间，以及处理整个业务的总体响应时间。
（2）Loadrunner 该工具目前是业内主流的性能测试工具之一，LoadRunner的测试 对象是整个企业的系统，它通过模拟实际用户的操作行为和实行实时性能监测，查找和发现问题。此外，LoadRunner能支持广泛的协议和技术。
（3）Jmeter JMeter是Apache组织开发的基于Java的压力测试工具。用于对软件做压力测试。JMeter 可以用于对服务器、网络或对象模拟巨大的负载，来自不同压力类别下测试它们的强度和分析整体性能。另外，JMeter能够对应用程序做功能/回归测试，通过创建带有断言的脚本来验证你的程序返回了你期望的结果。
（4） nmon 帮助在一个屏幕上显示所有重要的性能优化信息，并动态地对其进行更新。nmon工具还可以将相同的数据捕获到一个文本文件，便于以后对报告进行分析和绘制图形。
（5）Jconsole 内置java性能分析器，它用于连接正在运行的本地或者远程的JVM，对运行的java应用程序的资源消耗和性能进行监控。

三. 性能测试流程

3.1 性能测试流程图

3.2 性能测试流程详解

3.2.1需求分析
分析对象包括业务分布、业务高峰时间段、业务量、业务趋势、业务性能指标、系统架
构、系统服务软硬件配置等，明确性能测试的范围和性能指标。
（1）业务分布：主要是用来确定性能测试的范围
（a）高频次的业务
（b）性能影响大的业务
（c）重要的业务
（2）业务量、业务高峰时间段、业务趋势：主要是用来确定性能目标。
性能指标可以分为2类：
（a）业务指标(TPS、RT、事务成功率等)
（b）硬件指标(CPU使用率、内存使用率、磁盘读写速率等)
（c）系统架构、服务器软硬件配置：主要是在搭建性能测试环境和对生产环境性能评估提供参考，其中服务器配置包括应用服务器、DB服务器已经其它的一些中间件配置。如：服务器操作系统、CPU、内存、数据库连接池配置。

3.2.2制定性能测试计划
测试计划用来规划测试工作，一般需要考虑的内容包括：
（1）系统概述：简述系统功能，让阅读报告的人明白系统是做什么的。
（2）测试环境：系统生产环境、系统测试环境、负载机环境。
（3）测试范围：采集性能测试的需求，明确性能测试的范围和性能目标。
（4）性能指标：确定使用哪些性能指标作为系统性能的参考值。
（5）测试策略：明确性能测试将采用什么手段进行性能测试，在性能测试实施过程中关注哪些性能变化。
（6）测试场景：如何对单场景进行性能测试、如何对混合场景进行性能测试，混合场景的业务如何组合、是否需要集合
点、思考时间、测试开始如何增加负载、测试结束如何减少负载等。
（7）测试准备：测试前的环境准备、数据准备。
（8）人力投入&时间计划：通过确定的测试范围和测试策略、评估性能测试工作量，合理安排人力、时间。
（9）交付物清单：性能测试计划、性能测试报告、性能测试脚本。
（10）测试风险：对测试过程中可能涉及到的风险加以评估，确定风险应对策略。

3.2.3环境准备
性能测试环境包括软件环境、硬件环境和网络环境。这三大环境不仅是指应用服务器环境，还包括数据库服务器、缓存服务器、文件服务器以及其他中间应用服务器环境。
　　硬件环境包括：CPU、内存、磁盘等基本因素。
　　软件环境包括：操作系统版本、位数；JDK版本、位数、数据库版本号、位数等，以及这些软件的安装路径也最好与线上环境一致。配置文件包括JVM配置、中间件配置、数据库配置文件等。
　　网络环境包括：网络协议及网络带宽。
　　还有集群环境包括：应用相关服务器的负载均衡环境、数据库的热备或主从环境、集群环境等。
　
3.2.4脚本设计
（1）性能测试脚本可录制、可编程，不同工具在具体设计上存在差异，需要结合具体工具去实现。
（2）脚本设计需要考虑参数化、思考时间、关联、检查点等。

3.2.5场景设计
场景分单场景和混合场景：单场景有利于问题的分析定位；混合场景更贴近用户的使用场景。
如下场景设计的模板，可参考：

3.2.6数据准备
主数据：主数据要包括系统正常运行时需要的基础数据，比如功能菜单、账号、角色等。
业务数据：主要为业务测试过程中需要用到的业务数据
数据要求如下：
（1）要确保数据完整，能够支撑性能测试脚本对业务的覆盖。
（2）要确保数据量，能够满足性能测试脚本参数化要求。
（3）要确保存量数据，能够尽量真实反映系统的数据环境。
（4）要确保存量数据分布，能够对测试实施有意义。

3.2.7测试执行
（1）执行过程按照测试方案中设计的场景执行，执行过程中需要注意：
 ( a）每次执行前做好必要的初始化操作（如：数据还原、存量数据处理完成等）。
 ( b）同一个用例的场景，如果时间允许，尽量执行2-3遍，避免偶然性偏差。
 ( c）执行完毕收集好测试结果，详细记录下该场景的所有测试数据，方便后期分析。
（2）测试过程中我们要对资源进行监控，常见如下：

3.2.8结果分析
对性能测试过程中暴露出来的问题进行分析，找出原因。

（1）性能分析方法
不同的架构、不同的应用场景分析方法都有差异，具体分为2类
 a）自底向上：通过监控硬件及操作系统性能指标（CPU、内存、磁盘、网络等硬件资源的性能）来分析性能问题（配置、程序的问题）。因为用户请求最终是由计算机硬件设备完成的。
 b）自顶向下：通过生成负载来观察被测试的系统性能，比如响应时间、吞吐量，由外及里一层一层分析，从而找到性能问题所在。
备注：两种方法建议结合使用，先用自顶向下的方式解决掉明显性能问题，再结合自底向上的方式分析更深层次的问题。

（2）性能分析过程

1. 检查RT 模拟用户发起负载后，采用自顶向下的方式首先分析RT
2. 检查TPS TPS越大，RT越小，说明性能越良好
3. 检查负载机资源消耗，是否有性能问题 首先要排除负载机对性能测试结果的影响，确保测试结果的准确性
4. 检查Web/App Server服务器资源消耗 判断服务器硬件资源是否存在性能瓶颈
5. 检查中间件配置 确认中间件是否存在配置问题影响性能
6. 检查数据库服务器资源消耗 判断数据库服务器硬件资源是否存在问题，影响数据库性能
7. SQL分析
   a）索引是否正常应用；
   b）检查共享sql是否合理范围；
   c）检查解析是否合理；
   d）检查数据ER结构是否合理；
   e）检查数据分布是否合理；
   8）其它：如网络带宽

（3）性能分析关注点

1）AppServer（应用服务）
在应用程序这一层我们的性能问题多数表现为程序逻辑混乱，调用复杂，甚至是设计不合理。

2）WebServer（Web服务）
这一层主要是页面跳转控制和结果的渲染。当前前端技术的多样化，展现的内容更加丰富，内容多也导致了一些前端性能问题。
关注的问题如下：
a）页面Size：动态数据、CSS、JS、图片的大小
b）隐藏的，无用的数据传输：开发过程中未了方便，我们会继承一些基类，我们需要考虑成本，最好不要有大对象上次。还有在做SQL查询时，只查询需要的字段，对于无用字段排除掉，避免不必要的数据传输。

3）DB数据库
当前绝大多数应用都离不开数据库的支持，系统性能的好坏很大一部分是有数据库系统、应用系统数据库设计以及如何使用数据库来决定的。
对于数据库，我们主要关注点有：
a）慢查询
b）大事务
c）死锁
d）DB Time高
e）磁盘IO等待时间

4）系统资源
一般硬件瓶颈的表现如下：
a）CPU使用率过高，CPU使用率又分操作系统占用的CPU与用户程序占用的CPU，
 注意区分，过高常见原因有：
 计算量大，比如运算、数据统计
 非空闲等待，比如资源争用
 过多的系统调用
 过多的中断（说明：中断是CPU用来响应请求的机制，中断是通知CPU有任务需要响应，CPU停下正在执行的程序来响应当前的中断）
b）内存吃紧，多数是过多的页交换和内存溢出
 页交换：在系统硬件资源中，内存是用来缓解磁盘与CPU之间的速度差，在内存中我们会缓存一些数据，但是内存的容量是有限的，内存不够用来存储需要的数据是，操作系统会把原内存中的部分内容释放掉，然后把需要的内容载入，这个过程就是页交换。
 内存溢出：Java程序运行在JVM之上，JVM的内存设置也是有限制的，有时候JVM堆内存的对象无法回收，久而久之就没有空间来容纳新的对象，最后倒在JVM崩溃，这就是内存溢出，对象回收不了的这种现象就是内存泄漏，这往往是由程序原因引起的。
c）磁盘繁忙，读写数据繁忙。
磁介质磁盘的读写是物理作用，所以速度受限。如果频繁地对磁盘进行读写，因为磁盘的瓶颈就会导致CPU等待的情况激增。
d）高并发导致网络拥堵

5）中间件
J2EE架构的程序多数运行在Tomcat、WebLogic、WebSphere等中间件上，作为Java应用程序容器，中间件有其特定的指标项。
a）JVM：中间件是运行在JVM之上，我们需要监控JVM堆内存使用情况.包括GC（垃圾回收机制）频率，线程状态等。
 Full GC操作是对堆空间进行全面回升，此时是停止响应用户请求的，所以如果一个系统频繁发生FULL GC，那么会造成系统响应卡顿，影响响应时间，更严重的时候会导致系统崩溃。
 线程运行状态可以帮助我们了解线程的繁忙程度，特别要关注Blocked状态的线程，此状态说明当前线程运行相对较慢，长时间的Blocked可能是因为线程阻塞(任务繁重或者响应慢)，甚至造成死锁。
b）Thread pool:中间件在接收用户请求时建立了线程池，需求监控其使用情况。一般当超过一定的使用率时可考虑增大连接池数量。
c）DB Connections pool：为了节省程序与DB建立连接、释放连接的资源消耗，设计数据库连接池，一般超过使用率时，可以考虑加大连接池数量

3.2.9性能调优
（1）性能调优的常规手段
1）空间换时间：如内存、缓存就是典型的空间换时间，利用内存、缓存从磁盘上取出数据，CPU请求数据直接从内存/缓存中获取、比从磁盘上读取数据有更高的效率
2）时间换空间：当空间成为瓶颈时，切分数据分批次处理，用更少的空间完成任务处理。如上传大附件经常用这种处理方式。
3）异步处理；业务链路上有任务时间消耗时间较长，可以拆分业务、异步处理这些任务，减少阻塞影响。
4）用多个进程或者多个线程同时处理业务，缩短业务处理时间。
5）离用户近一点：比如CDN（内容分发网络）技术，把用户请求的静态资源放在离用户更近的地方。
6） 一切可扩展，业务模块化、服务化（同时无状态化）、良好的水平扩展能力

（2）性能调优

1）系统框架优化
SSH架构是当下最流行的MVC模型。SSH架构提供了明晰的层次结构，各层协同完成业务实现，简化了程序设计过程，加快了程序交付进程。但是对大型的业务系统，特别是大数据量的分析计算过程，可以把数据处理换成在数据库中进行处理，减少网络传输，性能也会提升，所以应该不同的应用场景选择更合适的处理方式。

2）程序优化
a）表单压缩：压缩表单，减少网络的传输量达到提高响应速度的效果。
b）局部刷新：页面中采取局部内容获取的方式，减少向服务器的请求，服务器由于负载减少就能更快的响应。
c）仅取所需：只向服务器请求必要的内容，只向客户端发送必要的内，减少网络传输，减轻服务器负担。
d）逻辑清晰：程序逻辑清晰方便维护，方便分析问题；不做多余调用，资源请求后能够释放。
e）谨慎继承：开发过程中要对系统架构了解，特别是一些基类、公共组件，合理利用，减少大数据对象产生的可能。
f）程序算法优化：试着分析程序，释放需要用算法来提高程序效率，比如我们可以用二分法
g）批处理：对于大批量的数据处理，最好能够做成批处理
h）延迟加载：对于大对象的展示可以采用延迟加载的方式，层层递进的显示明细，比如我们分页显示列表内容。
i）防止内存泄漏：内存泄漏是由于对象无法回收造成的，特别是一些长生命周期的对象风险较大。
j）减少大对象引用
k）防止争用死锁：一般出现在线程同步的场景，不同线程对同一资源的争用通常会导致等待，处理不当会导致死锁。可以适当的采用监听器来处理这类场景。
l）SQL编写：程序中编写合理的SQL，尽量利用索引
m）并行：使用多个进程或线程来处理任务
n）异步：比如用MQ（消息中间件）来解耦系统之间的依赖关系，减少阻塞。

3）DB优化
a）优化物理结构，数据库逻辑设计与物理设计要科学高效，比如分区、建立索引
b）共享SQL、绑定变量，减少编译
c）查询器优化，特殊情况调整执行计划。指定的执行计划加快查找速度。比如连接查
询时指定驱动表，减少表的扫描次数。
d）单台SQL优化，对单条SQL进行优化分析，比如查询条件选择索引列。
e）并行SQL，对数据量巨大的表进行数据变量，用多个线程分块处理任务。
f）减少资源争用（锁、缓存）。

4）系统资源优化
a）优化内存、减少物理IO访问
b）优化IO，进行条带化、读写分离等

5）配置优化
a）JVM配置优化：合理的分配堆与非堆的内存，配置合适的内存回收算法，提供系统服务能力。
b）数据库连接池：数据库连接池可以节省建立连接与关闭连接的资源消耗；连接池配置多少连接，原则是按需分配，够用就好。它没有精确的计算公式，可以通过测试来估算。比如以单位时间的业务量或者并发用户数为单位，监控使用了多少连接数，再以此为单位进行放大。
c）线程池：通过缓存线程的状态来减少新线程与关闭线程的开销，一般是在中间件中进行配置，比如在Tomcat的server.xml文件中进行配置
d）缓存机制：通过数据的缓存来减少磁盘的读写压力。

6）服务结构优化
a）单机结构(传统架构)：Web服务和App服务在一台服务器上，又或者把Web服务和APP服务拆分开，分别在一台服务器上。
b）集群结构：Web&App服务可以用多台机器来进行负载分担，DB的瓶颈也可以通 过分区、分库、分表的方式来缓解。还可以通过读写分离的方式减轻单台服务器IO压力。当一些热点数据过多时，还可以对这些热点数据进行缓存。
c）分布式结构
系统分层、系统服务化（SOA架构、微服务化等）、服务分布式、DB分布式、缓存分 布式及良好的水平扩展能力是当前分布式架构的典型特征。

7）业务流程优化
准确的说就是业务架构调整，对此做调整就是要推翻先前的设计，风险比较大，架构调整伴随着程序修改、测试，若改动太大，一般项目难以承受，建议改动只针对小范围的，或者其它优化方案已都消耗殆尽情况下再考虑业务流程优化。

3.2.10回归测试
性能回归测试中除了关注性能问题本身外，还要关注性能优化是否对业务功能造成了影响。

3.2.11发布性能测试报告
测试工作的重要交付件，对性能测试结果进行报告。主要包含如下内容：
（1）性能测试背景：结合系统简述一下性能测试开展的必要性。
（2）性能测试目标：此次性能测试的目标，我们要做哪方面的测试。
（3）性能测试范围：列出测试范围，参考测试计划中的测试范围。
（4）测试环境：测试工作中基于的测试环境
（5）测试进度：报告测试过程，什么时候做了什么工作。
（6）测试结果：全方面多方位的测试报告结果
（7）测试结论：分析给出测试结论，系统能否满足性能要求？存在什么问题？有哪些缺陷？解决了哪些问题，还有哪些问题没有解决。
（8）系统风险：报告系统可能存在的风险，帮助决策层应对风险。