软件测试教程 性能测试Loadrunner篇(一)

本课程主要讲解性能测试以及性能测试工具Loadrunner。

系统开发完毕了，去做一下性能测试吧！

系统要验收了，做一下压力测试吧！

当听到以上的要求后，是否一脸茫然？那么我们该怎样进行一次性能测试呢？

性能测试基础

概念和术语介绍

性能测试模型

性能测试分类介绍

性能测试实施与管理

性能测试基础

WHY： 为什么要进行性能测试

WHAT: 关注的性能测试内容

WHO: 哪些人员关注性能

WHERE: 性能测试的关注领域

WHEN: 何时进行性能测试

WHY：（为什么测试）

1521181369387.png

• 应用程序是否能够很快的响应用户的要求？
• 应用程序是否能处理预期的用户负载并有盈余能力？
• 应用程序是否能处理业务所需要的事务数量？
• 在预期和非预期的用户负载下，应用程序是否稳定？
• 是否能确保用户在真正使用软件时获得舒服的体验？

问题的根源是什么？

• 在多种平台上的数百个服务器
• 异构系统、多种应用
• 数千个工作站
• 局域网、广域网和其他分类型的分布式网络体系结构
• 交错的故障点

误区：提高一下硬件配置就可以提高性能了，因此性能测试不重要？
软件本身的问题如：内存泄漏？

WHAT：（关注什么）

• 并发用户数/吞吐量
• 平均响应时间
• 服务器资源占用情况
• 可靠性、可扩展性
• 发现引起系统问题的原因,关注采用何种技术提高系统性能
• 软、硬件配置是否合适（容量规划/硬件选型）

WHO：（谁关注）

• 开发人员

  系统架构：架构设计是否合理？

  数据库设计：数据库设计是否存在问题？

  代码：代码是否存在性能问题？系统中是否存在不合理的内存使用方式？

  设计和代码：系统中是否存在不合理的线程同步方式和不合理的资源竞争？

• 系统管理人员（操作系统、网络、服务器等等）

  资源利用率：应用服务器和数据库资源使用状况合理吗？

  系统容量：系统最多能支持多少用户的访问？系统最大的业务处理量是多少？

  系统稳定性：系统是否能支持7X24小时的业务访问？

  系统可扩展性：系统是否能够实现扩展？系统性能可能的瓶颈在哪里？更换哪些设备能够提高系统性能？

• 用户

  响应时间：过长时间的等待会让使用者烦躁不安；

  ​ 对于一般的web网站来说，在欧美国家普遍的标准为原则3/5/8(2/5/10)：

  ​ 3: 3秒钟用户会觉得是一个很好的体验。

  ​ 5: 5秒钟用户可能会觉得差了一点，还行，比较好。

  ​ 8: 8秒钟是用户所能承受的最大极限

  系统稳定性：出现HTTP500错误或数据库崩溃会让用户对系统失去信心

• 业务人员

  参数：如何向用户提供参数，例如支持多少用户使用？响应时间是多少？

• 测试人员

  以上所有层面都需要关注

  是否能够发现系统中存在的瓶颈？

  是否真实有效的评估系统性能能力？

WHERE:(关注领域)

• 能力验证

  性能测试中最简单也是最常用的一个应用领域，主要关心的是“在给定的条件下，系统能否具有预期的表现”。

• 规划能力

  规划能力领域与能力验证领域有些不同，其主要关心的是“应该如何才能使系统具有我们要求的性能能力”或是“在某种可能发生的条件下，系统具有如何的性能能力

• 性能调优

  主要应用于对系统性能进行调优。一般来说，性能调优活动会和其他领域的活动交杂在一起。是一种在开发阶段和测试阶段都可能会涉及到的性能测试应用领域。

• 发现缺陷

  主要该应用领域的主要目的是通过性能测试的手段来发现系统中存在的缺陷

  误区：
  1、性能测试独立于功能测试
  2、性能测试就是并发用户测试
  3、在开发环境测试一下性能就可以了
  

