软件性能测试Ⅵ

从软件过程来看，软件性能需求应该是软件项目启动之前，需求分析人员和客户共同讨论并确定下来的，这个需求对于性能测试人员来说，应该是明确的，无二义性，是一些列可操作的性能指标

注意的是，采取何种算法，何种方法细化性能需求并不是最重要的，最重要的是软件方和客户能够达成理解一致

一份详细的软件性能需求说明是一个成功的性能测试的基础，否则可能辛辛苦苦得出的性能测试报告却被客户认为说明不了系统的性能情况，在确定需求标准的时候，有以下技巧

1、积极参与性能需求的指定和细化工作

性能测试工程师应该比需求人员和客户更明白软件系统性能为何物，怎样度量，而且性能测试工程师还是性能测试的执行者

2、抓大放小设计测试场景

大多常见的性能测试属于负载测试，是模拟真实用户的集体行为。实际上，在真实环境下，用户的集体行为并不是十分明确的，甚至是混沌的，带有一定的随机性。因此负载测试与基准测试相比，在设计上并不是要求十分严格，与真实业务一丝不差，抓住用户业务行为模型的主要特征，设置场景

设计性能测试场景

Controller有两个视图：设计视图和运行视图

1、设计视图

设计视图显示场景中的所有Vuser组/脚本的列表、负载生成器计算机以及分配给每个组/脚本的Vuser数，该视图显示有关场景计划（手动场景）或目标（面向目标的场景）的基本信息

2、运行视图

场景一旦开始运行，Controller自动切换到运行视图，运行视图显示有关运行的Vuser的Vuser组的信息以及联机监视器

设计性能测试场景主要是在设计视图中完成的，性能测试中，场景的设计是十分重要的，它整个性能测试的成败

在设计视图中，场景有两种：手工场景和面向目标场景，其中手工场景还有百分比模式

1、手工场景：创建虚拟用户组，设置虚拟用户数目以及其他Run-time信息。手工场景是常用的设计模式，负载测试就常用它。手工场景符合性能测试常规思路，第一步，设置虚拟用户的数目、脚本以及它们运行的方式，第二步，运行，得出服务器的响应时间等指标

手工场景有一个百分比模式：在百分比模式里，只需要设定总用户数，Controller将总用户数以百分比的方式分派去执行不同的脚本

2、面向目标场景：如果说手工场景是一板一眼的因果关系（先有条件，再得结果），面向目标场景就是一个稍微复杂一些的闭环回馈关系。在面向目标场景中，先定义测试要达到的目标，然后LoadRunner自动基于这些目标创建场景，运行过程中，会不断地把结果和目标相比较，以决定下一步怎么走。

创建手工场景

创建虚拟用户组是执行同一脚本的虚拟用户的集合。因此在Controller中，添加了一个脚本，就是添加了一个虚拟用户组

设置集合点

如果在VU脚本中设置了集合点，Controller默认的集合点策略：在所有Running状态的Vuser达到集合点后才释放。

百分比模拟创建手工场景

百分比模式场景是设定总虚拟用户数，然后以百分比的形式把虚拟用户分配到各个脚本中。这种场景设置非常适合业务模型明确的性能测试

创建面向目标场景

面向目标场景的特点是闭关回馈关系，在面向目标场景中，先定义测试达到的目标，然后LoadRunner自动基于这些目标创建场景

Virtual Users

如果需要测试服务器的并发处理能力，即多少人可以同时运行Web应用，那么推荐定义Virtual Users目标类型。运行定义该目标类型的场景和运行Manual类型的场景类似

Hits per Second

如果系那个测试Web Server的真正实力，推荐定义目标类型为：Hits per Second、Pagers per Minute 或者 Transactions per Second，这些类型都需要指定一个虚拟用户的最小值和最大值的范围

Controller试图使用最少的虚拟用户来达到定义的最大值。如果使用了最多的虚拟用户数，定义的目标还没有实现，那么需要增加最大用户数，重新执行场景

Transactions per Second

Transaction Name中应该选定目标Transaction，当然这有一个前提，在脚本里应该有设置Transaction，否则这里就显示为空白

Transaction Response Time

如果想知道在多少用户并发访问网站时，事务的响应时间达到性能指标说明书中规定时间的最大值，推荐使用“Transaction Response Time”类型

Pages per Minute

理解加载机制

如果定义的类型是Pages per Minute、Hits/Transactions per Second，Controller首先用最小用户数除以定义的目标，得到一个值，然后确定每个用户应该达到的Hits/Transactions 或者 Pages per Minute，然后Controller开始按照策略加载用户

多IP的实现原理以及模拟

当运行场景时，虚拟用户使用它们所在的Load Generator的固定的IP地址。同时每个Load Generator上运行大量的虚拟用户，这样就造成了大量的用户使用同一IP同时访问一个网站的情况，这种情况和实际运行的情况不符，并且有一些网站会根据用户IP来分配资源，这些网站会限制同一IP的登录、使用等。

