学习笔记《软件性能测试过程详解与案例剖析》-推荐下载

2014.6 Eileen
《软件性能测试过程详解与案例剖析》学习笔记1
看的顺序不是按照章节来的。

so
第4章性能测试工具原理
4.1 性能测试工具模型
性能测试工具通常用来支持压力、负载测试，能够用来录制和生成脚本、设置和部署场景、产生并发用户、向系统施加持续压力
1 性能测试不是就用性能测试工具进行测试。

性能测试只能帮助测试工程师实施性能测试，并不能帮助您完成性能测试的需求、设计和分析工作
2 性能测试工具无法自主进行性能分析，而是根据测试工程师的要求以各种方式提供报表，这些报表可以被用来分析系统性能状况
3 性能测试工具的录制和回放与功能测试工具的录制和回放的区别
功能测试工具的录制和回放是针对GUI的操作录制，脚本中记录的是用户对控件的操作，主要通过操作和数据来验证功能的正确性
性能测试工具的录制和回放着重强调并发的性能，GUI的许多界面操作对服务器都不构成压力。

性能测试工具录制的是服务端和应用之间的通信数据，而不是GUI操作。

所以录制的时候要先选择录制的协议
4 如何选择协议取决于应用和客户端的通信协议。

对于WEB应用来说，采用HTTP/HTTPS协议
4.2 性能测试工具架构
1 虚拟用户脚本产生器Virtual User Generator
通过Proxy代理服务器方式，截获并记录客户端和服务器之间的数据流。

截获数据流后对齐进行协议层上的处理，最终形成的是容易看懂的HTTP业务交互过
程脚本。

自带IDE环境，用户可以通过IDE对脚本进行修改和调试。

2 压力产生器Player
用于根据脚本内容，产生实际的负载。

例如，如果一个测试场景要求产生100个虚拟用户，则压力产生器会生成100个进程或线程，每个线程都对指定的脚本进行解释执行
3 用户代理Agent
4 压力调度和监控系统Conductor
调度工具：可以根据用户的场景要求，设置各种不同脚本的VU数量，设置同步点等监控系统：可以对各种数据库、应用服务器、服务器的主要性能计数器进行监控
5 压力结果分析工具Analysis
2014.6 Eileen
辅助进行测试结果的分析
4.2 性能测试脚本录制时的协议类型
取决于应用和客户端的通信协议，而不是根据开发语言等选取协议
4.3 性能测试工具的选择与评估
1 罗列需要的工具功能列表
是否支持被测系统运行的平台软硬件数据库环境
是否支持被测系统使用的协议
是否支持特殊要求，例如防火墙等
是否提供对我们关心的服务器、应用服务器或是数据库类型计数器的监控
工具使用的脚本语言功能是否完善
2 工具比较
3 成本分析
价格和License方式
第5章性能测试的组织
5.1 性能测试团队的人员构成
1 项目测试经理
确定测试目标
制定测试计划
监控计划执行
处理项目干系人的交互
发现和处理测试中的风险
2 测试设计
根据用户需求和软件需求，从业务的角度分析和整理典型场景，
识别出性能需求
制定合理可行的测试方案和用例
3 测试开发
实现测试方案和用例，测试脚本的编写和维护
确定测试过程中需要监控的性能指标
4 测试执行
按照测试方案和用例，使用测试工具执行脚本
监控相关的性能指标，记录测试结果
5 测试分析
查看测试结果，对照测试目标分析测试数据和测试过程中获取的性能指标
得出测试结论
6 支持角色
系统支持网络支持数据库支持
5.2 性能测试的过程模型
性能测试过程通用模型PTGM Performance Test General Model (基于自动化测试生命周期方法ATLM和TMap模型)
1 测试前期准备
验证系统基础功能，确保当前应用系统具备性能测试的条件
2014.6 Eileen
组建测试团队，根据项目情况，确定人员所需技能 （测试设计、开发、执行、分
析等。

