性能测试场景分析范本模板.docx
《性能测试场景分析范本模板.docx》由会员分享，可在线阅读，更多相关《性能测试场景分析范本模板.docx（41页珍藏版）》请在冰豆网上搜索。
性能测试场景分析范本模板
录制脚本
录制参数设置
脚本录制
回放和调试脚本
用这按钮进行编译，编译通过后，点击运行按钮即可运行脚本。
只有在脚本运行正确后，才能进入Controller中来创建测试场景.
脚本录制的原则
⏹充分考虑脚本的执行效率
⏹录制重要的用户业务
⏹选择你所需要的进行录制
修改脚本
参数化功能
步骤1：
步骤2:
步骤3:
参数类型有多种：
●Date/Time：
需要输入日期的地方,可以用Date/Time类型来替代。
●GroupName：
使用虚拟用户组的名称来替代参数.
●LoadGeneratorName:
使用虚拟用户所在的LoadGenerator机器名来替代参数。
●LterationNumber:
测试脚本当前循环的次数来生成参数。
●RandomNumber：
随机数.
●UniqueNumber：
唯一的数（一般使用递增的数.）
●VuserID：
使用虚拟用户的ID来替代参数，ID是由Controller来控制的。
●File：
在属性中可以指定文件或数据库中提取数据。
●UserDefindeFunction:
从用户开发的dll文件中提取数据。
这里的重点是file类型：
在我们工作中最常用的是“Unique（唯一的）”和“Eachiteration（下一条数据）"的组合。
比如我们设计一个场景，要求10个虚拟用户都需要进行10次迭代。
那编号为1的用户取前10行数据，编号为2的用户取11～20行数据。
以此类推，那完成整个场景就需要数据表里至少要有100条数据,否则在Controller运行过程中会返回一个错误.
深入集合点（就是并发点）
使用集合点可以控制各个Vuser,以便在同一时刻执行任务。
原理是，当某个Vuser到达该集合点时，Controller会将其保留，直到参与该集合点的Vuser都到达,满足了集合条件时，Controller将释放Vuser，这样就产生了密集的同一类用户操作或请求。
Vuser从集合释放后,将执行脚本中的下一个任务。
需要注意的是：
●集合点一般会创建在用户事务的开始标志前。
●集合点只能加在action部分,而不是init或end部分。
比如我们想在登录时创建一个集合点，我们可以这样安排：
巧用检查点
Loadrunner的检查点有三种：
Web_find、Web_reg_find和Web_image_check。
至于为什么要用检查点可以用个小例子做个测试，例如一个登陆脚本登陆的账号为123456，密码为123456,可以正确登陆,当把账号或密码改掉再执行，发现脚本并没有报错,也顺利执行下来了。
原因是什么呢?
Loadrunner以用户角色向服务器发送一个登陆请求，却不会判断请求的返回消息是什么，只要有返回，即使这是个拒绝登陆的返回，Loadrunner也认为登陆成功了。
所以在登录或者其他有重要页面跳转的地方，很有必要做检查点。
Web_find和Web_image_check两个函数如果在脚本里面增加，需要在设置中打开“图像和文本检查”功能,该功能默认是不打开的,如果手工在脚本里面添加检查点，系统会有提示：
Action.c（43）:
Verificationchecksnotenabled.web_findisskipped。
Seethe’Run-timesettings/Preferences/Checks’[MsgId:
MMSG-27197］
Web_reg_find是注册类型函数,它本身并不执行,不能通过它的返回值来作为事务的判断条件（因为web_reg_find（）的返回值0和1表示web_reg_find（）是否注册成功，并不代表查找的内容是否存在,也就是说无论查找的文本内容是否存在,都返回0。
它是从返回的缓冲区扫描而不是在接收的页面中查找。
这是比web_find更高效的一个函数。
关联
所谓的关联（correlation）就是把脚本中某些写死的（hard-coded）资料，转变成是摘取自服务器所送的、动态的、每次都不一样的资料.
关于检查点和关联的内容，可以参见我们的案例“01checkproperties”.
另外，我们可以在
中配置脚本运行时的设置。
运行逻辑：
我们可以设置ACTION的迭代次数。
思考时间：
我们一般忽略思考时间，以得到更大的压力。
其他：
我们可以选择错误的处理方式，还可以选择线程方式运行脚本以得到更大的压力,最后的选项一般默认就行了。
速度模拟：
默认使用最大带宽,我们也可以模拟一些特殊的接入方式.
首选项：
需要特别注意的是，如果脚本中使用了文本检查点或图片检查点的时候，此项一定要勾选中
，默认是没有勾选的。
（如果是使用web_reg_find,则不要求勾选.）
其他的项我们一般都使用默认值即可.
创建测试场景
场景类型
我们在VuGen中完成虚拟用户脚本的调试后，就进入Controller中进行用例场景的设计与执行。
在Controller中，提供了两种类型的测试场景：
手动测试场景和面向目标的测试场景。
在场景运行后,Controller会在不同的负载生成器上（根据用户的设定进行分析：
手动场景）或（自动分析:
面向目标场景），生成一定数量的虚拟用户.通过这些虚拟用户的并发执行以及及时间的运行，来模拟真实情况下服务器承受的压力。
在场景运行的过程中，Controller可以提供对服务器资源、虚拟用户执行情况、事务响应时间等方面的监控,帮助测试人员实时的分析系统，并在运行完成后给出结果数据以便进行下一步的分析.
手动场景
在Controller中,新建场景时，我们选择上面的手动场景,也可以再选择使用百分比,不过不重要，我们可以在后面的
这个菜单对其更改。
手动场景是以用户定义虚拟用户数量来进行测试的。
面向目标场景
在面向目标的测试场景中，可以定义希望达到的目标.比如最大虚拟用户数量或每秒事务数等。
Controller将根据定义的目标自动构建测试场景，并评估能否达到测试目标.
在这个下拉菜单中，我们可以定义虚拟用户数、每秒点击数、每秒事务数、每分钟页面数和事务响应时间5种类型的目标。
在这个图的下半部分，可以看到有两个标签页面：
“场景设置”和“加载行为”。
这两个标签页用来设置一些场景的参数,主要用在负载和压力测试的设定。
测试场景设计
配置测试脚本
在虚拟用户脚本加载后的界面上,选中需要配置的脚本后,点击右侧的
可以查看和修改脚本.需要注意的是:
修改后就好重新载入,不然会使用修改前的脚本。
虚拟用户数目和每组用户所在的负载生成器可以直接在此界面中输入。
配置Generator（负载生成器）
使用Generator可以使用多台安装了负载生成器的主机产生压力.
点击：
==》
点击:
==》
配置Schedule（计划生成器）
点击：
，可以配置计划生成器
计划是场景配置的重要组成部分，主要用于配置用户的行为方式。
这里有两种类型:
按场景计划和按用户计划。
●按场景计划（SchedulebyScenario）
按场景计划有三个选项卡:
加压、持续时间、减压。
加压中，第一个是同时加载所有用户,第二个是每隔一段时间加载一定的虚拟用户.
持续时间中，第一个是照脚本的设置进行，直到运行完成.这种方式主要用在检测特定功能的实现上，比如在并发时，程序会不会出现一些功能缺陷。
第二个是按照指定的时间运行。
如果选择此项,迭代次数的设置会被忽略，每个虚拟用户都不断的进行迭代，直到指定时间为止.这种方式主要用在指定时间的性能测试。
第三个是一直运行，直到人工干预为止。
这种方式主要用来测试系统的极限。
减压中（必须选中持续时间选项卡中的第二项（按照时间运行），才能操作减压选项卡），指定场景如何结束。
这里对于加压，也是两种减压方式。
●按用户计划（SchedulebyGroup）
按用户计划有四个选项卡，后面三个和场景计划中是一样的。
注意在图左边的窗口中，有用户组的选择，可以对每个组进行独立的开始时间、加压减压和持续时间。
特别是一组用户需要使用另一组用户的操作结果时，就必须使用按用户计划方式配置场景了。
我们重点讲解一下开始时间选项卡.
场景开始时运行。
场景开始后一段时间再开始，这里可以指定具体时间。
在某些特定的用户组运行结束后再开始。
需要注意的是：
也是一个选项。
里面的第二和第三项一般是在运行时间很长，需要放到下班后执行时，我们可以选中它们.
配置集合点
我们之前讲过集合点，这里会具体配置集合点，以现实一定数量的并发,主要用来测试系统某个功能点的并发负载性能.
上面表示在03_checkproperties脚本中包含了一个集合点:
maipiao.通过策略按钮我们可以配置它。
这里有三种方式:
●当Vu中全部指定百分比的虚拟用户到达集合点时释放。
●当一定比例处于运行状态的虚拟用户到达集合点时释放。
●当一定数量的虚拟用户到达集合点时释放。
最后一项是超时配置,如果在设定时间内都没有新虚拟用户到达集体点，Controller就会自动释放到达集合点的用户。
配置IPSpoofer
现在一些服务器会对同一IP访问进行限制，这时我们可以通过“IPSpoofer（IP欺骗）”进行配置，以达到我们的测试目的.
我们只需要选择开始菜单中的“IPWizard”，进入配置界面.
第二步需要选择网卡。
之后再在Controller中的菜单里，启用IP欺骗器就可以了。
注意的是:
必须在连接到负载生成器之前选择该选项。
再在工具菜单内选中专家模式，进入选项中的常规，就可以根据需要来配置了.
测试果设置
为了更好的管理我们越来越多的测试结果，可以在菜单中的设置结果目录，对其进行管理。
通用参数设置
在菜单的选项中，值得注意的是“超时”选项卡，其他选项一般不用修改。
在超时选项卡中，可以对负载生成器的连接、断开以及每个虚拟用户的初始化、运行、暂停和停止操作的超时时间进行设置,一旦超过设定,则会给出一条错误提示。
执行测试场景
启动测试场景
在场景的［运行]界面中有多个窗口，可以观查到场景组、场景状态、多个视图及它们的统计数据。
控制用户与用户组
在场景运行过程中，可以通过
来对用户和用户组进行管理，包括添加、删除用户和用户组、控制虚拟用户运行状态等。
界面如下:
查看场景与用户状态
通过场景状态区域的数据,我们可以监控场景与用户状态.在测试过程中就可以直接点击链接进行观看。
控制集合点
在场景的运行中,我们也可以像前面配置集合点一样的查看和控制集合点的状态，即可以停止集合点和用户，也可以释放或重置集合点.
查看运行数据图
在Controller中，我们可以添加多种数据图进行查看。
在右边的小窗口中，我们可以添加多种数据视图。
监控系统资源
在性能测试中，最重要的一项就是监控系统资源。
需要监控这几个方面：
操作系统、数据库、中间件服务器等，其中，操作系统的性能表现关系着整个应该系统的性能，属于基础的系统资源数据。
需要注意的是：
监控系统是一项消耗资源的操作，所以,测试过程一定要考虑具体监控什么，以免影响测试结果的准确性。
在监控系统之前,我们还需要做一些准备工作：
●打上监控主机上的“NetworkDDE”,“RemoteProcedureCall（RPC）”，“RemoteRegistry”，“NetLogon”等服务.
●以系统管理员身份从Controller登录待监控主机.
●在监控图中可以添加计算机,输入IP地址后，点击OK就行了.
●在添架计算机的下面，我们再加入需要监控的计数器.
●如果看到数据就是正常，否则检查服务和防火墙有无问题。
Windows监控的主要参数有：
CPU占用率、可用内存容量、服务线程占用的CPU资源等。
下面列出一些我们常用的计数器。
System
（系统）
％TotalProcessorTime
（CPU占用率）
系统上所有处理器非空闲线程的平均时间比。
它反映了用于作业上的时间比率。
如果该值的数值持续超过90%，则说明整个系统面临这处理器方面的瓶颈，需要增加处理器来提高性能。
System
（系统）
FileDataOperations/sec
（文件读写操作）
当前系统中磁盘文件读写的频繁程度。
通过观察该计数器跟其他性能指标的变化趋势，通常能够判断磁盘文件操作是否是性能瓶颈。
类似的计数器还有NetworkInterface\Bytestotal/sec
System
（系统）
ProcessorQueueLength
（处理队列长度）
线程单元中处理器队列的即时长度。
此值为即时值,一般不超过2，否则表示处理器堵塞.
System
（系统）
TotalInterrupts/sec
（中断频繁度）
所有处理器花费在处理中断上的时间的总和。
表示周边硬件设备的繁忙程度。
Processor
（处理器）
％ProcessorTime
（CPU占用率）
提供了一个用100%减去CPU什么也不做的时间的衡量标准，系统可以更容易地衡量空闲线程运行的频率
Processor
（处理器）
％UserTime
（用户操作时间）
处理线程用于执行使用用户模式的代码的时间的百分比.用户模式是为应用程序、环境分系统和整数分系统设计的有限处理模式。
Memory
（内存）
AvailableMbytes
（可用内存）
用于描述系统可用内存的直接指标，在对系统进行操作系统级别的内存分析时，首先应通过该值建立一个初步的印象,了解性能系统测试过程中，系统是否仍然有足够的内存可用。
如果该指标的数据比较小,系统可能出现了内存方面的问题，此时需要进一步分析。
Memory
（内存）
PageFaults/sec
（每秒错误页面）
每秒发生页面失效的次数,页面失效次数越多，说明操作系统向内存中读取的次数越多。
此时还需要查看PagesRead/sec计数器,该计数器阀值为5，如果超过5，则可以判定存在内存方面的问题.
Memory
（内存）
PoolNonpagedByted
（非分页池字节数）
指在非分页池中的字节数，非分页池是指系统内存（操作系统使用的物理内存）中可供对象（指那些在不处于使用时不可以写入磁盘上而且只要分派过就必须保留在物理内存中的对象）使用的一个区域。
Memory
（内存）
Pages/sec
（页数/秒）
为解析内存对页面的引用而从硬盘读取的页数或定稿磁盘的页数.如果担心内存压力过大，这里需要考虑。
性能测试结果分析
如何分析测试结果
在Controller中的执行的测试场景结束后，首先要判断采集的结果数据是否真实有效。
多数场景都需要迭代执行，因此很多测试结果本身就不能反映真实问题，那我们一般按照以下几个步骤进行判断结果的有效性：
1.测试环境是否正常：
如果在测试场景的过程中出现过异常，则结果往往不准确，无须进行分析。
如CPU100%、网络断开……。
2.测试场景设置是否正常、合理:
测试场景的设置不合理会测试出现异常，这时需要对场景设置进行分析修正。
如同时在一台PC上加载全部Vu，太多的Vu可能会造成客户端不能正常初始化，而造成很多Vu不能初始化而失败，这样的失败和我们要测试的服务器根本没有关系。
这时我们可以改为逐步加压.
3.测试结果是否直接暴露出系统的一些问题：
性能测试的目的是分析出系统在压力下存在的问题，所以我们主要是对出现错误的结果进行分析。
测试结果直接暴露的问题有很多，如：
●一些用户事务响应时间过长
●系统支持最大的并发用户数过低
●服务器CPU利用率过高
●内存不足。
●……
测试人员针对这些结果，用Analysis对其进行深入分析,以发现在一些潜在的性能问题。
性能分析基础知识
在性能测试中，我们都遵循一个普遍的原则:
由外而内,由表及里，层层深入。
性能下降最直接的现象就是系统响应时间变长，所以我们都是以系统响应时间作为性能测试的切入点.而现在的IT系统架构复杂，任何一个环节都可能出现瓶颈,要准确的判断出瓶颈在什么地方，是一个比较头痛的问题。
我们分析问题的方法是：
任何系统都是由网络和服务器构成的，所以我们先确定问题是出现在网络还是服务器上的。
借助LR的Analysis组件,可以很容易分析。
如下图中,我们可以很容易的看出,在整个事务时间中，网络时间和服务器时间所占的多少，也可以很容易确定出问题主要现在在哪一个环节。
在实际的工作中，我们不能光发现问题，还要定位问题,并给出一个解决方案（或调优方案）.即使有了正确的测试结果，也不一定能对问题进行正确的定位.比如说我们在工作中会经常遇到CPU占用率过高，我们可能还会发现磁盘IO过于频繁，我们一般会认为是服务器内存不足。
但也可能是因为程序内部的编写不严密，资源没有释放而造成的，也可能是因为程序内部有内存泄漏。
解决工作实际问题不但要靠经验，也需要靠对系统的深入了解，所以说起码的编程能力还是很必要的.
Analysis基本功能
LR在Controller中运行场景，采集了Vu、操作系统、应用服务器等各种运行数据,当场景运行结束后，我们就可以用过LR专用的分析组件Analysis进行分析了。
当我们打开Analysis，通常是下面这样的一个界面：
在右边添加新图处，我们再进行打开新图的界面，这里还有很多的分析图
这里可以看到系统资源这些都是黑色，不是蓝色链接，说时这里没有采集到数据,我们需要在Controller中，场景运行之前开启相应的采集。
这里先简要介绍一下名类分析图的含义及用途.
●虚拟用户（Vusers）图：
虚拟用户图里分为运行的虚拟用户图、虚拟用户概要和集合点3类，主要用来查看场景与会话的虚拟用户行为。
●错误（Errors）图：
主要有错误统计、每秒错误数量两类，用来查看服务器什么时间发生错误以及错误的统计信息，可以发现服务器的处理能力。
●事务（Transactions）图：
描述和事务相关的分析图：
事务综述图、事务平均响应时间图、每秒通过事务数图、每秒通过事务总数图、事务性能摘要图、事务响应时间与负载分析图、事务响应时间百分比图、事务响应时间分布图等.通过这些分析图,我们可以分析应用系统事务的执行情况.
●Web资源（WebResources）图：
描述Web服务器的吞吐率图、点击率图、返回的HTTP状态代码图、每秒HTTP响应数图、每秒重试次数图、重试概述图、服务器连接数概要图、服务器每秒建立的连接数量图。
借助Web资源图，我们可以深入分析服务器性能。
●网页细节（WebPageBreakdown）图：
网页细分需要在Controller中启动（Controller菜单中诊断中的配置里面，激活“网页诊断”）。
在网页细分图中主要有：
页面分解总图、页面组件细分图、页面组件细分（随时间变化）图、页面下载时间细分图、页面下载时间细分（随时间变化）图、第一次缓冲时间细分图、第一次缓冲时间细分（随时间变化）图、已下载组件大小图。
借助网页细分图，我们可以分析页面元素是否影响事务响应时间。
●系统资源（SystemResources）图：
系统资源图描述在场景运行期间,由联机监控获得的系统资源使用情况。
要获得系统资源情况，必须在Controller里预先指定相关的计数器。
如何看Analysis图
我们使用Analysis分析，一般按以下几步来处理：
第一页：
首先从摘要开始。
摘要主要是判定事务的响应时间与执行情况是否合理。
如果发现问题，则需要做进一步的分析。
这里一般需要重视的是事务执行失败和响应时间过长等。
下面是查看分析摘要时的一些原则:
用户是否全部运行，最大运行并发用户数是否与场景设计的最大运行并发数一致。
如果没有，则需要打开与虚拟用户相关的分析图,进一步分析虚拟用户不能正常运行的详细原因；
事务平均响应时间、90%事务最大响应时间用户是否能接受。
如果事务响应时间过长,则要打开与事务相关的各类分析图，进行深入分析。
查看事务是否全部通过。
如果有失败的情况，则需要深入分析原因.很多时候，执行失败就说明系统有瓶颈。
如果一切正常，则本次测试没有必要进行深入分析,重新加大压力进行测试.
如果事务失败过多，则应该降低压力进行测试,使结果容易分析.
第二:
查看负载发生器和服务器的系统资源情况。
查看分析概要后，接下来要查看负载发生器和待测服务器的系统资源使用情况:
查看CPU的利用率和内存使用情况,尤其要注意查看是否存在内存泄漏问题。
这样做是由于很多时候系统出现瓶颈的最直接表现就是CPU占用率过高和内存不足.
这个测试应保存证负载发生器在整个测试过程中CPU、内存、带宽没有出现瓶颈，否则测试结果无效，如果硬件上都有瓶颈则不能表现出程序中的问题来。
第三：
查看虚拟用户与事务的详细执行情况。
在前两步确定了测试场景的执行情况基本正常后,接下要查看虚拟用户与事务执行情况.
对于虚拟用户，主要看看在整个测试过程中是否运行正常，如果有较多用户不能正常运行,则需要重新设计场影或调整init和end内容重新测试。
对于事务,主要看整个过程的事务响应时间是否逐渐变长以及是否存在不能正常执行的事务。
下面是虚拟用户与事务分析的常用准则：
●虚拟用户如有失败，则要查明原因；
●在整个测试过程中,所有的虚拟用户是否一直稳定运行并成功执行全部事务。
如果仅有一个用户或部分用户能够正常运行,则说明测试脚本可能存在问题.
●对于失败的事务首先要分析其失败原因，接着要查看事务的失败是否导致用户失败;
●判断用户是否可以接受事务平均响应时间值以及90%用户的最大响应时间值;
●查看整个测试过程的事务平均响应时间是否逐渐变长，正常情况下，事务平均响应时间的变化应该是一条接近平行于X轴的直线;
●事务响应时间是否在整个测试过程中随着用户的增加而线性变短。
正常情况应该是当一定范围内的用户并发时，事务响应时间应不会有太大变化；
●服务器每秒通过的事务总数、某一事务每秒通过数是否稳定，如果整个测试过程基本不变,则要分析是服务器达到了处理上限还是Generator产生的压力达到了上限；
●按照迭代次数来运行的场景，要分析通过的事务总数是否与设定一致，如果不一致，则可能脚本有问题,也可能是程序存在功能错误，应调整后再测。
Analysis对虚拟用户和事务提供了非常强大的跟踪功能，可以跟踪每一个用户及其相关事务的执行情况。
这些内容可以在菜单“报告”中的“crystal报告"里找到。
第一步：
查看错误发生情况。
整个测试过程的错误发生情况是分析的重点。
下面是错误发生情况的常用准则:
●查看错误发生曲线在整个测试过程中是否有规律变化，如果有，则意味程序在并发处理方面存在一定的缺陷。
如果没有规律，则可以将步调调慢一点，达到更好的测试效果，或可能是脚本有问题。
●查看错误分类统计，作为优化系统的参考。
比如“超时错误”达到90%以上，可能需要硬件上提高配置了;再比如出现较多的“内部服务器错误”，则可能是程序方面存在问题.
第二步:
查看Web资源与细分网页。
现在的系统多是Web广域网系统,所以需要很多的重视Web性能的测试。
查看Web图时，往往需要结合前而对虚拟用户以及事务响应时间的分析结果，重点分析服务器的稳定性。
对于网页细分功能则应遵循如下原则：
●分析从用户发出请求到收到第一个缓冲为止,哪些环节比较耗时；
●找出页面中哪些组成部分对用户响应时间
升级会员 