1.性能测试

LR函数：
lr_start_transaction

为性能分析标记事务的开始

lr_end_transaction

为性能分析标记事务的结束

lr_rendezvous

在 Vuser 脚本中设置集合点

lr_think_time

暂停 Vuser 脚本中命令之间的执行 

lr_end_sub_transaction

标记子事务的结束以便进行性能分析

lr_end_transaction

标记 LoadRunner 事务的结束

Lr_end_transaction("trans1",Lr_auto);

lr_end_transaction_instance

标记事务实例的结束以便进行性能分析

lr_fail_trans_with_error

将打开事务的状态设置为 LR_FAIL 并发送错误消息

lr_get_trans_instance_duration

获取事务实例的持续时间（由它的句柄指定）

lr_get_trans_instance_wasted_time

获取事务实例浪费的时间（由它的句柄指定）

lr_get_transaction_duration

获取事务的持续时间（按事务的名称）

lr_get_transaction_think_time

获取事务的思考时间（按事务的名称）

lr_get_transaction_wasted_time

获取事务浪费的时间（按事务的名称）

lr_resume_transaction

继续收集事务数据以便进行性能分析

lr_resume_transaction_instance

继续收集事务实例数据以便进行性能分析

lr_set_transaction_instance_status

设置事务实例的状态

lr_set_transaction_status

设置打开事务的状态

lr_set_transaction_status_by_name

设置事务的状态

lr_start_sub_transaction

标记子事务的开始

lr_start_transaction

标记事务的开始

Lr_start_transaction("trans1");

lr_start_transaction_instance

启动嵌套事务（由它的父事务的句柄指定）

lr_stop_transaction

停止事务数据的收集

lr_stop_transaction_instance

停止事务（由它的句柄指定）数据的收集

lr_wasted_time

 消除所有打开事务浪费的时间

lr_get_attrib_double

检索脚本命令行中使用的 double 类型变量

lr_get_attrib_long

检索脚本命令行中使用的 long 类型变量

lr_get_attrib_string

检索脚本命令行中使用的字符串

lr_user_data_point

记录用户定义的数据示例

lr_whoami

将有关 Vuser 脚本的信息返回给 Vuser 脚本

lr_get_host_name

返回执行 Vuser 脚本的主机名

lr_get_master_host_name

返回运行 LoadRunner Controller 的计算机名

lr_eval_string

用参数的当前值替换参数

lr_save_string

将以 NULL 结尾的字符串保存到参数中

lr_save_var

将变长字符串保存到参数中

lr_save_datetime

将当前日期和时间保存到参数中

lr _advance_param

前进到下一个可用参数

lr _decrypt

解密已编码的字符串

lr_eval_string_ext

检索指向包含参数数据的缓冲区的指针

lr_eval_string_ext_free

释放由 lr_eval_string_ext 分配的指针

lr_save_searched_string

在缓冲区中搜索字符串实例，并相对于该字符串实例，将该缓冲区的一部分保存到参数中

lr_debug_message

将调试信息发送到输出窗口

lr_error_message

将错误消息发送到输出窗口

lr_get_debug_message

检索当前消息类

lr_log_message

将消息发送到日志文件

lr_output_message

将消息发送到输出窗口

lr_set_debug_message

设置调试消息类

lr_vuser_status_message

生成带格式的输出，并将其写到 ControllerVuser 状态区域

lr_message

将消息发送到 Vuser 日志和输出窗口

lr_load_dll

加载外部 DLL

lr_peek_events

指明可以暂停 Vuser 脚本执行的位置

lr_think_time

暂停脚本的执行，以模拟思考时间（实际用户在操作之间暂停以进行思考的时间）

lr_continue_on_error

指定处理错误的方法

