1. 功能测试 1.1.链接测试 　　 链接是 Web 应用系统的一个主要特征，它是在页面之间切换和指导用户去一些不知道地址的页面的主要手段。链接测试可分为三个方面。首先，测试所有链接是否按指示的那样确实链接到了该链接的页面；其次，测试所链接的页面是否存在；最后，保证 Web 应用系统上没有孤立的页面，所谓孤立页面是指没有链接指向该页面，只有知道正确的 URL 地址才能访问。 　　 链接测试可以自动进行，现在已经有许多工具可以采用。链接测试必须在集成测试阶段完成，也就是说，在整个 Web 应用系统的所有页面开发完成之后进行链接测试。 1.2. 表单测试 　　 当用户给 Web 应用系统管理员提交信息时，就需要使用表单操作，例如用户注册、登陆、信息提交等。在这种情况下，我们必须测试提交操作的完整性，以校验提交给服务器的信息的正确性。例如：用户填写的出生日期与职业是否恰当，填写的所属省份与所在城市是否匹配等。如果使用了默认值，还要检验默认值的正确性。如果表单只能接受指定的某些值，则也要进行测试。例如：只能接受某些字符，测试时可以跳过这些字符，看系统是否会报错。 1.3.Cookies测试 Cookies 通常用来存储用户信息和用户在某应用系统的操作，当一个用户使用 Cookies 访问了某一个应用系统时， Web 服务器将发送关于用户的信息，把该信息以 Cookies 的形式存储在客户端计算机上，这可用来创建动态和自定义页面或者存储登陆等信息。 　　 如果 Web 应用系统使用了 Cookies ，就必须检查 Cookies 是否能正常工作。测试的内容可包括 Cookies 是否起作用，是否按预定的时间进行保存，刷新对 Cookies 有什么影响等。 1.4.设计语言测试 Web 设计语言版本的差异可以引起客户端或服务器端严重的问题，例如使用哪种版本的 HTML 等。当在分布式环境中开发时，开发人员都不在一起，这个问题就显得尤为重要。除了 HTML 的版本问题外，不同的脚本语言，例如 Java 、 Javascrīpt 、 ActiveX 、 VBscrīpt 或 Perl 等也要进行验证。 1.5.数据库测试 　　 在 Web 应用技术中，数据库起着重要的作用，数据库为 Web 应用系统的管理、运行、查询和实现用户对数据存储的请求等提供空间。在 Web 应用中，最常用的数据库类型是关系型数据库，可以使用 SQL 对信息进行处理。 在使用了数据库的 Web 应用系统中，一般情况下，可能发生两种错误，分别是数据一致性错误和输出错误。数据一致性错误主要是由于用户提交的表单信息不正确而造成的，而输出错误主要是由于网络速度或程序设计问题等引起的，针对这两种情况，可分别进行测试。 2. 性能测试 2.1.连接速度测试 　　 用户连接到 Web 应用系统的速度根据上网方式的变化而变化，他们或许是电话拨号，或是宽带上网。当下载一个程序时，用户可以等较长的时间，但如果仅仅访问一个页面就不会这样。如果 Web 系统响应时间太长（例如超过 5 秒钟），用户就会因没有耐心等待而离开。 　　 另外，有些页面有超时的限制，如果响应速度太慢，用户可能还没来得及浏览内容，就需要重新登陆了。而且，连接速度太慢，还可能引起数据丢失，使用户得不到真实的页面。 2.2.负载测试 　　 负载测试是为了测量 Web 系统在某一负载级别上的性能，以保证 Web 系统在需求范围内能正常工作。负载级别可以是某个时刻同时访问 Web 系统的用户数量，也可以是在线数据处理的数量。例如： Web 应用系统能允许多少个用户同时在线？如果超过了这个数量，会出现什么现象？ Web 应用系统能否处理大量用户对同一个页面的请求？ 2.3.压力测试 　　负载测试应该安排在 Web 系统发布以后，在实际的网络环境中进行测试。因为一个企业内部员工，特别是项目组人员总是有限的，而一个 Web 系统能同时处理的请求数量将远远超出这个限度，所以，只有放在 Internet 上，接受负载测试，其结果才是正确可信的。 　　 进行压力测试是指实际破坏一个 Web 应用系统，测试系统的反映。压力测试是测试系统的限制和故障恢复能力，也就是测试 Web 应用系统会不会崩溃，在什么情况下会崩溃。黑客常常提供错误的数据负载，直到 Web 应用系统崩溃，接着当系统重新启动时获得存取权。 　　 压力测试的区域包括表单、登陆和其他信息传输页面等。 3. 可用性测试 3.1.导航测试 　　 导航描述了用户在一个页面内操作的方式，在不同的用户接口控制之间，例如按钮、对话框、列表和窗口等；或在不同的连接页面之间。通过考虑下列问题，可以决定一个 Web 应用系统是否易于导航：导航是否直观？ Web 系统的主要部分是否可通过主页存取？ Web 系统是否需要站点地图、搜索引擎或其他的导航帮助？ 　　 在一个页面上放太多的信息往往起到与预期相反的效果。 Web 应用系统的用户趋向于目的驱动，很快地扫描一个 Web 应用系统，看是否有满足自己需要的信息，如果没有，就会很快地离开。很少有用户愿意花时间去熟悉 Web 应用系统的结构，因此， Web 应用系统导航帮助要尽可能地准确。 　　 导航的另一个重要方面是 Web 应用系统的页面结构、导航、菜单、连接的风格是否一致。确保用户凭直觉就知道 Web 应用系统里面是否还有内容，内容在什么地方。 Web 应用系统的层次一旦决定，就要着手测试用户导航功能，让最终用户参与这种测试，效果将更加明显。 3.2.图形测试 　　 在 Web 应用系统中，适当的图片和动画既能起到广告宣传的作用，又能起到美化页面的功能。一个 Web 应用系统的图形可以包括图片、动画、边框、颜色、字体、背景、按钮等。图形测试的内容有： 　　 （ 1 ）要确保图形有明确的用途，图片或动画不要胡乱地堆在一起，以免浪费传输时间。 Web 应用系统的图片尺寸要尽量地小，并且要能清楚地说明某件事情，一般都链接到某个具体的页面。 　　 （ 2 ）验证所有页面字体的风格是否一致。 　　 （ 3 ）背景颜色应该与字体颜色和前景颜色相搭配。 　　 （ 4 ）图片的大小和质量也是一个很重要的因素，一般采用 JPG 或 GIF 压缩。 3.3.内容测试 　　 内容测试用来检验 Web 应用系统提供信息的正确性、准确性和相关性。 　　 信息的正确性是指信息是可靠的还是误传的。例如，在商品价格列表中，错误的价格可能引起财政问题甚至导致法律纠纷；信息的准确性是指是否有语法或拼写错误。这种测试通常使用一些文字处理软件来进行，例如使用 Microsoft Word 的 " 拼音与语法检查 " 功能；信息的相关性是指是否在当前页面可以找到与当前浏览信息相关的信息列表或入口，也就是一般 Web 站点中的所谓 " 相关文章列表 " 。 3.4.整体界面测试 　　 整体界面是指整个 Web 应用系统的页面结构设计，是给用户的一个整体感。例如：当用户浏览 Web 应用系统时是否感到舒适，是否凭直觉就知道要找的信息在什么地方？整个 Web 应用系统的设计风格是否一致？ 对整体界面的测试过程，其实是一个对最终用户进行调查的过程。一般 Web 应用系统采取在主页上做一个调查问卷的形式，来得到最终用户的反馈信息。 　　 对所有的可用性测试来说，都需要有外部人员（与 Web 应用系统开发没有联系或联系很少的人员）的参与，最好是最终用户的参与。 4. 客户端兼容性测试 4.1.平台测试 　　 市场上有很多不同的操作系统类型，最常见的有 Windows 、 Unix 、 Macintosh 、 Linux 等。 Web 应用系统的最终用户究竟使用哪一种操作系统，取决于用户系统的配置。这样，就可能会发生兼容性问题，同一个应用可能在某些操作系统下能正常运行，但在另外的操作系统下可能会运行失败。 　　 因此，在 Web 系统发布之前，需要在各种操作系统下对 Web 系统进行兼容性测试。 4.2.浏览器测试 　　 浏览器是 Web 客户端最核心的构件，来自不同厂商的浏览器对 Java ，、 Javascrīpt 、 ActiveX 、 plug-ins 或不同的 HTML 规格有不同的支持。例如， ActiveX 是 Microsoft 的产品，是为 Internet Explorer 而设计的， Javascrīpt 是 Netscape 的产品， Java 是 Sun 的产品等等。另外，框架和层次结构风格在不同的浏览器中也有不同的显示，甚至根本不显示。不同的浏览器对安全性和 Java 的设置也不一样。 　　 测试浏览器兼容性的一个方法是创建一个兼容性矩阵。在这个矩阵中，测试不同厂商、不同版本的浏览器对某些构件和设置的适应性。 5. 安全性测试 Web 应用系统的安全性测试区域主要有： 　　 （ 1 ）现在的 Web 应用系统基本采用先注册，后登陆的方式。因此，必须测试有效和无效的用户名和密码，要注意到是否大小写敏感，可以试多少次的限制，是否可以不登陆而直接浏览某个页面等。 　　 （ 2 ） Web 应用系统是否有超时的限制，也就是说，用户登陆后在一定时间内（例如 15 分钟）没有点击任何页面，是否需要重新登陆才能正常使用。 　　 （ 3 ）为了保证 Web 应用系统的安全性，日志文件是至关重要的。需要测试相关信息是否写进了日志文件、是否可追踪。 　　 （ 4 ）当使用了安全套接字时，还要测试加密是否正确，检查信息的完整性。 　　 （ 5 ）服务器端的脚本常常构成安全漏洞，这些漏洞又常常被黑客利用。所以，还要测试没有经过授权，就不能在服务器端放置和编辑脚本的问题。 6. 总结 　　 本文从功能、性能、可用性、客户端兼容性、安全性等方面讨论了基于 Web 的系统测试方法。 基于 Web 的系统测试与传统的软件测试既有相同之处，也有不同的地方，对软件测试提出了新的挑战。基于 Web 的系统测试不但需要检查和验证是否按照设计的要求运行，而且还要评价系统在不同用户的浏览器端的显示是否合适。重要的是，还要从最终用户的角度进行安全性和可用性测试。

 

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

