精通软件性能测试与loadrunner实战

《精通软件性能测试与loadrunner实战》由会员分享，可在线阅读，更多相关《精通软件性能测试与loadrunner实战（97页珍藏版）》请在装配图网上搜索。

1、最新版LoadRunner性能测试实战内容介绍：很多使用LoadRunner的测试人员经常面临两个难题：脚本开发与性能测试分析。本书就是基于帮助测试人员解决这两个问题而编写，致力于使读者学精LoadRunnner这一强大的性能测试工具。全书共分为四部分：入门篇、基础篇、探索篇、实战篇。第一篇入门篇的内容包括第1章和第2章，着重于讲解性能测试与LoadRunner的基础理论知识。第二篇基础篇的内容包括第3章至第5章，是LoadRunner的基本使用部分，着重讲解Virtual User Generator、Controller、Analysis的使用方法。第三篇探索篇的.第1部分 入门篇. 1第

2、1章 性能测试基础知识. 31.1 性能测试基本概念. 41.1.1 什么是性能测试. 41.1.2 性能测试应用领域. 61.1.3 性能测试常见术语. 81.2 全面性能测试模型. 111.2.1 性能测试策略模型. 141.2.2 性能测试用例模型. 171.2.3 模型的使用方法. 201.3 性能测试调整基础. 211.4 如何做好性能测试. 241.5 本章小结. 28第2章 LoadRunner基础知识. 292.1 LoadRunner简介. 292.1.1 LoadRunner主要特点. 292.1.2 LoadRunner常用术语. 312.2 LoadRunner工作原理

3、. 322.3 LoadRunner测试流程. 332.4 LoadRunner的部署与安装. 352.5 本章小结. 41第2部分 基础篇. 43第3章 脚本的录制与开发. 453.1 Virtual User Generator简介. 453.1.1 VuGen录制原理. 463.1.2 VuGen功能简介. 483.1.3 如何选择协议. 493.2 VuGen录制功能详解. 503.2.1 录制参数设置. 503.2.2 脚本录制与创建事务. 573.2.3 回放与调试脚本. 613.2.4 脚本录制的基本原则. 633.3 修改虚拟用户脚本. 643.3.1 参数化功能. 643.3

4、.2 深入集合点. 713.3.3 巧用检查点. 723.3.4 关联. 783.4 配置虚拟用户脚本. 803.5 两个常用函数介绍. 843.6 本章小结. 86第4章 场景的创建与执行. 874.1 Controller简介. 874.2 场景类型介绍. 884.2.1 手动测试场景. 884.2.2 面向目标的测试场景. 904.3 测试场景设计. 934.3.1 配置测试脚本. 934.3.2 配置Generator 944.3.3 配置Schedule. 954.3.4 集合点配置. 994.3.5 IP Spoofer配置. 1004.3.6 其他设置场景. 1064.4 执行测

5、试场景. 1084.4.1 启动测试场景. 1084.4.2 控制用户与用户组. 1084.4.3 查看场景与用户状态. 1094.4.4 控制集合点. 1104.4.5 查看运行数据图. 1104.5 监控系统资源. 1114.5.1 监控Windows系统资源. 1124.5.2 监控Linux/Unix系统资源. 1144.6 本章小结. 121第5章 性能测试结果分析. 1235.1 如何分析性能测试结果. 1245.1.1 性能分析基础知识. 1255.1.2 Analysis使用基础. 1275.1.3 一个视频网站例子. 1355.2 如何从分析图中发现问题. 1485.2.1

6、虚拟用户图. 1485.2.2 事务图. 1515.2.3 Web资源图. 1605.2.4 网页细分图. 1665.2.5 小结. 1795.3 分析图的处理方法. 1795.3.1 修改默认配置. 1805.3.2 合并分析图. 1875.3.3 自动关联. 1885.3.4 场景运行比较. 1915.4 Analysis分析报告. 1935.4.1 事务活动报告（Activity Reports）. 1935.4.2 事务性能报告（Performance Reports）. 1965.4.3 HTML与Word报告. 1995.5 本章小结. 206第3部分 探索篇. 209第6章 用V

7、isual C+增强虚拟用户. 2116.1 认识LoadRunner动态链接库的调用功能. 2116.1.1 动态链接库调用功能简介. 2116.1.2 动态链接库调用功能适用范围. 2126.2 创建与调用动态链接库. 2126.2.1 用Visual C+创建Dll 2126.2.2 Dll调用方法. 2156.2.3 载入头文件方法. 2176.2.4 Dll调用需注意的问题. 2206.3 UDP发包应用案例. 2226.3.1 测试内容简介. 2226.3.2 测试程序设计. 2226.3.3 虚拟用户脚本. 2236.3.4 测试场景设置. 2246.3.5 测试结果分析. 22

8、56.4 本章小结. 226第7章 深入Java虚拟用户. 2277.1 认识Java虚拟用户. 2277.1.1 Java虚拟用户协议. 2277.1.2 Java虚拟用户适用范围. 2307.1.3 脚本开发环境配置. 2317.2 Java脚本开发基础. 2347.2.1 Java虚拟用户开发基础. 2347.2.2 LoadRunner的Java API. 2437.3 Java算法测试案例. 2457.4 本章小结. 260第8章 深入.NET虚拟用户. 2618.1 认识.NET虚拟用户. 2618.1.1 .NET虚拟用户适用范围. 2618.1.2 安装与配置.NET插件. 2