WHEN：（何时测试）

• 功能测试中后期

误区：
1、性能测试在其他测试完成后，测试一下就可以了

概念和术语介绍

系统的性能是一个很大的概念，对一个软件系统而言包括执行效率、资源占用、稳定性、安全性、兼容性、可扩展性、可靠性等等。

一般地，它主要是针对系统的性能指标制定性能测试方案，执行测试用例，得出测试结果来验证系统的性能指标是否满足既定值。性能指标里可能包括系统各个方面的能力，如系统并发处理能力，系统响应时间，批量业务处理能力等等。

性能测试主要用来保证产品上线或发布后系统的性能满足用户需求，性能测试在软件质量保证中起重要作用。

并发数

系统用户数：简单地说就是该系统的注册用户数。例如，BestTest论坛里存在6666个注册用户，他们可以是活跃的，也可以是僵尸的。

在线用户数：即登录系统的用户。例如，其中有666个用户的状态为在线，但在线用户并不一定都会对服务器产生压力，因为有的用户登录后什么都不干。

并发用户数：是对服务器产生压力的用户。例如，可能在线的666个用户中，只有20%的用户对服务器产生了压力，这20%的用户数就是并发用户数。

严格意义的并发用户数：同一时间进行同一个操作的用户数。

并发数如何估算?
没有准确的估算方式，下面是一个估算方法
 1）平均并发用户数为 C = nL/T
 2）并发用户数峰值 C' = C + 3*根号C
    C是平均并发用户数，n是login session的数量，L是login session的平均长度，T是值考察的时间长度
    C'是并发用户数峰值
举例1，假设系统A，该系统有3000个用户，平均每天大概有400个用户要访问该系统（可以从系统日志从获得），对于一个典型用户来说，一天之内用户从登陆到退出的平均时间为4小时，而在一天之内，用户只有在8小时之内会使用该系统。那么：
  平均并发用户数为：C = 400*4/8 = 200
  并发用户数峰值为：C' = 200 + 3*根号200 = 243

响应时间（Reponse Time）

又叫请求响应时间：TTLB（time to last byte）

对请求作出响应所需要的时间

网络传输（请求）时间+服务器处理（一层或多层）时间+网络传输（响应）时间。

1521183424662.png

事务响应时间（Transaction Reponse Time）

事务是指一组密切相关的操作组合。例如一次登录可能包含了多次HTTP请求，如：判断用户是否存在？密码是否正确？是否已登录？登录？等多个HTTP请求。

该数值对用户的意义更直观

每秒事务通过数（Transaction Per Second）

TPS 是指每秒系统能够处理的事务数。它是衡量系统处理能力的重要指标。

当压力加大时，TPS曲线如果变化缓慢或者有平坦的趋势，很有可能是服务器开始出现瓶颈了。如果环境没有发生大的变化，对于同一系统会存在一个最大处理事务能力，它并不随着并发用户的增减而改变。

地铁检票机：
只有十台进站检票的机器，一台机器一秒能进一个人
并发用户数为5，则TPS为5
并发用户数为10，则TPS为10
并发用户数为100，则TPS仍为10

点击率（Hit Per Second）

每秒点击数代表用户每秒向Web 服务器提交的HTTP请求数。点击率越大，服务器压力越大。

这里的点击并不是鼠标的一次点击，一次点击可能有多次HTTP请求。

吞吐量（Throughput）

单位时间内系统处理的客户请求的数量，直接体现软件系统的性能承载能力，一般来说用请求数/秒或是页面数/秒来衡量，从业务的角度，也可以用访问人数/天或是处理的业务数/小时来衡量，从网络的角度来说，也可以用字节数/天来衡量。

思考时间（Think Time）

思考时间就是用户进行操作时，每个请求或者操作之间的间隔时间，是为了更加真实地模拟用户的操作场景。

资源利用率

不同系统资源的使用情况。CPU,Memory，磁盘，网络。

性能测试模型