设置套接字的选项

 

1.什么是负载测试？什么是性能测试？

 

2.性能测试包含了哪些测试（至少举出3种）

 

3.简述性能测试的步骤

 

4.简述使用Loadrunner的步骤

 

5.什么时候可以开始执行性能测试？

 

6.LoadRunner由哪些部件组成？

 

7.你使用LoadRunner的哪个部件来录制脚本？

 

8.LoadRunner的哪个部件可以模拟多用户并发下回放脚本？

 

9.什么是集合点？设置集合点有什么意义?Loadrunner中设置集合点的函数是哪个?

 

10.什么是场景？场景的重要性有哪些?如何设置场景?

 

11.请解释一下如何录制web脚本？

 

12.为什么要创建参数?如何创建参数?

 

13.什么是关联？请解释一下自动关联和手动关联的不同。

 

14.你如何找出哪里需要关联？请给一些你所在项目的实例。

 

15.你在哪里设置自动关联选项？

 

16.哪个函数是用来截取虚拟用户脚本中的动态值？（手工管联）

 

17.你在VUGen中何时选择关闭日志？何时选择标准和扩展日志？

 

18.你如何调试LoadRunner脚本？

 

19你在LR中如何编写自定义函数？请给出一些你在以前进行的项目中编写的函数。

 