9、628.2 创建.NET虚拟用户. 2648.2.1 创建虚拟用户项目. 2648.2.2 参数、集合点、事务. 2668.3 网站视频性能测试应用案例. 2718.3.1 创建自定义的播放器类. 2728.3.2 创建抽象虚拟用户类. 2768.3.3 创建抽象并发测试类. 2828.3.4 创建自定义虚拟用户脚本. 2848.3.5 创建LoadRunner .NET虚拟用户. 2878.3.6 案例总结. 2908.4 本章小结. 290第9章 LoadRunner特殊协议应用. 2919.1 Windows Sockets协议应用. 2919.1.1 录制Windows Sockets

10、协议脚本. 2929.1.2 增强Windows Sockets协议脚本. 2949.2 WAP协议应用. 2989.3 Web Services协议应用. 3029.3.1 Web Services协议简介. 3029.3.2 录制Web Services协议脚本. 3039.4 FTP协议应用. 3129.5 本章小结. 317第4部分 实战篇. 319第10章 电子商务平台测试案例. 32110.1 GBE测试项目简介. 32110.1.1 项目背景信息. 32110.1.2 系统功能简介. 32210.1.3 项目测试计划. 32310.2 性能测试规划与设计. 32310.2.1 性

11、能测试的种类、范围、目标. 32410.2.2 人力资源、进度安排. 32510.2.3 测试环境需求. 32510.2.4 选择测试工具. 32710.2.5 用户场景分析与设计. 32810.2.6 性能测试计划. 33310.2.7 测试用例设计. 33410.2.8 其他事项. 34110.3 性能测试准备. 34110.3.1 测试环境. 34110.3.2 系统使用培训. 34210.3.3 测试数据. 34310.3.4 虚拟用户脚本. 34610.4 测试的实施与控制. 34910.4.1 设计测试用例场景. 34910.4.2 执行测试用例场景. 35110.4.3 进度与变

12、更控制. 35910.5 测试结论与建议. 36010.5.1 测试结果综述. 36010.5.2 系统性能优化建议. 36110.5.3 风险分析. 36210.6 本章小结. 362附录A LoadRunner性能测试常见问题. 365附录B LoadRunner性能测试模板. 373B.1 性能测试计划模板. 373B.1.1 项目背景简介. 373B.1.2 测试方案简介. 373B.1.3 测试环境与资源. 373B.1.4 项目里程碑. 374B.1.5 技能培训计划. 374B.1.6 风险分析. 374B.1.7 计划结束标准. 374B.2 性能测试用例模板. 374B.2.

13、1文档介绍. 374B.2.2 测试需求分析. 375B.2.3 性能测试用例. 375B.3 性能测试报告模板. 380B.3.1 基本信息. 380B.3.2 测试环境描述. 381B.3.3 性能测试用例执行分析. 381B.3.4 测试结果综合分析及建议. 381B.3.5 测试经验总结. 381后 记. 383前言 在作者的另一作品Web性能测试实战中，曾经提到过“软件亚健康”这个概念。现在，亚健康不但威胁着IT人的生活质量，也威胁很多应用软件的性能。为此，在Web性能测试实战一书中，作者提出了“全面性能测试模型”，期望能够成为解决软件亚健康问题的一剂“良药”。“全面性能测试模型”包

14、含了测试策略制定、测试用例设计、模型使用方法三部分内容，基本覆盖了性能测试规划和设计的相关内容，为开展性能测试提供了一种可行的方案。借助本模型，软件开发和测试人员可以更好的组织与规划性能测试，避免在项目后期遭遇性能问题的被动局面。不过要想做好性能测试，仅有性能测试模型还是远远不够的，因为还缺少像LoadRunner这样令性能测试工作如虎添翼的性能测试利器。本书将和读者一起深入LoadRunner的性能测试世界，探讨在企业的性能测试项目中如何应用它来发现应用系统存在的性能问题。LoadRunner在性能测试中的地位对于很多使用LoadRunner的测试人员而言，性能测试工作中最大的障碍就是测试脚

15、本开发与测试结果分析，这导致很多测试人员忽略了测试规划与设计的重要性，反而认为能开发测试脚本、运行测试场景、分析测试结果就算做好性能测试了。要想做好性能测试，首先应该把重心放在测试的规划与设计上，尤其要注重测试用例的设计，仅仅能写测试程序与运行测试脚本是远远不够的。诸如LoadRunner等测试工具仅仅是性能测试的执行与分析工具，它们应该服从于测试设计人员的意志。测试工具的使用属于测试人员的基本功，应该在开展性能测试工作前修炼好。只有好的测试用例或者测试场景才能发现系统的问题，这才是性能测试的本质所在。性能测试分析同样依赖于前面工作的输出结果，不是随便一个测试结果就能发现问题的。所谓“万丈高楼

16、平地起”，性能分析的准确性同样取决于此前所做的设计与实施等“地基”是否可靠。可以说，性能测试分析仅仅是百米赛跑的最后二十米而已。当然，这并不是说性能测试分析不重要，因为“最后冲刺的二十米没有跑好”，前面工作做的再好也是徒劳的。因此不难理解，性能测试分析工作开展的根基就是前面测试场景执行的结果。要想保证性能测试分析的结论是正确的，则测试结果数据首先就应该是正确的，而这也意味着测试场景以及测试执行过程都应该是正确的。实际上，性能测试从始至终都应该是相当严谨的一项工程，各个阶段的工作环环相扣，性能测试工程师应该认真对待各个阶段的工作。如果一味地追求找出系统瓶颈，无疑是舍本逐末的做法。因此，在性能测试

