系统性能测试中的几大步骤 1.明确测试目标；了解性能测试需求； 2.编写性能测试计划； 3.分析性能测试需求； 4.编写性能测试方案，设计测试场景； 5.相关资源准备(人力资源，硬件资源，软件资源)； 6.测试程序开发；脚本维护，测试数据准备，测试监控准备； 7.执行性能测试并收集测试结果； 8.分析结果； 9.系统调优及再测试；

 

1.明确测试目标；了解性能测试需求；     性能测试启动阶段要确定测试的负责人和组织结构.明确测试的总体目标和范围,确认资源情况.获取

性能测试需求；业务列表,性能指标,测试环境,数据量等详细需求.为策划做准备； 　性能调优是无止境的，所以在测试之前一确定一个明确性能调优目标，这也是后面评估"性能验证"

的一个基准，也是测试终止的一个基准； 在这个阶段要明确以下信息： .确定本次测试对象的相关背景； .总体目标和范围：1)客户需求和期望；2)实际业务需求；3)系统需求； .系统构架：以前测试的历史记录；系统目前的情况；与之相关的非性能需求； 　　以上提到的这些内容在初期只是从整体上做一个了解，具体的需求内容，将在测试需求分析章节

讲到．

 

2.编写性能测试计划；    

性能测试计划中包含测试目的和测试目标相关信息,还确定了实施和执行测试时使用的策略,方法;同时确定了测试工具,所需资源.日程表等;

性能测试计划关键点: .阶段任务描述(阶段,子阶段划分清晰;阶段关联关系明确;里程碑定义准确) .时间安排(满足项目预期周期要求,具有弹性) .文档定义(各阶段输入输出文档定义清晰) .所需资源(人力资源,资金资源等符合项目要求)

 

3.分析性能测试需求；

1)需求获取     需求的获取非常复杂,而且要求测试人员具有挖掘可能造成系统瓶颈因素的洞察力和敏锐,这个过程

在测试整体过程中是非常关键的一环.要获取的需求在后面几节中将会讲到.

2)需求分类     性能测试需求分析主要目的是要找出可能造成系统瓶颈的因素,为后面测试场景设计提供依据.影响

系统性能有很多种种原因,在此应关注如下几个关键点:

a.环境配置性能需求     应用配置需求:例如应用整体框架,涉及到哪些第三方的组件,应用层与数据库层的接口,使用了什么

数据库等;     系统配置需求:例如用户客户端配置,客户端与服务器端的网络配置,应用服务器或数据库服务器操作

系统等等;

b.服务器性能指标要求:     预期的在上线系统中服务器资源使用情况,吞吐量,软件运行情况等等;

c.系统设计需求:     系统架构,系统的技术实现,与其它系统接口关系及其技术实现,本系统测试数据及其与相关系统测试

数据关系等等;

d.工作负载需求:     用户使用情况需求:例如用户分布情况;哪些模块用户比较频繁;在用户操作的数据有哪些特点等等;

这些需求需要具体定位到系统的哪些功能模块,功能点;

e.客户端性能指标要求:     请求响应时间分布;请求的准确率等等;

根据性能需求的提出,需求又可以分为: .

用户提出的性能需求:例如业务量大,使用频繁的功能; .开发提出的性能需求:例如系统处理相对较复杂的位置; .系统本身的理想化性能展现:例如理想化的系统性能状况;

3)测试环境需求     环境需求主要包括:服务器环境配置要求,客户端机器配置要求,网络环境等等硬件因素,还包括一些

软件因素:如服务器使用的数据库,中间件类型和版本,客户端的类型版本,网络传输协议版本等等,这些

因素都会对系统产生不同程度的影响.

4)工作负载需求 根据测试项目类型的不同,要求的测试指标也不一样.最能反映系统性能情况的是:点击数,处理量,响

应时间,硬件的使用情况.测试指标包括如:并发用户数,事务,事务响应时间,每秒点击数,连接数,每秒

增加连接数.系统吞吐量等等.

4.编写性能测试方案，设计测试场景；     测试内容一般包括并发性能测试,疲劳强度测试,大数据量测试以及系统资源监控等,性能调优测试时

主要是做并发性能测试以及系统资源监控这些方面的工作.从对系统产生并发性能测试过程中监控系统

中各种资源的变化,来判断导致性能瓶颈的原因.

1)注意事项     测试案例主要是根据测试需求分析的结果制定出在测试执行时系统的执行方法,在测试案例设计时应

注意如下几点:     .明确测试目的,测试范围;明确项目功能需求以及负载分布情况.     .分析测试环境中可能出现瓶颈的位置,重点测试;     .综合业务场景中:稳中有操作的并发量,所占有百分比,准备完成请求数量,频率等等典型行为是明确