lr_continue_on_error (0）；lr_continue_on_error （1）；

lr_rendezvous

 在 Vuser 脚本中设置集合点

TE_wait_cursor

等待光标出现在终端窗口的指定位置

TE_wait_silent

等待客户端应用程序在指定秒数内处于静默状态

TE_wait_sync

等待系统从 X-SYSTEM 或输入禁止模式返回

TE_wait_text

等待字符串出现在指定位置

TE_wait_sync_transaction

记录系统在最近的 X SYSTEM 模式下保持的时间

 

WEB函数列表：

web_custom_request

允许您使用 HTTP 支持的任何方法来创建自定义 HTTP 请求

web_image

在定义的图像上模拟鼠标单击

web_link

在定义的文本链接上模拟鼠标单击

web_submit_data

执行“无条件”或“无上下文”的表单

web_submit_form

模拟表单的提交

web_url

加载由“URL”属性指定的 URL

web_set_certificate

使 Vuser 使用在 Internet Explorer 注册表中列出的特定证书

web_set_certificate_ex

指定证书和密钥文件的位置和格式信息

web_set_user

指定 Web 服务器的登录字符串和密码，用于 Web 服务器上已验证用户身份的区域

web_cache_cleanup

清除缓存模拟程序的内容

web_find

在 HTML 页内搜索指定的文本字符串

web_global_verification

在所有后面的 HTTP 请求中搜索文本字符串

web_image_check

验证指定的图像是否存在于 HTML页内

web_reg_find

在后面的 HTTP 请求中注册对 HTML源或原始缓冲区中文本字符串的搜索

web_disable_keep_alive

禁用 Keep-Alive HTTP 连接

web_enable_keep_alive

启用 Keep-Alive HTTP 连接

web_set_connections_limit

设置 Vuser 在运行脚本时可以同时打开连接的最大数目

web_concurrent_end

标记并发组的结束

web_concurrent_start

标记并发组的开始

web_add_cookie

添加新的 Cookie 或修改现有的 Cookie

web_cleanup_cookies

删除当前由 Vuser 存储的所有 Cookie

web_remove_cookie

删除指定的 Cookie

web_create_html_param

将 HTML 页上的动态信息保存到参数中。（LR 6.5 及更低版本）

web_create_html_param_ex

基于包含在 HTML 页内的动态信息创建参数（使用嵌入边界）（LR 6.5 及更低版本）。

web_reg_save_param

基于包含在 HTML 页内的动态信息创建参数（不使用嵌入边界）

web_set_max_html_param_len

设置已检索的动态 HTML 信息的最大长度

web_add_filter

设置在下载时包括或排除 URL 的条件

web_add_auto_filter

设置在下载时包括或排除 URL 的条件

web_remove_auto_filter

禁用对下载内容的筛选

web_add_auto_header

向所有后面的 HTTP 请求中添加自定义标头

web_add_header

向下一个 HTTP 请求中添加自定义标头

web_cleanup_auto_headers

 停止向后面的 HTTP 请求中添加自定义标头

web_remove_auto_header

停止向后面的 HTTP 请求中添加特定的标头

web_revert_auto_header

停止向后面的 HTTP 请求中添加特定的标头，但是生成隐性标头

web_save_header

将请求和响应标头保存到变量中

web_set_proxy

指定将所有后面的 HTTP 请求定向到指定的代理服务器

web_set_proxy_bypass

指定 Vuser 直接访问（即不通过指定的代理服务器访问）的服务器列表

web_set_proxy_bypass_local

指定 Vuser 对于本地 (Intranet) 地址是否应该避开代理服务器

web_set_secure_proxy

指定将所有后面的 HTTP 请求定向到服务器

web_set_max_retries

设置操作步骤的最大重试次数

web_set_timeout

指定 Vuser 等待执行指定任务的最长时间

web_convert_param

将 HTML 参数转换成 URL 或纯文本

web_get_int_property

返回有关上一个 HTTP 请求的特定信息

web_report_data_point

指定数据点并将其添加到测试结果中

web_set_option

在非 HTML 资源的编码、重定向和下载区域中设置 Web 选项

web_set_sockets_option

 设置套接字的选项

前言：总感觉自己写这个题目有点冒昧，因为我从来都不敢说我能全部看懂 LoadRunner的分析报表。然而我最终还是用了这个标题，大家权且把它理解为“为了看懂LoadRunner分析报表”而写下的一些东西吧，因为我发现现在有相当一部分使用LoadRunner的朋友面对LoadRunner的一大堆测试结果常常无所适从，不知道如何把这些测试结果真正利用起来，

因此我把我个人学习LoadRunner的一些笔记和心得贴在这里，它到目前为止还是一堆很杂乱的东西，并没有形成一个系统的东西，而且其中可能会存在很多错误，希望各位测试同行能多多批评指教。

一、 Web Page Breakdown

DNS 解析时间： 显示使用最近的 DNS 服务器将 DNS 名称解析为 IP 地址所需的时间； DNS 查找度量是指示 DNS 解析问题或 DNS 服务器问题的一个很好的指示器；

Connect 时间： 显示与包含指定 URL 的 Web 服务器建立初始连接所需的时间； Connect 度量是一个很好的网络问题指示器；它还可表明服务器是否对请求做出响应；

First buffer 时间： 显示从初始 HTTP 请求到成功收回来自 WEB 服务器的第一次缓冲时为止所经过的时间； First buffer 度量是很好的 Web 服务器延迟和网络滞后指示器；

SSL Handshaking time ： 显示建立 SSL 连接所用的时间

Receive Time ： 显示从服务器收到最后一个字节并完成下载之前经过的时间；接收度量是很好的网络质量指示器；

FTP 验证时间： 显示验证客户端所用的时间。

Client Time ： 显示因浏览器思考时间或其他与客户端有关的延迟而使客户机上的请求发生延迟时，所经过的时间。

Error 时间： 显示从发出 HTTP 请求到返回错误消息这期间所经过的平均时间

二、 关于 TPS （ Transactions per Second ）： 每秒处理事务数

这个值可以说明系统在特定的负载情况下，每秒可以处理多少个客户端请求，这是一个衡量服务器端性能的重要指标，相信各位在进行性能测试的时候经常会用到这个指标。但是一直以来我都有一个疑问，到底这个值是怎么算出来的。既然是每秒事务数，那算法自然是“事务数 / 时间”。事务数很好理解，执行了多少就是多少，关键是这个时间。是整个场景执行的时间，还是仅仅是在服务器端执行的时间？因为我们知道，这两个时间肯定是有区别的，前者还包括 thinktime 的时间、 pacing 的时间以及在网络上耗费的时间等等。

为了弄明白这个问题，我今天特地查了一下帮助文档，看到上面是这么说的：“每秒事务数图显示在场景或会话步骤运行的每一秒中，每个事务通过、失败以及停止的次数。”如果按照这句话去理解，那么上面那个问题的答案应该是后者，也就是说，在 Transaactions per Second 这张图中， LoadRunner 是针对场景运行过程中的每一个时间点取样一次，显示在这个时间点上每个事务的通过、失败以及停止的个数。

另外，我还在 Analysis 里面找了一下，发现图表的时间显示粒度也是可以设置的。具体方法为：在图表上点击右键 -> 选择“ Set Granularity ”或者直接按 Ctrl+G 。我试着把时间粒度调成以毫秒为单位，结果 LoadRunner 提示当前不支持以毫秒为显示粒度，由此我推断 LoadRunner 对于 Transactions per Second 这张图，最小的取样粒度为 1 秒。

三、 事务响应时间（百分比）图

这个图显示的是事务响应时间范围的分布情况。在场景的执行中，每个定义的事务可能会不止被处理一次（因为设置了持续时间或者迭代次数）， LoadRunner 会为每个事务实例的处理分别记录响应时间。在 Summary Report 中， LoadRunner 会针对每个事务的响应时间数据集合，分别取它的最大值、最小值和平均值，通常我们会关注响应时间的平均值。然而很多时候，单单是平均响应时间可能是不够的，因为一旦最大值和最小值出现较大的偏差，即便平均响应时间处在可以接受的范围内，但并不意味着整个系统的性能就是可以接受的，我们有必要再借助其它的分析报表来进一步分析，此时事务响应时间（百分比）图就派上用场了。

事务响应时间（百分比）给出的是每个事务的响应时间按百分比的分布情况，它告诉我们本次测试有多少个事务的平均响应时间是落在我们可以接受的时间范围之内。如果最大响应时间非常长，但是绝大多数事务（通常情况下以 95% 为参考）的响应时间具有可以接受的响应时间，则我们认为整个系统的性能还是可以接受的。

注意： Analysis 将对每个可用事务百分比的事务响应时间取近似值。因此 Y 轴的值可能并不准确。

四、 事务响应时间（负载下）图

这个图显示的是事务响应时间随着场景中虚拟用户的逐渐增长的变化趋势图，该图可以帮助我们查看 Vuser 负载对性能问题的影响。当我们需要了解某个事务的响应时间随着虚拟用户的增加而产生的变化时，可以通过在控制台中设置一个渐变负载的场景的方式来实现。例如每 5 分钟加载 10 个用户等，然后考察得到的这张图表，就能够对此有一个比较好的理解。

    本文是《LoadRunner没有告诉你的》系列的第六篇，我将继续保持“无废话”的原则，用尽可能简洁、明确的语句来表述我对性能测试的看法和经验。在这篇文章中，我们要讨论的是如何获取“有效的”性能需求。

     
    一个实际的例子

    为了便于大家的理解，我们先来看一个性能需求的例子，让大家有一个感性的认识，本文后面的讨论也会再次提到这个例子。

    这是一个证券行业系统中某个业务的“实际需求”——实际上是我根据通过网络搜集到的数据杜撰出来的，不过看起来像是真实的 ^_^

    系统总容量达到日委托6000万笔，成交9000万笔

    系统处理速度每秒7300笔，峰值处理能力达到每秒10000笔

    实际股东帐号数3000万

    这个例子中已经包括几个明确的需求：

    最佳并发用户数需求：每秒7300笔

    最大并发用户数需求：峰值处理能力达到每秒10000笔

    基础数据容量：实际股东帐号数3000万

    业务数据容量：日委托6000万笔，成交9000万笔——可以根据这个推算出每周、每月、每年系统容量的增长模型

    什么是“有效的”性能需求？

    要想获得有效的性能需求，就要先了解什么样的需求是“有效的”。有效的性能需求应该符合以下三个条件。

    1. 明确的数字，而不是模糊的语句。

    结合上面的例子来看，相信这个应该不难理解。但是有的时候有了数字未必就不模糊。例如常见的一种需求是“系统需要支持5000用户”，或者“最大在线用户数为8000”。这些有数字的需求仍然不够明确，因为还需要考虑区分系统中不同业务模块的负载，以及区分在线用户和并发用户的区别。关于这方面的内容，在下面两篇文章中的留言内容中有精彩的讨论：

    2. 有凭有据，合理，有实际意义。

    通常来说，性能需求要么由客户提出，要么由开发方提出。对于第一种情况，要保证需求是合理的，有现实意义的，不能由着客户使劲往高处说，要让客户明白性能是有成本的。对于第二种情况，性能需求不能简单的来源于项目组成员、PM或者测试工程师的估计或者猜测，要保证性能需求的提出是有根据的，所使用的数据和计算公式是有出处的——本文后面的部分会介绍获得可用的数据和计算公式的方法。

    3. 相关人员达成一致。

    这一点非常关键。如果相关人不能对性能需求达成一致，可能测了也白测——特别是在客户没有提出明确的性能需求而由开发方提出时。这里要注意“相关人员”的识别，通常项目型的项目的需要与客户方的项目经理或负责人进行确认，产品型的项目需要与直属领导或者市场部进行确认。如果实在不知道该找谁确认，那就把这个责任交给你的直属领导；如果你就是领导了，那这领导也白当了 ^_^

如何获得有效的性能需求

    上面提到了“有效的”性能需求的一个例子和三个条件，下面来我们将看到有哪些途径可以帮助我们获得相关的数据——这些方法我在实际的工作中都用过，并且已经被证实是可行的。这几种方法由易到难排列如下：

    1. 客户方提出

    这是最理想的一种方式，通常电信、金融、保险、证券以及一些其他运营商级系统的客户——特别是国外的客户都会提出比较明确的性能需求。

    2. 根据历史数据来分析

    根据客户以往的业务情况来分析客户的业务量以及每年、每月、每周、每天的峰值业务量。如果客户有旧的系统，可以根据已有系统的访问日志，数据库记录，业务报表来分析。要特别注意的是，不同行业、不同应用、不同的业务是有各自的特点的。例如，购物网站在平时的负载主要集中在晚上，但是节假日时访问量和交易量会是平时的数倍；而地铁的售票系统面临的高峰除了周末，还有周一到周五的一早一晚上下班时间。

    3. 参考历史项目的数据

    如果该产品已有其他客户使用，并且规模类似的，可以参考其他客户的需求。例如在线购物网站，或者超市管理系统，各行业的进销存系统。

    4. 参考其他同行类似项目的数据

    如果本企业没有做过类似的项目，那么可以参考其他同行企业的公布出来的数据——通常在企业公布的新闻或者成功解决方案中会提到，包括系统容量，系统所能承受的负载以及系统响应能力等。

    5. 参考其他类似行业应用的数据

    如果无法找打其他同行的数据，也可以参考类似的应用的需求。例如做IPTV或者DVB计费系统的测试，可以参考电信计费系统的需求——虽然不能完全照搬数据，但是可以通过其他行业成熟的需求来了解需要测试的项目有哪些，应该考虑到的情况有哪些种。

    6. 参考新闻或其他资料中的数据

    最后的一招，特别是对于一些当前比较引人关注的行业，涉及到所谓的“政绩”的行业，通常可以通过各种新闻媒体找到一些可供参考的数据，但是需要耐心的寻找。例如我们在IPTV和DVB系统的测试中，可以根据新闻中公布的各省、各市，以及国外各大运营商的用户发展情况和用户使用习惯来估算系统容量和系统各个模块的并发量。

引自：http://www.51testing.com/?action_viewnews_itemid_10568.html

提到性能测试，相信大家可以在网上找到很多种不同的定义、解释以及分类方法。不过归根结底，在大多数情况下，我们所要做的性能测试的目的是“观察系统在一个给定的环境和场景中的性能表现是否与预期目标一致，评判系统是否存在性能缺陷，并根据测试结果识别性能瓶颈，改善系统性能”。

本文是《LoadRunner没有告诉你的》系列的第五篇，在这篇文章中，我希望可以跟大家一起来探讨“如何将性能测试应用到软件开发过程的各个阶段中，如何通过尽早的开展性能测试来规避因为性能缺陷导致的损失”。

因此，本文的结构也将依据软件开发过程的不同阶段来组织。

另外，建议您在阅读本文前先阅读本系列文章的第三篇《理发店模型》和第四篇《理解性能》。

需求阶段

我们不可能将一辆设计载重为0.75吨的皮卡改装成载重15吨的大型卡车，如果你面对的正是这样的问题，那么恐怕你只能重做一辆，而且客户不会为你之前那辆付钱。对于一个已经完成的应用系统来说也是如此。

如果我们在系统结构确定之前就能够了解到系统的将要面对的压力，用户的使用习惯和使用频度，我们就可以更早也更有效的提前解决或预防可能发生的性能缺陷，也将会极大的减少后期返工和反复调优所带来的工作量。如果我们预期到系统的容量将会不断的增长，我们还可以给出相应的解决方案来低成本的解决这类问题，就像上面那辆皮卡，也许你可以有办法把20辆皮卡捆在一起，或者把15吨的东西分由20辆来运。

分析设计阶段

系统性能的优化并不是要等待整个系统全部集成后才能开始的，早在分析设计阶段，我们就可以开始考虑系统的技术架构和数据库部分的优化。

数据库通常位于整个系统的最底层，如果直到系统上线前才发现因为数据库设计不合理而导致性能极差，通常使用任何一种方法来优化都已经于事无补了。要避免这类问题，最常见的做法是在数据库结构确定后，通过工具或脚本向数据库中注入大量的数据，并模拟各种业务的数据库操作。根据对数据库性能的观察和分析，对数据库表结构和索引进行调整以优化数据库性能。

在系统的技术架构方面，要明白先进的技术并不是解决问题的唯一方法，过于强调技术的作用反而会将你带入歧途。例如：某些业务虽然经常面临着巨大的压力，并且业务本身的复杂性决定了通过算法的优化来提高系统的性能收效甚微。但是我们知道用户对于该业务的实时性要求并不高，并且返回结果对于不同用户来说是相同的。那么我们完全可以考虑将每次请求都动态生成返回结果的方式改为每次用户请求都返回一个定期更新的静态页面。

另外，所谓“先进技术”通常都会在带来某一方面改进的同时带来另一方面的问题，未经试验就盲目的在系统中加入各种流行元素未必是最好的选择。例如ORM可以提供一些方便，但是它生成的SQL是未经优化的，有时甚至比人工编写的SQL效率更低。

最后，要知道不同厂家的设备性能是不同的，而且不同的硬件设备搭载不同的操作系统、数据库、中间件以及应用服务器，表现出来的性能也是不同的。如果有足够的资源，应当考虑提前进行软硬件平台的对比选型；如果没有足够的资源，可以考虑通过一些专业的组织或网站来获取或购买相关的评估报告。

编码阶段

一片树叶在哪里最难被发现？——当这片树叶落在一堆树叶里面的时候。

如果你只是在系统测试完成后才开始性能测试，那么即使发现系统存在性能缺陷，并且已经有了几个可供怀疑的对象，但是当一段因为使用了不当的算法而导致执行效率很低的代码藏身于一个庞大的系统中时，找出它是非常困难的。避免这种情况出现的方法是尽早开始核心业务代码的性能测试，重点集中在对算法和实现方法的优化上。

另外，及早开始的测试也可以帮你更容易找到内存泄漏的问题。

测试阶段

产品终于交到我们手上了，搭建测试环境，设计测试场景，执行测试，找到系统的最佳并发用户数和最大并发用户数，将系统进行分类，评判系统的性能表现是否满足需求中定义的目标——如果有需求的话 ^_^

如果发现系统的性能表现与预期目标相去甚远，则需要根据执行测试过程中收集到的数据来分析和识别性能瓶颈，优化系统性能。

在这个阶段还有很多值得我们深入思考和讨论的东西，在本系列后续的文章中，我们将会更多的关注这一部分的内容。

维护阶段

维护阶段通常遇到的问题是需要在实验室中模拟客户环境，重现在客户那里发现的缺陷并修复缺陷。相比功能缺陷，性能缺陷与某一具体环境和场景的关联更加密切，所以在测试前需要检查生产环境中各服务器的资源利用率、系统访问日志、应用服务器的日志、数据库的日志。如果客户使用了专门的系统来监测各个服务器的软硬件资源使用情况的话，检查该系统是否记录下了软硬件资源的异常或者警告。

与性能测试相关的其他测试

可靠性测试（Reliability Testing）    对于一个运营商级的系统来说，能够保证提供7×24的连续稳定的服务是非常重要的。当然，你可以通过一些“高可用性（High Availability）”技术方案来增强系统的可靠性，但是对于系统本身的可靠性测试是不能被忽略的。

常用的测试方法是使用一定的负载长时间向服务器加压，并观察随着加压时间的延长，响应时间、吞吐量以及资源利用率的变化。要注意的是，所使用的负载应当是系统的最佳并并发用户数，而不是最大并发用户数。

可伸缩性测试（Scalability Testing） 对于一个系统来说，在一个给定的环境下，它的最佳并发用户数和最大并发用户数是客观存在的，但是系统所面临的压力却有可能随上线时间的延长而增大。例如，一个在线购物站点，注册用户数量不断增多，访问站点查询商品信息和购买商品的人也不断的增多，我们应该用一种什么样的方案，在不影响系统继续为用户提供服务的前提下来实现系统的扩容？

一种常用的方案是使用负载均衡（Load Balance）和集群（Cluster）技术。但是在我们为客户提供这种方案之前，需要先自己进行测试，保证该技术的有效性——我们是否真的可以通过简单的增加服务器数据和修改某些参数配置，就能够使得系统的容量得到线性的增长？

可恢复性测试（Recoverability Testing）      虽然我们已经可以准确的估算出系统上线后将要面对的压力，并且可以保证系统的最佳并发用户数和最大并发用户数是足以应对这些压力的，但是这个世界上总是有些事情上我们所无法预料到的——例如9.11事件发生后，AOL的网站访问量在短时间内增长到了平时的数十倍。

我们无法保证系统可以在任何情况下都能为用户正确无误的提供服务，但是我们需要确保当意外过去后，系统可以恢复到正常的状态，并继续后来的用户提供服务——就像从未发生过任何事情一样。

如果要实现“可恢复性测试”，我们可以借助于测试工具或脚本来逐渐的增大并发用户数，直至并发用户数已经超过了系统所能承受的最大并发用户数，并导致软硬件资源利用率饱和，响应时间无限延长，大量的请求因为超过响应时间要求或无法获得响应而失败；之后，我们逐渐的减少并发用户数，并观察资源利用率、响应时间、吞吐量以及交易成功率的变化是否与预期目标一致。

当然，这一切的前提是在系统负载达到峰值前，Server一直在顽强的挣扎着而没有down掉 ^_^

性能测试，并非网络应用专属

软件的性能和性能测试都是伴随着网络应用的兴起而逐渐被重视起来的，但是软件性能和性能测试却并非网络应用的专属名词，因为单机版的应用同样需要考虑性能问题。下面举几个简单的例子来方便大家的理解：

1. 当使用Word来编辑一个500多页，并包含了丰富图表、图片和各种格式、样式信息的文档时，是否每次对大段的文字或表格的修改、删除或重新排版，都要等待系统花几秒钟的时间进行处理？

2. 当在Excel中使用嵌套的统计和数学函数对几万行记录进行统计分析时，是否每次都要两三分钟才能看到结果？

3. 杀毒软件是否每次都要花费两个小时才能完成一次对所有的分区的扫描？

4. 是否每次在手机的通讯簿中根据姓名搜索某个人的联系方式都要三四秒钟才有响应？

如果大家有兴趣，也可以通过Google搜索到更多的有关单机应用性能测试的资料。

本文是《LoadRunner没有告诉你的》系列文章的第四篇，在这篇短文中，我将尽可能用简洁清晰的文字写下我对“性能”的看法，并澄清几个容易混淆的概念，帮助大家更好的理解“性能”的含义。
如何评价性能的优劣: 用户视角 vs. 系统视角
对于最终用户(End-User)来说，评价系统的性能好坏只有一个字——“快”。最终用户并不需要关心系统当前的状态——即使系统这时正在处理着成千上万的请求，对于用户来说，由他所发出的这个请求是他唯一需要关心的，系统对用户请求的响应速度决定了用户对系统性能的评价。
而对于系统的运营商和开发商来说，期望的是能够让尽可能多的用户在任意时刻都拥有最好的体验，这就要确保系统能够在同一时间内处理更多的用户请求。正如在《理发店模型》一文中所描述的：系统的负载（并发用户数）与吞吐量（每秒事务数）、响应时间以及资源利用率（包括软硬件资源）之间存在着一个“此消彼长”的关系。因此，从系统的运营商和开发商的角度来看，所谓的“性能”是一个整体的概念，是系统的负载与吞吐量、可接受的响应时间以及资源利用率之间的平衡。
换句话说，“好的性能”意味着更大的最佳并发用户数（The Optimum Number of Concurrent Users）和 最大并发用户数（The Maximum Number of Concurrent Users）。有关“最佳/最大并发用户数”的概念请参见《理发店模型》一文。
另外，从系统的视角来看，所需要关注的还包括三个与“性能”有关的属性：可靠性（Reliability），可伸缩性（Scalability）和 可恢复性（Recoverability）——我将会在本系列文章的第五篇“无处不在的性能测试”中专门讨论这三个属性的含义和相关的实践经验。
 
响应时间

上面这张图引自段念兄的一份讲义，不过我略作了些修改。从图中我们可以清楚的看到一个请求的响应时间是由几部分时间组成的，包括
C1：用户请求发出前在客户端需要完成的预处理所需要的时间；
C2：客户端收到服务器返回的响应后，对数据进行处理并呈现所需要的时间；
A1：Web/App Server 对请求进行处理所需要的时间；
A2：DB Server 对请求进行处理所需的时间；
A3：Web/App Server 对 DB Server 返回的结果进行处理所需的时间；
N1：请求由客户端发出并达到Web/App Server 所需要的时间；
N2：如果需要进行数据库相关的操作，由Web/App Server 将请求发送至DB Server 所需要的时间；
N3：DB Server 完成处理并将结果返回Web/App Server 所需的时间；
N4：Web/App Server 完成处理并将结果返回给客户端所需的时间；
从用户的角度来看，响应时间＝(C1+C2)+(A1+A2+A3)+(N1+N2+N3+N4)；但是从系统的角度来看，响应时间只包括(A1+A2+A3)+(N1+N2+N3+N4)。
在理解了响应时间的组成之后，可以帮助我们通过对响应时间的分析来更好的识别和定位系统的性能瓶颈。
 
吞吐量 vs. 吞吐量
在不同的测试工具中，对于吞吐量(Throughput)会有不同的解释。例如，在LoadRunner中，这个指标是以字节数为单位来衡量网络吞吐量的，而在JMeter中则是以事务数/秒为单位来衡量系统的响应能力的。不过在大多数英文的性能测试方面的书籍或资料中，吞吐量的定义使用的是后者。
 
并发用户数 ≠ 每秒请求数
这是两个容易让初学者混淆的概念。
简单说，当你在性能测试工具或者脚本中设置了100并发用户数后，并不能期望着一定会有每秒100个请求发给服务器。事实上，对于一个虚拟用户来说，每秒发出多少请求只跟服务器返回响应的速度有关。如果虚拟用户在0.5秒内就收到了响应，那么它会立即发出第二个请求；而如果要一直等待3秒才能得到响应，它将会一直等到收到响应后才发出第二个请求。也就是说，并发用户数的设置只是保证服务器在任一时刻都有100个请求需要处理，而并不一定是保证每秒中发送100个请求给服务器。
所以，只有当响应时间恰好是1秒时，并发用户数才会等于每秒请求数；否则，每秒请求数可能大于并发用户数或小于并发用户数。

引自：http://www.51testing.com/?action_viewnews_itemid_10565.html

    不过，在这篇文章中，我将会尽量的只描述模型本身以及相关的一些扩展，而具体如何将这个模型完全同性能测试关联起来，我不会全部说破，留下足够的空间让大家继续思考和总结，最好也一起来对这个模型做进一步的完善和扩展^_^ 我相信，当大家在思考的过程中有所收获并有所突破时，那种快感和收获的喜悦才真的是让人倍感振奋而且终生难忘的 ^_^

    当然，我要说明的是，这个模型仅仅是1个模型，它与大家实际工作中遇到的各式各样的情况未必都可以一一对应，但是大的方向和趋势应该是一致的。 

    相信大家都进过或见过理发店，一间或大或小的铺面，1个或几个理发师，几张理发用的椅子和供顾客等待的长条板凳。

在我们的这个理发店中，我们事先做了如下的假设：

1. 理发店共有3名理发师；

2. 每位理发师剪一个发的时间都是1小时；

3. 我们顾客们都是很有时间观念的人而且非常挑剔，他们对于每次光顾理发店时所能容忍的等待时间+剪发时间是3小时，而且等待时间越长，顾客的满意度越低。如果3个小时还不能剪完头发，我们的顾客会立马生气的走人。

  通过上面的假设我们不难想象出下面的场景：

  1. 当理发店内只有1位顾客时，只需要有1名理发师为他提供服务，其他两名理发师可能继续等着，也可能会帮忙打打杂。1小时后，这位顾客剪完头发出门走了。那么在这1个小时里，整个理发店只服务了1位顾客，这位顾客花费在这次剪发的时间是1小时；

  2. 当理发店内同时有两位顾客时，就会同时有两名理发师在为顾客服务，另外1位发呆或者打杂帮忙。仍然是1小时后，两位顾客剪完头发出门。在这1小时里，理发店服务了两位顾客，这两位顾客花费在剪发的时间均为1小时；

  3. 很容易理解，当理发店内同时有三位顾客时，理发店可以在1小时内同时服务三位顾客，每位顾客花费在这次剪发的时间仍然是均为1小时；

  从上面几个场景中我们可以发现，在理发店同时服务的顾客数量从1位增加到3位的过程中，随着顾客数量的增多，理发店的整体工作效率在提高，但是每位顾客在理发店内所呆的时间并未延长。

  当然，我们可以假设当只有1位顾客和2位顾客时，空闲的理发师可以帮忙打杂，使得其他理发师的工作效率提高，并使每位顾客的剪发时间小于1小时。不过即使根据这个假设，虽然随着顾客数量的增多，每位顾客的服务时间有所延长，但是这个时间始终还被控制在顾客可接受的范围之内，并且顾客是不需要等待的。

  不过随着理发店的生意越来越好，顾客也越来越多，新的场景出现了。假设有一次顾客A、B、C刚进理发店准备剪发，外面一推门又进来了顾客D、E、F。因为A、B、C三位顾客先到，所以D、E、F三位只好坐在长板凳上等着。1小时后，A、B、C三位剪完头发走了，他们每个人这次剪发所花费的时间均为1小时。可是D、E、F三位就没有这么好运，因为他们要先等A、B、C三位剪完才能剪，所以他们每个人这次剪发所花费的时间均为2小时——包括等待1小时和剪发1小时。

  通过上面这个场景我们可以发现，对于理发店来说，都是每小时服务三位顾客——第1个小时是A、B、C，第二个小时是D、E、F；但是对于顾客D、E、F来说，“响应时间”延长了。如果你可以理解上面的这些场景，就可以继续往下看了。

  在新的场景中，我们假设这次理发店里一次来了9位顾客，根据我们上面的场景，相信你不难推断，这9位顾客中有3位的“响应时间”为1小时，有3位的“响应时间”为2小时（等待1小时+剪发1小时），还有3位的“响应时间”为3小时（等待2小时+剪发1小时）——已经到达用户所能忍受的极限。假如在把这个场景中的顾客数量改为10，那么我们已经可以断定，一定会有1位顾客因为“响应时间”过长而无法忍受，最终离开理发店走了。

 我想并不需要特别说明，大家也一定可以把上面的这些场景跟性能测试挂上钩了。如果你还是觉得比较抽象，继续看下面的这张图 ^_^

这张图中展示的是1个标准的软件性能模型。在图中有三条曲线，分别表示资源的利用情况（Utilization，包括硬件资源和软件资源）、吞吐量（Throughput，这里是指每秒事务数）以及响应时间（Response Time）。图中坐标轴的横轴从左到右表现了并发用户数（Number of Concurrent Users）的不断增长。

 在这张图中我们可以看到，最开始，随着并发用户数的增长，资源占用率和吞吐量会相应的增长，但是响应时间的变化不大；不过当并发用户数增长到一定程度后，资源占用达到饱和，吞吐量增长明显放缓甚至停止增长，而响应时间却进一步延长。如果并发用户数继续增长，你会发现软硬件资源占用继续维持在饱和状态，但是吞吐量开始下降，响应时间明显的超出了用户可接受的范围，并且最终导致用户放弃了这次请求甚至离开。

 根据这种性能表现，图中划分了三个区域，分别是Light Load（较轻的压力）、Heavy Load（较重的压力）和Buckle Zone（用户无法忍受并放弃请求）。在Light Load和Heavy Load 两个区域交界处的并发用户数，我们称为“最佳并发用户数（The Optimum Number of Concurrent Users）”，而Heavy Load和Buckle Zone两个区域交界处的并发用户数则称为“最大并发用户数（The Maximum Number of Concurrent Users）”。

 当系统的负载等于最佳并发用户数时，系统的整体效率最高，没有资源被浪费，用户也不需要等待；当系统负载处于最佳并发用户数和最大并发用户数之间时，系统可以继续工作，但是用户的等待时间延长，满意度开始降低，并且如果负载一直持续，将最终会导致有些用户无法忍受而放弃；而当系统负载大于最大并发用户数时，将注定会导致某些用户无法忍受超长的响应时间而放弃。

 对应到我们上面理发店的例子，每小时3个顾客就是这个理发店的最佳并发用户数，而每小时9个顾客则是它的最大并发用户数。当每小时都有3个顾客到来时，理发店的整体工作效率最高；而当每小时都有9个顾客到来时，前几个小时来的顾客还可以忍受，但是随着等待的顾客人数越来越多，等待时间越来越长，最终还是会有顾客无法忍受而离开。同时，随着理发店里顾客人数的增多和理发师工作时间的延长，理发师会逐渐产生疲劳，还要多花一些时间来清理环境和维持秩序，这些因素将最终导致理发师的工作效率随着顾客人数的增多和工作的延长而逐渐的下降，到最后可能要1.5小时甚至2个小时才能剪完1个发了。

 当然，如果一开始就有10个顾客到来，则注定有1位顾客剪不到头发了。

 进一步理解“最佳并发用户数”和“最大并发用户数”

 在上一节中，我们详细的描述了并发用户数同资源占用情况、吞吐量以及响应时间的关系，并且提到了两个新的概念——“最佳并发用户数（The Optimum Number of Concurrent Users）”和“最大并发用户数（The Maximum Number of Concurrent Users）”。在这一节中，我们将对“最佳并发用户数”和“最大并发用户数”的定义做更加清晰和明确的说明。

 对于一个确定的被测系统来说，在某个具体的软硬件环境下，它的“最佳并发用户数”和“最大并发用户数”都是客观存在。以“最佳并发用户数”为例，假如一个系统的最佳并发用户数是50，那么一旦并发量超过这个值，系统的吞吐量和响应时间必然会 “此消彼长”；如果系统负载长期大于这个数，必然会导致用户的满意度降低并最终达到一种无法忍受的地步。所以我们应该 保证最佳并发用户数要大于系统的平均负载。

 要补充的一点是，当我们需要对一个系统长时间施加压力——例如连续加压3-5天，来验证系统的可靠性或者说稳定性时，我们所使用的并发用户数应该等于或小于“最佳并发用户数”——大家也可以结合上面的讨论想想这是为什么 ^_^

 而对于最大并发用户数的识别，需要考虑和鉴别一下以下两种情况：

 1. 当系统的负载达到最大并发用户数后，响应时间超过了用户可以忍受的最大限度——这个限度应该来源于性能需求，例如：在某个级别的负载下，系统的响应时间应该小于5秒。这里容易疏忽的一点是，不要把顾客因为无法忍受而离开时店内的顾客数量作为理发店的“最大并发用户数”，因为这位顾客是在3小时前到达的，也就是说3小时前理发店内的顾客数量才是我们要找的“最大并发用户数”。而且，这位顾客的离开只是一个开始，可能有会更多的顾客随后也因为无法忍受超长的等待时间而离开；

 2. 在响应时间还没有到达用户可忍受的最大限度前，有可能已经出现了用户请求的失败。以理发店模型为例，如果理发店只能容纳6位顾客，那么当7位顾客同时来到理发店时，虽然我们可以知道所有顾客都能在可容忍的时间内剪完头发，但是因为理发店容量有限，最终只好有一位顾客打道回府，改天再来。

 对于一个系统来说，我们应该 确保系统的最大并发用户数要大于系统需要承受的峰值负载。

 如果你已经理解了上面提到的全部的概念，我想你可以展开进一步的思考，回头看一下自己以往做过的性能测试，看看是否可以对以往的工作产生新的理解。也欢迎大家在这里提出自己的心得或疑惑，继续讨论下去。

 理发店模型的进一步扩展

 这一节中我会提到一些对理发店模型的扩展，当然，我依然是只讲述现实中的理发店的故事，至于如何将这些扩展同性能测试以及性能解决方案等方面关联起来，就留给大家继续思考了 ^_^

 扩展场景1：有些顾客已经是理发店的老顾客，他们和理发师已经非常熟悉，理发师可以不用花费太多时间沟通就知道这位顾客的想法。并且理发师对这位顾客的脑袋的形状也很熟悉，所以可以更快的完成一次理发的工作。

 扩展场景2：理发店并不是只有剪发一种业务，还提供了烫发染发之类的业务，那么当顾客提出新的要求时，理发师服务一位顾客的时间可能会超过标准的1小时。而且这时如果要计算每位顾客的等待时间就变得复杂了很多，有些顾客的排队时间会比原来预计的延长，并最终导致他们因为无法忍受而离开。

 扩展场景3：随着烫发和染发业务的增加，理发师们决定分工，两位专门剪发，一位专门负责烫发和染发。

 扩展场景4：理发店的生意越来越好，理发师的数量和理发店的门面已经无法满足顾客的要求，于是理发店的老板决定在旁边再开一家店，并招聘一些工作能力更强的理发师。

 扩展场景5：理发店的生意变得极为火爆了，两家店都无法满足顾客数量增长的需求，并且有些顾客开始反映到理发店的路途太远，到了以后又因为烫发和染发的人太多而等太久。可是理发店的老板也明白烫发和染发的收入要远远高于剪发阿，于是他脑筋一转，决定继续改变策略，在附近的几个大型小区租用小的铺面开设分店，专职剪发业务；再在市区的繁华路段开设旗舰店，专门为烫发、染发的顾客，以及VIP顾客服务。并增设800电话，当顾客想要剪发时，可以拨打这个电话，并由服务人员根据顾客的居住地点，将其指引到距离最近的一家分店去。

 这篇文章就先写到这里了，希望大家在看完之后可以继续思考一下，也写出自己的心得体会或者新的想法，记下自己的不解和疑惑，让我们在不断的交流和讨论中走的更远 ^_^

 性能测试相关术语的英文书写方法（不断更新ing）——知道了这些术语在英文中的正确书写方法之后，可以通过 Google 更加高效的获取到更多有用的资料。

数据统计分析的思路与分析结果的展示方式是同样重要的，有了好的分析思路，但是却不懂得如何更好的展示分析结果和数据来印证自己的分析，就像一个人满腹经纶却不知该如何一展雄才

一图胜千言，所以这次我会用两张图表来说明“描述性统计”在性能测试结果分析中的其他应用。

这张图所使用的数据与第一张图一样，但是我们使用了另外一个视角来对数据进行展示。表中最左侧的2000/5000/10000/50000的单位是毫秒，分别表示了在整个测试过程中，响应时间在0-2000毫秒范围内的事务数量占成功的事务总数的百分比，响应时间在2001-5000毫秒范围内的事务数量占成功的事务总数的百分比，响应时间在5001-10000毫秒范围内的事务数量占成功的事务总数的百分比，以及响应时间在10001-50000毫秒范围内的事务数量占成功的事务总数的百分比。

这几个时间范围的确定是参考了业内比较通行的“2-5-10原则”——当然你也可以为自己的测试制定其他标准，只要得到企业内的承认就可以。所谓的“2-5-10原则”，简单说，就是当用户能够在2秒以内得到响应时，会感觉系统的响应很快；当用户在2-5秒之间得到响应时，会感觉系统的响应速度还可以；当用户在5-10秒以内得到响应时，会感觉系统的响应速度很慢，但是还可以接受；而当用户在超过10秒后仍然无法得到响应时，会感觉系统糟透了，或者认为系统已经失去响应，而选择离开这个Web站点，或者发起第二次请求。

那么从上面的图表中可以看到，当并发用户数量为10时，超过95％的用户都可以在5秒内得到响应；当并发用户数量达到25时，已经有80％的事务的响应时间处在危险的临界值，而且有相当数量的事务的响应时间超过了用户可以容忍的限度；随着并发用户数量的进一步增加，超过用户容忍限度的事务越来越多，当并发用户数到达75时，系统几乎已经无法为任何用户提供响应了。

这张图表也同样可以用于对不同负载下事务的成功、失败比例的比较分析。

Note：上面两个图表中的数据，主要通过Excel 中提供的FREQUENCY，AVERAGE，MAX，MIN和PERCENTILE几个统计函数获得，具体的使用方法请参考Excel帮助手册。

LoadRunner中的90％响应时间是什么意思？这个值在进行性能分析时有什么作用？本文争取用最简洁的文字来解答这个问题，并引申出“描述性统计”方法在性能测试结果分析中的应用。

为什么要有90％用户响应时间？因为在评估一次测试的结果时，仅仅有平均事务响应时间是不够的。为什么这么说？你可以试着想想，是否平均事务响应时间满足了性能需求就表示系统的性能已经满足了绝大多数用户的要求？

假如有两组测试结果，响应时间分别是 {1，3，5，10，16} 和 {5，6，7，8，9}，它们的平均值都是7，你认为哪次测试的结果更理想？

假如有一次测试，总共有100个请求被响应，其中最小响应时间为0.02秒，最大响应时间为110秒，平均事务响应时间为4.7秒，你会不会想到最小和最大响应时间如此大的偏差是否会导致平均值本身并不可信？

为了解答上面的疑问，我们先来看一张表：

在上面这个表中包含了几个不同的列，其含义如下：

CmdID   测试时被请求的页面

NUM      响应成功的请求数量

MEAN    所有成功的请求的响应时间的平均值

STD DEV      标准差（这个值的作用将在下一篇文章中重点介绍）

MIN              响应时间的最小值

50 th(60/70/80/90/95 th)          如果把响应时间从小到大顺序排序，那么50％的请求的响应时间在这个范围之内。后面的60/70/80/90/95 th 也是同样的含义

MAX      响应时间的最大值

我想看完了上面的这个表和各列的解释，不用多说大家也可以明白我的意思了。我把结论性的东西整理一下：

1.      90％用户响应时间在 LoadRunner中是可以设置的，你可以改为80％或95％；

2.      对于这个表，LoadRunner中是没有直接提供的，你可以把LR中的原始数据导出到Excel中，并使用Excel中的PERCENTILE 函数很简单的算出不同百分比用户请求的响应时间分布情况；

3.      从上面的表中来看，对于Home Page来说，平均事务响应时间(MEAN)只同70％用户响应时间相一致。也就是说假如我们确定Home Page的响应时间应该在5秒内，那么从平均事务响应时间来看是满足的，但是实际上有10-20％的用户请求的响应时间是大于这个值的；对于Page 1也是一样，假如我们确定对于Page 1 的请求应该在3秒内得到响应，虽然平均事务响应时间是满足要求的，但是实际上有20-30％的用户请求的响应时间是超过了我们的要求的；

4.      你可以在95 th之后继续添加96/ 97/ 98/ 99/ 99.9/ 99.99 th，并利用Excel的图表功能画一条曲线，来更加清晰表现出系统响应时间的分布情况。这时候你也许会发现，那个最大值的出现几率只不过是千分之一甚至万分之一，而且99％的用户请求的响应时间都是在性能需求所定义的范围之内的；

5.      如果你想使用这种方法来评估系统的性能，一个推荐的做法是尽可能让你的测试场景运行的时间长一些，因为当你获得的测试数据越多，这个响应时间的分布曲线就越接近真实情况；

6.      在确定性能需求时，你可以用平均事务响应时间来衡量系统的性能，也可以用90％或95％用户响应时间来作为度量标准，它们并不冲突。实际上，在定义某些系统的性能需求时，一定范围内的请求失败也是可以被接受的；

7.      上面提到的这些内容其实是与工具无关的，只要你可以得到原始的响应时间记录，无论是使用LoadRunner还是JMeter或者OpenSTA，你都可以用这些方法和思路来评估你的系统的性能。

事实上，在性能测试领域中还有更多的东西是目前的商业测试工具或者开源测试工具都没有专门讲述的——换句话说，性能测试仅仅有工具是不够的。我们还需要更多其他领域的知识，例如数学和统计学，来帮助我们更好的分析性能数据，找到隐藏在那些数据之下的真相。

引自：http://www.51testing.com/?action_viewnews_itemid_10545.html

1. Which of the following information are considered relevant when gathering system
usage for a performance test? There are two answers.
a. System architecture
b. Business processes
c. Application modules about to be unit-tested
d. Financial data such as general ledger and P&L statements
2. There are three main criteria to determine which business processes to select for per-
formance testing. What are these criteria?
3. Each business process takes a certain amount of time to complete. Under ideal condi-
tions, you determine this amount of time as ________________________
4. You want to determine how many users are active on a Web site during a twenty-four
hour period. What type of diagram can you use to map the business processes and the
volume of each across a fixed time line?
5. How many transactions will need to run per minute if a load test has to run for two
hours with 5000 users, assuming an average transaction length of five minutes?
6. This value represents the number of users performing business processes on the appli-
cation during the busiest time frame of an atypical day (e.g. holiday). What do you call
this value?
7. Write a quantifiable performance test objective given the following information
Maximum number of concurrent users at peak time: 6000
Business Process: Update Totals
Preferred response time range: 5 to 7 seconds
Core LoadRunner and Virtual User Generator (VuGen)
1. What is a Load Test?
2. What is an Integration Test?
3. What are the LoadRunner Components and what role does each play in creating a
performance test?
4. General Vuser Functions:
Transactions are defined and measured in a Vuser scrīpt using which two functions?
5. What is ThinkTime?
6. Create a Vuser scrīpt where the value of lr_think_time is parameterized. The value of
thinktime should be displayed as an output message in the execution log.
7. What is correlation?
Correlation Activity:
This exercise requires internet access.
Application: Mercury Tours
URL: http://newtours.mercuryinteractive.com
Vuser Recording Settings:
■ Recording should be HTML-based
■ Correlation during recording should be turned off
■ Advanced recording should be turned off
General Vuser Settings:
■ Save correlation information during replay
■ Show only differences that appear in action
■ Download images on Snapshots viewer
■ HTML comparison: for scanning differences
■ Record the application startup
Record User Actions:
1. Sign in to the Mercury Tours Web site as jojo with the password bean.
2. Enter the flight information to the FLIGHT FINDER page.
Accept the defaults for all input fields except the following listed below (round-trip
flight, 1 passenger, economy class, etc)
Departing From: San Francisco
Arriving In: New York
3. Click the CONTINUE button.
4. Accept the first departing flight in the list.
By default, the first available flight is selected for each direction when the SELECT
FLIGHT page appears.
5. Select the last (4th) return flight in the list.
6. Click the CONTINUE button on the SELECT FLIGHT page.
7. Purchase the selected flight.
Enter the passenger and credit card information in the BOOK A FLIGHT page. Use the
data supplied below:
First Name: Joseph
Last Name: Smith
Number: 783921045786
8. Click the SECURE PURCHASE button on the BOOK A FLIGHT page.
9. Verify that the Flight Confirmation page appeared.
10. In the browser, click Sign-Off and wait for the Sign-On page to appear. Stop record-
ing.
Vuser Requirements:
■ Save the Vuser scrīpt twice.
■ In one of the scrīpts, parameterize the fields “fromPort” and “toPort” as type, file,
sequential using the following data:
Depart                 Arrive
San Francisco      New York
Seattle                  Frankfurt
Sydney                  London
Zurich                   Acapulco
■ The scrīpt should play back correctly.
Questions:
■ What were the errors found in the Vuser scrīpt?
■ How did you correct the errors?
 
 
smallfish

Performance Test Planning
1. A B
2. Mission-critical, heavy throughput, dynamic content
3. Preferred response time
4. Task Distribution Diagram
5. 1000 transactions per minute
6. Peak load
7. The Update Totals transaction time should be seven seconds or less during peak hours
for 6000 concurrent users.
Core Technology and Navigation

1. A load test is a short-term test of system performance under typical real-world condi-
tions using critical business processes.

2.
3. Controller - the administrative center for creating, maintaining, executing and moni-
toring scenarios. Scenarios have a .lrs extension
LoadRunner Generators - Machines that emulate user volume and locally stores load
test results until the scenario completes running, then the results are transferred to
the results file specified.
LoadRunner Analysis - Processes the results from the scenario run. Results files have
a .lrr extension. After the results are processed by the LR Analysis tool, the results
files have a .lra extension.
Virtual User Generator - records Vuser scrīpts that emulate the steps of real users
using the application under test
4. lr_start_transaction
lr_end transaction
5. ThinkTime is a measure of time that a real user takes to pause between the execution
of steps.
6. A sample snippet of code that parameterizes the value of thinktime and outputs the
value to the execution log:
//Save the string value of the parameter to an INT variable
int yzf = atoi(lr_eval_string(“{param1}”);

lr_think_time(yzf);
lr_output_message (“The parameter value is %s”, lr_eval_string(“{param1}”));
7. Correlation is the method of capturing values in a scrīpt as a result of dynamic data
passed from server to the client and back. The values are saved in a LoadRunner
parameter and is reused instead of the original re corded value.

8. Correlation Activity:
First error is in the basic scrīpt. On the list of available flights, even if the first listed
flight is selected by default in the Departing From table, you still need to record
clickin on it for the value to be captured and correlated when the cities are parameter-
ized.
When the departing and arrival cities were parameterized, errors occured during the
run because the flight information changes depending on the selected departing and
arrival cities. An auto-scan corrected the errors by placing the appropriate
web_reg_save_param statements in two correlations found, Blue Skies and United
flight details.