17、工作中首先要做好性能测试的规划与设计工作，然后再借助LoadRunner的强大功能来发现系统存在的问题。如何通过本书学习LoadRunner首先应该弄清楚学习LoadRunner的目的，那就是在项目的性能测试中应用LoadRunner来发现系统的性能问题。因此，仅仅会用LoadRunner还远远不够，这也是为什么很多培训班出来的学员虽然把工具用的非常熟练，但是仍然不能做好性能测试工作。学好LoadRunner的标准是真正能够把LoadRunner应用到实际项目中去，这就要求学习LoadRunner的同时一定要学好性能测试相关知识。本书的第1章即为基本的性能测试知识，读者需要认真体会这些内容，建

18、议在学习后面的内容时，经常翻阅本章的内容。如果要学习更多的性能测试规划与设计的知识以及性能测试案例，建议读者参考本书的姊妹篇Web性能测试实战。本书的第2章是LoadRunner的简介部分，读者需要通过本章了解LoadRunner的工作原理、测试流程、部署与安装等内容，尤其要掌握图2-1所示的LoadRunner工作原理，这是用LoadRunner开展工作的基础。本书的第3章、第4章、第5章分别讲解了LoadRunner的Virtual User Generator、Controller、Analysis。这三大组件分别负责脚本的录制与开发、场景的创建与执行、测试结果分析工作。用LoadRun

19、ner来开展性能测试，必须要掌握这三大组件的使用。如果连基本的工具都没有用好，很难正确地执行设计好的测试用例，更不用说根据结果来分析系统的瓶颈了。在第35章中，详细探讨了LoadRunner各个组件的使用细节，但是这还远远不够，尤其对于那些只会录制或者简单修改录制结果的测试人员！学习这三章的内容时，最好的方法是结合LoadRunner的联机帮助文档，这样可以学习到更多的内容。学习完第35章后，可能还有一些读者会问：“我还是不会自己写测试脚本，很多协议仍然不能进行测试怎么办？”碰到这种情况就需要补习自己的开发知识了。开发知识应该分两个方面来学习：一是面向对象基础知识的学习，二是开发语言的学习。很

20、多人可能会认为面向对象基础知识比较通用，相对容易学习；而开发语言种类繁多，不知道如何入手。根据作者的经验，这两个方面应该结合起来进行：面向对象是现在主流开发语言的灵魂，一起学习可以互相促进。具体做法就是选择C+、Java、C#等一种主流语言来学习，只要这门语言是自己所在公司的主流语言即可。当学会面向对象基础和一门语言后，再去学习其它的语言将会非常容易。具有一定的开发能力后，就可以开始本书探索篇第69章的学习。这四章是LoadRunner的探索篇，讲解了在LoadRunner中如何应用C+、Java、C#语言进行开发以及一些特殊的脚本协议。相信通过前面9章的学习，读者已经掌握LoadRunner

21、的精髓了。不过本书不是一本“LoadRunner使用百科大全”，接下来就需要读者自己不断地应用与探索LoadRunner了，逐步完成成为一个LoadRunner高手的蜕变过程。如何学习本书的性能测试案例本书在第10章中，花了很大的篇幅介绍了一个电子商务平台的性能测试案例，目的不是为了介绍如何测试电子商务系统，而是让读者在掌握前面技能的基础上，更加深入地体会在项目中如何通过LoadRunner来实施性能测试。因此，案例的业务并不重要，读者也没有必要深究具体的细节。通过本案例，能清晰地了解了能测试的整个过程就已经达到了目的。本书案例的学习重点在以下几个方面：l 借助案例体会“全面性能测试模型”在G

22、BE项目中的应用；l 学习性能测试规划与设计中的需求分析过程，例如测试环境需求、人力资源；l 学习性能测试规划与设计中的测试场景分析与设计、测试用例设计；l 学习如何做好性能测试实施前的准备工作；l 测试执行过程的进度与变更控制；l 一些分析性能问题的过程。关于性能测试案例更多的内容，读者可以阅读Web性能测试实战中的案例部分。关于本书本书的主旨在于让读者学会LoadRunner的应用，并能在此基础上自行探索性能测试世界。本书共分为四部分：入门篇、基础篇、探索篇、实战篇。第一部分：入门篇，包括第1章和第2章，着重于讲解性能测试与LoadRunner的基础理论知识。在第1章中，讲解了性能测试基本

23、概念、全面性能测试模型、性能测试调整等基础的性能测试理论知识；第2章则介绍了LoadRunner的特点与术语、工作原理、测试流程、部署与安装等内容。第二部分：基础篇，包括第3章至第5章，着重讲解LoadRunner三大组件的使用，是LoadRunner的基本使用部分。在第3章中，主要讲解如何在Virtual User Generator中完成代码的录制与开发；第4章讲解如何在Controller中创建与执行场景；第5章中讲解如何结合Analysis来分析性能测试结果。第三部分：探索篇，包括第6章至第9章，着重讲解LoadRunner的高级应用。第6章讲解如何用Visual C+来增强虚拟用户；

24、第7章深入探索了Java虚拟用户；第8章深入探索了.NET虚拟用户；第9章则讲解了Socket虚拟用户的相关知识。第四部分：实战篇，即第10章，结合案例来讲解在具体项目中如何应用LoadRunner来完成性能测试工作。在第10章中，通过真实的性能测试实例，向读者展示了如何在项目中完成性能测试的整体规划与设计、测试的准备与实施、测试结果分析等工作。致谢感谢广大读者对Web性能测试实战一书的支持，读者的支持是作者写作的真正动力。正是一年来因为大家对Web性能测试实战的肯定才促使我完成本书的写作工作；感谢博文视点周筠老师对本书的支持，周老师对我这个新人一直给予很大的鼓励；感谢电子工业出版社博文视点资