但大部分情况是一个人完成，脚本可能是开发人员提供）
2 测试工具引入
工具选择
功能符合度
工具应用技能培训
测试工作相关人员 确定工具应用过程
确定测试工具在测试中的具体应用范围工具使用过程中的问题解决方法测试工具的脚本如何管理
3 测试计划
性能测试领域分析
不同的性能测试应用领域，性能测试的目标定义会有区别
用户活动剖析与业务建模
目的：寻找用户的关键性能关注点，确定最贴近用户要求的性能目标
用户活动剖析
方法：系统日志分析和用户调查分析业务建模
是对业务系统的行为及其实现方式和方法的建模，一般采用流程图的方式描绘出各进程之间的交互关系和数据流向
确定性能目标
性能测试目标根据性能测试需求和用户活动分析结果和业务建模来确定
制定测试时间计划
4 测试设计与开发
测试环境设计
性能测试的结果与测试环境之间的关联性非常大，必须先确定测试的环境。

测试
环境设计包括系统的软硬件环境、数据环境设计、环境的维护方法。

能力验证领域：明确是在特定的部署环境下进行
规划能力领域：测试环境不特定，但也需要设计基准环境
性能调优领域：调优过程是一个反复的过程，在调优过程中必须保证每
次测试时的环境保持不变
测试场景设计
测试场景模拟的一般是实际业务运行的剖面，其包括业务、业务比例、测试指标
的目标以及需要在测试过程中进行监控的性能计数器。

剖面：对性能测试而言，剖面表示的是某个时刻用户使用该应用的典型模式，一
般由“用户执行的操作”、“执行不同操作的用户比例”以及“用户使用系统的频
率”进行描述。

测试用例设计
把针对每个测试场景规划出相应的工具部署、应用部署、测试方法和步骤，这个
过程就是测试用例设计活动。

测试用例是对测试场景的进一步细化。

细化内容包括场景中涉及业务的操作序列
描述、场景需要的环境部署等内容。

业务描述中一定会给出判断业务是否执行成功的准则。

测试脚本和辅助工具开发
测试脚本的开发通常基于“录制”，依靠工具提供的录制功能，可以将需要性能测
试关注的业务在工具的录制下操作一遍，然后基于该录制后的脚本，对齐进行修
改和调试，确保其可以在性能测试中顺利使用。

最常用的脚本修改和调试技巧是参数化、关联、日志输出。

5 测试执行和管理
建立测试环境
软硬件系统环境搭建
数据库环境搭建
应用系统的部署
系统设置参数的调整
数据环境
（使用检查列表Checklist，检查环境的可用性）
部署测试脚本和测试场景
通过测试工具部署测试脚本和测试场景。

部署完成后，需要一个确认步骤，保证场景部署与设计一致。

保证需要监控的计
数器都已经部署好相应的监控手段。

执行测试和记录结果
测试执行非常简单，一般只需要使用菜单或是按钮就可以完成。

记录结果也可以依靠测试工具完成，通过测试工具中的监控模块，可以获取并记
录需要关注的性能计数器的值。

如果测试工具不提供，可以用脚本调用操作系统提供的工具，在脚本实现中讲各性能计数器值分析出来并按照一定格式记录在本地文件中。

6 测试分析
测试分析过程用于对测试结果进行分析，根据测试的目的和目标给出测试结论。

性能测试的分析需要借助各种图表，一般的性能测试工具提供了报表模块来生成不同的图表，报表模块同时还允许用户通过叠加、关联等方式处理和生成新的图表。

如果是自己编写的脚本获取性能计数器的值，则可以通过Excel生成图表。

性能分析的通用方法之一：
“拐点分析”方法是一种利用性能计数器曲线图上的拐点进行性能分析的方法。

基本思想是基于这个事实：性能产生瓶颈是由于某个资源的使用达到了极限，此时的表现是随着压力增大系统性能表现急剧下降，因此只要关注性能表现上的“拐点”，获取拐点附近的资源使用情况，就能够定位系统性能瓶颈。

但只能定位到资源上的制约，无法直接定位引起制约的原因。

第2章性能测试的应用领域
2.1 性能测试的方法
1性能测试Performance Testing
通过模拟生成运行的业务压力量和使用场景组合，测试系统的性能是否满足生成性能要求。

一个典型的场景包括操作序列、并发用户数量条件。

且要有确定的性能目标。

性能目标的描述基本上是：要求系统在100个并发用户的条件下进行某业务操作，响应时间不超过5秒。

2负载测试Load Testing
通过在被测系统上不断增加压力，直到性能指标超过预定指标或某种资源使用已经达到饱和状态。

这种性能测试方法主要目的是找到系统处理能力的极限。

