性能测试培训基础知识.docx
《性能测试培训基础知识.docx》由会员分享，可在线阅读，更多相关《性能测试培训基础知识.docx（18页珍藏版）》请在冰豆网上搜索。
性能测试培训基础知识
性能测试培训
（一）
——基础知识
1.软件性能测试的概念
1.1软件性能与性能测试
软件性能：
覆盖面广泛，对一个系统而言，包括执行效率、资源占用、稳定性、安全性、兼容性、可扩展性、可靠性等。
性能测试：
为保证系统运行后的性能能够满足用户需求，而开展的一系列的测试组织工作。
1.2不同角色对软件性能的认识
用户眼中的软件性能：
⏹软件对用户操作的响应时间
如用户提交一个查询操作或打开一个web页面的链接等。
⏹业务可用度，或者系统的服务水平如何
管理员眼中的软件性能：
管理员关心的问题
软件性能描述
服务器的资源使用状况
资源利用率
系统支持多少用户访问，处理量
系统的容量
系统性能的可能瓶颈
系统可扩展性
更换哪些设备可提供系统性能
系统可扩展性
系统能否支持7*24小时的业务访问
系统稳定性
开发人员眼中的软件性能：
开发人员关心的问题
软件性能描述
架构设计是否合理
系统架构
数据库设计是否合理
数据库设计
代码是否需要优化
代码
1.3性能测试的对象
服务器端：
⏹负载均衡系统；
⏹服务器（单机、双机热备、集群）；
⏹存储系统、灾备中心；
⏹数据库、中间件。
网络端：
⏹核心交换设备、路由设备；
⏹广域网络、专线网络、局域网络、拨号网络等；
应用系统：
由此可见，性能测试是一个系统性的工作，被测对象包括系统运行时使用的所有软硬件。
但在实际操作时，将根据项目的特点，选择特定的被测对象。
1.4性能测试的目标
评价系统当前的性能：
⏹系统刚上线使用，即处于试运行时，用户需要确定当前系统是否满足验收要求；
⏹系统已经运行一段时间，如何保证一直具有良好的性能。
分析系统瓶颈、优化系统：
⏹用户提出业务操作响应时间长，如何定位问题，调整性能；
⏹系统运行一段时间后，速度变慢，如何寻找瓶颈，进而优化性能。
预见系统未来性能、容量可扩充性：
⏹系统用户数增加或业务量增加时，当前系统是否能够满足需求，如果不能，需要进行哪些调整？
提高硬件配置？
增加应用服务器？
提高数据库服务器的配置？
或者是需要对代码进行调整？
1.5性能测试的分类
按照测试压力级别：
⏹负载测试；
⏹压力测试；
按照测试实施目标：
⏹应用在客户端的测试；
⏹应用在网络的测试；
⏹应用在服务器端的测试；
按照测试实施策略：
⏹并发性能测试；
⏹疲劳强度测试；
⏹大数据量测试；
⏹失效恢复测试。
其他分类：
⏹并发测试；
⏹执行效率测试；
⏹资源占用测试；
⏹容量测试；
⏹网络测试；
⏹稳定性测试。
1.5.1负载测试
负载测试是为了确定系统在各种工作负载下的性能，目标是测试当负载逐渐增加时，系统的性能变化，并最终确定在满足性能指标的情况下，系统所能承受的最大负载量。
如：
系统在保证一定的响应时间（或稳定性）的情况下，能够允许多少并发用户访问。
系统的各项指标包括：
响应时间、CPU负载、内存使用等如何决定系统的性能。
1.5.2压力测试
压力测试通过确定一个系统的瓶颈或者不能接受的性能点，来获得系统能提供的最大的服务级别的测试。
通俗的讲，压力测试是为了发现在什么条件下，应用程序的性能会变得不可接受。
1.5.3并发性能测试
并发性能测试是一般意义上的负载压力测试。
1.5.4疲劳强度测试
疲劳强度测试是通过一定时间长度的负载压力测试，使测试者能够了解系统是否可以满足7*24小时运行的需要。
疲劳强度测试属于可靠性测试的范畴。
1.5.5大数据量测试
大数据量测试是测试应用程序随着数据库数据量级数增加的情况下的性能表现。
1.5.6失效恢复测试
失效恢复测试是针对有冗余备份或负载均衡的系统来说的。
检验当系统局部发生故障时，系统灾备措施是否可以正常启动，用户是否可以继续使用。
通过实施失效恢复测试，评估系统的健壮性和可恢复性。
2.性能测试策略
2.1.应用在客户端的测试
2.1.1.实现机制
通过在一台或几台PC机上模拟成百上千的虚拟用户同时执行业务的情景，对应用程序进行测试。
通过可重复的、真实的测试，能够彻底的度量应用程序的性能，确定问题所在。
2.1.2.常用工具
⏹商业测试工具
LoadRunner,RationalRobot，QALoad,Silk
Performor
⏹开源（OpenSource）测试工具
ApacheJmeter,OpentSTA…
⏹自主开发测试程序或者测试工具
2.1.3.自动化性能测试的优势
自动化性能测试的优势
可靠
每次运行精确地执行相同的操作，可以排除手工操作错误；
可重复
测试相同操作重复执行时，软件如何响应
可编程
可以编程实现得到应用系统隐藏信息的复杂测试
综合测试
可以实现覆盖应用系统每个特征的一套综合测试方案
可重用的
针对应用系统的不同版本，测试脚本可重复使用，即使用户界面发生变化
2.1.4.测试工具使用的基本步骤
⏹录制业务流程，形成测试脚本；
⏹修改调试脚本；
⏹执行性能测试。
2.1.5.测试脚本执行策略
性能测试脚本应本着一一对应的原则录制业务，即一个脚本仅针对一项业务录制。
测试脚本执行策略应按照以下顺序执行：
1、单一脚本单用户执行；
2、单一脚本多用户执行；
3、采用增殖的方式集成混合脚本，且仅使用单用户执行；
4、混合脚本多用户执行。
2.2.应用在网络的测试
2.2.1.网络仿真技术
网络仿真技术的作用是模拟网络的吞吐量、延时、抖动、错包、丢包等性能特性，从而在测试环境下就可以得到设备或软件在实际的网络环境下的表现，并在发现性能问题时，对每个数据包进行分析，从而可以快速的找到问题所在。
2.2.2.网络性能监控
2.2.2.1.测试目标
⏹分析关键应用程序的性能；
⏹定位问题的根源是在客户端、服务器、应用程序还是网络；
⏹哪些应用程序占用大量带宽；
⏹哪些应用程序导致系统瓶颈或资源竞争；
⏹哪些应用程序产生了最大的网络流量。
2.2.2.2.常用工具
⏹Compuware：
NetworkVantage
⏹HP：
NetworkNodeManager
⏹IBM:
Tivoli
2.2.2.3.工作原理
在客户端、应用服务器端、数据库服务器端等处部署捕捉点采集数据，并利用管理工具对采集到的数据进行分析。
⏹捕捉点：
Agent被动监听数据包来实现实时数据采集
⏹分析：
AgentManager完成对所跟踪到的数据的分析
2.2.2.4.响应时间的计算
上图为响应时间的示意图。
图中共设置四个捕捉点，客户端在第0秒发出请求，服务器在第0.31秒接收到客户端的请求，服务器响应请求后，在第2.11秒时发送响应结果，客户端在第3秒时接收到响应结果。
因此，上图中的响应时间应为3秒。
注意，在应用逻辑路径上多点数据采集，以便于在任何两个节点间进行数据整合，测量分段的响应时间，分析应用故障。
2.2.2.5.实现方法
⏹探针
采集、存储数据，并根据应用对数据进行分类。
设置的原则是根据网络组成和监控要求。
⏹探针管理器
管理配置探针，设定数据采集与上传时间，汇总收集的数据。
⏹时间服务器
对探针进行时针同步
⏹交互界面
数据展示平台
2.3.应用在服务器端的测试
2.3.1.对服务器操作系统的监控
对服务器操作系统的监控内容如下：
⏹CPU
⏹内存&SWAP
⏹磁盘管理
⏹网络
⏹文件系统
⏹活动的进程
2.3.2.对数据库的监控
对数据库的监控内容如下：
⏹监控数据库系统中关键的资源
⏹监测读写页面的使用情况
⏹监控超出共享内存缓冲区的操作数
⏹监测上一轮询期间作业等待缓冲区的时间
⏹跟踪共享内存中物理日志和逻辑日志的缓冲区的使用率
⏹监控磁盘的数据块使用情况以及被频繁读写的热点区域
⏹监控用户事务或者表空间监控事务日志
⏹监控数据库锁资源
⏹监测关键业务的数据表的表空间增长
⏹监控SQL执行情况
2.3.3.对中间件的监控
对中间件的监控，需要分析具体的中间件的特性，以确定监控内容。
如：
IBM的MQ，则需要监控其Client信息、队列信息、服务信息等。
2.3.4.监控方法
⏹监控工具
spotslight、tivoli、nmon、siteview
⏹操作系统本身自带命令
如：
vmstat,iostat,netstat,top,topas
3.性能测试需求分析
3.1.原始需求与测试目标的制定
原始需求
测试目标
要花多少时间做完一笔交易?
测量对最终用户的响应时间
什么样的配置提供了最好的性能?
确定最优硬件配
系统能在无错情况下能承担多大及多长时间的负载?
可靠性测试
这些升级对系统性能影响多大？
测试软、硬件升级前后的性能表现并作出对比
服务器应该选择哪些硬件与软件？
评估新产品
在没有较大性能衰减的前提下，系统能够承受多大负载？
测试系统负载
哪些因素降低交易响应时间
分析系统瓶颈
3.2.测试强度估算
80～20原理：
每个工作日中80％的业务在20％的时间内完成。
举例：
每年业务量集中在8个月，每个月20个工作日，每个工作日8小时，即每天80%的业务在1.6（8*0.2）小时完成。
去年全年处理业务约100万笔，其中15％的业务处理中每笔业务需对应用服务器提交7次请求；其中70％的业务处理中每笔业务需对应用服务器提交5次请求；其余15％的业务处理中每笔业务需对应用服务器提交3次请求。
根据以往统计结果，每年的业务增量为15％，考虑到今后3年业务发展的需要，测试需按现有业务量的两倍进行。
每年总的请求数：
（100x15%x7+100x70%x5+100x15%x3）x2=1000万次/年
每天请求数：
1000/160（8*20）=6.25万次/天
每秒请求数：
（62500x80%）/（8x3600x20%）=8.68次/秒
即服务器处理请求的能力应达到9次/秒
几个关键数据:
⏹全年业务总量；
⏹各类业务请求次数；
⏹各类业务所占百分比；
⏹交易发生时间；
⏹年业务增量。
3.3.测试需求分析方法
3.3.1.任务分布图
关注点：
⏹有哪些交易任务；
⏹在一天的某些特定时刻系统都有哪些主要操作。
登录
220
250
210
记账
10
15
12
21
创建记录
180
110
120
90
50
数据更新
90
75
50
30
查询
50
30
20
15
批处理
20
25
15
生成报表
50
60
40
系统备份
11
8
12
0
2
4
6
8
10
12
14
16
18
20
22
24
根据上图所示，性能测试应选择黄色部分标识的业务场景及其业务强度；且分为两个测试场景执行。
3.3.2.交易混合图
关注点：
⏹高峰期有哪些操作？
⏹中间件操作有多少？
数据库操作有多少？
⏹如果任务失败，那么商业风险有多少？
交易名称
日常业务
高峰业务
WEB负载
数据库负载
风险
登录
70笔/小时
210笔/小时
高
低
大
用户注册
10笔/小时
15笔/小时
中等
中等
小
生成订单
130笔/小时
180笔/小时
中等
中等
中
更新订单
20笔/小时
30笔/小时
中等
中等
大
发货
40笔/小时
90笔/小时
中等
高
大
选择依据：
⏹高负载
⏹高吞吐量
⏹高数据库I/O
⏹高商业风险
3.3.3.用户概况分析
关注点：
⏹哪些任务是每个用户都要执行的?
⏹针对不同角色的用户，他们的任务是什么?
⏹针对每个用户，不同任务的比例如何?
采购部门
库管部门
销售部门
经理
输入订单
18
50
300
修改订单
10
20
70
计算
5
8
20
50
统计分析
70
如上图所示，此种方法可用于计算不同的用户所操作的业务种类以及业务种类间的分配比例。
根据此图，可制定测试场景的执行策略。
4.性能测试工作组织流程
4.1.性能测试前期调研
4.1.1.环境调研
⏹了解工作环境
⏹了解软硬件设备
⏹了解相关人员及职责
⏹了解项目背景
⏹了解进度计划
4.1.2.业务调研
⏹核心业务功能
⏹用户使用习惯
⏹业务交易量
⏹业务交易分布
⏹数据量/增量
4.1.3.系统调研
⏹系统架构
⏹开发语言
⏹通信协议
⏹实际使用情况
⏹物理部署
⏹操作系统
⏹关键参数
⏹数据库
⏹中间件
⏹软件部署结构
4.1.4.需求调研
测试目的：
⏹测试对象
⏹测试类型
测试指标：
⏹用户并发数
⏹事务吞吐率
⏹响应时间
⏹资源使用情况
⏹高可用
⏹可扩展性
⏹可靠／稳定性
⏹产品对比
4.2.性能测试方案设计
4.2.1.建立业务模型
⏹分析系统所可能存在的瓶颈和原因；
⏹分析历史交易数据来确定各业务交易类型所占的比例；
⏹对每一类业务的访问或交易，选取最有代表性的操作步骤；
⏹最终目的是建立一个能够逼真模拟系统实际运行场景的业务模型；
4.2.2.建立数据模型
⏹依据业务模型准备测试数据和基础数据，具体的数据类型和数据量需要根据选择的交易类别或性能测试场景设置而定；
⏹数据容量符合实际运行情况；
⏹尽量模拟真实业务数据；
⏹能贯穿各相关系统，保证业务流程的顺畅正确；
4.2.3.建立监控模型
⏹性能测试的目的不仅仅是获得关键业务的性能指标，同时也要通过性能测试监控主机、数据库、中间件的各个性能指标，从而发现性能瓶颈，为进一步的性能调优提供准确的参考数据；
⏹监控对象及指标选择；
监控工具选择：
⏹监控程序对待测系统产生较小的压力；
⏹监控程序获取的数据便于分析和统计；
⏹监控分实时监控和非实时监控；
4.2.4.建立测试模型
⏹负载生成方式
⏹测试工具选择
⏹一般应该采取基准测试、单业务负载测试、混合负载测试的顺序来执行。
这样做的好处，在单业务负载测试是就可以发现各个系统本身的性能缺陷，而混合负载测试时将重点检查各个业务相互影响导致的性能缺陷；
4.2.5.建立执行模型
系统的性能测试必须要用户、硬件厂家、中间件厂家、数据库厂家紧密配合，才能保证整个测试工作的成功。
因此，只有建立一套规范的性能测试流程，明确各个角色的工作职责，才能使性能测试工作有序、高效的开展。
公司内部则需要软件开发工程师、数据库工程师、软件测试工程师、协调人员的紧密配合。
4.3.测试环境搭建
⏹测试环境＝硬件环境＋软件环境＋网络环境；
⏹硬件环境与系统实际运行的硬件环境尽量保持一致；
⏹软件版本与系统实际运行的软件版本必须保持一致；
⏹尽可能的使用独立网络；
⏹待测软件版本相对稳定；
⏹测试相关的数据从生产环境导出；
⏹测试环境是可用的；
当测试环境发生变化时，所得到的测试结果，仅能够作为测试环境变化后的参考，决不能作为推断依据。
如：
在当前的硬件环境下得到的测试结果，不能作为硬件提高后，肯定能够提高性能的推断依据。
注意事项：
⏹多次测试时，操作系统、被测软件、中间件、数据库应保持相同的版本号；
⏹各类参数保持一致性；
⏹环境变化应做详细记录；
⏹应先分析测试结果，推断瓶颈原因，制订优化方案后，方能修改测试环境。
4.4.测试数据准备
⏹基本数据类型
系统用户数据：
登陆系统使用的帐户名-口令等，数量与虚拟用户数一致。
业务数据：
每个虚拟用户模拟真实用户进行操作时使用到的数据。
辅助数据：
为保证业务操作的正常进行而设置的基本信息资料
⏹可重用数据：
如客户信息等查询类的数据，此类数据只需一次准备即可。
⏹不可重用数据：
此类数据为一次性消耗数据，不可重用，一般应用在数据增加或修改类业务交易，此类数据如帐单标识、发票标识等；
4.5.测试开发与调试
⏹准备测试开发环境；
⏹熟悉被测软件功能原理、处理逻辑和约束；
测试程序包括数据处理程序、负载生成程序、监控程序、数据分析程序和辅助程序。
⏹数据处理程序
用于准备测试数据，包括基础数据、预埋数据、增量数据等；
⏹负载生成程序
用于对被测系统生成压力，可用测试工具或脚本实现；
⏹监控程序-
用于监控软硬件指标，可使用测试工具以及操作系统、中间件、数据库自带监控程序或定制开发的监控程序；
⏹数据分析程序
用于对各类数据的采集和分析，包括：
监控数据及业务数据。
其中，监控数据指系统运行时的运行数据以及操作系统、中间件、数据库的运行数据；业务数据用于分析系统是否存在由性能问题引起的功能缺陷；
⏹辅助程序
保证或增强以上程序功能的程序。
4.6.监控环境搭建与调试
⏹监控工具可用
确保监控工具通信正常且能够捕获所需的监控指标数据；
⏹监控PC资源充足
确保部署监控程序的PC机资源充足；防止因监控PC机资源不足而引起的监控数据搜集失败。
4.7.性能测试实施
⏹按测试方案及计划执行测试场景；
⏹操作系统需要全新部署，且每个测试场景执行完毕，应重启测试环境并清除测试数据；
⏹及时识别和规避测试过程中的风险；
⏹记录详尽的工作日志；
⏹及时采集运行数据、监控数据、业务数据并记录；
4.8.性能测试分析
业务数据分析：
⏹业务日志
⏹系统日志
⏹交易数据
监控数据分析：
⏹指标数据
⏹异常信息
通过不同场景的设计目的，验证是否达到测试预期；通过各项测试数据对比，分析系统运行瓶颈，调整性能测试方案；通过监控数据分析，调整软硬件部署结构或分析瓶颈产生原因，优化性能测试方案。
4.9.性能测试报告
测试工作报告
⏹测试安排
⏹工作进度
⏹风险/问题及处理
软件评测报告
⏹场景执行情况
⏹系统问题及建议
⏹遗留问题
5.总结
本次培训定位于普及性培训，其目的是帮助更多的同事正确理解软件性能测试工作。
因此，本文在第一章节着重介绍了软件性能测试的一些基本概念，包括软件性能测试的对象、目标、分类以及各类软件性能测试的含义和测试目的。
第二章节主要是从性能测试策略的角度，阐述了应用在不同测试实施目标的测试目的、测试方法、常用工具等内容。
第三章性能测试需求分析本应在性能测试工作组织流程中阐述，为突出其重要性，特将此部分内容以独立章节的形式进行描述。
详细阐述了性能测试的目标制定、测试强度估算方法以及测试需求分析方法。
第四章则描述了性能测试工作组织的流程及其和环节的功能内容及其注意要点。
在此，提出几个对软件性能测试的观点，以辅助各位同事对软件性能测试工作的认识：
1、影响性能测试质量的关键因素是分析设计能力而不是工具
在以往接触到的同行中，尤其是对刚入行或从未从事过性能测试工作的人来说，往往认为只要学会LoadRunner等工具，就等于能够做性能测试工作了。
持这种观点的，包括我自己。
但事实证明，工具使用的熟练程度，基本上不会对性能测试工作成果有任何影响。
而决定性能测试工作质量的因素取决于对需求的分析能力、对系统瓶颈可能存在的原因的分析能力、对测试场景的设计能力、对测试结果的分析能力。
2、性能测试工作并不是软件测试人员的专职工作
性能测试的组织工作，可以理解为工程的组织工作，需要各个专业方向的人员配合。
包括：
项目管理人员、软件开发人员、数据库管理人员、网络管理人员、工程实施人员等。
各类人员应职责明确，协作到位。
3、性能测试工作容不得一丝马虎
硬件环境、网络环境和操作系统、中间件、数据库、被测软件的参数都有可能影响到性能测试的结果。
因此，在制定性能测试方案时，应详细描述对测试环境的要求，每个测试场景应明确测试目的、测试环境变更、测试执行策略等信息。
且在执行过程中，应严格按照测试方案中明确的测试步骤执行，详尽记录各类测试执行数据。
4、性能测试应有明确的目标
根据项目成本、对性能的要求等信息，制定切实可行的性能测试指标。
虽然性能测试可监控的对象和指标有很多，但决不能盲目的增加被测对象和指标，就像软件测试工作不能穷尽测试一样，性能测试是必须在一定的条件下进行的，必须有所取舍。
5、性能测试的场景设计一定是可叠加的
性能测试的场景设计，一定要按照由简单到复杂，由单一到综合的增殖叠加方式。
因为性能测试的目的在于验证被测软件最终上线后的综合性能表现。
无法叠加的测试场景，不能说明任何问题。
6、每个场景执行完毕都是一个新的开始
性能测试的场景执行完毕，一定要分析测试运行结果是否达到预期的测试目的。
随时做好调整测试方案、测试场景的准备。
7、性能测试工作任重而道远
性能测试工作涉及操作系统、中间件、数据库、硬件、网络等各方面的技术知识，熟悉各方面的知识，对性能测试方案的有效性有很大的帮助，而掌握这些方面的知识，绝非一朝一夕的事情。
因此，大家要求足够的心理准备，并能够持之以恒，才能够有所收获。
希望本次培训能够对大家有所帮助，在今后的工作中，能够一同积累性能测试经验，共同探讨性能测试的各类问题。
升级会员 