Jmeter：性能测试基础

什么是性能测试：

1、性能测试是通过自动化的测试工具模拟多种正常、峰值以及异常负载条件来对系统的各项性能指标进行测试。

2、负载测试和压力测试都属于性能测试，两者可以结合进行。通过负载测试，确定在各种工作负载下系统的性能，目标是测试当负载逐渐增加时，系统各项性能指标的变化情况。压力测试是通过确定一个系统的瓶颈或者不能接收的性能点，来获得系统能提供的最大服务级别的测试。

 

性能测试流程

在做性能测试过程中我们一般有如下的常规流程：

说明：

1、业务学习：通过查看各类文档(需求文档)，手工操作系统来了解系统的功能

2、需求分析：分析系统非功能需求，确定性能测试的范围，了解系统性能指标

3、工作评估：工作量分解，评估工作量，计划资源投入(即需要多少人力、多少工作日来完成性能测试工作)

4、设计模型：确定性能测试范围后，把业务模型映射成测试模型

5、计划编写：计划测试工作，在文档中明确列出测试范围，人力投入，持续时间、工作内容、风险评估、风险应对策略等

6、脚本开发：录制或编写性能测试脚本，开发测试挡板程序、开发测试程序等

7、测试环境准备：性能测试环境准备包括服务器和负载机两部分。服务器就是被测系统的运行平台(包括硬件与软件，比如应用服务器需要8Core，32G内存，中间件是Jboss7等)，负载机就是我们用来产生负载的机器，用来安装负载工具，运行测试脚本。

8、测试数据准备：根据测试模型来准备被测系统的主数据与业务数据(主数据是保证业务能够正常运行的基础，比如菜单、用户数据等；业务数据是运行业务产生的数据，比如订单；)

9、测试执行：测试执行是性能测试成败关键，同样的脚本不同的执行人员得出的结果可能差异较大。这些差异主要体现在场景设计与测试执行上。

10、缺陷管理：对性能测试过程中发现的缺陷进行管理

11、性能分析：对性能测试过程中暴露出来的问题进行分析，找出原因

12、性能调优：性能测试工程师与开发人员一起解决性能问题

13、测试报告：测试工作的重要交付件，对测试结果进行报告，主要包括常见的性能指标说明(TPS,RT,CPU UING....等)，发现的问题等。

注：
测试模型：

1、比如一个支付系统需要与银行的系统进行交互(充值或转出等)，由于银行不能提供支持，我们就会开发程序去替代银行系统功能(这就是挡板程序，Mock程序)，保证此功能的性能测试能够展开。这个过程就是设计测试模型

2、如在论坛中一般都是大家发帖或回帖前都会登录，那么我们在开发脚本时就要把登录与发帖或回帖的场景绑定在一起进行测试。这就是测试模型。

3、通俗点讲就是：性能测试用例设计+性能测试实现方案，用例只关注业务，模型还需关注如何实现，是否具有可操作性、可验证性等问题，最后还需要根据不同的测试目的组合成不同的测试场景

 

性能测试的几大难点：

1、需求分析

2、场景设计

3、性能诊断调优

4、环境搭建和模拟

在很多时候测试人员在需求分析方面没有做到位，不能准确的预估用户行为，在场景上不能复现用户操作，无法把需求体现在脚本和场景设计上，无法模拟真实的系统负载。因此在性能测试过程中我们需要重点关注下面几点：

1、评估系统、需求分析
对于初次上线的系统：可以使用同行的系统数据，进行用户行为分析和商业数据结构的估算为前提，利用性能估算法推算。得到的负荷和响应时间数据可以被用于验证所计划的模型能力
对于已上线的系统：可以通过相关人员获取已有的TPS和时间的比例分布图，用户数和时间的分布图等，直接精确得到目前系统的用户行为和业务数据关系，进而得出我们需要的性能需求

2、场景设计、用例设计
充足的需求调研与分析之后，我们要在测试场景中尽可能真实的复原系统负载(确定哪些功能要参与性能执行，如何参与)

3、测试执行
模拟不同负载执行测试场景来识别系统弱点：做好各种监听、甄别各种问题，验证系统的稳定性。下图是我们在执行测试时常见的需要关注的指标

 

性能测试相关术语

1、负载：模拟业务操作对服务器造成压力的过程。比如模拟100个用户进行发帖

2、性能测试：模拟用户负载来测试系统在负载情况下系统的响应时间、吞吐量等指标是否满足性能要求

3、负载测试：在一定软硬件环境下，通过不断加大负载(不同虚拟用户数)来确定阿紫满足性能指标情况下能够承受的最大用户数。简单的来讲就是，可以帮助我们对系统进行容定量，找出系统性能的拐点。从操作层面上来说，负载测试也是一种性能测试手段

4、压力/强度测试：在一定软硬件情况下通过高负载的手段来使服务器资源(强调服务器资源，硬件资源)处于极限状态，测试系统在极限状态下长时间运行是否稳定，确定是否稳定的指标包括：TPS、RT、CPU Uing、Mem Uing等