前面讲解了一些性能测试的概念和术语，现在来深入的理解一下。

曲线拐点模型

1521187121660.png

1）X轴代表并发用户数，Y轴代表资源利用率、吞吐量、响应时间。X轴与Y轴区域从左往右分别是轻压力区、重压力区、拐点区。

2）随着并发用户数的增加，在轻压力区的响应时间变化不大，比较平缓，进入重压力区后呈现增长的趋势，最后进入拐点区后倾斜率增大，响应时间急剧增加。

3）接着看吞吐量，随着并发用户数的增加，吞吐量增加，进入重压力区后逐步平稳，到达拐点区后急剧下降，说明系统已经达到了处理极限，有点要扛不住的感觉。

4）同理，随着并发用户数的增加，资源利用率逐步上升，最后达到饱和状态。

5）最后，把所有指标融合到一起来分析，随着并发用户数的增加，吞吐量与资源利用率增加，说明系统在积极处理，所以响应时间增加得并不明显，处于比较好的状态。但随着并发用户数的持续增加，压力也在持续加大，吞吐量与资源利用率都达到了饱和，随后吞吐量急剧下降，造成响应时间急剧增长。轻压力区与重压力区的交界点是系统的最佳并发用户数，因为各种资源都利用充分，响应也很快；而重压力区与拐点区的交界点就是系统的最大并发用户数，因为超过这个点，系统性能将会急剧下降甚至崩溃。

地铁模型

假设：

# 某地铁站进站只有3个刷卡机。

# 人少的情况下，每位乘客很快就可以刷卡进站，假设进站需要1s。

# 乘客耐心有限，如果等待超过30min，就暴躁、唠叨，甚至放弃。

场景一：只有1名乘客进站时，这名乘客可以在1s的时间内完成进站，且只利用了一台刷卡机，剩余2台等待着。

场景二：只有2名乘客进站时，2名乘客仍都可以在1s的时间内完成进站，且利用了2台刷卡机，剩余1台等待着。

场景三：只有3名乘客进站时，3名乘客还能在1s的时间内完成进站，且利用了3台刷卡机，资源得到充分利用。

场景四：A、B、C三名乘客进站，同时D、E、F乘客也要进站，因为A、B、C先到，所以D、E、F乘客需要排队。那么，A、B、C乘客进站时间为1s，而D、E、F乘客必须等待1s，所以他们3位在进站的时间是2s。

场景五：假设这次进站一次来了9名乘客，有3名的“响应时间”为1s，有3名的“响应时间”为2s（等待1s+进站1s），还有3名的“响应时间”为3s（等待2s+进站1s）。

场景六：如果地铁正好在火车站，每名乘客都拿着大小不同的包，包太大导致卡在刷卡机堵塞，每名乘客的进站时间就会又不一样。刷卡机有加宽的和正常宽度的两种类型，那么拿大包的乘客可以通过加宽的刷卡机快速进站（增加带宽）。

场景七：进站的乘客越来越多，3台刷卡机已经无法满足需求，为了减少人流的积压，需要再多开几个刷卡机，增加进站的人流与速度（提升TPS、增大连接数）。

场景八：终于到了上班高峰时间了，乘客数量上升太快，现有的进站措施已经无法满足，越来越多的人开始抱怨、拥挤，情况越来越糟。单单增加刷卡机已经不行了，此时的乘客就相当于“请求”，乘客不是在地铁进站排队，就是在站台排队等车，已经造成严重的“堵塞”，那么增加发车频率（加快应用服务器、数据库的处理速度）、增加车厢数量（增加内存、增大吞吐量）、增加线路（增加服务的线程）、限流、分流等多种措施便应需而生。

性能测试分类介绍

• 基准测试
• 性能测试
• 负载测试
• 压力测试
• 配置测试
• 并发测试
• 可靠性测试
• 失效恢复测试
• 大数据量测试

基准测试

有基础的标准，这样能通过对比发现系统的不同点与变化。

应用于以下场景：