25、讯有限公司的陈元玉编辑，她是本书的责任编辑；感谢师兄王玉亭，他再次为本书提供了很多素材；感谢同事关晓培、周雪松、李熠，他们为本书提供了很多素材；感谢电子工业出版社为本书辛勤付出的所有朋友们；特别感谢夫人小姬，她通篇审校了本书并润色了那些难于理解的句子，特别是她对我在公司的日常工作和编写工作的支持，因为本书占据了大量可以陪她的时间；最后要感谢自己的父母和老师，能写出本书是父母和老师多年教育的结果。软件在性能方面的“亚健康”问题一直伴随着国内很多企业的软件产品而存在。早期由于多数软件应用系统在企业中得不到有效的推广应用，因此用户往往会忽略自己在性能方面的需求。而现在软件几乎渗透到人们工作与生活的各

26、个方面，因而软件的性能开始得到越来越多的重视。随着软件工程技术、软件开发方法和软件开发工具的发展，一方面使人们可以快速开发更加复杂的应用，另一方面也使开发出的软件规模越来越庞大，架构越来越复杂。随之而来的是软件性能问题也越来越多，最终导致很多软件系统由于性能方面存在问题而停止使用，给软件公司以及客户都带来了一定的损失。因此，解决软件性能问题是十分必要的一项工作中，对于企业自身以及客户都具有重要的现实意义。在绍英的上一本著作Web性能测试实战中，为接近软件性能问题提出了“全面性能测试模型”，以期成为解决软件亚健康问题的一剂良药。“全面性能测试模型”包含了性能测试策略制定、测试用例设计、模型使用方

27、法三部分内容，覆盖了性能测试规划和设计的相关内容，为开展性能测试工作提供了一种可行的方案。但是仅有理论是不够的，对于性能测试工作而言，不但需要好的性能测试理论作为工作指导，更需要掌握好的性能测试工具，因此本书的几位作者共同创作了LoadRunner性能测试实战一书。LoadRunner是目前国内性能测试领域应用最广泛的工具之一，它可以通过模拟成千上万的用户，很快地帮助用户确认和查找性能问题。但是国内图书市场上却没有任何相关书籍，LoadRunner性能测试实战填补了这个空白。LoadRunner性能测试实战是非常注重实际应用的作品。书中详细描述了LoadRunner在性能测试领域诸多方面的应用

28、，并结合具体的案例来说明如何应用Web性能测试实战一书中提到的“全面性能测试模型”。强大的性能测试工具加上合理的理论来指导，将为读者打开很多新的思路。本书是由三位作者共同完成的。绍英有流媒体、P2P、电子政务、银行、门户网站等领域应用软件的性能测试经验，在LoadRunner方面更有五年以上的使用经验。他曾到很多公司去推广自己的性能测试模型以及讲解LoadRunner课程，对企业在软件测试方面的需求非常熟悉；建华是在读研究生，因此有充裕的时间来研究LoadRunner的特殊应用；小姬在性能测试方面也有着丰富的经验。相信他们的这些实践经验是很多测试人员急需的。本书对国内软件企业提高性能测试水平是

29、很有价值的。我很高兴能为这本实战性非常强的作品做序，预祝LoadRunner性能测试实战早日出版。也希望国内有更多的人来关注软件性能测试，探讨解决软件亚健康问题的方法！北京大学软件与微电子学院副教授北京市软件促进中心专家顾问 黎怡兰(Melody Le)1.1 性能测试基本概念在一些软件项目中，项目经理或测试经理经常会安排测试工程师进行下面的工作：l 用LoadRunner测试系统的最大并发用户数。l 用LoadRunner测试系统8小时的最大业务吞吐量。l 用LoadRunner测试系统的稳定性与健壮性。l 用LoadRunner测试系统在数据达到100万条记录时的性能。l 用LoadRun

30、ner测试核心事务响应时间是否满足用户的需求。可以说，现在很多IT企业的性能测试工作已经离不开LoadRunner了。不过，尽管使用了LoadRunner这一强大的工具，很多企业软件产品遇到的性能问题仍未能解决因为仅有好的测试工具是不够的。除了比较实用的测试工具外，要想做好性能测试还应该掌握相关的理论知识。只有以坚实的理论作为实际工作的依托，才能让测试工具发挥出应有的功效。本章将介绍一些性能测试的基础知识，主要内容如下：n 性能测试基本概念n 全面性能测试模型n 性能测试调整基础n 如何做好性能测试提示：关于性能测试理论的更多内容，可以参考作者性能测试方面的专著Web性能测试实战，电子工业出版

31、社，2006年5月出版。1.1 性能测试基本概念在软件系统日益复杂的今天，性能已经成为软件质量重要的衡量标准之一，这一点尤其体现在和Web相关的系统上。软件几乎无处不在，在给用户带来方便的同时，也对开发人员和测试人员提出了更高的要求。性能测试不但要求测试人员具备很强的技术能力，还要具备综合分析问题的能力。本节从性能测试的概念入手，强化性能测试的基础知识。1.1.1 什么是性能测试目前很少能见到性能测试的准确定义，但是性能测试又似乎是涉及范围非常广泛的测试。压力测试、负载测试、强度测试、稳定性测试、健壮性测试、大数据量测试都和性能测试有着密切的关系。在本书中，主要从狭义和广义两方面来讨论性能测试