5、稳定性测试：在一定软硬件环境下，长时间运行一定负载，确定系统在满足性能指标的前提下是否运行稳定。与上面的压力测试区别在于负载并不强调是在极限状态下，着重的是满足性能要求的情况下，系统的稳定性，一般我们会在满足性能要求的负载情况下加大1.5到2倍的负载量来进行测试

6、配置测试：为了合理的调配资源，提高系统运行效率，通过测试手段来获取、验证、调整配置信息的过程。可以收集到不同配置反应出来的不同性能，从而为设备选择、设备配置提供参考

7、性能指标：一般包括TPS(每秒事务数)、RT(事务平均响应时间)、CPU Uing(CPU利用率)、Mem Uing(内存使用情况)等软硬件指标

8、TPS：每秒完成的事务数，通常指每秒成功的事务数。一个事务是一个业度量单位，有时一个事务会包括多个子操作，但为了方便统计，我们会把这多个子操作计为一个事务。比如一个电子支付操作，在后台系统操作中可能会经历会员系统、账务系统、支付系统、会计系统银行网关等，但对于用户来说只想知道整笔支付花费了多长时间

9、RT/ART：响应时间/平均响应时间，指一个事务花费多长时间完成(多长时间响应用户请求)，为了使这个响应时间更加具有代表性，会统计更多的响应时间然后取平均值

10、PV：每秒用户访问页面的次数。此参数用来分析平均每秒有多少用户访问页面

11、Vuser虚拟用户：模拟真实业务逻辑步骤的虚拟用户数，虚拟用户模拟的操作步骤都被记录在虚拟用户脚本里。Vuser脚本用于描述Vuser在场景中执行的操作

12、Concurrency并发：并发分为狭义和广义两类
    ⑴狭义的并发：所有用户在同一时刻做同一件事情或操作，这种操作一般针对同一类型的业务，或者所有用户进行完全一样的操作，目的是测试数据库和程序对并发操作的处理。
    ⑵广义的并发：多个用户对系统发出了请求或者进行了操作，但是这些请求或者操作可以是不同的。对整个系统而言仍然有很多用户同时进行操作
    注：狭义并发强调对系统的请求操作是完全相同的，多适用于性能测试、负载测试、压力测试、稳定性测试场景；广义并发不限制对系统的请求操作多适用于混合场景、稳定性测试场景

13、场景：性能测试过程中为了模拟真实用户的业务处理过程，在LoadRunner中构建的基于事务、脚本、虚拟用户、运行设置、运行计划、监控、分析等的一系列动作的集合，称之为性能测试场景。场景中包含了待执行脚本、脚本组、并发用户数、负载生成器、测试目标、测试执行时的配置条件等。

14、思考时间：模拟真实用户在实际操作时的停顿间隔时间。从业务的角度来讲，思考时间指的是用户在进行操作时，每个请求之间的间隔时间。在测试脚本中思考时间体现为脚本中两个请求语句之间的间隔时间

15、标准差：该标准差根据数理统计的概念得来，标准差越小，说明波动越小，系统越稳定，反之标准差越大，系统越不稳定。包括响应时间标准差、TPS标准差等

 

性能测试通过标准

性能测试通过标准包括服务端性能、前端性能和用户体验性能。通常通过标准如下图

拓展：

关于性能测试模型的探讨如下：
　　随着单位时间流量的不断增长，被测系统的压力不断增大，服务器资源会不断被消耗，TPS值会因为这些因素而发生变化，而且符合通常情况下的规律。以下是一个性能测试压力变化模型图：

说明：
a点：性能期望值
b点：高于期望，系统资源处于临界点
c点：高于期望，性能处于拐点
d点：超过负载，资源不够用，系统处于崩溃

通过如上模型图中的情况，我们大致可以将当前性能测试分成如下4类：
1、性能测试
2、负载测试
3、压力测试
4、稳定性测试

性能测试
　　以上模型图为准则，在a点与b点之间的系统性能，表示以性能目标预期为前提，对系统进行施压，验证系统在资源可用范围内，是否能达到性能预期的目标。
负载测试
　　b点的系统性能，表示在系统在一定的压力下持续一段时间，直到系统的某项或多项指标达到极限，比如系统资源CPU、Memory或者IO等达到饱和状态。
压力测试
　　b点到d点的系统性能，表示在超过安全负载的条件下，不断对系统进行加压，直到系统不能再接受请求，并可以确定一个系统瓶颈的情况下，目的是为了找出系统的瓶颈，需要对系统进行调优。
稳定性测试
　　a点到b点的系统性能，表示被测试系统在特定硬件、软件、网络环境条件下，给系统加载一定业务压力，使系统运行一段较长时间，以此检测系统是否稳定，一般稳定性测试时间为n*12小时。