1）可以在制定的标准下通过基准测试建立一个性能基准，这样以后当系统的环境、参数发生变化之后，再进行一次相同标准下的测试，即可看出变化对性能的影响。

2）系统进行基准测试可以在较早的阶段发现性能问题。

3）某系统从来没有进行过任何性能测试，需要对该系统做一次性能评估作为后续开发调优的参考。

狭义性能测试（Performance Testing）

​ 是通过模拟生产运行的业务压力量和使用场景组合，测试系统的性能能否满足生产系统要求。Performance Testing是一种常见的测试方法，就是在特定的运行条件下验证系统的能力情况。该测试是一种正常的测试，主要是测试系统正常使用时是否满足要求。

负载测试（Load Testing）

负载测试是在被测系统上不断增加压力，直到性能，例如“响应时间”超过预定指标或者某种资源使用已经达到饱和状态。这种测试方法可以找到系统的处理极限，为系统调优提供数据。

压力测试（StressTesting）

压力测试是测试系统在一定饱和状态下，例如cpu、内存等在饱和使用状态下，系统能够处理的会话能力，以及系统能否会出现错误。压力测试与负载测试有些类似，经常把负载测试描述成压力测试的一种场景-例如增加用户数对系统进行压力测试。压力测试的目的是为了揭露高负载下的问题，例如资源竞争、同步问题、内存泄漏等。

配置测试（ConfigurationTesting）

​ 配置测试方法是通过被测系统的软/硬件环境的调整，了解各种不同环境对系统性能影响的程度，从而找到各项资源的最优分配原则

例如在测试执行时更换、扩充硬件设备，调整网络环境、调整应用服务器和数据库服务器的参数设置，比较每次测试结果，从而确定各个因素对系统性能的影响。

并发测试（Concurrency Testing）

并发测试是通过模拟用户的并发访问，测试多用户并发访问同一个应用，同一个模块或者数据记录时是否存在死锁或者其他性能问题。