32、。狭义的性能测试主要用于描述常规的性能测试，是指通过模拟生产运行的业务压力或用户使用场景来测试系统的性能是否满足生产性能的要求。例如，以实际投产环境进行测试，来求出最大的吞吐量与最佳响应时间，以保证上线的平稳、安全等。性能测试是一种“正常”的测试，主要测试正常使用时系统是否满足要求，同时可能为了保留系统的扩展空间而进行的一些稍稍超出“正常”范围的测试。广义的性能测试则是压力测试、负载测试、强度测试、并发（用户）测试、大数据量测试、配置测试、可靠性测试等和性能相关的测试统称。下面分别介绍各类测试的主要内容和特点。压力测试对系统不断施加压力的测试，是通过确定一个系统的瓶颈或不能接收用户请求的性能点

33、，来获得系统能提供的最大服务级别的测试。例如测试一个Web站点在大量的负荷下，系统的事务响应时间何时会变得不可接受或事务不能正常执行。压力测试的目的是发现在什么条件下系统的性能变得不可接受，并通过对应用程序施加越来越大的负载，直到发现应用程序性能下降的拐点。压力测试和负载测试有些类似，但是通常把负载测试描述成一种特定类型的压力测试例如增加用户数量或延长压力时间以对应用程序进行压力测试。负载测试对系统不断地增加压力或增加一定压力下的持续时间，直到系统的一些性能指标达到极限，例如响应时间超过预定指标或某种资源已经达到饱和状态。这种测试可以找到系统的处理极限，为系统调优提供依据。压力测试侧重压力大小

34、，而负载测试往往强调压力持续的时间。在实际工作中，没有必要严格区分这两个概念，有关内容可以参见后面1.2节的“全面性能测试模型”。强度测试强度测试主要是为了检查程序对异常情况的抵抗能力。强度测试总是迫使系统在异常的资源配置下运行。例如：l 当正常的用户点击率为“1000次/秒”时，运行点击率为“2000次/秒”的测试用例；l 运行需要最大存储空间（或其他资源）的测试用例；l 运行可能导致操作系统崩溃或磁盘数据剧烈抖动的测试用例，等等。强度测试是一种特别重要的测试，对测试系统的稳定性，以及系统未来的扩展空间均具有重要的意义。在这种异常条件下进行的测试，更容易发现系统是否稳定以及性能方面是否容易扩

35、展。疲劳强度测试是一类特殊的强度测试，主要测试系统长时间运行后的性能表现，例如724小时的压力测试。并发（用户）测试主要指当测试多个用户并同时访问同一个应用程序、同一个模块或数据记录时是否存在死锁或其他性能问题，几乎所有的性能测试都会涉及并发测试。在具体的性能测试工作中，并发用户往往都是借助工具来进行模拟的，LoadRunner中称之为并发虚拟用户。大数据量测试大数据量测试分为两种：一种是针对某些系统存储、传输、统计查询等业务进行大数据量的测试；另一种是与并发测试相结合的极限状态下的综合数据测试。如专项的大数据量测试主要针对前者，后者尽量放在并发测试中。此外，也可以把大数据量测试分为“运行时大

36、数据量测试”与“历史大数据量测试”来进行测试用例设计。配置测试配置测试主要指通过测试找到系统各项资源的最优分配原则。配置测试是系统调优的重要依据。例如，可以通过不停地调整Oracle的内存参数来进行测试，使之达到一个较好的性能。可以看出，配置测试本质上是前面提到的某些种类的性能测试组合在一起而进行的测试。可靠性测试在给系统加载一定业务压力的情况下，使系统运行一段时间，以此检测系统是否稳定。例如，可以施加让CPU资源保持70%90%使用率的压力，连续对系统加压8个小时，然后根据结果分析系统是否稳定。这么多类型的性能测试看起来很吓人，实际上它们大多是密切相关的。例如，运行8个小时来测试系统是否可靠

37、，而这个测试极有可能包含了可靠性测试、强度测试、并发（用户）测试、负载测试，等等。因此，当实施性能测试时绝不能割裂它们的内部联系去进行，而应分析它们之间的关系，以一种高效的方式来规划与设计性能测试。为此，本书在1.2节提出了“全面性能测试模型”，以更好的方式来开展性能测试工作。1.1.2 性能测试应用领域性能测试往往是为了实现下面的一个或几个目标：l 判定软件是否满足预期的性能需求；l 根据测试结果判定软件的性能表现；l 查找系统可能存在的性能问题，如果有，则找出并加以解决；l 发现一些应用程序在功能实现方面的缺陷；l 对一些存在性能问题的系统，找出瓶颈并加以解决；l 为用户部署系统提供性能参

38、考；l 通过分析性能测试的种种目标，不难总结出性能测试主要应用在几个领域中，下面分别予以介绍。系统的性能瓶颈定位系统的性能瓶颈定位是性能测试最常见的应用领域。借助LoadRunner等工具，可以在测试场景运行过程中监控系统资源、Web服务器资源等运行数据，与响应时间进行同步分析，可以在一定程度上进行性能瓶颈的分析与定位。系统的参数配置通过性能测试可以测试系统在不同参数配置下的性能表现，进而找出令系统表现更优的系统配置参数，为应用系统投产提供最佳配置建议。实际上，操作系统、数据库、中间件服务器等的参数配置是应用系统发生性能问题的重要原因。例如分配给Oracle的内存大小与系统自身的业务特点有极大

39、关系，配置不同的数据库，性能表现就会不同；而即使在内存一定的情况下，SGA的分配也会对性能产生很大的影响。因此，要通过测试，以确定内存的最佳配置。发现一些软件算法方面的缺陷一些多线程、同步并发算法在单用户模式下测试是很难发现问题的，只有通过模拟多用户的并发操作，才能验证其运行是否正常与稳定。例如作者就经历过在一次性能测试过程中，测试人员模拟多个用户并发时发现的一个明显的缺陷：测试对象是一个随机分配任务的模块，只要有用户申请，就会给用户分配任务。这个算法在单用户情况下调试没有任何问题，但是当多个用户同时申请任务时，就发生了把同一任务分配给多个不同用户的现象。经证实，这个缺陷就是“同步算法”发生了