的;虚拟用户的操作步骤要尽量类似于真实用户的操作;操作的数据要类同于真实用户实际使用数据;在

案例设计时要充分考虑到需求中用户对模块的使用频率.使得在模拟时每个模块使用情况尽量地类似于

真实环境;    .明确的通过指标;为每个典型业务制定测试通过的指标;    .有效的测试工具;需要产生负载的应用可以在合理的时间内达到你期望的负载,然后再缓慢增加;   . 详细的结果记录:对于每个请求的响应时间,开始时间,结束时间,响应时间细分,传输数据量,请求内

容等等做详细的记录,以方便性能测试进行分析;   . 资源利用率的监测:有效的资源监控方式,使能获得所有需在的资源数据;    .软硬伯环境一致性;    .数据库或文件系统中测试数据与正式环境数据的数量和内容的一致性;

2)测试场景      性能测试在软件测试中占有重要的地位,性能测试包含的内容是很多的.例如针对一个网站进行性能

测试,常规性能测试,压力,负载测试,大数据量测试,强度测试等等都应该包含在内的.     测试方案中可能把测试按照类型划分,每个类型下又设计N个场景.通常测试中会使用的一些场景: 预期性能指标测试:通常系统在设计前都会提出一些性能指标,这些指标是性能测试要完成的首要工作

之一.针对每个指标都要编写多个测试用例来验证是否达到要求. 单一功能加压测试:这类场景主要为了验证某一特定功能的性能状况,或者检测该功能是否存在隐藏的

性能问题. 复杂场景测试:根据业务数据分析,设计与真实情况类似的场景,测试系统整体性能.一般,预期性能指标

验证.整个系统性能评定.整个系统的性能调优测试都采用这种场景;

5.相关资源准备(人力资源，硬件资源，软件资源)；

测试环境准备及配置:     包括被测应用和应用环境的申请,部署,压力发生环境准备,监控系统准备和网络环境申请和部署,提

供符合需求可使用的测试环境;     包括被测应用系统,压力发生系统.监控系统,网络系统的配置等等.

测试场景准备:     根据业务模型确定测试场景;

    测试脚本开发.数据准备,参数化数据,脚本预验证;     测试脚本的开发;     基础数据的获得,数据量评估和基础数据设计;     设置测试程序中需参数化的字段,使所有参数化数据可以正确执行场景.保证参数化的测试脚本与基

础数据结合能够在测试执行环境下正确运行;     验证最终可是脚本可以在测试环境正确执行,并且自身无性能问题.   监控系统与数据分析系统准备:     设计合理的监控方案,并设计相应的监控工具实施监控;     对监控数据和结果数据进行分析的脚本或者程序;

 

测试环境准备      测试环境:配置测试环境是测试实施的一个重要阶段,测试环境的适合与否会严重影响测试结果的真实

性和正确性.测试环境包括硬件环境和软件环境,硬件环境指测试必需的服务器,客户端.网络连接设备

以及打印/扫描仪等辅助硬件设备所构成的环境;软件环境指被测试软件运行时的操作系统,数据库及其

他应用软件构成的环境;       一个充分准备好的测试环境有四具优点:一个稳定,可重复的测试环境,能够保证测试结果的正确;保

证达到执行的技术需求;保证得到正确的,可重复的以及晚理解的测试结果;与真实环境的一致或尽量保

持一致.      性能测试环境,要求和真实环境一致或存在可比性.

6.测试程序开发；脚本维护，测试数据准备，测试监控准备；

测试程序开发       性能测试场景设计和性能测试脚本设计中需在注意以下几个问题: 场景真实性:       每个脚本的具体操作步骤,是和真实环境操作类似的,每个场景内的测试程序之间的逻辑关系,压力比

重也是与真实环境类似的.在测试方案设计中已经将这些真实环境的信息量化到可用程序模拟程度.     场景中各个脚本所占的比例主要是通过线程组来控制的,即可以控制多少个线程在某一阶段运行哪一

个或几个脚本;     具体操作步骤需要注意两个相邻的操作动作之间的习惯性时间间隔,某些特定操作的集合在特定时间

同时发起请求等等;

    确定某个操作步骤中需要将输入数据进行参数化,参数化数据尽量选择读文件的方式,在数据库中读

取会严重影响速度.如果数据量不大,可以在并发程序开始执行前先将数据读到内存;     值得注意的是,不是所有的数据都可以通过读取预先定制的文件来获得.而是在程序执行过程中,在返