查看虚拟IP是否实现

可以在VU脚本中使用lr_get_vuser_ip函数来得到当前虚拟用户的IP地址

运行场景

性能测试场景的运行和监控都是在运行视图中进行的

两条线索是场景的控制和场景的查看，三个对象是场景、Vuser组和Vuser

场景控制

场景组：显示每个虚拟用户组及其当前运行状态

在场景组的左边区域显示虚拟用户组的状态，右边区域则是场景的控制，比如：开始、停止、复位、虚拟用户控制等

停止方式在场景运行之前就需要在“Tools”菜单下的“Options”选项中设置好

控制整个虚拟用户组

重新编号：重新对组中的Vuser编号，从而更改它们的ID号。ID号是场景运行时分配给虚拟用户组的各个Vuser的。一般的，Vuser执行的结果和其ID没有联系。如果在某个场景下，30号的Vuser总是执行出错，那么就考虑重新编号试试

初始化组：将组中的Vuser分配给其指定的负载生成器，这样它们就可以执行它们的脚本了。Vuser组的状态将从“关闭”变为“挂起”、“正在初始化”、“就绪”。如果Vuser组初始化失败，该Vuser组的状态将变为“错误”

1、高级——从同步点中手动释放Vuser

在运行方案时，在Controller释放Vuser之前可以从集合中手动释放它们

2、高级——向正在运行的场景中手动添加Vuser

在运行场景期间，使用“运行/停止 Vuser”对话框可以手动控制新Vuser的添加

监视场景

查看场景状态信息可以知道哪个虚拟用户执行脚本的哪条语句出了错，这远远是不够的，做性能测试的目的是要找到软件系统的瓶颈，光凭客户端的错误显然还不够，必须监控软件系统各个节点的服务器的性能表现，以判断瓶颈到底出现在哪里

1、联机监视器

LoadRunner提供下列联机监视器

1）“运行时”监视器显示参与方案的Vuser的数目和状态，以及Vuser所生成的错误数量和类型

2）“事务”监视器显示方案执行期间的事务速率和响应时间

3）“Web资源”监视器用于度量方案运行期间Web服务器上的统计信息。它提供关于方案运行期间的Web连接、吞吐量、HTTP响应、服务器重试和下载页的数据

4）“系统资源”监视器测量方案运行期间使用的Windows、UNIX、TUXEDO、SNMP和Antare FlameThrower资源。要激活系统资源监视器，必须在运行方案之前设置监视器选项

5）“网络延迟”监视器显示关于系统上的网络延迟的信息。要激活网络延迟监视器，必须在运行安放之前设置要监视的网络路径

6）“防火墙”监视器用于度量方案运行期间防火墙服务器上的统计信息。要激活防火墙监视器，必须在运行方案之前设置要监视的资源列表

7）“Web服务器资源”监视器用于度量方案运行期间Apache、Microsoft IIS、iPlanet（SNMP）和iPlanet/Netscape Web服务器上的统计信息。要激活Web服务器资源监视器，必须在运行方案之前设置要监视的资源列表

等等...

2、在Controller中启动监控器

在运行过程中，可以监视各个服务器的运行情况（DataBase Server、Web Server等），监视场景通过添加性能计数器来实现

3、配置监视器

创建监视器后，可以配置监视器，使之“个性化”。通过LoadRunner可以配置联机监视器的设置。可以设置图的度量和属性，例如采样时间、线条颜色及图的比例

1、监视器选项

在“Tools”>“Options”中的“Monitors”选项卡中进行全局采样速率、错误处理、调试和频率设置

设定监视器采样频率、出错处理等

2、图属性

选择“监视器”>“联机图”>“配置”，或者右键单击某个图并选择“配置”，将打开“图配置”对话框，其中显示刷新率、显示类型、X轴（图的时间）以及Y轴比例

设定监视器的显示方式

高级——用户自定义数据采集点

如果想采集的数据不在LoadRunner监视器之列的话，那就需要用户自定义数据点。通过在脚本适当位置插入自定义数据采集函数，这样每当脚本运行到此处，就采集数据一次，在测试场景结束后，LoadRunner会生成图表，和其他监视器数据一样，反映被采集数据随时间变化的趋势。

主要的计数器

内存是第一个监视对象，确定系统瓶颈的第一个步骤就是排除内存问题。内存短缺可能会引起各种各样的问题

内存问题主要检查应用程序是否存在内存泄漏。如果发生内存泄漏，Process/private Bytes计数器和Process/Working Set 计数器的值往往会升高，同时Available Bytes 的值会降低

内存泄漏应该通过一个长时间的，用来研究分析当所有内存都耗尽时，应用程序反应情况的测试来检验

场景运行后

场景成功运行后，可手工或自动设置开启Analysis对结果数据进行分析