40、问题而引起的。系统的验收测试系统验收测试经常会验证一些预期的性能指标，或者验证系统中一些事务指标是否符合用户期望，这时就需要借助性能测试来完成验证工作。随着用户对性能的重视，现在性能测试几乎是系统验收测试中必不可少的内容之一。用户甚至自己进行专门的性能测试来验证系统上线前的性能，以保证运行时的性能稳定。因此，性能测试在用户验收测试中越来越重要。系统容量规划通过总结系统在不同硬件环境下的性能表现，可以为系统部署时提供非常好的参考。对于一些性能要求较高的系统，性能测试可以为硬件规划提供很好的参考数据，使用户在购买硬件时“有据可依”。例如同一系列机型：两颗CPU系统支持500用户并发、四颗CPU支持

41、800用户并发，这些都是用户根据自身需求来规划硬件的重要依据。产品评估/选型产品评估/选型是性能测试的又一应用领域。通过性能测试，可以对产品的软硬件性能进行更全面的评估，选出更适合自己的产品类型。性能测试的应用领域越来越广，因此在实际工作中，性能测试往往会一次应用在一个或多个领域。对于软件性能测试设计人员，应该根据测试的具体应用领域、测试原则和目标来进行性能测试的规划与设计。1.1.3 性能测试常见术语本节将介绍一些性能测试中的常见术语，只有掌握这些基础的性能测试知识，才可以进一步开展测试工作。性能测试常见的术语主要有并发、并发用户数量、请求响应时间、事务响应时间、吞吐量、吞吐率、TPS、点击

42、率、资源利用率等，下面分别介绍它们。并发狭义的并发一般分两种情况。一种是严格意义上的并发，即所有的用户在同一时刻做同一件事情或操作，这种操作一般针对同一类型的业务。例如在信用卡审批业务中，一定数目的用户在同一时刻对已经完成的审批业务进行提交（操作的不是同一记录）；还有一种是特例，即所有用户进行完全一样的操作，目的是测试数据库和程序对并发操作的处理。例如在信用卡审批业务中，所有的用户可以一起申请业务，或者修改同一条记录。另外一种并发是广义的并发。这种并发与狭义的并发的区别是尽管多个用户对系统发出了请求或进行了操作，但是这些请求或操作可以是相同的，也可以是不同的。对整个系统而言，仍然有很多用户同时

43、对系统进行操作，因此，仍然属于并发的范畴。可以看出，广义的并发是包含狭义的并发的，而且广义的并发更接近用户的实际使用情况，因为对大多数系统而言，只有数量很少的用户进行“严格意义上的并发”。对于性能测试而言，这两种并发一般都需要进行测试，通常做法是先进行严格意义上的并发测试。严格意义上的并发一般发生在使用比较频繁的模块中，尽管发生的概率不是特别高，但是一旦发生性能问题，后果很可能是致命的。严格意义上的并发测试往往和功能测试关联起来，因为只要并发功能遇到异常通常都是程序的问题，这种测试也是健壮性和稳定性测试的一部分。并发用户数量关于并发用户的数量，有两种常见的错误观点。一种错误观点是把并发用户数量

44、理解为使用系统的全部用户的数量，理由是这些用户可能同时使用系统；还有一种比较接近正确的观点是把用户在线数量理解为并发用户数量。实际上，在线用户不一定会和其他用户发生并发，例如正在浏览网页信息的用户，对服务器是没有任何影响的。但是，用户在线数量是统计并发用户数量的主要依据之一。并发主要针对服务器而言，是否并发的关键是看用户的操作是否对服务器产生了影响。因此，并发用户数量的正确理解是，在同一时刻与服务器进行交互的在线用户数量。这些用户的最大特征是和服务器发生了交互，这种交互既可以是单向传送数据的，也可以是双向传送数据的。并发用户数量的统计方法目前还没有准确的公式，因为不同的系统会有不同的并发特点。

45、例如OA系统统计并发用户数量的经验公式为：使用系统的用户数量（520）。对于这个公式，没有必要拘泥于计算出的结果，因为为了保证系统的扩展空间，测试时的并发用户数量都会稍稍大一些，除非要测试系统能承受的最大并发用户数量。举例说明：如果一个OA系统的期望用户为1 000个，只要测试出系统能支持200个并发用户就可以了。请求响应时间请求响应时间是指从客户端发出请求到得到响应的整个过程的时间。这个过程从客户端发送一个请求开始计时，到客户端接到从服务器端返回的响应结果计时结束。在某些工具中，请求响应时间通常会被称为“TTLB”，即“Time to last byte”，意思是从发送一个请求开始，到客户端

46、收到最后一个字节的响应为止所耗费的时间。请求响应时间的单位一般为“秒”或“毫秒”。请求响应时间的分解如图1-1所示。图1-1 Web请求过程分解图从图1-1可以看出，请求响应时间为“网络响应时间”和“应用程序与系统响应时间”之和，具体由7个部分组成，即(N1+N2+N3+N4)+(A1+A2+A3)。事务响应时间事务可能由一系列请求组成，事务的响应时间主要针对用户而言，属于宏观上的概念，是为了向用户说明业务响应时间而提出的。例如：跨行取款事务的响应时间就是由一系列的请求组成的。事务响应时间和后面的业务吞吐率都是直接衡量系统性能的参数。吞吐量指在一次性能测试过程中网络上传输的数据量的总和。吞吐量