这个极限一般会描述成：在给定条件下最多允许120个并发用户访问；在给定条件下最多能够在1小时内处理2100
笔业务。

预期的性能指标一般会定义为：响应时间不超过10秒、服务器平均CPU利用率
低于65%。

负载测试一般用来了解系统的性能容量，或是配合性能调优来使用。

（系统在保证一定响应时间的情况下能够允许多少并发用户的访问）
3压力测试Stress Testing
通过增加访问压力（例如增加并发用户数量）使应用系统的资源使用保持在一定的水平。

主要目的是检验此时应用表现，重点在于有无出错信息产生，系统对应用的响应时间。

4配置测试Configuration Testing
了解各种不同环境对系统性能影响的程度，从而找到系统各项资源的最优分配原则。

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

是否经常出现长事务（Long Transaction）
线程进程问题是否出现线程进程同步失败
是否出现资源争用导致的死锁
其他问题
是否没有正确处理异常（例如超时）导致系统死锁
6可靠性测试Reliability Testing
通过给系统加载一定的业务压力的情况下，让应用持续运行一段时间，测试系统在这种条件下是否能够稳定运行。

对于一般的非关键性大型应用来讲，让系统处于可能的峰值压力下，进行2-3天的稳定性测试基本上足够。

测试过程中需要关注系统的运行状况。

关注系统内存使用状况，系统的其他资源使用有无明显的变化，以及系统响应时间有无明显变化。

如果随着时间推移，响应时间有明显变化，或是系统资源使用率有明显波动，都可能是系统不稳定的征兆，需重点关注。

7失效恢复测试Failover Testing
这种方法是针对有冗余备份和负载均衡的系统设计的。

用来验证如果系统局部发生故障，用户是否能够继续使用系统；以及如果这种情况发生，用户将受到多大程度的影响。

2.2 性能测试应用领域分析
1 能力验证
关注的是，在给定条件下，系统能否具有预期的能力表现。

一般采用的测试方法包括性能测试可靠性测试压力测试失效恢复测试
2 能力规划
关注的是，在某种可能发生的条件下，系统具有如何的性能能力。

一般会描述为：某系统能否支持未来一段时间内的用户增长，或是，应该如何调整系统配置，使系统能够满足增长的用户数的需要。

一般采用的测试方法包括负载测试配置测试压力测试
3 性能调优
性能调优的标准过程
确定基准环境、基准负载、基准性能指标
调整系统运行环境和实现方法，执行测试
记录测试结果，进行分析
性能调优主要测试方法是配置测试负载测试压力测试失效恢复测试
4 缺陷发现
主要目的是发现系统中存在的缺陷，并没有可以参照的性能指标或是需要达到的性能目标。

一般采用的测试方法：并发测试压力测试
第3章性能计数器及性能分析方法
性能计数器通常被用来衡量被测系统当前的状况和进行性能测试结果分析。

可以在操作系统级别、应用服务器级别和数据库级别上查看和记录性能计数器的数值，在性能测试分析结果对这些数据进行分析。

3.1 操作系统计数器及分析
后续完善。

2 UNIX操作系统的主要计数器
3 内存分析方法
4 处理器分析方法
5 磁盘I/O分析方法
6 进程分析方法
7 网络分析方法
3.2 应用服务器计数器
1 IIS应用服务器计数器
除此之外，还有如下几个需关注的
Active Server Page计数器
重点关注：超时的请求数、脚本运行时期的错误、队列中的请求数、请求等待时间、请求总数、失败的请求总数、送出的总字节数。

其中，队列中的请求数和请求等待时间直接反映应用服务器的处理能力。

如果队列中的请求数数值处于一个比较高的水平，同时请求等待时间是一个比较大的值，则应用服务器本身是瓶颈。

Web Service计数器
重点关注：Bytes Total/Sec:显示Web服务器发送和接收的总字节数。

数值低表明该IIS正在以较低的速度进行数据传输。

Connection Refused:数值越低越好。

数值高表明网络适配器或处理器存在瓶颈。

Not Found Errors：显示由于被请求文件无法找到而无法由服务器满足的请求数（HTTP状态代码404）
2 J2EE应用服务器计数器
常用的包括WebLogic WebSphere Tomcat等。

