最新版LoadRunner性能测试实战
内容介绍：
很多使用LoadRunner的测试人员经常面临两个难题：脚本开发与性能测试分析。本书就是基于帮助测试人员解决这两个问题而编写，致力于使读者学精LoadRunnner这一强大的性能测试工具。
全书共分为四部分：入门篇、基础篇、探索篇、实战篇。第一篇入门篇的内容包括第1章和第2章，着重于讲解性能测试与LoadRunner的基础理论知识。第二篇基础篇的内容包括第3章至第5章，是LoadRunner 的基本使用部分，着重讲解Virtual User Generator、Controller、Analysis的使用方法。第三篇探索篇的... 第1部分入门篇.. (1)
第1章性能测试基础知识.. 3
1.1 性能测试基本概念 (4)
1.1.1 什么是性能测试 (4)
1.1.2 性能测试应用领域 (6)
1.1.3 性能测试常见术语 (8)
1.2 全面性能测试模型 (11)
1.2.1 性能测试策略模型 (14)
1.2.2 性能测试用例模型 (17)
1.2.3 模型的使用方法 (20)
1.3 性能测试调整基础 (21)
1.4 如何做好性能测试 (24)
1.5 本章小结 (28)
第2章LoadRunner基础知识.. 29
2.1 LoadRunner简介 (29)
2.1.1 LoadRunner主要特点 (29)
2.1.2 LoadRunner常用术语 (31)
2.2 LoadRunner工作原理 (32)
2.3 LoadRunner测试流程 (33)
2.4 LoadRunner的部署与安装 (35)
2.5 本章小结 (41)
第2部分基础篇 (43)
第3章脚本的录制与开发.. 45
3.1 Virtual User Generator简介 (45)
3.1.1 VuGen录制原理 (46)
3.1.2 VuGen功能简介 (48)
3.1.3 如何选择协议 (49)
3.2 VuGen录制功能详解 (50)
3.2.1 录制参数设置 (50)
3.2.2 脚本录制与创建事务 (57)
3.2.3 回放与调试脚本 (61)
3.2.4 脚本录制的基本原则 (63)
3.3 修改虚拟用户脚本 (64)
3.3.1 参数化功能 (64)
3.3.2 深入集合点 (71)
3.3.3 巧用检查点 (72)
3.3.4 关联 (78)
3.4 配置虚拟用户脚本 (80)
3.5 两个常用函数介绍 (84)
3.6 本章小结 (86)
第4章场景的创建与执行.. 87
4.1 Controller简介 (87)
4.2 场景类型介绍 (88)
4.2.1 手动测试场景 (88)
4.2.2 面向目标的测试场景 (90)
4.3 测试场景设计 (93)
4.3.1 配置测试脚本 (93)
4.3.2 配置Generator 94
4.3.3 配置Schedule. 95
4.3.4 集合点配置 (99)
4.3.5 IP Spoofer配置 (100)
4.3.6 其他设置场景 (106)
4.4 执行测试场景 (108)
4.4.1 启动测试场景 (108)
4.4.2 控制用户与用户组 (108)
4.4.3 查看场景与用户状态 (109)
4.4.4 控制集合点 (110)
4.4.5 查看运行数据图 (110)
4.5 监控系统资源 (111)
4.5.1 监控Windows系统资源 (112)
4.5.2 监控Linux/Unix系统资源 (114)
4.6 本章小结 (121)
第5章性能测试结果分析.. 123
5.1 如何分析性能测试结果 (124)
5.1.1 性能分析基础知识 (125)
5.1.2 Analysis使用基础 (127)
5.1.3 一个视频网站例子 (135)
5.2 如何从分析图中发现问题 (148)
5.2.1 虚拟用户图 (148)
5.2.2 事务图 (151)
5.2.3 Web资源图 (160)
5.2.4 网页细分图 (166)
5.2.5 小结 (179)
5.3 分析图的处理方法 (179)
5.3.1 修改默认配置 (180)
5.3.2 合并分析图 (187)
5.3.3 自动关联 (188)
5.3.4 场景运行比较 (191)
5.4 Analysis分析报告 (193)
5.4.1 事务活动报告（Activity Reports） (193)
5.4.2 事务性能报告（Performance Reports） (196)
5.4.3 HTML与Word报告 (199)
5.5 本章小结 (206)
第3部分探索篇 (209)
第6章用Visual C++增强虚拟用户.. 211
6.1 认识LoadRunner动态链接库的调用功能 (211)
6.1.1 动态链接库调用功能简介 (211)
6.1.2 动态链接库调用功能适用范围 (212)
6.2 创建与调用动态链接库 (212)
6.2.1 用Visual C++创建Dll 212
6.2.2 Dll调用方法 (215)
6.2.3 载入头文件方法 (217)
6.2.4 Dll调用需注意的问题 (220)
6.3 UDP发包应用案例 (222)
6.3.1 测试内容简介 (222)
6.3.2 测试程序设计 (222)
6.3.3 虚拟用户脚本 (223)
6.3.4 测试场景设置 (224)
6.3.5 测试结果分析 (225)
6.4 本章小结 (226)
第7章深入Java虚拟用户.. 227
7.1 认识Java虚拟用户 (227)
7.1.1 Java虚拟用户协议 (227)
7.1.2 Java虚拟用户适用范围 (230)
7.1.3 脚本开发环境配置 (231)
7.2 Java脚本开发基础 (234)
7.2.1 Java虚拟用户开发基础 (234)
7.2.2 LoadRunner的Java API. 243
7.3 Java算法测试案例 (245)
7.4 本章小结 (260)
第8章深入.NET虚拟用户.. 261
8.1 认识.NET虚拟用户 (261)
8.1.1 .NET虚拟用户适用范围 (261)
8.1.2 安装与配置.NET插件 (262)
8.2 创建.NET虚拟用户 (264)
8.2.1 创建虚拟用户项目 (264)
8.2.2 参数、集合点、事务 (266)
8.3 网站视频性能测试应用案例 (271)
8.3.1 创建自定义的播放器类 (272)
8.3.2 创建抽象虚拟用户类 (276)
8.3.3 创建抽象并发测试类 (282)
8.3.4 创建自定义虚拟用户脚本 (284)
8.3.5 创建LoadRunner .NET虚拟用户 (287)
8.3.6 案例总结 (290)
8.4 本章小结 (290)
第9章LoadRunner特殊协议应用.. 291
9.1 Windows Sockets协议应用 (291)
9.1.1 录制Windows Sockets协议脚本 (292)
9.1.2 增强Windows Sockets协议脚本 (294)
9.2 WAP协议应用 (298)
9.3 Web Services协议应用 (302)
9.3.1 Web Services协议简介 (302)
9.3.2 录制Web Services协议脚本 (303)
9.4 FTP协议应用 (312)
9.5 本章小结 (317)
第4部分实战篇 (319)
第10章电子商务平台测试案例.. 321
10.1 GBE测试项目简介 (321)
10.1.1 项目背景信息 (321)
10.1.2 系统功能简介 (322)
10.1.3 项目测试计划 (323)
10.2 性能测试规划与设计 (323)
10.2.1 性能测试的种类、范围、目标 (324)
10.2.2 人力资源、进度安排 (325)
10.2.3 测试环境需求 (325)
10.2.4 选择测试工具 (327)
10.2.5 用户场景分析与设计 (328)
10.2.6 性能测试计划 (333)
10.2.7 测试用例设计 (334)
10.2.8 其他事项 (341)
10.3 性能测试准备 (341)
10.3.1 测试环境 (341)
10.3.2 系统使用培训 (342)
10.3.3 测试数据 (343)
10.3.4 虚拟用户脚本 (346)
10.4 测试的实施与控制 (349)
10.4.1 设计测试用例场景 (349)
10.4.2 执行测试用例场景 (351)
10.4.3 进度与变更控制 (359)
10.5 测试结论与建议 (360)
10.5.1 测试结果综述 (360)
10.5.2 系统性能优化建议 (361)
10.5.3 风险分析 (362)
10.6 本章小结 (362)
附录A LoadRunner性能测试常见问题.. 365 附录B LoadRunner性能测试模板.. 373 B.1 性能测试计划模板 (373)
B.1.1 项目背景简介 (373)
B.1.2 测试方案简介 (373)
B.1.3 测试环境与资源 (373)
B.1.4 项目里程碑 (374)
B.1.5 技能培训计划 (374)
B.1.6 风险分析 (374)
B.1.7 计划结束标准 (374)
B.2 性能测试用例模板 (374)
B.2.1文档介绍 (374)
B.2.2 测试需求分析 (375)
B.2.3 性能测试用例 (375)
B.3 性能测试报告模板 (380)
B.3.1 基本信息 (380)
B.3.2 测试环境描述 (381)
B.3.3 性能测试用例执行分析 (381)
B.3.4 测试结果综合分析及建议 (381)
B.3.5 测试经验总结 (381)
后记.. 383
前言
在作者的另一作品《Web性能测试实战》中，曾经提到过“软件亚健康”这个概念。现在，亚健康不但威胁着IT人的生活质量，也威胁很多应用软件的性能。为此，在《Web性能测试实战》一书中，作者提出了“全面性能测试模型”，期望能够成为解决软件亚健康问题的一剂“良药”。
“全面性能测试模型”包含了测试策略制定、测试用例设计、模型使用方法三部分内容，基本覆盖了性能测试规划和设计的相关内容，为开展性能测试提供了一种可行的方案。借助本模型，软件开发和测试人员可以更好的组织与规划性能测试，避免在项目后期遭遇性能问题的被动局面。
不过要想做好性能测试，仅有性能测试模型还是远远不够的，因为还缺少像LoadRunn er这样令性能测试工作如虎添翼的性能测试利器。本书将和读者一起深入LoadRunner的性能测试世界，探讨在企业的性能测试项目中如何应用它来发现应用系统存在的性能问题。LoadRunner在性能测试中的地位
对于很多使用LoadRunner的测试人员而言，性能测试工作中最大的障碍就是测试脚本开发与测试结果分析，这导致很多测试人员忽略了测试规划与设计的重要性，反而认为能开发测试脚本、运行测试场景、分析测试结果就算做好性能测试了。
要想做好性能测试，首先应该把重心放在测试的规划与设计上，尤其要注重测试用例的设计，仅仅能写测试程序与运行测试脚本是远远不够的。诸如LoadRunner等测试工具仅仅是性能测试的执行与分析工具，它们应该服从于测试设计人员的意志。测试工具的使用属于测试人员的基本功，应该在开展性能测试工作前修炼好。只有好的测试用例或者测试场景才能发现系统的问题，这才是性能测试的本质所在。
性能测试分析同样依赖于前面工作的输出结果，不是随便一个测试结果就能发现问题的。所谓“万丈高楼平地起”，性能分析的准确性同样取决于此前所做的设计与实施等“地基”是否可靠。可以说，性能测试分析仅仅是百米赛跑的最后二十米而已。当然，这并不是说性能测试分析不重要，因为“最后冲刺的二十米没有跑好”，前面工作做的再好也是徒劳的。因此不难理解，性能测试分析工作开展的根基就是前面测试场景执行的结果。要想保证性能测
试分析的结论是正确的，则测试结果数据首先就应该是正确的，而这也意味着测试场景以及测试执行过程都应该是正确的。
实际上，性能测试从始至终都应该是相当严谨的一项工程，各个阶段的工作环环相扣，性能测试工程师应该认真对待各个阶段的工作。如果一味地追求找出系统瓶颈，无疑是舍本逐末的做法。
因此，在性能测试工作中首先要做好性能测试的规划与设计工作，然后再借助LoadRu nner的强大功能来发现系统存在的问题。
如何通过本书学习LoadRunner
首先应该弄清楚学习LoadRunner的目的，那就是在项目的性能测试中应用LoadRunne r来发现系统的性能问题。因此，仅仅会用LoadRunner还远远不够，这也是为什么很多培训班出来的学员虽然把工具用的非常熟练，但是仍然不能做好性能测试工作。
学好LoadRunner的标准是真正能够把LoadRunner应用到实际项目中去，这就要求学习LoadRunner的同时一定要学好性能测试相关知识。本书的第1章即为基本的性能测试知识，读者需要认真体会这些内容，建议在学习后面的内容时，经常翻阅本章的内容。如果要学习更多的性能测试规划与设计的知识以及性能测试案例，建议读者参考本书的姊妹篇《W eb性能测试实战》。
本书的第2章是LoadRunner的简介部分，读者需要通过本章了解LoadRunner的工作原理、测试流程、部署与安装等内容，尤其要掌握图2-1所示的LoadRunner工作原理，这是用LoadRunner开展工作的基础。
本书的第3章、第4章、第5章分别讲解了LoadRunner的Virtual User Generator、C ontroller、Analysis。这三大组件分别负责脚本的录制与开发、场景的创建与执行、测试结果分析工作。用LoadRunner来开展性能测试，必须要掌握这三大组件的使用。如果连基本的工具都没有用好，很难正确地执行设计好的测试用例，更不用说根据结果来分析系统的瓶颈了。在第3～5章中，详细探讨了LoadRunner各个组件的使用细节，但是这还远远不够，尤其对于那些只会录制或者简单修改录制结果的测试人员！学习这三章的内容时，最好的方法是结合LoadRunner的联机帮助文档，这样可以学习到更多的内容。
学习完第3～5章后，可能还有一些读者会问：“我还是不会自己写测试脚本，很多协议仍然不能进行测试怎么办？”碰到这种情况就需要补习自己的开发知识了。
开发知识应该分两个方面来学习：一是面向对象基础知识的学习，二是开发语言的学习。很多人可能会认为面向对象基础知识比较通用，相对容易学习；而开发语言种类繁多，不知道如何入手。根据作者的经验，这两个方面应该结合起来进行：面向对象是现在主流开发语言的灵魂，一起学习可以互相促进。具体做法就是选择C++、Java、C#等一种主流语言来学习，只要这门语言是自己所在公司的主流语言即可。当学会面向对象基础和一门语言后，再去学习其它的语言将会非常容易。
具有一定的开发能力后，就可以开始本书探索篇第6～9章的学习。这四章是LoadRun ner的探索篇，讲解了在LoadRunner中如何应用C++、Java、C#语言进行开发以及一些特殊的脚本协议。
相信通过前面9章的学习，读者已经掌握LoadRunner的精髓了。不过本书不是一本“L oadRunner使用百科大全”，接下来就需要读者自己不断地应用与探索LoadRunner了，逐步完成成为一个LoadRunner高手的蜕变过程。
如何学习本书的性能测试案例
本书在第10章中，花了很大的篇幅介绍了一个电子商务平台的性能测试案例，目的不是为了介绍如何测试电子商务系统，而是让读者在掌握前面技能的基础上，更加深入地体会在项目中如何通过LoadRunner来实施性能测试。因此，案例的业务并不重要，读者也没有必要深究具体的细节。通过本案例，能清晰地了解了能测试的整个过程就已经达到了目的。
本书案例的学习重点在以下几个方面：
l 借助案例体会“全面性能测试模型”在GBE项目中的应用；
l 学习性能测试规划与设计中的需求分析过程，例如测试环境需求、人力资源；
l 学习性能测试规划与设计中的测试场景分析与设计、测试用例设计；
l 学习如何做好性能测试实施前的准备工作；
l 测试执行过程的进度与变更控制；
l 一些分析性能问题的过程。
关于性能测试案例更多的内容，读者可以阅读《Web性能测试实战》中的案例部分。关于本书
本书的主旨在于让读者学会LoadRunner的应用，并能在此基础上自行探索性能测试世界。
本书共分为四部分：入门篇、基础篇、探索篇、实战篇。
第一部分：入门篇，包括第1章和第2章，着重于讲解性能测试与LoadRunner的基础理论知识。在第1章中，讲解了性能测试基本概念、全面性能测试模型、性能测试调整等基础的性能测试理论知识；第2章则介绍了LoadRunner的特点与术语、工作原理、测试流程、部署与安装等内容。
第二部分：基础篇，包括第3章至第5章，着重讲解LoadRunner三大组件的使用，是LoadRunner的基本使用部分。在第3章中，主要讲解如何在Virtual User Generator中完成代码的录制与开发；第4章讲解如何在Controller中创建与执行场景；第5章中讲解如何结合Analysis来分析性能测试结果。
第三部分：探索篇，包括第6章至第9章，着重讲解LoadRunner的高级应用。第6章讲解如何用Visual C++来增强虚拟用户；第7章深入探索了Java虚拟用户；第8章深入探索了.NET虚拟用户；第9章则讲解了Socket虚拟用户的相关知识。
第四部分：实战篇，即第10章，结合案例来讲解在具体项目中如何应用LoadRunner 来完成性能测试工作。在第10章中，通过真实的性能测试实例，向读者展示了如何在项目中完成性能测试的整体规划与设计、测试的准备与实施、测试结果分析等工作。
致谢
感谢广大读者对《Web性能测试实战》一书的支持，读者的支持是作者写作的真正动力。正是一年来因为大家对《Web性能测试实战》的肯定才促使我完成本书的写作工作；
感谢博文视点周筠老师对本书的支持，周老师对我这个新人一直给予很大的鼓励；
感谢电子工业出版社博文视点资讯有限公司的陈元玉编辑，她是本书的责任编辑；
感谢师兄王玉亭，他再次为本书提供了很多素材；
感谢同事关晓培、周雪松、李熠，他们为本书提供了很多素材；
感谢电子工业出版社为本书辛勤付出的所有朋友们；
特别感谢夫人小姬，她通篇审校了本书并润色了那些难于理解的句子，特别是她对我在公司的日常工作和编写工作的支持，因为本书占据了大量可以陪她的时间；
最后要感谢自己的父母和老师，能写出本书是父母和老师多年教育的结果。
软件在性能方面的“亚健康”问题一直伴随着国内很多企业的软件产品而存在。早期由于多数软件应用系统在企业中得不到有效的推广应用，因此用户往往会忽略自己在性能方面的需求。而现在软件几乎渗透到人们工作与生活的各个方面，因而软件的性能开始得到越来越多的重视。
随着软件工程技术、软件开发方法和软件开发工具的发展，一方面使人们可以快速开发更加复杂的应用，另一方面也使开发出的软件规模越来越庞大，架构越来越复杂。随之而来的是软件性能问题也越来越多，最终导致很多软件系统由于性能方面存在问题而停止使用，给软件公司以及客户都带来了一定的损失。因此，解决软件性能问题是十分必要的一项工作中，对于企业自身以及客户都具有重要的现实意义。
在绍英的上一本著作《Web性能测试实战》中，为接近软件性能问题提出了“全面性能测试模型”，以期成为解决软件亚健康问题的一剂良药。“全面性能测试模型”包含了性能测试策略制定、测试用例设计、模型使用方法三部分内容，覆盖了性能测试规划和设计的相关内容，为开展性能测试工作提供了一种可行的方案。但是仅有理论是不够的，对于性能测试工作而言，不但需要好的性能测试理论作为工作指导，更需要掌握好的性能测试工具，因此本书的几位作者共同创作了《LoadRunner性能测试实战》一书。
LoadRunner是目前国内性能测试领域应用最广泛的工具之一，它可以通过模拟成千上万的用户，很快地帮助用户确认和查找性能问题。但是国内图书市场上却没有任何相关书籍，《LoadRunner性能测试实战》填补了这个空白。
《LoadRunner性能测试实战》是非常注重实际应用的作品。书中详细描述了LoadRunner在性能测试领域诸多方面的应用，并结合具体的案例来说明如何应用《Web性能测试实战》一书中提到的“全面性能测试模型”。强大的性能测试工具加上合理的理论来指导，将为读者打开很多新的思路。
本书是由三位作者共同完成的。绍英有流媒体、P2P、电子政务、银行、门户网站等领域应用软件的性能测试经验，在LoadRunner方面更有五年以上的使
用经验。他曾到很多公司去推广自己的性能测试模型以及讲解LoadRunner课程，对企业在软件测试方面的需求非常熟悉；建华是在读研究生，因此有充裕的时间来研究LoadRunner的特殊应用；小姬在性能测试方面也有着丰富的经验。相信他们的这些实践经验是很多测试人员急需的。
本书对国内软件企业提高性能测试水平是很有价值的。我很高兴能为这本实战性非常强的作品做序，预祝《LoadRunner性能测试实战》早日出版。也希望国内有更多的人来关注软件性能测试，探讨解决软件亚健康问题的方法！
北京大学软件与微电子学院副教授
北京市软件促进中心专家顾问黎怡兰(Melody Le)
1.1性能测试基本概念
在一些软件项目中，项目经理或测试经理经常会安排测试工程师进行下面的工作：
l 用LoadRunner测试系统的最大并发用户数。
l 用LoadRunner测试系统8小时的最大业务吞吐量。
l 用LoadRunner测试系统的稳定性与健壮性。
l 用LoadRunner测试系统在数据达到100万条记录时的性能。
l 用LoadRunner测试核心事务响应时间是否满足用户的需求。
可以说，现在很多IT企业的性能测试工作已经离不开LoadRunner了。不过，尽管使用了LoadRunner这一强大的工具，很多企业软件产品遇到的性能问题仍未
能解决——因为仅有好的测试工具是不够的。除了比较实用的测试工具外，要想做
好性能测试还应该掌握相关的理论知识。只有以坚实的理论作为实际工作的依托，
才能让测试工具发挥出应有的功效。
本章将介绍一些性能测试的基础知识，主要内容如下：
n 性能测试基本概念
n 全面性能测试模型
n 性能测试调整基础
n 如何做好性能测试
提示：关于性能测试理论的更多内容，可以参考作者性能测试方面的专著《Web 性能测试实战》，电子工业出版社，2006年5月出版。
1.1 性能测试基本概念
在软件系统日益复杂的今天，性能已经成为软件质量重要的衡量标准之一，这一点尤其体现在和Web相关的系统上。软件几乎无处不在，在给用户带来方便的同时，也对开发人员和测试人员提出了更高的要求。性能测试不但要求测试人员具备很强的技术能力，还要具备综合分析问题的能力。本节从性能测试的概念入手，强化性能测试的基础知识。
1.1.1 什么是性能测试
目前很少能见到性能测试的准确定义，但是性能测试又似乎是涉及范围非常广泛的测试。压力测试、负载测试、强度测试、稳定性测试、健壮性测试、大数据量测试……都和性能测试有着密切的关系。
在本书中，主要从狭义和广义两方面来讨论性能测试。
狭义的性能测试主要用于描述常规的性能测试，是指通过模拟生产运行的业务压力或用户使用场景来测试系统的性能是否满足生产性能的要求。
例如，以实际投产环境进行测试，来求出最大的吞吐量与最佳响应时间，以保证上线的平稳、安全等。性能测试是一种“正常”的测试，主要测试正常使用时系统是否满足要求，同时可能为了保留系统的扩展空间而进行的一些稍稍超出“正常”范围的测试。
广义的性能测试则是压力测试、负载测试、强度测试、并发（用户）测试、大数据量测试、配置测试、可靠性测试等和性能相关的测试统称。下面分别介绍各类测试的主要内容和特点。
压力测试
对系统不断施加压力的测试，是通过确定一个系统的瓶颈或不能接收用户请求的性能点，来获得系统能提供的最大服务级别的测试。例如测试一个Web站点在大量的负荷下，系统的事务响应时间何时会变得不可接受或事务不能正常执行。
压力测试的目的是发现在什么条件下系统的性能变得不可接受，并通过对应用程序施加越来越大的负载，直到发现应用程序性能下降的拐点。压力测试和负载测试有些类似，但是通常把负载测试描述成一种特定类型的压力测试——例如增加用户数量或延长压力时间以
对应用程序进行压力测试。
负载测试
对系统不断地增加压力或增加一定压力下的持续时间，直到系统的一些性能指标达到极限，例如响应时间超过预定指标或某种资源已经达到饱和状态。这种测试可以找到系统的处理极限，为系统调优提供依据。
压力测试侧重压力大小，而负载测试往往强调压力持续的时间。在实际工作中，没有必要严格区分这两个概念，有关内容可以参见后面1.2节的“全面性能测试模型”。
强度测试
强度测试主要是为了检查程序对异常情况的抵抗能力。强度测试总是迫使系统在异常的资源配置下运行。例如：
l 当正常的用户点击率为“1000次/秒”时，运行点击率为“2000次/秒”的测试用例；
l 运行需要最大存储空间（或其他资源）的测试用例；
l 运行可能导致操作系统崩溃或磁盘数据剧烈抖动的测试用例，等等。
强度测试是一种特别重要的测试，对测试系统的稳定性，以及系统未来的扩展空间均具有重要的意义。在这种异常条件下进行的测试，更容易发现系统是否稳定以及性能方面是否容易扩展。
疲劳强度测试是一类特殊的强度测试，主要测试系统长时间运行后的性能表现，例如7×24小时的压力测试。
并发（用户）测试
主要指当测试多个用户并同时访问同一个应用程序、同一个模块或数据记录时是否存在死锁或其他性能问题，几乎所有的性能测试都会涉及并发测试。在具体的性能测试工作中，并发用户往往都是借助工具来进行模拟的，LoadRunner中称之为并发虚拟用户。
大数据量测试
大数据量测试分为两种：一种是针对某些系统存储、传输、统计查询等业务进行大数据量的测试；另一种是与并发测试相结合的极限状态下的综合数据测试。如专项的大数据量测试主要针对前者，后者尽量放在并发测试中。此外，也可以把大数据量测试分为“运行时大数据量测试”与“历史大数据量测试”来进行测试用例设计。
配置测试
配置测试主要指通过测试找到系统各项资源的最优分配原则。配置测试是系统调优的重要依据。例如，可以通过不停地调整Oracle的内存参数来进行测试，使之达到一个较好的性能。
可以看出，配置测试本质上是前面提到的某些种类的性能测试组合在一起而进行的测试。
可靠性测试
在给系统加载一定业务压力的情况下，使系统运行一段时间，以此检测系统是否稳定。例如，可以施加让CPU资源保持70%～90%使用率的压力，连续对系统加压8个小时，然后根据结果分析系统是否稳定。
这么多类型的性能测试看起来很吓人，实际上它们大多是密切相关的。例如，运行8个小时来测试系统是否可靠，而这个测试极有可能包含了可靠性测试、强度测试、并发（用户）测试、负载测试，等等。
因此，当实施性能测试时绝不能割裂它们的内部联系去进行，而应分析它们之间的关系，以一种高效的方式来规划与设计性能测试。为此，本书在1.2节提出了“全面性能测试模型”，以更好的方式来开展性能测试工作。
1.1.2 性能测试应用领域
性能测试往往是为了实现下面的一个或几个目标：
l 判定软件是否满足预期的性能需求；
l 根据测试结果判定软件的性能表现；
l 查找系统可能存在的性能问题，如果有，则找出并加以解决；
l 发现一些应用程序在功能实现方面的缺陷；
l 对一些存在性能问题的系统，找出瓶颈并加以解决；
l 为用户部署系统提供性能参考；
l ……
通过分析性能测试的种种目标，不难总结出性能测试主要应用在几个领域中，下面分别予以介绍。
系统的性能瓶颈定位
系统的性能瓶颈定位是性能测试最常见的应用领域。借助LoadRunner等工具，可以在测试场景运行过程中监控系统资源、Web服务器资源等运行数据，与响应时间进行同步分析，可以在一定程度上进行性能瓶颈的分析与定位。
系统的参数配置
通过性能测试可以测试系统在不同参数配置下的性能表现，进而找出令系统表现更优的系统配置参数，为应用系统投产提供最佳配置建议。
实际上，操作系统、数据库、中间件服务器等的参数配置是应用系统发生性能问题的重要原因。
例如分配给Oracle的内存大小与系统自身的业务特点有极大关系，配置不同的数据库，性能表现就会不同；而即使在内存一定的情况下，SGA的分配也会对性能产生很大的影响。因此，要通过测试，以确定内存的最佳配置。
发现一些软件算法方面的缺陷
一些多线程、同步并发算法在单用户模式下测试是很难发现问题的，只有通过模拟多用户的并发操作，才能验证其运行是否正常与稳定。
例如作者就经历过在一次性能测试过程中，测试人员模拟多个用户并发时发现的一个明显的缺陷：测试对象是一个随机分配任务的模块，只要有用户申请，就会给用户分配任务。这个算法在单用户情况下调试没有任何问题，但是当多个用户同时申请任务时，就发生了把同一任务分配给多个不同用户的现象。经证实，这个缺陷就是“同步算法”发生了问题而引起的。
系统的验收测试
系统验收测试经常会验证一些预期的性能指标，或者验证系统中一些事务指标是否符合用户期望，这时就需要借助性能测试来完成验证工作。
随着用户对性能的重视，现在性能测试几乎是系统验收测试中必不可少的内容之一。用户甚至自己进行专门的性能测试来验证系统上线前的性能，以保证运行时的性能稳定。因此，性能测试在用户验收测试中越来越重要。
系统容量规划
通过总结系统在不同硬件环境下的性能表现，可以为系统部署时提供非常好的参考。对于一些性能要求较高的系统，性能测试可以为硬件规划提供很好的参考数据，使用户在购买硬件时“有据可依”。例如同一系列机型：两颗CPU系统支持500用户并发、四颗CPU支持800用户并发，这些都是用户根据自身需求来规划硬件的重要依据。
产品评估/选型
产品评估/选型是性能测试的又一应用领域。通过性能测试，可以对产品的软硬件性能进行更全面的评估，选出更适合自己的产品类型。
性能测试的应用领域越来越广，因此在实际工作中，性能测试往往会一次应用在一个或多个领域。对于软件性能测试设计人员，应该根据测试的具体应用领域、测试原则和目标来进行性能测试的规划与设计。
1.1.3 性能测试常见术语
本节将介绍一些性能测试中的常见术语，只有掌握这些基础的性能测试知识，才可以进一步开展测试工作。性能测试常见的术语主要有并发、并发用户数量、请求响应时间、事务响应时间、吞吐量、吞吐率、TPS、点击率、资源利用率等，下面分别介绍它们。
并发
狭义的并发一般分两种情况。一种是严格意义上的并发，即所有的用户在同一时刻做同一件事情或操作，这种操作一般针对同一类型的业务。例如在信用卡审批业务中，一定数目的用户在同一时刻对已经完成的审批业务进行提交（操作的不是同一记录）；还有一种是特例，即所有用户进行完全一样的操作，目的是测试数据库和程序对并发操作的处理。例如在信用卡审批业务中，所有的用户可以一起申请业务，或者修改同一条记录。
另外一种并发是广义的并发。这种并发与狭义的并发的区别是尽管多个用户对系统发出了请求或进行了操作，但是这些请求或操作可以是相同的，也可以是不同的。对整个系统而言，仍然有很多用户同时对系统进行操作，因此，仍然属于并发的范畴。
可以看出，广义的并发是包含狭义的并发的，而且广义的并发更接近用户的实际使用情况，因为对大多数系统而言，只有数量很少的用户进行“严格意义上的并发”。对于性能测试而言，这两种并发一般都需要进行测试，通常做法是先进行严格意义上的并发测试。严格意义上的并发一般发生在使用比较频繁的模块中，尽管发生的概率不是特别高，但是一旦发生性能问题，后果很可能是致命的。严格意义上的并发测试往往和功能测试关联起来，因为只要并发功能遇到异常通常都是程序的问题，这种测试也是健壮性和稳定性测试的一部分。并发用户数量
关于并发用户的数量，有两种常见的错误观点。一种错误观点是把并发用户数量理解为使用系统的全部用户的数量，理由是这些用户可能同时使用系统；还有一种比较接近正确的观点是把用户在线数量理解为并发用户数量。实际上，在线用户不一定会和其他用户发生并发，例如正在浏览网页信息的用户，对服务器是没有任何影响的。但是，用户在线数量是统计并发用户数量的主要依据之一。
并发主要针对服务器而言，是否并发的关键是看用户的操作是否对服务器产生了影响。因此，并发用户数量的正确理解是，在同一时刻与服务器进行交互的在线用户数量。这些用
户的最大特征是和服务器发生了交互，这种交互既可以是单向传送数据的，也可以是双向传送数据的。
并发用户数量的统计方法目前还没有准确的公式，因为不同的系统会有不同的并发特点。例如OA系统统计并发用户数量的经验公式为：使用系统的用户数量×（5％～20％）。对于这个公式，没有必要拘泥于计算出的结果，因为为了保证系统的扩展空间，测试时的并发用户数量都会稍稍大一些，除非要测试系统能承受的最大并发用户数量。举例说明：如果一个OA系统的期望用户为1 000个，只要测试出系统能支持200个并发用户就可以了。请求响应时间
请求响应时间是指从客户端发出请求到得到响应的整个过程的时间。这个过程从客户端发送一个请求开始计时，到客户端接到从服务器端返回的响应结果计时结束。在某些工具中，请求响应时间通常会被称为“TTLB”，即“Time to last byte”，意思是从发送一个请求开始，到客户端收到最后一个字节的响应为止所耗费的时间。请求响应时间的单位一般为“秒”或“毫秒”。请求响应时间的分解如图1-1所示。
图1-1 Web请求过程分解图
从图1-1可以看出，请求响应时间为“网络响应时间”和“应用程序与系统响应时间”之和，具体由7个部分组成，即(N1+N2+N3+N4)+(A1+A2+A3)。
事务响应时间
事务可能由一系列请求组成，事务的响应时间主要针对用户而言，属于宏观上的概念，是为了向用户说明业务响应时间而提出的。例如：跨行取款事务的响应时间就是由一系列的请求组成的。事务响应时间和后面的业务吞吐率都是直接衡量系统性能的参数。
吞吐量
指在一次性能测试过程中网络上传输的数据量的总和。吞吐量/传输时间，就是吞吐率。吞吐率（Throughput）
通常用来指单位时间内网络上传输的数据量，也可以指单位时间内处理的客户端请求数量。它是衡量网络性能的重要指标。
但是从用户或业务角度来看，吞吐率也可以用“请求数/秒”或“页面数/秒”、“业务数/小时或天”、“访问人数/天”、“页面访问量/天”来衡量。例如在银行卡审批系统中，可以用“千件/每小时”来衡量系统的业务处理能力。
TPS(Transaction Per Second)
每秒钟系统能够处理的交易或事务的数量。它是衡量系统处理能力的重要指标。TPS是LoadRunner中重要的性能参数指标。
点击率（Hit Per Second）
每秒钟用户向Web服务器提交的HTTP请求数。这个指标是Web应用特有的一个指标：Web应用是“请求-响应”模式，用户发出一次申请，服务器就要处理一次，所以“点击”是We b应用能够处理交易的最小单位。如果把每次点击定义为一次交易，点击率和TPS就是一个概念。不难看出，点击率越大，对服务器的压力也越大。点击率只是一个性能参考指标，重要的是分析点击时产生的影响。
需要注意的是，这里的点击不是指鼠标的一次“单击”操作，因为在一次“单击”操作中，客户端可能向服务器发出多个HTTP请求。
资源利用率
资源利用率指的是对不同系统资源的使用程度，例如服务器的CPU利用率、磁盘利用率等。资源利用率是分析系统性能指标进而改善性能的主要依据，因此，它是Web性能测试工作的重点。
资源利用率主要针对Web服务器、操作系统、数据库服务器、网络等，是测试和分析瓶颈的主要参数。在性能测试中，要根据需要采集具体的资源利用率参数来进行分析。
1.2 全面性能测试模型
1.2 全面性能测试模型
通过前面的内容可以看出，性能测试的很多内容都是关联的。这就提供了一条思路：性能测试的很多内容可以经过一定的组织来统一进行。统一开展性能测试的最大好处是，可以按照由浅入深的层次对系统进行测试，进而减少不必要的工作量，以实现节约测试成本的目的。为此，本书提出了“全面性能测试模型”。
性能测试培训（一） ——基础知识 1.软件性能测试的概念 1.1软件性能与性能测试 软件性能：覆盖面广泛，对一个系统而言，包括执行效率、资源占用、稳定性、安全性、兼容性、可扩展性、可靠性等。 性能测试：为保证系统运行后的性能能够满足用户需求，而开展的一系列的测试组织工作。 1.2不同角色对软件性能的认识 用户眼中的软件性能： ?软件对用户操作的响应时间 如用户提交一个查询操作或打开一个web页面的链接等。 ?业务可用度，或者系统的服务水平如何 管理员眼中的软件性能：
开发人员眼中的软件性能： 1.3性能测试的对象 服务器端： ?负载均衡系统； ?服务器（单机、双机热备、集群）； ?存储系统、灾备中心； ?数据库、中间件。 网络端： ?核心交换设备、路由设备； ?广域网络、专线网络、局域网络、拨号网络等； 应用系统： 由此可见，性能测试是一个系统性的工作，被测对象包括系统运行时使用的所有软硬件。但在实际操作时，将根据项目的特点，选择特定的被测对象。 1.4性能测试的目标 评价系统当前的性能：
?系统刚上线使用，即处于试运行时，用户需要确定当前系 统是否满足验收要求； ?系统已经运行一段时间，如何保证一直具有良好的性能。分析系统瓶颈、优化系统： ?用户提出业务操作响应时间长，如何定位问题，调整性能； ?系统运行一段时间后，速度变慢，如何寻找瓶颈，进而优 化性能。 预见系统未来性能、容量可扩充性： ?系统用户数增加或业务量增加时，当前系统是否能够满足 需求，如果不能，需要进行哪些调整？提高硬件配置？增 加应用服务器？提高数据库服务器的配置？或者是需要对 代码进行调整？ 1.5性能测试的分类 按照测试压力级别： ?负载测试； ?压力测试； 按照测试实施目标： ?应用在客户端的测试； ?应用在网络的测试； ?应用在服务器端的测试； 按照测试实施策略：
Loadrunner学习总结 LoadRunner，是一种预测系统行为和性能的负载测试工具。通过以模拟上千万用户实施并发负载及实时性能监测的方式来确认和查找问题，LoadRunner 能够对整个企业架构进行测试。企业使用LoadRunner能最大限度地缩短测试时间，优化性能和加速应用系统的发布周期。 LoadRunner可适用于各种体架构的自动负载测试，能预测系统行为并评估系统性能。操作流程如下： 1.录制脚本： 选择适当的协议，web服务器一般选择http协议。 录制方式一般选择HTML-based Script，但有下列情况选择URL-based Script：不是基于浏览器的应用程序，应用程序中包含javaScript脚本且产生了请求，基于浏览器的应用程序使用了https协议
默认设置记录的浏览器为IE，不要使用其他浏览器 在录制过程中不要后退页面 2.录制结束后点绿色方块按钮结束录制，系统会自动生成录制脚本。
3.录制完之后就是对脚本的回放处理，可以在运行时设置界面设置回放的设置， 如：迭代（重复次数）、步（开始新迭代时候的时间设置）、思考时间（录制时间的停留时间）等，设置好之后就开始回放。 4.回放结束后，回放的情况会显示出来，没有错误表示录制的进程没有问题。 5.负载测试运行
选择录制的脚本添加，然后确认。
可以在场景计划 可以在场景计划这里设置要测试的参数，比如开始用户数，持续时间，停止方式等。 如果想测定某个操作的响应时间，可以在脚本中插入事务，使用事务把该操作包装起来。分析执行结果的时候可以查看到该事务的响应时间。 插入集合点，可以使多个用户并发进行同一操作，提高操作的并发程度，以对服务器增加负载，测试并发能力。 在Run-Time Setting设置中，设置网络带宽以模拟不同带宽的网络；设置block、action的迭代次数。 对脚本进行参数化，设置参数变更方式
使用LoadRunner编写性能测试方案 1.声明 本测试方案适用于航空订票系统的性能测试，可指导其他航空订票系统的测试。本方案版权归于某某性能测试开发组，如果引用请声明具体测试环境和测试数据，否则测试结果无效。 2. 系统概述 此次测试的系统是航空订票网站系统，此系统应用Perl语言开发的基于B/S架构的网上订票系统，此系统的主要功能包括：用户注册、用户登录、定制票据、查看票据、取消票据、用户注销等主要功能。 本次测试过程重点关注系统的响应时间、并发用户、吞吐量等性能指标。 3. 词汇表 1）用户 用户指所有的访问系统的人，包括已经注册了用户名的人和没有注册用户名的人，测试过程中的Vusers就是模拟人的行为。 2）在线用户 在线用户指所有访问系统的用户，这些用户可以是正在和服务器进行交互的用户，也可以是正在浏览信息、填写表单等跟服务器没有交互行为的用户。 3）并发用户 并发用户指同时向服务器发出请求的用户，这些用户必须跟服务器进行数据交互。 4）响应时间 响应时间指从客户端发出请求到客户端从服务器获得数据这个过程花费的时间。响应时间是一个往返的过程，包括了客户端请求和服务器响应的时间，可以模拟用户的真实感受。5）平均响应时间 平均响应时间指针对某个业务的访问统计所有的响应时间，然后求平均。 6）标准偏差 标准偏差指一组数据取样空间中所有的值对应平均值的偏离度，用来衡量系统响应的可靠性和稳定性的指标。 7）TPS 每秒钟的事物数 5. 性能测试模型 5.1 用户体验模型
业界网站的用户感受标准符合一个3-5秒的标准，其中3秒的响应时间用户会感觉网站的响应很好，我们定义为良好响应；5秒的响应时间用户还可以接受，我们定义为可忍受；响应时间在8秒以上时，用户感受基本上已经不能接受，我们定义为不可忍受。 5.2 系统用户模型 1. 系统创建1000个注册用户，test0001-test1000 2. 基准测试过程中采用非注册用户 3. 用户登录、订票、查票等业务采用注册用户 5.3 业务模型 通过登录订票网站系统我们确认以下业务模型 5.4 用户接入模型 用户接入模型：是指用户在访问系统时，以什么样的方式或者带宽来访问系统。比如拨号方式、ADSL、小区宽带或者校园网等。测试过程中可通过测试工具或者相关设备对用户接入模式进行仿真。对用户接入行为的仿真模型我们称为用户接入模型。 测试过程中为了保证在系统的最大压力下，测试系统支持并发用户的能力，因此在测试过程中采用局域网环境，所有用户接入均采用共享100MBPS或者1000MBPS方式。根据木桶原理在保证最大压力情况下系统的性能特征，同样可以支持在不足带宽情况下用户接入的情况5.5 浏览器模型 浏览器模型：是指在测试过程中模拟用户浏览器的类型、操作模式、缓存处理、非HTML 资源处理等配置方式的一个模型。浏览器模型的建立可以真实的仿真用户基于客户端访问系统的情况。 测试过程中的浏览器模型： 浏览器仿真：IE6.0、IE7.0、Firefox 浏览器缓存仿真：缓存HTML资源、每次迭代清除缓存 非HTML资源：下载非HTML资源 5.6 思考时间模型 思考时间模型：是指在测试过程中模拟人的真实操作行为，比如一个人访问应用系统的过程中，不可能是一直跟服务器进行交互，一定存在浏览、填写表单、阅读说明等行为，因此在性能测试过程中，需要通过一种机制来模拟这种行为，那么这种行为的模拟方式就是建立“思考时间模型”，通过测试脚本程序上的等待来完成用户以上行为的仿真。 测试过程中的思考时间模型：通过对一般用户行为的调查确定思考时间为5-10秒随机选取方式 6. 性能测试环境 6.1 测试环境 负载与性能测试环境图
LoadRunner性能测试实战讲解 内容介绍： 很多使用LoadRunner的测试人员经常面临两个难题：脚本开发与性能测试分析。本书就是基于帮助测试人员解决这两个问题而编写，致力于使读者学精LoadRunnner这一强大的性能测试工具。 全书共分为四部分：入门篇、基础篇、探索篇、实战篇。第一篇入门篇的内容包括第1章和第2章，着重于讲解性能测试与LoadRunner的基础理论知识。第二篇基础篇的内容包括第3章至第5章，是LoadRunner 的基本使用部分，着重讲解Virtual User Generator、Controller、Analysis的使用方法。第三篇探索篇的... 第1部分入门篇.. (1) 第1章性能测试基础知识.. 3 1.1 性能测试基本概念 (4) 1.1.1 什么是性能测试 (4) 1.1.2 性能测试应用领域 (6) 1.1.3 性能测试常见术语 (8) 1.2 全面性能测试模型 (11) 1.2.1 性能测试策略模型 (14) 1.2.2 性能测试用例模型 (17) 1.2.3 模型的使用方法 (20) 1.3 性能测试调整基础 (21) 1.4 如何做好性能测试 (24) 1.5 本章小结 (28) 第2章LoadRunner基础知识.. 29 2.1 LoadRunner简介 (29) 2.1.1 LoadRunner主要特点 (29) 2.1.2 LoadRunner常用术语 (31) 2.2 LoadRunner工作原理 (32) 2.3 LoadRunner测试流程 (33) 2.4 LoadRunner的部署与安装 (35) 2.5 本章小结 (41) 第2部分基础篇 (43) 第3章脚本的录制与开发.. 45 3.1 Virtual User Generator简介 (45)
7 分析以及监视场景 在运行过程中，可以监视各个服务器的运行情况（DataBase Server、Web Server 等）。 监视场景通过添加性能计数器来实现。这一章非常的重要，确定系统瓶颈全靠它了。 下面重点讲讲需要添加那些计数器，以及那些计数器代表什么意思。 由于Win2000 Professional、Server 以及Advanced Server 提供的计数器不完全相同，这 里我们讨论将以Server 为基准。 监视场景需要在Run 视图中设置 然后，出现添加计数器的对话框 其他的操作就和控制面板“性能”中添加性能计数器的操作一样，这里不再详细说明。本章主要说明一下各个系统计数器的含义（数据库的计数器不做重点，只是拿SQL Server2000 作为例子进行说明。因为数据库各个版本之间差异比较大，请参考您使用的数据
库系统的帮助）。 8 分析实时监视图表 这一章仅仅介绍几个最重要的图表。 Q1 事务响应时间是否在可接受的时间内？哪个事务用的时间最长？ 看Transaction Response Time 图，可以判断每个事务完成用的时间，从而可以判断出那个事 务用的时间最长，那些事务用的时间超出预定的可接受时间。 下图可以看出，随着用户数的不断增加，login 事务的响应时间增长的最快！ Q2 网络带宽是否足够? “Throughput”图显示在场景运行期间的每一秒钟，从Web Server 上接受到的数据量的值。拿这个值和网络带宽比较，可以确定目前的网络带宽是否是瓶颈。 如果该图的曲线随着用户数的增加，没有随着增加，而是呈比较平的直线，说明目前的 网络速度不能够满足目前的系统流量。 Q3 硬件和操作系统能否处理高负载? “Windows Resources”图实时地显示了Web Server 系统资源的使用情况。利用该图提供的数据，可以把瓶颈定位到特定机器的某个部件。
Official Test Report正式的测试报告 测试项目：软件性能测试 Project Information项目信息: Project Code: 项目代码 072V24S Project Phase: 项目阶段 研发 Software Version: 软件版本 V1.2 Sample Information样品信息: Sample Level: 样品类型 BMS Quantity: 数量 1 Serial Number: 序列号 020151025 Test Operation Information测试信息: Location: 地点上海博强 Start Date: 开始日期 2015-12-18 Finish Date: 完成日期 2015-12-21 Conclusion结论: Pass通过Fail 不通过 Other其它: Performed by测试: 樊佳伦Signature Date: 2015-12-22 Written by撰写: 邓文签名：日期：2015-12-23 Checked by核查: 董安庆2015-12-24 Approved by批准: 穆剑权2015-12-25
Revision History修订履历 SN 序号Report No. 报告编号 Report Version 报告版本 Contents 变更内容 Release Date 发行日期 1 BQ-72V-BMS-0007 V1.0 New release. 2015-12-25 2 BQ-72V-BMS-0007 V1.1 RTC时间再次验证2015-1-7
Loadrunner 结果分析论文 指导老师：高小雷 作者：闵光辉 学校：东莞理工学院 班级：08计算机科学与技术2班 邮箱：mingh168@https://www.doczj.com/doc/4417641815.html, Loadrunner性能测试的目的： 自动性能测试是一项规范，它利用有关产品、人员和过程的信息来减少应用程 序、升级程序或修补程序部署中的风险。自动性能测试的核心原理是通过将生产 时的工作量应用于预部署系统来衡量系统性能和最终用户体验。构造严密的性能 测试可回答如下问题： ?应用程序是否能够很快地响应用户的要求？ ?应用程序是否能处理预期的用户负载并具有盈余能力？ ?应用程序是否能处理业务所需的事务数量？ ?在预期和非预期的用户负载下，应用程序是否稳定？ ?是否能确保用户在真正使用软件时获得积极的体验？ 通过回答以上问题，自动性能测试可以量化更改业务指标所产生的影响。进而可 以说明部署的风险。有效的自动性能测试过程将有助于您做出更明智的发行决 策，并防止系统出现故障和解决可用性问题。 LoadRunner 包含下列组件： ?虚拟用户生成器用于捕获最终用户业务流程和创建自动性能测试脚本（也称为虚拟用户脚本）。 ?Controller 用于组织、驱动、管理和监控负载测试。 ?负载生成器用于通过运行虚拟用户生成负载。 ?Analysis 有助于您查看、分析和比较性能结果。 ?Launcher 为访问所有LoadRunner 组件的统一界面。 负载测试流程： 负载测试通常由五个阶段组成：计划、脚本创建、场景定义、场景执行和结果 分析。 计划负载测试：定义性能测试要求，例如并发用户的数量、典型业务流程和所需 响应时间。 创建Vuser 脚本：将最终用户活动捕获到自动脚本中。 定义场景：使用LoadRunner Controller 设置负载测试环境。 运行场景：通过LoadRunner Controller 驱动、管理和监控负载测试。 分析结果：使用LoadRunner Analysis 创建图和报告并评估性能。Loadrunner测试结果分析如下：
南昌大学软件学院 实验报告 实验名称 LoadRunner的使用 实验地点 实验日期 指导教师 学生班级 学生姓名 学生学号 提交日期 LoadRunner简介： LoadRunner 是一种适用于各种体系架构的自动负载测试工具，它能预测系统行为并优化系统性能。LoadRunner 的测试对象是整个企业的系统，它通过模拟实际用户的操作行为和实行实时性能监测，来帮助您更快的查找和发现问题。此外，LoadRunner 能支持广范的协议和技术，为您的特殊环境提供特殊的解决方案。LoadRunner是目前应用最为广泛的性能测试工具之一。 一、实验目的
1. 熟练LoadRunner的工具组成和工具原理。 2. 熟练使用LoadRunner进行Web系统测试和压力负载测试。 3. 掌握LoadRunner测试流程。 二、实验设备 PC机：清华同方电脑 操作系统：windows 7 实用工具：WPS Office，LoadRunner8.0工具，IE9 三、实验内容 （1）、熟悉LoadRunner的工具组成和工具原理 1.LoadRunner工具组成 虚拟用户脚本生成器：捕获最终用户业务流程和创建自动性能测试脚本，即我们在以后说的产生测试脚本； 压力产生器：通过运行虚拟用户产生实际的负载； 用户代理：协调不同负载机上虚拟用户，产生步调一致的虚拟用户；压力调度：根据用户对场景的设置，设置不同脚本的虚拟用户数量；监视系统：监控主要的性能计数器； 压力结果分析工具：本身不能代替分析人员，但是可以辅助测试结果的分析。 2.LoadRunner工具原理 代理（Proxy）是客户端和服务器端之间的中介人，LoadRunner 就是通过代理方式截获客户端和服务器之间交互的数据流。 ①虚拟用户脚本生成器通过代理方式接收客户端发送的数据包，
性能测试与LoadRunner基础笔试题 笔试：45分钟满分100分 选择：（共6分，3分一题） 1. To control the time between iterations in a Vuser, you will need to configure which run-time（2分） feature? A. Run Logic B. Pacing C. Think Time D. Network Speed 2. You are about to run a Debug scenario with a small number of Vusers. What type of log setting will you select to help identify and check errors in the Vuser scripts?（2分） A. Only when errors occur B. Standard log C. Extended log 判断：（共20分，2分一题） 1.集合点可以贯穿整个事务，加了集合点，整个事务都是同步运行的 2.集合点可以加在vuser_int中 3.LR可以录制单机程序 4.一个脚本中可以有多个action 5.10M的网络环境中，不能模拟20M的带宽 6.HTTPS安全协议，可以使用‘HTML-based script’模式录制 7.vuser_end中内容是不可以迭代运行的 8.file类型参数化，最多只能参数化100个 9.手动关联，查找需要关联的数据，要在Sending request中查找 10.调试lr脚本可以run step by step
LoadRunner 压力测试结果分析探讨 分析原则: 1.具体问题具体分析（这是由于不同的应用系统，不同的 测试目的，不同 的性能关注点） 2. 查找瓶颈时按以下顺序，由易到难。 服务器硬件瓶颈 网络瓶颈（对局域网，可以不考虑） 服务器操作系统 瓶颈（参数配置） 中间件瓶颈（参数配置，数据库,web 服务器等） 瓶颈（SQL 语句、数据库设计、业务逻辑、算法等） 分析的信息来源: 1.根据场景运行过程中的错误提示信息 2.根据测试结果收集到的监控指标数据 .错误提示分析 分析实例: 1. Error: Failed to connect to server Connection 分析: A 应用服务死掉。 （小用户时：程序上的问题。程序上处理数据库的问题，实际测试中多半是 服务器链接的配置问题） B 、应用服务没有死 （应用服务参数设置问题） 应用 “172.17.7.230 〃 ： [10060] Error: timed out Error: Server conn ecti on p rematurely “172.17.7.230 〃 has shut down the
对应的Apache 和tomcat 的最大链接数需要修改，如果连接时收到 connection refused 消息，说明应提高相应的服务器最大连接的设置，增加幅 度要根据实际情况和服务器硬件的情况来定，建议每次增加 25%! C 数据库的连接 （数据库启动的最大连接数（跟硬件的内存有关） ） D 我们的应用程序spring 控制的最大链接数太低 2. Error: Page download timeout (120 seconds) has expired 分析： 实际测试时有些资源需要请求外网，而我们的测试环境是局域网环境 3. Error “http://172.17.7.230/Home.do 分析： A 脚本设计错误，造成页面异常。服务器有响应! B 、并发数过大，造成服务器响应延迟。 4. Error page “text=xxxxx ” 分析： A 脚本设计问题，例如，前一脚本修改了某些内容，造成后面的脚本访问 异常。 B 、不确定因素，有时候回放正常的脚本，一放到场景中就出现这样的错误。 只能反复修改脚本! ．监控指标数据分析 1．Vusers 数 A 、 应用服务参数设置太大导致服务器的瓶颈 B 、 页面中图片太多 C 、 在程序处理表的时候检查字段太大多 D 、
LoadRunner性能测试软件的基本使用步骤 一. 1、测试脚本录制 1.1录制前准备工作 在录制脚本前需检查压测环境的整体功能是否正确，待测部分的功能是否正确，只有确定功能正确后才可进行压测。 1.2录制及调试脚本 在准备工作OK后，进行脚本的录制，具体过程如下： 打开“开始>程序>MercuryLoadRunner>MercuryLoadRunner”测试脚本录制； 2、点击“Create/EdirScripts”，也可在“File”下选择New 新建。 3、选择Web(HTTP/HTML)协议，我们测试的是B/S模式，采用的是Web协议，选择后点【OK】按钮。 4、点击界面中的录制按钮，这个表示开始录制脚本点。 录制前，如果已经打开待测页面的话，建议关闭该页面。点【OK】后，同时会出现这表示现在已经开始录制。 5、所有操作完成后，点击中停止按钮，停止录制，页面将自动关闭，返回到loadrunner录制界面，将在界面中显示录制脚本代码，保存录制的脚本。 6、调试代码并进行参数化 录制后的代码需要进行调试才可用于压测，调试的办法就是进行
回放操作，如果回放过程无错误，运行结果也正确的话，则可用于压测。 二．设计测试场景 在脚本录制完成，调试通过后，可以进行测试场景的设计。 1.打开“开始>程序>MercuryLoadRunner >MercuryLoadRunner” 2.点击的RunLoadTests；在新建场景的窗口，选择一种场景类型。 3.选择要进行场景设计的脚本，若没有出现需要对应的脚本，可点击Browse查找后添加进来，选择好脚本后，点add则可加入到右边的窗口中然后点【OK】。 4.显示的是脚本的路径与并发数个数，根据测试方案中的并发 数可更改此处的并发数。 Eg：假如我们设计的场景是每15秒增加2个，所有并发数增加完后持续运行5分钟，5分钟运行结束后，每30秒减少5个并发。 5.再点击页面右下角的“Run-timeSettings” 。 6.一切设置OK后，点击运行测试场景。 三．测试结果分析 1.场景执行结束后可以，使用loadrunner自带的分析工具进行结果分析。 2.在菜单栏中选择打开，找到要分析的场景执行结果，点【打开】即可，还可以直接在场景运行结束后，点击Controller菜单栏
具体实例教你如何做LoadRunner结果分析 文本Tag：测试工具性能测试LoadRunner 【IT168 技术文档】1.前言: LoadRunner 最重要也是最难理解的地方--测试结果的分析.其余的录制和加压测试等设置对于我们来讲通过几次操作就可以轻松掌握了.针对Results Analysis 我用图片加文字做了一个例子,希望通过例子能给大家更多的帮助.这个例子主要讲述的是多个用户同时接管任务,测试系统的响应能力,确定系统瓶颈所在.客户要求响应时间是1 个人接管的时间在5S 内. 2.系统资源: 2.1 硬件环境： CPU：奔四2.8E 硬盘：100G 网络环境：100Mbps 2.2 软件环境： 操作系统：英文windowsXP 服务器：tomcat 服务 浏览器：IE6.0 系统结构：B/S 结构 3.添加监视资源
下面要讲述的例子添加了我们平常测试中最常用到的 一些资源参数.另外有些特殊的资源暂时在这里不做讲解了.我会在以后相继补充进来。 Mercury Loadrunner Analysis 中最常用的5 种资源. 1. Vuser 2. Transactions 3. Web Resources 4. Web Page Breakdown 5. System Resources 在Analysis 中选择“Add graph”或“New graph”就可以看到这几个资源了.还有其他没有数据的资源,我们没有让它显示. 如果想查看更多的资源,可以将左下角的display only graphs containing data 置为不选.然后选中相应的点“open graph”即可. 打开Analysis 首先可以看的是Summary Report.这里显示了测试的分析摘要.应有尽有.但是我们并不需要每个都要仔细去看.下面介绍一下部分的含义： Duration(持续时间)：了解该测试过程持续时间.测试人员本身要对这个时期内系统一共做了多少的事有大致的熟 悉了解.以确定下次增加更多的任务条件下测试的持续时间。
性能测试指标参考 目录 1术语 (2) 1.1响应时间 (2) 1.2并发用户数 (2) 1.3在线用户数 (2) 1.4吞吐量 (3) 2 Vuser图 (3) 2.1 “运行Vuser ”图（Running Vusers） (3) 2.2 “集合”图(Rendezvous) (3) 3 错误图 (3) 3.1 “每秒错误数（按描述）”图（Error Statistics） (3) 4 事务图 (4) 4.1 “平均事务响应时间”图（Average Transaction Response Time） (4) 4.2“负载下的事务响应时间”图（Running Vuser –Average Transaction Response Time） (4) 4.3“页面细分”图（Web Page Diagnostics图） (5) 4.4“每秒事务数”（Transactions per second 简称：TPS） (6) 5 Web资源图 (6) 5.1“每秒点击次数”图（Hits per Second） (6) 5.2“吞吐量”图（Throughput） (6) 6 系统资源图 (6) 6.1 LoadRunner下监控的UNIX资源指标 (6) 6.1.1平均负载（Average load） (6) 6.1.2 CPU利用率（CPU utilization） (7) 6.1.3 每秒传入的包数（Paging rate） (7) 6.2使用NMON工具监控Linux资源 (7) 6.2.1 系统资源汇总（SYS_SUMM） (7) 6.2.2 磁盘资源汇总（DISK_SUMM） (8) 6.2.3 内存资源（MEM） (8) 7 网络监控器图 (9) 7.1 “网络延迟时间”图（Network Delay Time） (9) 8 数据库服务器资源图 (10) 8.1 Oracle服务器监控度量 (10) 8.1.1 添加Oracle自定义计数器 (11) 8.1.2 性能分析工具Statspack所提供的性能分析指标 (15) 8.2 SQL Server服务器监控度量 (18)
实验三：性能测试与LoadRunner（4学时） 一、实验目的 1、了解Load Runner负载测试工具的安装过程，进行安装实验。 2、了解Load Runner负载测试工具的用途和简单的操作。 3、掌握Load Runner负载测试工具测试过程。 4、能够使用Load Runner负载测试工具进行简单的测试工作。 二、实验环境 操作系统：windows 2000 XP + SP2 应用系统：LoadRunner9.5+负载测试工具 三、实验过程： LoadRunner 是HP公司开发一款成熟的性能测试工具，LoadRunner 作为性能测试的实现者，涉及性能测试流程、性能测试技术和软件体系架构等众多方面的知识点。 性能测试的基准大体有以下几方面： —响应时间 从应用系统发出请求开始，到客户端接收到最后一个字节数据为止所消耗的时间。合 理的响应时间取决于实际的用户需求。 —并发用户数 一般是指同一时间段内访问系统的用户数量。 —吞吐量 指单位时间内系统处理的客户请求数量。 —性能计数器 描述服务器或操作系统性能的一些数据指标，比如Windows 系统资源管理器。 ------------------------------------------------------------------------------- 本次实验课是针对LoadRunner（以下简称LR）的使用，我们将采用LR 自带的HP WEBTours 应用程序来进行熟悉。 1.启动示例程序 在开始程序中启动LoadRunneràsamplesàWebà启动Web 服务器,如下图 启动后在屏幕右下角会出现如下标识 :
最新版LoadRunner性能测试实战 内容介绍： 很多使用LoadRunner的测试人员经常面临两个难题：脚本开发与性能测试分析。本书就是基于帮助测试人员解决这两个问题而编写，致力于使读者学精LoadRunnner这一强大的性能测试工具。 全书共分为四部分：入门篇、基础篇、探索篇、实战篇。第一篇入门篇的内容包括第1章和第2章，着重于讲解性能测试与LoadRunner的基础理论知识。第二篇基础篇的内容包括第3章至第5章，是LoadRunner 的基本使用部分，着重讲解Virtual User Generator、Controller、Analysis的使用方法。第三篇探索篇的... 第1部分入门篇.. (1) 第1章性能测试基础知识.. 3 1.1 性能测试基本概念 (4) 1.1.1 什么是性能测试 (4) 1.1.2 性能测试应用领域 (6) 1.1.3 性能测试常见术语 (8) 1.2 全面性能测试模型 (11) 1.2.1 性能测试策略模型 (14) 1.2.2 性能测试用例模型 (17) 1.2.3 模型的使用方法 (20) 1.3 性能测试调整基础 (21) 1.4 如何做好性能测试 (24) 1.5 本章小结 (28) 第2章LoadRunner基础知识.. 29 2.1 LoadRunner简介 (29) 2.1.1 LoadRunner主要特点 (29) 2.1.2 LoadRunner常用术语 (31) 2.2 LoadRunner工作原理 (32) 2.3 LoadRunner测试流程 (33) 2.4 LoadRunner的部署与安装 (35) 2.5 本章小结 (41) 第2部分基础篇 (43) 第3章脚本的录制与开发.. 45
性能测试项目名称 拟制日期 审核日期 批准日期
修订记录
目录 介绍 (4) 1 目的 (4) 2 总览 (4) 表 1.1 –软件性能测试计划内容 (4) 3 范围 (4) 性能测试方法 (5) 4 负载测试流程 (5) 4.1 系统分析 (5) 4.1.1 创建虚拟用户脚本 (5) 4.1.2 创建负载测试场景 (5) 4.1.3 测试用例执行和性能监控 (5) 4.1.4 分析结果 (5) 5 远景目标和近期目标 (5) 业务流程&测试用例 (5) 6 业务流程 (6) 6.1.1 高容量/高负载流程 (6) 6.1.2 低容量/低负载流程 (6) 7 数据准备 (6) 8 LoadRunner 事务（Transactions） (6) 9 LoadRunner 脚本（Scripts） (6) 10 Load Runner 场景（Scenarios） (6) 11 LoadRunner 监控器（Monitors） (7) 11.1 具体的监控器 (7) 11.2 具体的监控器 (7) 负载测试需求 (7) 12 Checklist (7) 13 测试入口标准 (8) 14 测试结束标准 (8) 应用程序环境 (8) 15 应用程序软件环境 (8) 16 应用程序硬件环境 (8) 17 LoadRunner 环境 (8) 测试结果和版本管理 (9) 18 缺陷/版本管理 (9) 19 发现 (9) 20 详细测试结果 (9) 20.1 场景1 (9)
介绍 1 目的 目的介绍 2 总览 本文档表格中第二部分到第七部分为重要部分。 表 1.1 –软件性能测试计划内容 项目序号名字内容项目内容 1介绍 2性能测试方法 3业务流程&测试用例 4负载测试需求 5应用程序开发环境 6Load Runner 环境 7测试结果 & 版本管 理 3 范围 计划适用范围. 软件需求规格说明书(Software Requirements Specifications - SRS) 软件详细设计文档（Software Detail Design - SDD) 软件测试计划 (SoftWare Test Plan - STP) White Paper: Load Testing to Predict Web Performance. Mercury Interactive Corp.
LoadRunner测试结果分析LoadRunner测试结果分析之我见一 LoadRunner生成测试结果并不代表着这次测试结果的结束，相反，这次测试结果的重头戏才刚刚开始。如何对测试结果进行分析，关系着这次测试的成功与否。网上关于LoadRunner测试结果如何分析的介绍相当匮乏，在总结他人的观点和自己的实验体会基础上来介绍如何进行LoadRunner测试结果分析。 1. LoadRunner测试结果分析的第一步应该是查看分析综述（Analysis Summary），其包括统计综述（Statistics Summary）、事务综述（Transaction Summary）、HTTP响应综述（HTTP Responses Summary）三部分。在统计综述中查看Total Errors的数量，HTTP响应综述中查看HTTP 404数量，若数值相对较大（HTTP 404则相对于HTTP 200），则说明系统测试中出错较多，系统系能有问题；另外查看事务的平均响应时间和其90%的事务平均响应时间，若时间过长，超过测试计划中的要求值，则说明系统的性能不满足我们的要求。 2.第二步对LoadRunner测试结果图进行分析，首先对事务综述（Transaction Summary）进行分析，该图可以直观地看出在测试时间内事务的成功与失败情况，所以比第一步更容易判断出被测系统运行是否正常。 3.接着分析事务平均响应时间（Average Transaciton Response Time），若事务平均响应时间曲线趋高，则说明被测系统处理事务的速度开始逐渐变慢，即被测系统随着运行时间的变化，整体性能不断下降。当系统性能存在问题时，该曲线的走向一般表现为开始缓慢上升，然后趋于平稳，最后缓慢下降。原因是：被测系统处理事务能力下降，事务平均响应时间变长，在曲线上表现为缓慢上升；而并发事务达到一定数量时，被测系统无法处理多余的事务，此时曲线变现为趋于平稳；当一段时间后，事务不断被处理，其数量减少，在曲线上表现为下降。如果被测系统没有等待机制，那么事务响应时间会越来越长，最后系统崩溃。
LoadRunner性能测试基础知识问答 作者: aovenus , 发布于2011-06-24 Q1：什么是负载测试？什么是性能测试？ A1：负载测试是通过逐步增加系统负载，测试系统性能的变化，并最终确定在满足性能指标的情况下，系统所能承受的最大负载量的测试，例如，访问一个页面的响应时间规定不超过1秒，负载测试就是测试在响应时间为1秒时，系统所能承受的最大并发访问用户的数量。 性能测试：指在一定的约束条件下（指定的软件、硬件、网络环境等），确定系统所能承受的最大负载压力。 Q2.性能测试包含了哪些测试（至少举出3种） A2：性能测试包含负载测试、压力测试、大数据量测试、疲劳强度测试等。 Q3.简述性能测试的步骤 Q4.简述使用Loadrunner的步骤 A4：制定性能测试计划—>开发测试脚本—>设计测试场景—>执行测试场景—>监控测试场景—>分析测试结果
Q5.什么时候可以开始执行性能测试？ A5：功能测试通过；一般需要进行性能测试的系统，都是用户量比较大、业务使用比较频繁、比较重要的功能模块。 Q6.LoadRunner由哪些部件组成？ A6：主要有三部分组成： Q7.你使用LoadRunner的哪个部件来录制脚本？ A7：使用Virtual User Generator录制测试脚本 Q8.LoadRunner的哪个部件可以模拟多用户并发下回放脚本？ A8：LoadRunner的Controller组件。 Q9.什么是集合点？设置集合点有什么意义？Loadrunner中设置集合点的函数是哪个？ A9：在性能测试过程中，需要模拟大量用户在同一时刻，访问系统并同时
软件性能测试需要学什么 随着互联网IT产业的蓬勃发展，软件测试的行业也日趋火热，更多人的转向了软件测试行业，当然更多的问题也亟待解决，比如软件测试自学教程视频内容？软件测试视频教程？软件测试培训入门教程？软件测试培训学习思路？鉴此千锋教育不惜教育成本，全面推出软件测试课程，与之相辅的视频课程也耀世而生。 软件测试（Software Testing），描述一种用来促进鉴定软件的正确性、完整性、安全性和质量的过程。换句话说，软件测试是一种实际输出与预期输出之间的审核或者比较过程。软件测试的经典定义是：在规定的条件下对程序进行操作，以发现程序错误，衡量软件质量，并对其是否能满足设计要求进行评估的过程。 千锋教育软件测试的学习，主要分为四大板块： 一、应用程序通用测试技术 1.软件测试的历史 2.软件测试基本概念与意义 3.软件测试过程模型 4.常用软件测试方法
5.软件测试生命周期与流程 6.软件测试计划方案编写 7.软件测试需求分解与跟踪 8.黑盒测试用例设计方法 9.白盒测试用例设计方法 10.缺陷识别与缺陷跟踪系统 11.测试评审与风险分析 12软件测试总结与过程度量 通过本课程的学习，掌握软件测试的意义与重要性，掌握软件的通用测试技术与方法，掌握软件测试各阶段工作的主要流程与方法，具备从业的基本资格 二、应用程序全栈测试技术 1.全栈测试概述 2.WEB测试方法 3.UI测试方法 4.兼容性测试方法 5.安全测试技术 6.易用性与其他指标测试方法
通过学习本课程，熟悉全栈软件测试方法，掌握除功能测试外的其他全栈测试技术 三、自动化测试技术 1.自动化测试基础 2.自动化测试框架构建 3.HP UFT工具介绍 4.HP UFT脚本开发与增强 5.VBScript语言 6.HP UFT测试对象集合 7.Selenium工具介绍 8.Selenium IDE详解 9.Selenium脚本开发 10.Selenium测试实战 在本门课程中重点介绍自动化测试技术，掌握两种主流测试工具UFT 与Selenium的使用，掌握自动化测试框架的构建方法 四、性能测试技术 1.性能测试基础 2.初识HP LoadRunner 3.HP LoadRunner脚本录制与调试 4.HP LoadRunner场景设计与监控 5.HP LoadRunner测试结果分析与调优 6.Jmeter工具介绍
Loadrunner分析结果图说明 1、Running Vusers图 使用Vuser 图可以确定方案，执行期间Vuser 的整体行为。 X 轴表示从方案开始运行以来已用的时间。Y 轴表示方案中的Vuser 数。 Vuser-Rendezvous 图主要反映Vuser 是在什么时候集合在这个点上,又是怎样的一个被释放的过程. 图中可以看到在1分4秒的地方50个用户全部集中到达集合点，持续了5分48秒开始释放用户，整个过程持续了6分钟。 2、Hits per Second图 “每秒点击次数”，即使运行场景过程中虚拟用户每秒向Web服务器提交的HTTP请求数。 通过它可以评估虚拟用户产生的负载量，如将其和“平均事务响应时间”图比较，
可以查看点击次数对事务性能产生的影响。通过对查看“每秒点击次数”，可以判断系统是否稳定。系统点击率下降通常表明服务器的响应速度在变慢，需进一步分析，发现系统瓶颈所在。 3、Throughput图 “吞吐率”显示的是场景运行过程中服务器的每秒的吞吐量。其度量单位是字节，表示虚拟用在任何给定的每一秒从服务器获得的数据量。 可以依据服务器的吞吐量来评估虚拟用户产生的负载量，以及看出服务器在流量方面的处理能力以及是否存在瓶颈。 X 轴表示从方案开始运行以来已用的时间。Y 轴表示服务器的吞吐量（以字节为单位）。 “吞吐率”图和“点击率”图的区别： “吞吐率”图，是每秒服务器处理的HTTP申请数。 “点击率”图，是客户端每秒从服务器获得的总数据量。
4、Transaction Summary图 对事务进行综合分析是性能分析的第一步，通过分析测试时间内用户事务的成功与失败情况，可以直接判断出系统是否运行正常。 5、Average Transaction Response Time图 “事务平均响应时间”显示的是测试场景运行期间的每一秒内事务执行所用的平均时间，通过它可以分析测试场景运行期间应用系统的性能走向。 例：随着测试时间的变化，系统处理事务的速度开始逐渐变慢，这说明应用系统随着投产时间的变化，整体性能将会有下降的趋势。 可以将事务平均响应时间图与“正在运行的Vuser”图进行比较，了解正在运行的Vuser 的数目对事务执行时间产生的影响。例如：如果平均事务响应时间图显示执行时间逐渐改善，则 可以将其与“正在运行的Vuser”图进行对比，看执行时间是否因为Vuser 负载减少而得到改