学习笔记《软件性能测试过程详解与案例剖析》Word格式.docx
《学习笔记《软件性能测试过程详解与案例剖析》Word格式.docx》由会员分享，可在线阅读，更多相关《学习笔记《软件性能测试过程详解与案例剖析》Word格式.docx（16页珍藏版）》请在冰豆网上搜索。
是否支持被测系统使用的协议
是否支持特殊要求，例如防火墙等
是否提供对我们关心的服务器、应用服务器或是数据库类型计数器的监控
工具使用的脚本语言功能是否完善
2工具比较
3成本分析
价格和License方式
第5章性能测试的组织
5.1性能测试团队的人员构成
1项目测试经理
Ø
确定测试目标
制定测试计划
监控计划执行
处理项目干系人的交互
发现和处理测试中的风险
2测试设计
根据用户需求和软件需求，从业务的角度分析和整理典型场景，
识别出性能需求
制定合理可行的测试方案和用例
3测试开发
实现测试方案和用例，测试脚本的编写和维护
确定测试过程中需要监控的性能指标
4测试执行
按照测试方案和用例，使用测试工具执行脚本
监控相关的性能指标，记录测试结果
5测试分析
查看测试结果，对照测试目标分析测试数据和测试过程中获取的性能指标
得出测试结论
6支持角色
系统支持网络支持数据库支持
5.2性能测试的过程模型
性能测试过程通用模型PTGMPerformanceTestGeneralModel（基于自动化测试生命周期方法ATLM和TMap模型）
1测试前期准备
验证系统基础功能，确保当前应用系统具备性能测试的条件
组建测试团队，根据项目情况，确定人员所需技能（测试设计、开发、执行、分析等。
但大部分情况是一个人完成，脚本可能是开发人员提供）
测试工具需求确认
被测系统环境
测试工具功能需求
操作系统环境
测试工具是否能运行在本操作系统上
测试工具是否支持对本操作系统的监控
应用服务器环境
测试工具能否支持对本应用服务器的监控
数据库环境
测试工具能否支持本数据库的监控
应用使用的协议
本系统使用了哪些协议
哪些协议需要在性能测试中通过工具进行录制和产生负载
测试工具能否支持需要进行录制和产生负载的协议
网络环境
是否需要测试工具支持防火墙
是否需要测试工具支持负载均衡
测试管理支持
测试工具是否能够提供方便的测试结果分析和管理
性能预备测试
2测试工具引入
工具选择
功能符合度
工具应用技能培训
测试工作相关人员
确定工具应用过程
确定测试工具在测试中的具体应用范围
工具使用过程中的问题解决方法
测试工具的脚本如何管理
3测试计划
性能测试领域分析
不同的性能测试应用领域，性能测试的目标定义会有区别
应用领域
性能测试目标
性能目标
能力验证
验证系统在给定环境中的性能能力
重点关注的关键业务响应时间、吞吐量
规划能力
验证系统的性能扩展能力，找出系统能力扩充的关键点，给出改善其性能扩展能力的建议
业务的性能瓶颈
性能调优
提供系统的性能表现
发现缺陷
发现系统中的缺陷
无
用户活动剖析与业务建模
目的：
寻找用户的关键性能关注点，确定最贴近用户要求的性能目标
用户活动剖析
方法：
系统日志分析和用户调查分析
业务建模
是对业务系统的行为及其实现方式和方法的建模，一般采用流程图的方式描绘出各进程之间的交互关系和数据流向
确定性能目标
性能测试目标根据性能测试需求和用户活动分析结果和业务建模来确定
制定测试时间计划
4测试设计与开发
测试环境设计
性能测试的结果与测试环境之间的关联性非常大，必须先确定测试的环境。
测试环境设计包括系统的软硬件环境、数据环境设计、环境的维护方法。
能力验证领域：
明确是在特定的部署环境下进行
规划能力领域：
测试环境不特定，但也需要设计基准环境
性能调优领域：
调优过程是一个反复的过程，在调优过程中必须保证每次测试时的环境保持不变
测试场景设计
测试场景模拟的一般是实际业务运行的剖面，其包括业务、业务比例、测试指标的目标以及需要在测试过程中进行监控的性能计数器。
剖面：
对性能测试而言，剖面表示的是某个时刻用户使用该应用的典型模式，一般由“用户执行的操作”、“执行不同操作的用户比例”以及“用户使用系统的频率”进行描述。
测试用例设计
把针对每个测试场景规划出相应的工具部署、应用部署、测试方法和步骤，这个过程就是测试用例设计活动。
测试用例是对测试场景的进一步细化。
细化内容包括场景中涉及业务的操作序列描述、场景需要的环境部署等内容。
业务描述中一定会给出判断业务是否执行成功的准则。
测试脚本和辅助工具开发
测试脚本的开发通常基于“录制”，依靠工具提供的录制功能，可以将需要性能测试关注的业务在工具的录制下操作一遍，然后基于该录制后的脚本，对齐进行修改和调试，确保其可以在性能测试中顺利使用。
最常用的脚本修改和调试技巧是参数化、关联、日志输出。
5测试执行和管理
建立测试环境
软硬件系统环境搭建
数据库环境搭建
应用系统的部署
系统设置参数的调整
数据环境
（使用检查列表Checklist，检查环境的可用性）
部署测试脚本和测试场景
通过测试工具部署测试脚本和测试场景。
部署完成后，需要一个确认步骤，保证场景部署与设计一致。
保证需要监控的计数器都已经部署好相应的监控手段。
执行测试和记录结果
测试执行非常简单，一般只需要使用菜单或是按钮就可以完成。
记录结果也可以依靠测试工具完成，通过测试工具中的监控模块，可以获取并记录需要关注的性能计数器的值。
如果测试工具不提供，可以用脚本调用操作系统提供的工具，在脚本实现中讲各性能计数器值分析出来并按照一定格式记录在本地文件中。
6测试分析
测试分析过程用于对测试结果进行分析，根据测试的目的和目标给出测试结论。
性能测试的分析需要借助各种图表，一般的性能测试工具提供了报表模块来生成不同的图表，报表模块同时还允许用户通过叠加、关联等方式处理和生成新的图表。
如果是自己编写的脚本获取性能计数器的值，则可以通过Excel生成图表。
性能分析的通用方法之一：
“拐点分析”方法是一种利用性能计数器曲线图上的拐点进行性能分析的方法。
基本思想是基于这个事实：
性能产生瓶颈是由于某个资源的使用达到了极限，此时的表现是随着压力增大系统性能表现急剧下降，因此只要关注性能表现上的“拐点”，获取拐点附近的资源使用情况，就能够定位系统性能瓶颈。
但只能定位到资源上的制约，无法直接定位引起制约的原因。
第2章性能测试的应用领域
2.1性能测试的方法
1性能测试PerformanceTesting
通过模拟生成运行的业务压力量和使用场景组合，测试系统的性能是否满足生成性能要求。
一个典型的场景包括操作序列、并发用户数量条件。
且要有确定的性能目标。
性能目标的描述基本上是：
要求系统在100个并发用户的条件下进行某业务操作，响应时间不超过5秒。
2负载测试LoadTesting
通过在被测系统上不断增加压力，直到性能指标超过预定指标或某种资源使用已经达到饱和状态。
这种性能测试方法主要目的是找到系统处理能力的极限。
这个极限一般会描述成：
在给定条件下最多允许120个并发用户访问；
在给定条件下最多能够在1小时内处理2100笔业务。
预期的性能指标一般会定义为：
响应时间不超过10秒、服务器平均CPU利用率低于65%。
负载测试一般用来了解系统的性能容量，或是配合性能调优来使用。
（系统在保证一定响应时间的情况下能够允许多少并发用户的访问）
3压力测试StressTesting
通过增加访问压力（例如增加并发用户数量）使应用系统的资源使用保持在一定的水平。
主要目的是检验此时应用表现，重点在于有无出错信息产生，系统对应用的响应时间。
4配置测试ConfigurationTesting
了解各种不同环境对系统性能影响的程度，从而找到系统各项资源的最优分配原则。
5并发测试ConcurrencyTesting
并发测试方法通过模拟用户的并发访问，测试多用户访问同一个应用、同一个模块或者数据记录时是否存在死锁或者其他性能问题。
并发测试主要关注的问题
问题类别
问题描述
内存问题
是否有内存泄漏（C/C++）
是否有太多的临时对象（Java）
是否有太多的超过设计生命周期的对象（Java）
数据库问题
是否有数据库死锁（DeadLock）
是否经常出现长事务（LongTransaction）
线程进程问题
是否出现线程进程同步失败
其他问题
是否出现资源争用导致的死锁
是否没有正确处理异常（例如超时）导致系统死锁
6可靠性测试ReliabilityTesting
通过给系统加载一定的业务压力的情况下，让应用持续运行一段时间，测试系统在这种条件下是否能够稳定运行。
对于一般的非关键性大型应用来讲，让系统处于可能的峰值压力下，进行2-3天的稳定性测试基本上足够。
测试过程中需要关注系统的运行状况。
关注系统内存使用状况，系统的其他资源使用有无明显的变化，以及系统响应时间有无明显变化。
如果随着时间推移，响应时间有明显变化，或是系统资源使用率有明显波动，都可能是系统不稳定的征兆，需重点关注。
7失效恢复测试FailoverTesting
这种方法是针对有冗余备份和负载均衡的系统设计的。
用来验证如果系统局部发生故障，用户是否能够继续使用系统；
以及如果这种情况发生，用户将受到多大程度的影响。
2.2性能测试应用领域分析
1能力验证
关注的是，在给定条件下，系统能否具有预期的能力表现。
一般采用的测试方法包括性能测试可靠性测试压力测试失效恢复测试
2能力规划
关注的是，在某种可能发生的条件下，系统具有如何的性能能力。
一般会描述为：
某系统能否支持未来一段时间内的用户增长，或是，应该如何调整系统配置，使系统能够满足增长的用户数的需要。
一般采用的测试方法包括负载测试配置测试压力测试
3性能调优
性能调优的标准过程
确定基准环境、基准负载、基准性能指标
调整系统运行环境和实现方法，执行测试
记录测试结果，进行分析
性能调优主要测试方法是配置测试负载测试压力测试失效恢复测试
4缺陷发现
主要目的是发现系统中存在的缺陷，并没有可以参照的性能指标或是需要达到的性能目标。
一般采用的测试方法：
并发测试压力测试
第3章性能计数器及性能分析方法
性能计数器通常被用来衡量被测系统当前的状况和进行性能测试结果分析。
可以在操作系统级别、应用服务器级别和数据库级别上查看和记录性能计数器的数值，在性能测试分析结果对这些数据进行分析。
3.1操作系统计数器及分析
1Windows操作系统的主要计数器
类别
计数器名称
计数器描述
Memory
AvailableMbytes
可用物理内存数
后续完善。
2UNIX操作系统的主要计数器
3内存分析方法
4处理器分析方法
5磁盘I/O分析方法
6进程分析方法
7网络分析方法
3.2应用服务器计数器
1IIS应用服务器计数器
除此之外，还有如下几个需关注的
ActiveServerPage计数器
重点关注：
超时的请求数、脚本运行时期的错误、队列中的请求数、请求等待时间、请求总数、失败的请求总数、送出的总字节数。
其中，队列中的请求数和请求等待时间直接反映应用服务器的处理能力。
如果队列中的请求数数值处于一个比较高的水平，同时请求等待时间是一个比较大的值，则应用服务器本身是瓶颈。
WebService计数器
重点关注：
BytesTotal/Sec:
显示Web服务器发送和接收的总字节数。
数值低表明该IIS正在以较低的速度进行数据传输。
ConnectionRefused:
数值越低越好。
数值高表明网络适配器或处理器存在瓶颈。
NotFoundErrors：
显示由于被请求文件无法找到而无法由服务器满足的请求数（HTTP状态代码404）
2J2EE应用服务器计数器
常用的包括WebLogicWebSphereTomcat等。
主要三类：
JVM、JDBCConnectionPool、ExecuteQueue
3.3数据库计数器
数据库服务器常用计数器
第1章软件性能测试基本概念
1.1什么是软件性能
性能是一种指标，表明软件系统或构件对于其及时性要求的符合度；
其次，性能是软件产品的一种特性，可以用时间来度量。
性能的及时性用响应时间或者吞吐量来衡量。
对于软件性能的关注是多个层面的。
1用户视角的软件性能
从用户角度来说，软件性能就是软件对用户操作的响应时间。
2管理员视角的软件性能
从管理员角度来看，首先软件性能表现在系统的响应时间，同时还更关注和系统状态相关的信息。
管理员关心的问题
软件性能描述
服务器的资源使用状况是否合理
资源利用率
应用服务器和数据库服务器使用状况是否合理
系统是否能够实现扩展
系统可扩展性
系统最多能支持多少用户的访问？
系统最大的业务处理量是多少
系统容量
系统性能可能的瓶颈在哪里
更换哪些设备能够提高系统性能
系统能否支持7*24小时的业务访问
系统稳定性
3开发视角的软件性能
从开发角度，最想知道的是如何通过调整设计和代码实现，或者如何通过调整系统设置等方法提高软件的性能表现；
和如何发现和解决软件设计和开发过程中产品的由于多用户访问引起的缺陷；
使性能表现不佳的因素，即“性能瓶颈”。
开发人员关心的问题
架构设计是否合理
系统架构
数据库设计是否存在问题
数据库设计
代码是否存在性能方面的问题
代码
系统中是否有不合理的内存使用方式
系统中是否存在不合理的线程同步方法
设计与代码
系统中是否存在不合理的资源竞争
1.2软件性能的几个主要术语
1响应时间
呈现时间+系统响应时间
呈现时间是指数据在客户端收到响应数据后呈现页面所消耗的时间。
系统响应时间是指应用系统从请求发出开始到客户端接收到数据所消耗的时间。
合理的响应时间取决于实际的用户需求。
2并发用户数
并发用户数决定与具体的业务场景，一般会先对业务分解，分析出其中典型业务场景，然后基于场景采用某些方法获取其并发用户数。
（业务并发用户数）
3吞吐量
吞吐量是指单位时间内系统处理的客户请求的数量。
4性能计数器
性能计数器Counter是描述服务器或操作系统性能的一些数据指标。
5思考时间
思考时间ThinkTime，从业务角度来说，这个时间指的是用户在进行操作时，每个请求之间的间隔时间。
对于交互式应用，一般模式是，用户在发出一个请求后，等待一段时间，再发出下一个请求。
在脚本中，思考时间提醒为脚本中两个请求语句之间的间隔时间。
如何计算思考时间：
步骤如下：
首先计算出系统的并发用户数；
统计出系统平均的吞吐量；
统计出平均每个用户发出的请求数量；
根据公式6计算出思考时间。
1.3软件性能测试方法论
1SEI负载测试计划过程SEILoadtestingplanningprocess
其目标是产生：
清晰、易理解、可验证的负载测试计划
SEI负载此时计划过程包括6个关注的区域：
目标、用户、用例、生产环境、测试环境、测试场景。
缺点：
只给出了负载测试需要关注的重点区域，但没有形成实际可以操作的过程。
2RBI方法RapidBottleneckIdentify
用于快速识别系统性能瓶颈的方法。
该方法基于以下事实：
发现的80%的系统的性能瓶颈都是由吞吐量制约；
并发用户数和吞吐量之间存在一定的关联；
采用吞吐量测试可以更快速定位问题。
3性能下降曲线分析法
实际上描述的是性能随用户数增长而出现下降趋势的曲线。
这里的性能可以是响应时间，也可以是吞吐量或单击数/秒的数据。
主要关注：
系统性能最优秀的区间、系统性能开始变坏的区间、系统性能急剧下降的拐点。
从而找到性能瓶颈的原因，和为性能调优提供依据。
4LoadRunner的性能测试过程
LR将性能测试过程分为6个步骤。
计划测试阶段：
收集测试需求、确定典型场景；
测试设计阶段：
设计测试用例；
创建VU脚本阶段：
根据设计的用例创建脚本；
创建测试场景阶段：
设计和设置测试场景，包括设定监控指标；
运行测试场景阶段：
执行已经创建的测试场景，收集相应数据；
分析结果阶段：
结果分析和报告工作。
整个过程都紧密与LR工具集成，没有兼顾使用其他工具，没有普适性。
5Segue提供的性能测试过程
SilkPerformer提供的性能测试过程从确定性能基线开始，通过单用户对应用的访问获取性能取值的基线，然后设定可接受的性能目标（响应时间），用不同的并发用户数等重复进行测试。
适合性能调优和性能优化。
过于和LR一样，过于依赖工具本身，同时缺乏对计划、设计阶段的明确划分。
6PTGM模型
性能测试过程通用模型PTGM
测试前期准备
测试工具引入
测试计划
测试设计与开发
测试执行和管理
测试分析
升级会员 