回结果中获取这个数据信息,然后运用到下一操作中.测试界把它称作"关联"常用测试工具都提供关联功能,自己编写程序时也可以指导它作为单独的程序模块来编写,方便在后续的项目中利用.

事务:     一个复杂的操作应该是有很多个事务组合而成的.使用事务可以更方便灵活的进行数据统计.

检查点:     检查点的作用是验证操作结果是否正确.它可以写在程序中,可以通过操作返回结果来判断.具体实

现的方式不固定的.只要能够方便的检查,我们运行的并发请求是否都是有效的.但是检查点不宜设置过

多,因为在检查时会有系统消耗,影响并发性;

保存登录信息     很多系统性能测试场景是需要在用户登录状态下操作的.那么保存登录用户信息也很重要,需

要我们注意;

 

测试数据准备 性能测试中用到的数据有两类: 1)测试环境中系统应该具备的初始数据以及和正式环境同等数据量(或加权值)的有效数据,或者在系统

生命周期内预期能达到的最大数据量的数据,尽量保证其真实性. 2)运行测试脚本需用到的数据,参数化数据.     在测试需求调研过程中也要明确数据量要求,数据准备一定要关注数据的质量和数量,不要出现一些

不符合业务逻辑的废数据,并且数据量要满足测试运行的需要.否则会导致测试执行结果出现大的偏差.

数据的部署也应该尽量保证真实性.     如果是配置测试或者测试数据对测试结果影响很大的场景,要保证测试过程基准一致,否则测试结果

将没有可比性.所以,测试数据创建完成后,要及时备份,以便多个场景中重复使用这些数据,可以创建一

个测试库来管理测试数据.

 

测试监控准备   根据测试的目的不同,测试监控的对象不同,测试的主要指标也不相同.   测试指标一般分为两大类:业务处理指标,系统资源指标.其中,业务处理性能指标主要包括:业务结果

的正确性.每分钟处理请求数,事务响应时间(Min,Max,Avg,90%响应时间范围,响应时间变化,分布等

等),并发用户数,系统吞量等等,系统资源指标主要是指CPU,内存,硬盘,网络等系统资源使用及变化情

况.

 

测试执行     在性能测试启动之前,需要就被系统是否符合准入标准,和实施性能测试的可行性和必要性进行分析.

考察破坏性测试系统是否具备性能测试的条件.      测试执行过程中,要特别注意测试脚本和场景的运行是有效的.在测试程序开发过程中,我们加入了

检查点就是为了保证程序正确的执行,产生我们所需要的负载.但是,在测试程序长期执行过程中,我们

还需要经常检查测试是否正确执行.否则,得出的测试结果可能是错误的,无意义的.     测试执行与监控的主要目的是根据设计方案去验证系统是否存在瓶颈,给测试分析提供各种分析数据

.此过程会与测试分析过程不断进行重复执行,直至真正确定出系统瓶颈所在.

测试执行关键点     执行测试的过程中,有一些需要重点关注的事件:     在测试执行前,需要确认:用例和场景确认;测试环境确认;测试数据确认;测试脚本确认;测试 工具和

监控工具确认;     执行过程中注意:执行每个场景时都需要做执行记录,结果搜集等工作.     执行完成后注意:数据恢复.环境清理,结果整理.

测试记录     测试过程中要记录如下信息:运行前的系统配置,运行前的参数或者软件调整情况;运行过程中的系统

资源的使用情况;运行过程中的故障现象;请求的响应时间;单位时间内的处理请求数;请求的成功率;等

等.

 

测试分析:     测试分析的主要目的是要根据测试执行获取到的数据去判断造成系统出现瓶颈的位置,挖掘造成系统

瓶颈的真正原因.这个过程是技术含量最高的一环.     性能分析通常要围绕三个方面进行:软件,服务器,网络.     软件主要是分析具体事务执行时间,尤其并发用户部分,根据测试工具测试出的结果分析那些事务执

行的慢,然后可以分析执行较慢的代码,针对网页可以分析具体的页面元素执行情况.     服务器的分析要结合软件的运行情况进行分析,着重分析硬件的执行参数,CPU,硬盘,内存,中断,内存

等情况,分析尤其要注意对这些参数进行综合分析,往往各个参数之间会互相影响,最后在调查,分析整

体系统的基础上,找出影响服务器整体性能的瓶颈,确定相应的升级需求.     网络性能分析要结合服务器和目标软件,通常网络传输慢会有软件和服务器方面的原因,甚至有时候

会有客户端方面的原因.不过目前网络的环境普遍可以,不管是局域网还是广域网,网络的环境越来越好

.

测试分析建议     测试分析小组应该由具有以下素质的人员组成:开发,测试,应用服务器.数据库,操作系统,网络,存储