主要三类：JVM 、JDBC Connection Pool 、Execute Queue
3.3 数据库计数器
数据库服务器常用计数器
第1章软件性能测试基本概念
1.1 什么是软件性能
性能是一种指标，表明软件系统或构件对于其及时性要求的符合度；其次，性能是软件产品的一种特性，可以用时间来度量。

性能的及时性用响应时间或者吞吐量来衡量。

对于软件性能的关注是多个层面的。

1 用户视角的软件性能
从用户角度来说，软件性能就是软件对用户操作的响应时间。

2 管理员视角的软件性能
从管理员角度来看，首先软件性能表现在系统的响应时间，同时还更关注和系统状态
2014.6 Eileen
从开发角度，最想知道的是如何通过调整设计和代码实现，或者如何通过调整系统设置等方法提高软件的性能表现；和如何发现和解决软件设计和开发过程中产品的由于多用户访问引起的缺陷；使性能表现不佳的因素，即“性能瓶颈”。

1.2 软件性能的几个主要术语
1 响应时间
呈现时间+系统响应时间
呈现时间是指数据在客户端收到响应数据后呈现页面所消耗的时间。

系统响应时间是指应用系统从请求发出开始到客户端接收到数据所消耗的时间。

合理的响应时间取决于实际的用户需求。

2 并发用户数
并发用户数决定与具体的业务场景，一般会先对业务分解，分析出其中典型业务场景，然后基于场景采用某些方法获取其并发用户数。

（业务并发用户数）
3 吞吐量
吞吐量是指单位时间内系统处理的客户请求的数量。

4 性能计数器
性能计数器Counter是描述服务器或操作系统性能的一些数据指标。

5 思考时间
思考时间Think Time，从业务角度来说，这个时间指的是用户在进行操作时，每个请
2014.6 Eileen
求之间的间隔时间。

对于交互式应用，一般模式是，用户在发出一个请求后，等待一段时间，再发出下一个请求。

在脚本中，思考时间提醒为脚本中两个请求语句之间的间隔时间。

如何计算思考时间：步骤如下：
首先计算出系统的并发用户数；
统计出系统平均的吞吐量；
统计出平均每个用户发出的请求数量；
根据公式6计算出思考时间。

1.3 软件性能测试方法论
1 SEI负载测试计划过程SEI Load testing planning process
其目标是产生：清晰、易理解、可验证的负载测试计划
SEI负载此时计划过程包括6个关注的区域：目标、用户、用例、生产环境、测试环境、测试场景。

缺点：只给出了负载测试需要关注的重点区域，但没有形成实际可以操作的过程。

2 RBI方法Rapid Bottleneck Identify
用于快速识别系统性能瓶颈的方法。

该方法基于以下事实：
发现的80%的系统的性能瓶颈都是由吞吐量制约；
并发用户数和吞吐量之间存在一定的关联；
采用吞吐量测试可以更快速定位问题。

3 性能下降曲线分析法
实际上描述的是性能随用户数增长而出现下降趋势的曲线。

这里的性能可以是响应时间，也可以是吞吐量或单击数/秒的数据。

主要关注：系统性能最优秀的区间、系统性能开始变坏的区间、系统性能急剧下降的拐点。

从而找到性能瓶颈的原因，和为性能调优提供依据。

4 LoadRunner的性能测试过程
LR将性能测试过程分为6个步骤。

计划测试阶段：收集测试需求、确定典型场景；
测试设计阶段：设计测试用例；
创建VU脚本阶段：根据设计的用例创建脚本；
创建测试场景阶段：设计和设置测试场景，包括设定监控指标；
运行测试场景阶段：执行已经创建的测试场景，收集相应数据；
分析结果阶段：结果分析和报告工作。

缺点：整个过程都紧密与LR工具集成，没有兼顾使用其他工具，没有普适性。

5 Segue提供的性能测试过程
Silk Performer提供的性能测试过程从确定性能基线开始，通过单用户对应用的访问获
2014.6 Eileen
取性能取值的基线，然后设定可接受的性能目标（响应时间），用不同的并发用户数等重复进行测试。

适合性能调优和性能优化。

缺点：过于和LR一样，过于依赖工具本身，同时缺乏对计划、设计阶段的明确划分。

6 PTGM模型
性能测试过程通用模型PTGM
测试前期准备
测试工具引入
测试计划
测试设计与开发
测试执行和管理
测试分析。