20.在运行设置下你能更改那些设置？

 

21.你在不同的环境下如何设置迭代？

 

22.你如何在负载测试模式下执行功能测试？

 

23.什么是逐步递增？你如何来设置？

 

24.以线程方式运行的虚拟用户有哪些优点？

 

25.当你需要在出错时停止执行脚本，你怎么做？

 

26.响应时间和吞吐量之间的关系是什么？

 

27.说明一下如何在LR中配置系统计数器？

 

28.你如何识别性能瓶颈？

 

29.如果web服务器、数据库以及网络都正常，问题会出在哪里？

 

30.如何发现web服务器的相关问题？

 

31.如何发现数据库的相关问题？

 

32.解释所有web录制配置？

 

33.解释一下覆盖图和关联图的区别？

 

34.你如何设计负载？标准是什么？

 

35.Vuser_init中包括什么内容？

 

36. Vuser_end中包括什么内容？

 

37.什么是think time？think_time有什么用？

 

38.标准日志和扩展日志的区别是什么？

 

39.解释以下函数及他们的不同之处。

Lr_debug_message

Lr_output_message

Lr_error_message

Lrd_stmt

Lrd_fetch

 

40.什么是吞吐量？

 

41.场景设置有哪几种方法？

 

 

考虑时间Thinking Time指的是在性能测试脚本中，事务与事务之间，会有一些短暂的停顿，就好像真实用户在操作时，两次操作之间需要考虑一下。比如用户注册的时候，在打开注册页面到提交注册页面之间，是有一段考虑时间的（用户在填写个人信息）。
 
        下面就讨论一下在性能测试实战中，为什么要设置考虑时间。
 
        先说一个概念：吞吐量，这指的是服务器系统（包括软件和硬件）单位时间内处理业务的数量。我们现在做一个小试验，写一个小程序，执行一个简单的业务，并且在程序中进行计时，计算每分钟能执行多少次。然后当我们运行1路这个程序的时候，每分钟能完成约6万次。好，现在问一个问题，如果我们起2路，是不是每一路都能达到 6万/分钟 的吞吐量？
 
        试验发现，当运行2路的时候，两个程序的数值都降了下来，但是它们的总和仍然是6万次。而且不管我们起多少路，这些程序的性能总和都接近于6万。
 
        这就好像一个人1分钟最快能吃1个馒头，你让他一个一个吃，他两分钟能吃2个，如果你让他一手拿一个，同时吃，他两分钟吃不了4个，还是只能吃两个。
 
        我们不是在说“考虑时间”么，哈哈，别急，因为上面的问题必须要先说清楚。
 
        如果我们需要进行性能测试的业务是一个单纯的业务，就好像上面举的那个例子一样，那么测试脚本中就不需要设置“考虑时间”，因为不管你用什么方法测试，一个服务系统处理单一业务的吞吐量总是一个定值。
 
        但是在实际环境里面，往往一个系统都是要处理多种业务，并且这些业务之间是有逻辑关系的。举例说明，比如一个论坛系统，每天最常处理的业务有两个：A打开帖子、B回复帖子。那么每天系统处理AB业务的总数是不是一样的呢，答案很明显，看帖子多，回复的少一些。假设A:B=2:1。
 
        好，如果我们不设置考虑时间，起2路A的脚本，1路B的脚本进行性能测试，我们会得到什么结果呢？我们会得到这两个业务的吞吐量，并且能算出每个小时系统完成A、B业务的总数，吞吐量 × 时间 ＝ 总数。
 
        这时我们发现，同样时间，AB业务的处理总数却不是2:1的关系，这是为什么呢？原因是这样的，我们在跑AB脚本的时候，这两组脚本都在尽全力争夺服务器的资源，他们的并发路数虽然是2:1，但是给服务器的压力却不一定是2:1，可能会出现偏差，测试结果就是最好的证据。A查看帖子由于响应时间短，因此跑的次数更多，最后的比例可能是4:1。
 
        那么这样的结果有什么问题呢。总结为一句话：测试环境的业务和真实环境不符，这样测出的数据没有价值。即使测试通过，也不能证明真实环境是ok的；或者即使测试不通过，也不能说明真实环境不ok，呵呵。
 
        比如上面的例子，如果我们测出的结果是B回复帖子的吞吐量不够，响应时间太长，那可能是因为A业务抢走了过多的，本不属于A的资源，而引起了B的性能降低。
 
        说到这里，大家应该明白了，我们设置考虑时间，是为了保证测试复合业务的时候，各个业务之间的比例关系符合我们的真实生产环境。