等等.     在测试分析时使用较多的一种方式是排除法,根据开始获取到的信息大概能将问题定位在某一层面上

.但具体在什么地方,就可以采取排除的方法去定位;     尽量使用一些较成熟的工具协助分析工作,这样将大大减轻工作负担.     在确定出真正的性能瓶颈时,可以做一些小的模型去做验证,确定分析的正确性.

 

瓶颈分析 1)处理器分析方法     首先查看System\%Total Processor time计数器的值.该值体现的是CPU的平均利用率,若超过90%,则

说明存在处理器方面的瓶颈.     其次查看每个CPU的Processor\%User Time计数器的值.若应用服务器的%User Time值较大,可以考虑

是否能通过算法优化等方法降低这个值.若数据服务器的%User Time值较大,可考虑对数据库系统进行

优化.     查看System\Processor Queue Length计数器的值.当该值大于CPU数量的总数+1时,说明存在处理器

方面的问题. 2)磁盘I/O分析方法     查看%Disk Time计数器的值.该值较大,则可能存在磁盘瓶颈问题.     与Processor\Privileged Time合并进行分析.若%Disk Time值较大,而Processor\Privileged Time

的值适中,则可判断存在磁盘问题,若Processor\Privileged Time较大,持续超过80%,则可能是内存泄

漏.     根据Disk sec/Transfer进行分析.该值超过60ms,则磁盘存在问题. 3)网络分析方法     查看Network Interface\Bytes Total/sec 计数器的值.用 Bytes Total/sec计数器的值和网络的带

宽进行比较,若超过 50%,则说明网络存在性能瓶颈问题. 4)软件瓶颈分析方法     分析事务响应时间,吞吐量,确定是否存在性能问题,若发现存在性能问题,则找出响应时间不符合要

求或者出现多个失败的事务,对其进行分解,然后对其进行网页细分,以确定影响性能的元素.

 

内存泄漏 对于C++或java系统,如果GC处理不合理,会引起很多内存堆栈问题.常见有: 1) Array Bounds Read (ABR) : 数组越界读; 2) Array Bounds Write(ABW): 数组越界写; 3) Beyond stack Read(BSR): 堆栈越界读; 4) Free Memory Read(FMR): 空闲内存读; 5) Invalid pointer Read(IPR): 非法指针阅读; 6) Null Pointer Read(NPR): 空指针阅读; 7)Uninitialized Memory Read(UMR): 未初始化内存读写; 8)Memory Leaka: 内存泄漏.

 

WEB 响应时间细分 响应时间: Time = DNS + Conn +Handshaking +FTPAuthentication + Send + ServerTime + Rec + Client;; ServerTime = logic +DB*n + .....;

 

吞吐量等指标变化情况   不断的增加用户数,提高压力.各性能指标变化情况;   响应时间和吞吐量会受到负载的影响.随着服务器上负载的增加,吞吐量会不断攀升,直到到达一个点

.     最初的一段时间,执行队列的长度为零,然后就开始以稳定的速度增长.     在某一点上,执行队列开始增长,因为服务器上所有的线程都已投入使用,传入的请求不再被立即处理

,而是放入队列中,当线程空闲时再处理.     当系统达到饱和点,服务器吞吐量保持稳定后,就达到了给定条件下的系统上限.但是,随着服务器负

载的继续增长,系统和响应时间也随之延长,虽然吞吐量保持稳定.     进入饱和状态后继续增加负载,服务器吞吐量保持稳定,系统的响应时间延长,最终会出现系统不可能

用,宕机等情况.

 

9.系统调优及再测试； 配置优化 缓存机制,可是设置多级缓存; 数据压缩机制,减小网络传输;(减少每个请求的大小) 大数据块分块传输; 负载平衡,用来水平放服务器的结构; 分为读写服务器和只读服务器,还要对服务器群负载平衡; 增加更多的硬件资源:CPU,内存,磁盘等; 增加网络的带宽;等等.

 

瓶颈分析工具   应用层:开发人员可以通过Profilers来发现低效率的代码,比如说较差的查找算法.   数据库层:开发人员和数据库管理员(DBA)可以通过特定的数据库Profilers及事件探查器(query optimizers)   操作系统层:系统工程师可以使用一些工具如在Unix类的操作系统中的top,vmstat,iostat,在Windows系统中的PerfMon来监控CPU,内存,swap，磁盘I/O等硬件资源;专门的内核监控软件也可以在这一层面上被使用.    网络层:网络工程师可以使用报文探测器(如tcpdump),网络协议分析器(如ethereal),还有其它的工具(如netstat,MRTG,ntop,mii-tool)