47、/传输时间，就是吞吐率。吞吐率（Throughput）通常用来指单位时间内网络上传输的数据量，也可以指单位时间内处理的客户端请求数量。它是衡量网络性能的重要指标。但是从用户或业务角度来看，吞吐率也可以用“请求数/秒”或“页面数/秒”、“业务数/小时或天”、“访问人数/天”、“页面访问量/天”来衡量。例如在银行卡审批系统中，可以用“千件/每小时”来衡量系统的业务处理能力。TPS(Transaction Per Second)每秒钟系统能够处理的交易或事务的数量。它是衡量系统处理能力的重要指标。TPS是LoadRunner中重要的性能参数指标。点击率（Hit Per Second）每秒钟用户向We

48、b服务器提交的HTTP请求数。这个指标是Web应用特有的一个指标：Web应用是“请求-响应”模式，用户发出一次申请，服务器就要处理一次，所以“点击”是Web应用能够处理交易的最小单位。如果把每次点击定义为一次交易，点击率和TPS就是一个概念。不难看出，点击率越大，对服务器的压力也越大。点击率只是一个性能参考指标，重要的是分析点击时产生的影响。需要注意的是，这里的点击不是指鼠标的一次“单击”操作，因为在一次“单击”操作中，客户端可能向服务器发出多个HTTP请求。资源利用率资源利用率指的是对不同系统资源的使用程度，例如服务器的CPU利用率、磁盘利用率等。资源利用率是分析系统性能指标进而改善性能的主

49、要依据，因此，它是Web性能测试工作的重点。资源利用率主要针对Web服务器、操作系统、数据库服务器、网络等，是测试和分析瓶颈的主要参数。在性能测试中，要根据需要采集具体的资源利用率参数来进行分析。1.2 全面性能测试模型 1.2 全面性能测试模型通过前面的内容可以看出，性能测试的很多内容都是关联的。这就提供了一条思路：性能测试的很多内容可以经过一定的组织来统一进行。统一开展性能测试的最大好处是，可以按照由浅入深的层次对系统进行测试，进而减少不必要的工作量，以实现节约测试成本的目的。为此，本书提出了“全面性能测试模型”。“全面性能测试模型”提出的主要依据是：一种类型的性能测试可以在某些条件下转化

50、成为另一种类型的性能测试，而这些测试的实施方式很类似。例如：对一个网站进行测试，模拟10个到50个用户就是常规的性能测试。当用户增加到1000乃至上万时就变成了压力/负载测试。如果同时对系统进行大量的数据查询操作，就包含了大数据量测试。在“全面性能测试模型”中，把常见的性能测试分为8个类别，然后结合测试工具把性能测试用例归纳为5类来进行设计。下面首先介绍这8个性能测试类别的主要内容：预期指标的性能测试系统在需求分析和设计阶段都会提出一些性能指标，完成和这些指标相关的测试是性能测试的首要工作。本模型把针对预先确定的一些性能指标而进行的测试称为预期指标的性能测试。这些指标主要指诸如“系统可以支持1

51、000个并发用户”、“系统响应时间不得长于10秒”等这些在产品说明书等文档中规定得十分明确的内容。对这种预先承诺的性能要求，测试小组应该首先进行测试验证。独立业务性能测试独立业务实际是指一些与核心业务模块对应的业务，这些模块通常具有功能比较复杂、使用比较频繁、属于核心业务等特点。这类特殊的、功能比较独立的业务模块始终都是性能测试的重点。因此，不但要测试这类模块和性能相关的一些算法，还要测试这类模块对并发用户的响应情况。核心业务模块在需求设计阶段就可以确定，在集成或系统测试阶段开始单独测试其性能。如果是系统类软件或特殊应用领域的软件，通常从单元测试阶段就开始进行测试，并在后继的集成测试、系统测试

52、、验收测试中进一步进行，以保证核心业务模块的性能稳定。何时开始测试核心模块主要由性能测试策略决定，读者可以参考1.2.2节“性能测试用例模型”部分。组合业务性能测试通常所有的用户不会只使用一个或几个核心业务模块，一个应用系统的每个功能模块都可能被使用到。所以性能测试既要模拟多用户的“相同”操作（这里的“相同”指很多用户使用同一功能），又要模拟多用户的“不同”操作（这里的“不同”指很多用户同时对一个或多个模块的不同功能进行操作），对多项业务进行组合性能测试。组合业务测试是最接近用户实际使用情况的测试，也是性能测试的核心内容。通常按照用户的实际使用人数比例来模拟各个模板的组合并发情况。由于组合业务

53、测试是最能反映用户使用情况的测试，因而组合测试往往和服务器（操作系统、Web服务器、数据库服务器）性能测试结合起来进行。在通过工具模拟用户操作的同时，还通过测试工具的监控功能采集服务器的计数器信息，进而全面分析系统的瓶颈，为改进系统提供有利的依据。疲劳强度性能测试疲劳强度测试是指在系统稳定运行的情况下，以一定的负载压力来长时间运行系统的测试。其主要目的是确定系统长时间处理较大业务量时的性能。通过疲劳强度测试基本可以判断系统运行一段时间后是否稳定。大数据量性能测试大数据量测试通常是针对某些系统存储、传输、统计查询等业务进行大数据量的测试。主要测试运行时数据量较大或历史数据量较大时的性能情况，这类