并发数计算方法1：
并发数=PV / PV Time× 页面连接次数×HTTP 响应时间× 因数/ Web 服务器数量。
其中，PV Time 是PV 的统计时间，换算成秒，一天是86 400s。页面连接次数包括外部的JS、CSS、图片等，一般为10。HTTP 响应时间一般可为1s 或更少。因数一般为5。假设，网易官网每天有6 万PV，其余参数保持默认，那么推算出来的并发数大致为35。(pv---page view，即页面浏览量）
并发数计算方法2：80-20原则

可靠性测试（Reliability Testing）

可靠性测试是通过给系统加载一定的业务压力（例如资源在70%-90%的使用率）的情况下，让应用系统持续运行一段时间，测试系统在这种条件下是否能够稳定运行。

失效恢复测试（Failover Testing）

1.失效恢复测试方法是针对有备份和负载均衡的系统设计的，这种测试方法可以用来检验如果系统局部发生故障，用户能否继续使用系统，以及如果这种情况发生，用户将受到多大程度的影响。

2.一般的关键业务系统都会采用热备份或是负载均衡的方式来实现。这种业务系统一般要求有一台或几台服务器出现问题，应用系统仍然可以正常执行业务。该方法就是在测试中模拟设备故障，验证预期的恢复技术是否可以正常发挥作用

3.不是所有的系统都需要进行这种类型的测试，尤其是并没有明确给出系统需要持续运行指标的系统

大数据量测试：

大数据量测试的两种类型：

1.独立的数据量测试

针对某些系统存储、传输、统计、查询等业务进行大数据量测试

2.综合数据量测试

和压力测试、负载测试、并发测试、可靠性测试相结合的综合测试方案

这些测试类型其实是密切相关，甚至无法区别，例如几乎所有的测试都有并发测试。在实际中不用纠结具体的概念。而是要明确测试的目的。

	能力验证	规划能力	性能调优	发现缺陷
性能测试	*
负载测试		*	*
压力测试	*	*	*	*
配置测试		*	*
并发测试				*
可靠性测试	*
失效恢复测试	*		*	*

性能测试实施与管理

性能测试前期准备

测试工具引入

测试方案

测试设计与开发

测试执行与管理

测试分析与调优

测试报告

性能测试前期准备

• 系统基础功能验证

确保当前需要进行测试的应用系统具备了进行性能测试的条件

确保当前进行性能测试的应用系统版本已经稳定；

必须保证性能测试之前至少进行了一轮的系统功能覆盖测试，且性能测试选取的业务功能正常。

• 组建测试团队

​ 确定团队内角色的构成，以及确定人员的技能

角色	职责	技能
测试经理	1、和用户等项目干系人交互，确保测试的外部环境 2、制定测试计划 3、监控测试进度 4、发现和处理测试中的风险	1、计划执行和监控能力 2、风险意识和能力 3、外交能力和灵活变通的能力

支持角色（系统）	系统支持，协助解决测试工程师无法解决的系统问题	专职的系统管理员
支持角色（网络）	网络方面的支持，协助测试工程师解决网络方面的问题，在必要时为测试分析角色提供网络方面的分析支持	专职的网络管理员
支持角色（数据库）	数据库方面的支持，在必要时为测试分析角色提供数据库方面的支持	专职的DBA
测试工程师	测试数据的准备	性能测试工程师

• 测试工具需求确认

​ 根据被测系统的了解，评估性能测试工具所应具备的功能

被测系统环境	测试工具功能需求建议
操作系统环境	测试工具是否能运行在本操作系统上
测试工具是否能支持对本操作系统的监控
应用服务器环境	测试工具能否支持对本应用服务器的监控
数据库环境	测试工具能否支持本数据库的监控
应用使用的协议	测试工具能否支持需要进行录制和产生负载的协议
网络环境	是否需要测试工具支持防火墙
是否需要测试工具支持负载均衡
测试管理支持	测试工具是否能够提供方便的测试结果分析和管理

测试工具引入

• 工具选择

​ 选择适合项目的性能测试工具，商业工具或者是自行开发的工具，Loadrunner，jmeter

• 工具应用技能培训

  为项目组的相关参与者进行测试工具的应用技能培训，以使参与者能够具备测试需要的技能

• 确定工具应用过程

​ 确定测试工具在测试中的具体应用范围，并不是“工具无所不能”，哪些工作使用工具完成，哪些无法使用工具完成

性能测试方案

1、调研测试需求

• 测试业务范围

关键的、常用的、压力较大的、有代表性的、不宜过多

• 测试环境

硬件环境：主机型号、配置…

软件环境：操作系统、数据库…

网络环境：带宽？交换机？防火墙？

• 测试目的：

上线前性能测试？对比性能测试？调优？查找缺陷

• 性能指标

业务性能指标：

一般步骤是首先从需求和设计中分析出性能测试需求，性能测试需求的来源是多方面的， 需求文档（非功能需求的描述）、设计文档、 客户备忘录、历史经验的积累等等

系统性能指标：

cpu使用率 、内存使用率

注：实际测试时，需要监控许多其他的性能指标：数据库、服务器系统、网络，用于定位问题

2、测试策略和测试资源需求

测试工具、测试方式、测试执行

人力资源：明确所需的人员类型（性能测试负责人、性能测试工程师、应用工程师、系统工程师、数据库工程师、网络工程师）、由何方提供、明确职责分工

硬件资源：明确测试时所需的硬件资源(测试工具要求机器的内存，磁盘空间)

3、性能测试计划

任务	起止时间	责任人	任务说明
1性能测试方案
2测试环境准备	预计2天
2.1应用软件部署、检查
2.2数据库基础数据导入
3测试脚本、测试数据	预计1天
3.1脚本录制
3.2脚本参数化
3.3脚本调试
4测试执行	预计5天
4.1压力测试、系统调优
4.2 负载测试
5编写性能测试报告	预计1天

性能测试设计与开发

1.测试环境设计

性能测试的结果与测试环境之间的关联性非常大，无论那种性能测试，都必须首先确定测试的环境，包括系统的软/硬件环境、数据库环境等等（50万条数据和空数据库执行操作的时间显然是不同的）

2.测试场景设计

测试场景模拟的一般是实际业务进行的一个剖面，其包括业务、业务比例、测试指标的目标、测试过程中需要监控的性能计数器

场景名称	混合交易性能表现测试
目的	通过多个交易的混合场景运行，获得各个交易在混合情况下的平均响应时间，配合开发人员调优，同时监控服务器和数据库资源。 在一定时间内经过调优确定参数后，获得性能表现。
结果	获得各个交易的平均响应时间和监控数据
配置信息	并发用户数分别为100、200、300 运行30分钟，用户一起增加，无思考时间，无迭代等待时间
交易名称	百分比	100	200	300
Tran1	30	30	60	90
Tran2	30	30	60	90
Tran3	40	40	80	120

3.测试用例设计

对测试场景进一步细化，一般包括测试类型、测试内容描述、前置条件、业务操作序列、参数化需求、验证点等

4.脚本和辅助工具开发

​ 测试脚本是对业务操作的体现，一个脚本一般就是一个业务过程的描述，脚本的开发通常都基于“录制”，然后对脚本进行完善，以满足在性能测试中顺利使用。

​ 辅助工具开发一般基于性能工具无法满足，或者是获取特定资源需要使用。

性能测试执行与管理

1.建立测试环境

​ 搭建需要的测试环境，需要多个团队角色的参与，包括硬件、软件系统环境的搭建、数据库环境建立、应用系统的部署、系统设置参数的调整、以及数据库环境准备

2.部署测试脚本和测试场景

​ 脚本和测试场景的部署最终需要保证场景与设计的一致性，保证需要监控的计数器都已经部署好了相应的监控手段。

3.执行测试和记录结果

​ 可以依靠工具完成，对于工具不支持的，可以采用系统自带工具或自行开发工具解决。测试结果是最后分析的基础。

测试交易	Tran1
测试时间	测试类型	场景说明
2006-05-06 14：10—14：20	单交易多用户测试	100用户执行20分钟；模拟系统延时1s 无思考时间，无间隔时间
测试结果描述及存在瓶颈
测试结果： 每秒钟交易数7.19、事物平均响应时间5.56、交易成功率90% 存在的问题 虚拟用户渐进增加。虚拟用户少于40个时，系统性能良好，随着虚拟用户增加，响应时间基本不变，TPS增加；超过40个用户时，响应时间变慢，TPS基本不变。部分事物因为超时失败。
测试环境配置及性能调优点
应用系统服务器
系统配置参数	日志	其他
Socket 连接池连接数=100	级别调试
数据库服务器
Oracle参数	索引	表分析
Pga_aggregate_target=524288000 Processes=1000、DB_CACHE_SIZE_2046m Sga_max_size=4094m
调优情况及效果	改进状态跟踪和负责人
资源监控明细
应用服务器	DB服务器	模拟系统服务器
CPU：20.3%；	CPU：31.5%；	CPU：20.3%；
测试场景及测试脚本	测试结果存放目录
Fund_0701_Scensrio_base	Result\res_0701_vu100_15m
备注：

性能测试分析与调优

测试结果分析是最难的部分。是一个灵活的过程，每次性能测试结果的分析都需要测试分析人员具有相当程度的对软件性能、软件架构和各种性能测试指标的了解，性能测试分析需要借助各种图表。

通用方法之一就是“拐点分析的”方法。关注性能表现上的“拐点”，获得“拐点”附近使用情况，定位处系统的性能瓶颈。

性能测试报告

测试目标

指标要求:本次测试预期达到的性能要求。 (TPS,ART，交易成功率，并发数等）

测试概要描述

系统结构

测试时间

测试地点和测试人员

工具和环境

测试过程简介

测试结果和数据

测试结论

测试结果

建议

测试结论限制