54、测试一般都是针对某些特殊的核心业务或一些日常比较常用的组合业务的测试。由于大数据量测试一般在投产环境下进行，所以把它独立出来并和疲劳强度测试放在一起，在整个性能测试的后期进行。大数据量测试可以理解为特定条件下的核心业务或组合业务测试。网络性能测试网络性能测试主要是为了准确展示带宽、延迟、负载和端口的变化是如何影响用户响应时间的。在实际的软件项目中，主要是测试应用系统的用户数目与网络带宽的关系。网络性能测试一般有专门的工具，本书不加详述。网络测试的任务通常由系统集成人员来完成。服务器性能测试（操作系统、Web服务器、数据库服务器）服务器性能测试主要是对数据库、Web服务器、操作系统的测试，目的是

55、通过性能测试找出各种服务器的瓶颈，为系统扩展、优化提供相关的依据。一些特殊测试主要是指配置测试、内存泄漏测试等一些特殊的Web性能测试。这类性能测试或/和前面的测试结合起来进行，或者在一些特殊的情况下独立进行，本书重点讨论前一种情况。后一种情况由于投入较大往往通过特有的工具进行，可以不纳入性能测试的范畴。“全面性能测试模型”是在以上性能测试分类和总结的基础上提出来的，主要包含3部分内容：第1部分：性能测试策略模型，这是整个性能测试模型的基础。软件类型决定着性能测试的策略，同时用户对待软件性能的态度也影响性能测试策略的制定。本部分内容主要结合软件类型和用户特点来讨论性能测试策略制定的基本原则和方

56、法。第2部分：性能测试用例模型，这是整个性能测试模型的核心部分。其主要思想就是结合测试工具，把以上性能测试的8项内容进一步归纳，形成5类测试用例：l 预期指标的性能测试；l 并发用户的性能测试；l 疲劳强度和大数据量的性能测试；l 服务器性能测试；l 网络性能测试。在具体的测试设计中，性能测试用例往往和测试工具结合起来，把服务器、网络性能测试的用例设计与前三种类型结合起来。例如LoadRunner就可以在进行压力测试的同时，完成后面两类测试的数据采集工作。因此，后面两部分的测试用例只进行总体设计就可以了。第3部分：模型的使用方法。本部分内容讨论如何在工作中使用“全面性能测试模型”。1.2.1

57、性能测试策略模型本节主要介绍性能测试策略的制定方法。性能测试策略一般从需求设计阶段就开始讨论如何制定了，它决定着性能测试工作将要投入多少资源、什么时间开始实施等后继工作的安排。其制定的主要依据是“软件自身特点”和“用户对性能的关注程度”两个因素，其中软件的自身特点起决定作用。软件按照用途的不同可以分为两大类：系统类软件和应用类软件。系统类软件通常对性能要求比较高，因此性能测试应该尽早介入。应用类软件分为特殊类应用和一般类应用，特殊类应用主要指银行、电信、电力、保险、医疗、安全等领域类的软件，这类软件使用比较频繁，用户较多，一般也要较早进行性能测试；一般类应用主要指一些普通应用，例如办公自动化软

58、件、MIS系统等。一般应用类软件多根据实际情况来制定性能测试策略，例如OA系统，既可以早开始，也可以最后进行性能测试，这类软件受用户因素影响比较大。按对性能重视程度的不同一般可以将用户分为4类，即高度重视、中等重视、一般重视、不重视。这么划分主要是为了说明用户对性能测试的影响。实际上，用户不关注性能并不意味着测试人员就可以忽略性能测试，但是如果用户特别关注系统性能，那么测试人员也要特别重视性能测试工作。表1-1列出了性能测试策略制定的基本原则。注意：这里的用户是广义范围的用户，包括所有和产品有利害关系的群体。因而不单单指最终使用产品的用户，这些用户既可以是提出需求的产品经理，也可以是公司的董事

59、会成员，甚至是项目的研发人员。表1-1 性能测试策略制定的基本原则 软件类别用户重视程度系统类软件应用类软件一般类应用特殊类应用高度重视从设计阶段就开始针对系统架构、数据库设计等方面进行规划，从根源来提高性能;系统类软件一般从单元测试阶段开始进行性能测试实施工作，主要是测试一些和性能相关的算法或模块设计阶段开始进行一些规划工作，主要在系统测试阶段开始进行性能测试实施从设计阶段就开始针对系统架构、数据库设计等方面进行规划，从根源来提高性能;特殊应用类软件一般从单元测试阶段开始进行性能测试实施工作，主要是测试一些和性能相关的算法或模块中等重视/一般重视可以在系统测试阶段的功能测试结束后进行性能测试

60、不重视可以在软件发布前进行性能测试，提交测试报告即可从表1-1中可以看出：（1）“系统类软件”、“特殊应用类软件”应该从设计阶段开始进行性能测试；（2）制定性能测试策略的主要依据是软件的特点，用户对待系统性能的态度影响性能测试策略，但不起决定作用。软件的特点决定性能测试策略的另外一个重要原因是“一般应用类软件”本身对性能要求不高，发生性能问题的概率较小。因此可以通过提高硬件配置来改善运行环境，进而提高性能。不过这也不是普遍适用的原则。例如一个几千用户使用的OA系统，仍然要高度重视性能，不管客户对待系统性能是什么态度。虽然从硬件方面解决性能问题往往更容易做到，同时还可以降低开发成本，但是也不能要求用户进行过大的硬件投入，否则会降低“客户满意度”。调整性能最好的办法还是软硬件相结合。“用户对待系统性能的态度影响性能测试策略，但不起决定作用”的根本原因是，产品最终是要交付给用户使用的，而不是做出来给用户欣赏的。因此，不管用户是否重视性能测试，甚至根本不关心，对于性能要求较高的软件产品也应按照表1-1的策略来执行性