当前位置： >>
LoadRunner性能测试实战讲解
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 全面性能测试模型 通过前面的内容可以看出，性能测试的很多内容都是关联的。这就提供了一条思路：性 能测试的很多内容可以经过一定的组织来统一进行。 统一开展性能测试的最大好处是， 可以 按照由浅入深的层次对系统进行测试， 进而减少不必要的工作量， 以实现节约测试成本的目 的。为此，本书提出了“全面性能测试模型”。 “全面性能测试模型”提出的主要依据是：一种类型的性能测试可以在某些条件下转化成 为另一种类型的性能测试，而这些测试的实施方式很类似。例如：对一个网站进行测试，模 拟 10 个到 50 个用户就是常规的性能测试。当用户增加到 1000 乃至上万时就变成了压力/ 负载测试。如果同时对系统进行大量的数据查询操作，就包含了大数据量测试。 在“全面性能测试模型”中，把常见的性能测试分为 8 个类别，然后结合测试工具把性能 测试用例归纳为 5 类来进行设计。下面首先介绍这 8 个性能测试类别的主要内容： 预期指标的性能测试系统在需求分析和设计阶段都会提出一些性能指标， 完成和这些指标相关的测试是性能 测试的首要工作。 本模型把针对预先确定的一些性能指标而进行的测试称为预期指标的性能 测试。 这些指标主要指诸如“系统可以支持 1000 个并发用户”、“系统响应时间不得长于 10 秒” 等这些在产品说明书等文档中规定得十分明确的内容。 对这种预先承诺的性能要求， 测试小 组应该首先进行测试验证。 独立业务性能测试 独立业务实际是指一些与核心业务模块对应的业务，这些模块通常具有功能比较复杂、 使用比较频繁、属于核心业务等特点。这类特殊的、功能比较独立的业务模块始终都是性能 测试的重点。因此，不但要测试这类模块和性能相关的一些算法，还要测试这类模块对并发 用户的响应情况。 核心业务模块在需求设计阶段就可以确定，在集成或系统测试阶段开始单独测试其性 能。如果是系统类软件或特殊应用领域的软件，通常从单元测试阶段就开始进行测试，并在 后继的集成测试、系统测试、验收测试中进一步进行，以保证核心业务模块的性能稳定。何 时开始测试核心模块主要由性能测试策略决定，读者可以参考 1.2.2 节“性能测试用例模型” 部分。 组合业务性能测试 通常所有的用户不会只使用一个或几个核心业务模块， 一个应用系统的每个功能模块都 可能被使用到。所以性能测试既要模拟多用户的“相同”操作（这里的“相同”指很多用户使用 同一功能），又要模拟多用户的“不同”操作（这里的“不同”指很多用户同时对一个或多个模 块的不同功能进行操作），对多项业务进行组合性能测试。组合业务测试是最接近用户实际 使用情况的测试， 也是性能测试的核心内容。 通常按照用户的实际使用人数比例来模拟各个 模板的组合并发情况。 由于组合业务测试是最能反映用户使用情况的测试，因而组合测试往往和服务器（操作 系统、Web 服务器、数据库服务器）性能测试结合起来进行。在通过工具模拟用户操作的 同时，还通过测试工具的监控功能采集服务器的计数器信息，进而全面分析系统的瓶颈，为 改进系统提供有利的依据。 疲劳强度性能测试 疲劳强度测试是指在系统稳定运行的情况下， 以一定的负载压力来长时间运行系统的测 试。 其主要目的是确定系统长时间处理较大业务量时的性能。 通过疲劳强度测试基本可以判 断系统运行一段时间后是否稳定。大数据量性能测试 大数据量测试通常是针对某些系统存储、传输、统计查询等业务进行大数据量的测试。 主要测试运行时数据量较大或历史数据量较大时的性能情况， 这类测试一般都是针对某些特 殊的核心业务或一些日常比较常用的组合业务的测试。 由于大数据量测试一般在投产环境下进行， 所以把它独立出来并和疲劳强度测试放在一 起， 在整个性能测试的后期进行。 大数据量测试可以理解为特定条件下的核心业务或组合业 务测试。 网络性能测试 网络性能测试主要是为了准确展示带宽、延迟、负载和端口的变化是如何影响用户响应 时间的。在实际的软件项目中，主要是测试应用系统的用户数目与网络带宽的关系。网络性 能测试一般有专门的工具，本书不加详述。网络测试的任务通常由系统集成人员来完成。 服务器性能测试（操作系统、Web 服务器、数据库服务器） 服务器性能测试主要是对数据库、Web 服务器、操作系统的测试，目的是通过性能测试 找出各种服务器的瓶颈，为系统扩展、优化提供相关的依据。 一些特殊测试 主要是指配置测试、内存泄漏测试等一些特殊的 Web 性能测试。这类性能测试或/和前 面的测试结合起来进行，或者在一些特殊的情况下独立进行，本书重点讨论前一种情况。后 一种情况由于投入较大往往通过特有的工具进行，可以不纳入性能测试的范畴。 “全面性能测试模型”是在以上性能测试分类和总结的基础上提出来的，主要包含 3 部分 内容： 第 1 部分：性能测试策略模型，这是整个性能测试模型的基础。软件类型决定着性能测 试的策略， 同时用户对待软件性能的态度也影响性能测试策略的制定。 本部分内容主要结合 软件类型和用户特点来讨论性能测试策略制定的基本原则和方法。 第 2 部分：性能测试用例模型，这是整个性能测试模型的核心部分。其主要思想就是结 合测试工具，把以上性能测试的 8 项内容进一步归纳，形成 5 类测试用例： l 预期指标的性能测试； l 并发用户的性能测试； l 疲劳强度和大数据量的性能测试； l 服务器性能测试； l 网络性能测试。 在具体的测试设计中，性能测试用例往往和测试工具结合起来，把服务器、网络性能测 试的用例设计与前三种类型结合起来。例如 LoadRunner 就可以在进行压力测试的同时，完 成后面两类测试的数据采集工作。因此，后面两部分的测试用例只进行总体设计就可以了。 第 3 部分：模型的使用方法。本部分内容讨论如何在工作中使用“全面性能测试模型”。 1.2.1 性能测试策略模型 本节主要介绍性能测试策略的制定方法。 性能测试策略一般从需求设计阶段就开始讨论 如何制定了， 它决定着性能测试工作将要投入多少资源、 什么时间开始实施等后继工作的安排。其制定的主要依据是“软件自身特点”和“用户对性能的关注程度”两个因素，其中软件的 自身特点起决定作用。 软件按照用途的不同可以分为两大类：系统类软件和应用类软件。系统类软件通常对性 能要求比较高，因此性能测试应该尽早介入。应用类软件分为特殊类应用和一般类应用，特 殊类应用主要指银行、电信、电力、保险、医疗、安全等领域类的软件，这类软件使用比较 频繁，用户较多，一般也要较早进行性能测试；一般类应用主要指一些普通应用，例如办公 自动化软件、MIS 系统等。一般应用类软件多根据实际情况来制定性能测试策略，例如 OA 系统，既可以早开始，也可以最后进行性能测试，这类软件受用户因素影响比较大。 按对性能重视程度的不同一般可以将用户分为 4 类， 即高度重视、 中等重视、 一般重视、 不重视。这么划分主要是为了说明用户对性能测试的影响。实际上，用户不关注性能并不意 味着测试人员就可以忽略性能测试， 但是如果用户特别关注系统性能， 那么测试人员也要特 别重视性能测试工作。表 1-1 列出了性能测试策略制定的基本原则。注意：这里的用户是广义范围的用户，包括所有和产品有利害关系的群体。因而 不单单指最终使用产品的用户， 这些用户既可以是提出需求的产品经理， 也 可以是公司的董事会成员，甚至是项目的研发人员。 表 1-1 性能测试策略制定的基本原则软件类别 用户重视程度高度重视中等重视/一般重 视不重视应用类软件 一般类应用 特殊类应用 设计阶段开 从设计阶段 从设计阶段就 始进行一些规 就开始针对系 开始针对系统 划工作，主要 统架构、数据 架构、数据库设 在系统测试阶 库设计等方面 计等方面进行 段开始进行性 进行规划，从 规划，从根源来 能测试实施 根源来提高性 提高性能; 可以在系统 能; 系统类软件一 特殊应用类 测试阶段的功 般从单元测试 能测试结束后 软件一般从单 阶段开始进行 进行性能测试 元测试阶段开 性能测试实施 始进行性能测 工作，主要是测 可以在软件 试实施工作， 试一些和性能 发布前进行性 主要是测试一 相关的算法或 能测试，提交 些和性能相关 模块 测试报告即可 的算法或模块系统类软件从表 1-1 中可以看出：（1）“系统类软件”、“特殊应用类软件”应该从设计阶段开始进行 性能测试；（2）制定性能测试策略的主要依据是软件的特点，用户对待系统性能的态度影 响性能测试策略，但不起决定作用。软件的特点决定性能测试策略的另外一个重要原因是“一般应用类软件”本身对性能要 求不高，发生性能问题的概率较小。因此可以通过提高硬件配置来改善运行环境，进而提高 性能。不过这也不是普遍适用的原则。例如一个几千用户使用的 OA 系统，仍然要高度重视 性能，不管客户对待系统性能是什么态度。 虽然从硬件方面解决性能问题往往更容易做到，同时还可以降低开发成本，但是也不能 要求用户进行过大的硬件投入，否则会降低“客户满意度”。调整性能最好的办法还是软硬件 相结合。 “用户对待系统性能的态度影响性能测试策略，但不起决定作用”的根本原因是，产品最 终是要交付给用户使用的， 而不是做出来给用户欣赏的。 因此， 不管用户是否重视性能测试， 甚至根本不关心， 对于性能要求较高的软件产品也应按照表 1-1 的策略来执行性能测试。 只 是如果用户特别重视产品性能，意味着测试团队可能要进行更多的成本投入。 下面是一些性能测试策略制定的案例。案例一 一个银行卡审批业务系统的性能测试策略制定。 这个项目的性能测试策略从立项时开始 制定，贯穿整个项目的执行过程。 银行卡业务系统属于特殊应用软件， 加上用户高度重视性能， 因而采取的策略 是从设计阶段就开始进行性能测试的准备工作。案例的详细内容如表 1-2 所示。 表 1-2 某银行项目测试策略制定案例产品类 型 项目背 景 用户要 求银行卡审批业务系统，使用非常频繁，业务量每年达到 200 万次左右，属于银行领域的特殊应用软件系统属于二次开发。前一开发商在系统开发完成后没有通过性能测试，当 100 个用户并发访问系统时就会造成数据库服务器崩溃。因此从项目启动开始，性 能测试就已经成为用户关注的焦点 用户提出性能首先要过关，否则功能再好也不会投产 从系统设计阶段开始进行性能测试准备工作。测试人员主要参加系统的设计、 评审。前一开发商失利的重要原因是数据库设计不合理，所以重点讨论了数据 库的设计 系统设计阶段，完成了性能测试方案的设计 单元测试阶段，通过测试工具对一些重要模块的算法进行了测试。主要是一些 并发控制算法的性能测试，测试对象是一些核心业务模块 集成测试阶段进行组合模块的性能测试 整个系统测试阶段都在进行性能测试，性能测试和功能测试同步进行。对功能 测试引起的一些相关修改，立刻进行性能测试 验收测试阶段，在用户现场的投产环境进行性能测试，根据测试结果对系统运 行环境进行调优，以达到更好的运行效果性能测 试策略案例二一个 OA 系统的测试案例， 其性能测试策略和案例一差别很大， 具体内容如表 1-3 所示。 表 1-3 某 OA 项目测试策略制定案例产品类 型 项目背 景 用户要 求 性能测 试策略企业办公系统，用户数目在 1000 人以内，主要是一些信息的发布，以及公文 流转、收发邮件等功能。软件系统的地位属于辅助办公功能。因此该类软件 属于一般类型的应用软件，对性能要求不高，性能测试不属于重要工作 已有稳定产品在工作。主要是按照客户的个性化需求进行二次开发 客户提出了性能方面的需求：要求系统响应时间要加快，可以满足 2000 个用 户使用的需要 系统测试阶段开始进行性能测试准备工作，完成测试用例设计。其目标主要 是评估系统性能，根据测试结果对系统进行一定的优化 验收测试阶段在用户现场执行性能测试用例，根据测试结果进行一定的调优 工作，提交测试报告给用户以便进行系统验收案例三 一个门户系统的测试案例，具体内容如表 1-4 所示。 表 1-4 某门户项目测试策略制定案例产品类型 主要用于一些单位信息的发布，用户在 50 人以下。因此该类软件属于一 般类型的应用软件，对性能要求很低 软件运行的硬件环境较好 用户没有提出具体的要求 验收测试在使用现场进行，根据测试结果进行一定的调优工作，提交测试 报告给用户，以便进行系统验收项目背景 用户要求 性能测试 策略仅仅三个案例不足以说明所有性能测试策略制定的方法， 但是通过这三个案例可以对性 能测试策略的制定有更进一步的了解，能够认识到性能测试策略的制定由软件自身特点决 定，同时受用户态度的影响。实际上，软件项目的背景、软件运行环境等许多方面都会影响 性能测试策略的制定。因此，本节提出的只是基本的参考方案。制定测试策略是十分复杂的 工作，最有效的方法就是“从实际出发”。项目的特点千差万别，只有把用户当成“上帝”，充 分为用户考虑，才可以制定出合理的性能测试策略。 本节介绍了性能测试策略制定的基本思路和方法。 性能测试策略是后期性能测试工作的 基础，决定着性能测试工作的投入。因此，要充分意识到这一工作的重要性，认识到只有做 好了前期的“路线”制定工作，才可以走对后面的“道路”。 1.2.2 性能测试用例模型 “性能测试用例模型”是“全面性能测试模型”的核心内容。限于篇幅和本书主旨，本节仅 对“性能测试用例模型”做概要介绍。关于“性能测试用例模型”以及“全面性能测试模型”更详 细的内容，读者可以参考作者的另一本专著《Web 性能测试实战》。 在前面的内容中，已经介绍了性能测试分为 8 个方面。而在“性能测试用例模型”中，则 融合了性能、强度、压力、负载等多方面测试内容，对性能测试进行了重新组织和分类，最 终归纳出五类性能测试用例。下面介绍各类性能测试用例包含的内容以及设计方法。 预期性能指标测试用例所谓预期或预定性能指标，就是指一些十分明确的、在系统需求设计阶段预先提出的、 期望系统达到的，或者向用户保证的性能指标，这些指标是性能测试的首要任务。针对每个 指标都要编写一个或多个测试用例来验证系统是否达到要求， 如果达不到目标， 则需根据测 试结果来改进系统的性能。 预期指标的用例设计比较简单，主要参考需求和设计文档，把里面十分明确的性能要求 提取出来即可。指标中通常以单用户为主，如果涉及并发用户内容，则归并到并发用户测试 用例中进行设计，遇到其他内容亦可采用同样的方法处理。 用户并发性能测试用例 本节的用户并发测试融合了前面提到的“独立业务性能测试”和“组合业务性能测试”两类 内容， 主要是为了使性能测试按照一定的层次来开展。 独立业务性能测试实际上就是核心业 务模块的某一业务的并发性能测试，可以理解为“单元性能测试”；组合业务的性能测试是一 个或多个模块的多项业务同时进行并发性能测试，可以理解为“集成性能测试”。“单元性能 测试”和“集成性能测试”两者紧密相连，由于这两部分内容都是以并发用户测试为主，因此 把这两类测试合并起来通称为“用户并发性能测试”。 用户并发性能测试要求选择具有代表性的、关键的业务来设计测试用例，以便更有效地 评测系统性能。 当编写具体的测试用例设计文档时， 一般不会像功能测试那样进行明确的分 类，其基本的编写思想是按照系统的体系结构进行编写的。很多时候，“独立业务”和“组合 业务”是混合在一起进行设计的。 单一模块本身就存在“独立业务”和“组合业务”，所以性能测试用例的设计应该面向“模 块”，而不是具体的业务。在性能测试用例设计模型中，用户并发测试实际就是关于“独立核 心模块并发”和“组合模块并发”的性能测试。 用户并发性能测试的详细分类如图 1-2 所示。图 1-2 用户并发性能测试的分类示意图 独立核心模块（以下简称“核心模块”）并发性能测试的重点是测试一些系统重要模块独 立运行的情况，因此可以将其理解为“单元性能测试”。只有这些决定系统性能的“核心单元” 性能稳定，后面的性能测试才有意义。核心模块并发性能测试是整个性能测试工作的基础。 组合模块并发性能测试是最能反映用户实际使用情况的测试， 是在前面各个核心模块运 行良好的基础上、把系统的一些具有耦合关系的模块组合起来的测试，因此可以理解成 “集成性能测试”。组合模块用户并发性能测试最重要的是模拟实际用户比较常见的场景，只有 这样才可以真实地反映用户使用系统的情况，进而发现系统的瓶颈和其他一些性能问题。 疲劳强度与大数据量测试 疲劳强度测试属于用户并发测试的延续， 因此测试内容仍然是“核心模块用户并发”与“组 合模块用户并发”。在实际工作中，一般通过工具模拟用户的一些核心或典型的业务，然后 长时间地运行系统，以检测系统是否稳定。 大数据量测试主要是针对那些对数据库有特殊要求的系统而进行的测试， 例如电信业务 系统的手机短信业务。由于有的用户关机或不在服务区，每秒钟需要有大量的短信息保存， 同时在用户联机后还要及时发送，因此对数据库性能有极高的要求，需要进行专门测试。编 写本类用例前，应对需求设计文档进行仔细分析，提出测试点。 大数据量测试分为 3 种： l 实时大数据量测试： 模拟用户工作时的实时大数据量， 主要目的是测试用户较多或某些业 务产生较大数据量时，系统能否稳定地运行； l 极限状态下的测试：主要是测试系统使用一段时间后，即系统累积一定量的数据后，能否 正常地运行业务； l 前面两种的结合： 测试系统已经累积较大数据量时， 一些运行时产生较大数据量的模块能 否稳定地工作。 网络性能测试 网络性能测试的用例设计主要有以下两类： l 基于硬件的测试：主要通过各种专用软件工具、仪器等来测试整个系统的网络运行环境， 一般由专门的系统集成人员来负责，不在本书的研究范围之内； l 基于应用系统的测试：在实际的软件项目中，主要测试用户数目与网络带宽的关系。通过 测试工具准确展示带宽、延迟、负载和端口的变化是如何影响用户响应时间的。例如，可以 分别测试不同带宽条件下系统的响应时间。 服务器性能测试 服务器性能测试主要有两种类型：l 高级服务器性能测试：主要指在特定的硬件条件下，由数据库、Web 服务器、操作系统 相应领域的专家进行的性能测试。例如，数据库服务器由专门的 DBA 来进行测试和调优。 这类测试一般不由测试工程师来完成，所以不在本书的研究范围之内； l 初级服务器性能测试： 主要指在业务系统工作或进行前面其他种类性能测试的时候， 监控 服务器的一些计数器信息。通过这些计数器对服务器进行综合性能分析，找出系统瓶颈，为 调优或提高性能提供依据。 1.2.3 模型的使用方法 “全面性能测试模型”是针对性能测试而提出的一种方法，主要是为了比较全面地开展性 能测试， 使性能测试更容易组织和开展。 本模型包含了测试策略制定的通用方法和测试用例 设计的通用方案。其中测试用例的设计覆盖了应用软件、服务器、操作系统等多方面内容， 按照由浅入深的层次对性能测试进行合理的组织。 “全面性能测试模型”是一种从很多性能测试项目抽象出来的方法论，主要用来指导测 试， 一般不适合具体的性能测试项目， 因为任何一个项目都会有它的特定背景。 要想通过“全 面性能测试模型”做好性能测试工作，首先要制定好性能测试策略，同时还要按照一些基本 指导原则来使用“性能测试用例模型”的内容。这些原则主要包括如下内容： l 测试策略遵从最低成本原则。 全面性能测试本身是一种高投入的测试， 而很多公司在测试 上的投入都比较低； 性能测试同时又是全部测试工作的一部分， 很多项目只能进行一些重要 的性能测试内容。 这就决定了测试负责人制定性能测试策略时在资源投入方面一定要遵从最 低成本化原则。最低成本的衡量标准主要指“投入的测试成本能否使系统满足预先确定的性 能目标”。 只要经过反复的“测试―系统调优―测试”后， 系统符合性能需求并有一定的扩展空 间，就可以认为性能测试工作是成功的。反之，如果系统经过测试后不能满足性能需求或满 足性能需求后仍须继续投入资源进行测试，则可以认为是不合理的。 l 策略为中心原则。 本原则不但对性能测试工作有效， 对其他类型的测试工作同样具有指导 意义。 测试策略不但决定了测试用例设计的主要内容， 还决定着实施测试工作时如何根据项 目的实际情况进行处理。 例如当项目时间比较紧张时， 就可以按照测试用例的优先级只执行 一部分性能测试用例。因此，性能测试策略应该贯穿整个性能测试的全过程。 l 适当裁剪原则。 裁剪原则主要是针对性能用例设计而言的。 性能测试用例设计模型主要是 针对电信、银行等特殊领域的应用而提出的，包含的测试内容比较全面，而这类项目的性能测试一般周期较长、投入较大。一些银行项目的性能测试周期可能会超过一年。要想性能测 试用例设计模型在大多数测试项目中适用， 就必须对测试用例模型包含的内容进行合理的裁 剪。这样做主要是为了适合特定项目的测试需求，进而节约测试成本。 裁减的主要依据是性能测试策略。根据策略制定方法制定出测试策略，然 后从“5 类性能测试用例”中选择适当的类别来编写测试用例。例如有些要求不 高的静态门户网站，用户没有提出性能方面的要求，可以只测试用户并发情况 作为系统性能的参考。 l 完善模型原则。 本模型只是作者工作经验的总结， 由于性能测试任务都有自己的项目背景， 因而需要对模型内容进行不断的调整、补充、完善，使之适合更多的性能测试工作。具体来 说，不断完善就是要在工作中不断总结经验，形成自己的“全面性能测试模型”。只有“自己 的”测试模型，才是最符合需要的模型。 l 模型具体化原则。 模型具体化是指把模型运用到具体的项目中去， 这是前面所有指导原则 的终极目标。如果只记住模型的条条框框，生搬硬套框架来设计测试，只能得到适得其反的 结果。 要想使模型在性能测试工作中发挥作用， 只有根据实际项目的特点制定合理的性能测 试策略、编写适当的性能测试用例，并在测试实施中灵活地执行测试方案才是上策。 综合上面的分析可以看出，模型的使用可以概括为两个字――活用。要想真正做好性能 测试工作，最有效的办法就是在掌握基本理论和方法后，在工作中不断地探索和总结，形成 自己的“全面性能测试模型”。1.3 性能测试调整基础 所谓性能测试调整是为了改善系统某些方面的性能而对系统软件或硬件进行的修改。 性 能调整不是测试人员的职责， 性能测试工程师的主要任务是发现并定位性能问题。 对于性能 测试中发现的问题，通常由性能测试工程师、DBA、系统管理员、开发人员共同来解决。但 是对于测试人员，了解调整的相关知识则是十分必要的。 在性能测试工作中经常会提到“性能调优”或“系统调优”等概念。实际上，“性能调优”或 “系统调优”只是性能调整的一部分内容。例如，可能为了让某些部分“更优”而把某些部分调 得“不优”，因此本书使用“性能调整”这一说法。 本节主要讨论性能调整的基础知识。性能调整应该按照一定的顺序进行，主要包括下面 五个步骤：确定问题 首先根据测试结果确定系统是否存在问题，重点是发现系统的瓶颈。如果存在，就应该 确定是什么问题，并对问题进行正确的定位。确定系统问题可从下面几个方面入手： l 检查应用程序代码：通常情况下，很多程序的性能问题都是“写”出来的。因此对于发现瓶 颈的模块，应该首先检查代码； l 调整数据库配置：数据库配置经常会引起整个系统运行缓慢，一些诸如 Oracle 的大型数 据库都需要 DBA 进行正确的参数调整才能投产； l 调整操作系统配置：操作系统配置不合理也可能引起系统瓶颈； l 检查硬件设置：磁盘速度、内存大小等都是引起瓶颈的原因，因此这些也是分析的重点； l 检查网络：网络负载过重会导致网络冲突和网络延迟。 同时，还要对系统的使用情况进行调查，例如： l l l l 是否听到了很多用户的抱怨？ 某些操作的响应时间是否随着使用时间的增长而增长？ CPU 的使用率是否很低而 I/O 的使用率却很高？ 使用过程中性能是否稳定？ 系统性能问题不是显而易见的，要仔细查找才能正确地定位。 确定原因 确定系统存在问题后就要仔细进行分析，进而确定引起问题的原因。确定原因很大程度 上靠的是团队的经验和技术能力，涉及的知识有操作系统、数据库、网络、程序开发等许多 方面。 和确定性能问题一样，确定原因仍然要广泛地搜集信息。通常要进行以下的分析： l 问题的影响是什么：响应速度还是吞吐量，或者其他问题？ l 是大多数用户还是少数用户遇到了问题？如果是少数用户， 这几个用户与其他用户的操作 有什么不同？ l 系统资源监控的结果是否正常，如 CPU 的使用是否到了极限？I/O 情况如何？ l 问题是否集中在某一类模块中？ l 是客户端还是服务器出现问题？ l 系统硬件配置是否合理？ l 实际负载是否超过了系统的负载能力？ l 是否未对系统进行优化？ 通过这些分析以及系统的一些具体表现，可以对系统瓶颈有更深入的了解，进而分析出 真正的原因。 确定调整目标和解决方案 在分析出问题发生的原因后，测试人员和系统调整人员首先要确定调整目标，然后设计 解决方案。确定调整目标的主要作用是明确何时停止系统调整，否则工作将永无尽头。每个系统都有不同的特点，因此调整目标可能各有不同。例如，下面这些都是系统的调 整目标： l 提高系统吞吐量； l 缩短响应时间； l 更好地支持并发； 设计解决方案的主要依据就是这些调整目标。有了明确的方案和目标，就可以进行后面 的工作了。 测试解决方案 实施解决方案后，就要对方案进行测试。可以使用以前的测试用例来进行测试，验证系 统是否解决了性能问题。 测试解决方案尽量要在仿真环境下进行， 因为在生产环境下可能会 带来破坏，除非充分估计了测试的风险，并且准备了万全的补救方案。 分析调整结果 性能调整的最后一步是分析调整结果，如果问题没有得到解决，则要重复前面的工作。 在测试系统调整方案过程中， 要经常分析所做的工作。 如果没能准确定位问题或调整方案不 正确，可能会达不到预期目标。要尽早发现这些错误，以使工作早些回到正确的轨道上来。 分析结果时主要考虑下面的问题： l 系统调整是否达到或超出了预定目标？ l 系统是整体性能得到了改善，还是牺牲了某部分性能来解决问题的？ l 调整是否可以结束了？ 达到预期目标后，调整工作基本就可以结束了。 1.4 如何做好性能测试 多数企业都想使产品获得高性能，以降低投产后的风险。但是现实中的性能测试工作却 经常不受重视，常会碰到“走过场”或“拖到整个项目最后进行”的情况，甚至有时会做很多无 意义的性能测试。此外，多数企业的测试人员能力水平不高，这也是导致性能测试不过关的 原因。 根据作者多年的经验，要想做对性能测试应该从管理与技术两个方面入手。 按照规范的管理流程开展测试工作软件性能的低下很多时候是由于系统架构设计不好或代码效率低下而引起的， 如果上线 后发现性能问题往往已很难补救。 因此性能测试应该按照规范的流程来执行， 尽量把问题消 灭在产品上线以前。 根据多数企业的实际情况，性能测试应该分为开发与用户现场两个阶段来进行。 严格地讲，性能测试应该按照测试环境的软、硬件配置高低分为两个阶段。只是由于开 发阶段的软、硬件配置相对较低，而用户现场的投产环境软、硬件配置较高，因此才把性能 测试分为开发与用户现场两个阶段。 对于拥有先进实验设备甚至实验室的公司， 完全可以在 开发阶段完成全部的性能测试工作， 如果用户现场仍要进行性能测试， 则只是简单的验收测 试而已。 l 开发阶段的性能测试实施 开发阶段的性能测试主要指软件试运行前的性能测试， 即团队 内部的性能测试。这一阶段的性能测试是一个反复迭代的过程。 性能测试不是特别重要的项目，这一阶段的性能测试较多关注于软件功能而 引起的缺陷。因此主要进行用户并发性能测试，即核心模块并发用户测试与组合 模块并发用户测试。此外，可能还会进行一些预期性能指标的性能测试。通过开 发阶段的性能测试可以发现一些核心算法问题，最大限度地排除由软件本身引起 的问题。 对于系统类软件或特殊应用系统的性能测试，解决其性能问题可能很耗时， 所以应该较早地组织硬件资源进行各类性能测试， 例如疲劳强度与大数据量测试、 服务器性能测试等。 l 用户现场性能测试的实施 用户现场的性能测试有验收测试的“味道”，是开发阶段性能测 试工作的延续。这一阶段的性能重点是关注性能测试的整体表现。 可以看出，用户现场的性能测试主要是为了验收与调优。因此对于系统软件 和特殊应用系统，性能测试应该尽可能全方位覆盖。而对于一般应用系统，由于 风险较低，所以测试范围可以适当缩小以节省成本。用户现场的性能测试主要基 于投产环境，测试对象多是即将准备投产的系统，甚至可能是已经投产的系统。 投产环境的硬件资源配置通常较高，各类性能测试基本都可以开展。 对于系统软件和特殊领域的应用系统，这一阶段的性能测试主要包含预期指 标性能测试、并发用户性能测试、各类服务器性能测试、疲劳强度与大数据量性 能测试等内容，基本覆盖了“全面性能测试模型”的各个方面。与开发阶段的性能 测试相比，本阶段执行的性能测试用例数量可能会少一些，但是测试用例覆盖的 范围与开发阶段的性能测试基本一致。 一般应用系统在用户现场的性能测试通常包含预期指标性能测试与用户并发 性能测试，可能也会对服务器进行一定的测试，不过内容通常比较简单。一般应 用系统发生性能问题的风险通常不会太高，因此只要通过验收测试即可。 这两个阶段的性能测试都应该按照“需求分析―规划与设计―执行―调优―验证”的顺序 来执行。提高测试人员在性能测试方面的技能 很多时候，由于性能测试人员水平较低，即使进行了测试也不能发现系统潜在的问题， 而最终把问题留给了用户。因此，测试执行人员首先要提高自己的素质和技能。 根据作者多年的经验，一个有竞争力的测试人员要具备以下 3 方面的素质： l 计算机专业技能 计算机领域的专业技能是测试工程师应该必备的一项素质， 这是做好测 试工作的前提条件。尽管没有任何 IT 背景的人也可以从事测试工作，但是一名要想获得更 大发展空间或持久竞争力的测试工程师， 计算机专业技能是必不可少的。 计算机专业技能主 要包含 3 个方面： （1）测试专业技能。现在，软件测试已经成为一个很有潜力的专业。要想成 为一名优秀的测试工程师，首先应该具有扎实的专业基础，这也是本书的编写目 的之一。测试工程师应该努力学习测试专业知识，告别简单的“点击”式的测试工 作，让测试工作以自己的专业知识为依托。 测试专业知识很多， 本书内容主要以测试人员应该掌握的基础专业技能为主。 测试专业技能涉及的范围很广：既包括黑盒测试、白盒测试、测试用例设计等基 础测试技术，也包括单元测试、功能测试、集成测试、系统测试、性能测试等测 试方法，还包括基础的测试流程管理、缺陷管理、自动化测试技术等知识。 （2）软件编程技能。“测试人员是否需要学会编程？”这是测试人员经常提出 的问题之一。实际上，由于在我国开发人员待遇普遍高于测试人员，因此能写代 码的几乎都去做开发了。很多人是因为做不了开发或者不能从事其他工作才“被 迫”从事测试工作。最终的结果则是很多测试人员只能从事相对简单的功能测试， 能力相对强一点的则可以借助测试工具进行简单的自动化测试（主要进行脚本录 制与修改、回放测试脚本等）。 软件编程技能应该是测试人员的必备技能之一。在微软，很多测试人员都拥 有多年的开发经验。因此，测试人员要想得到较好的职业发展，必须能够编写程 序。只有能够进行测试开发，才可以胜任诸如单元测试、集成测试、性能测试等 难度较大的测试工作。 此外，对于软件测试人员的编程技能的要求也有别于开发人员：测试人员编 写的程序应着眼于运行正确，同时兼顾高效率，尤其要体现在与性能测试相关的 测试代码编写上。因此测试人员要具备一定的算法设计能力。依据作者的经验， 测试工程师至少应该掌握 Java、C#、C++之中的一门语言以及相应的开发工具。 （3）网络、操作系统、数据库、中间件等知识。与开发人员相比，测试人员 掌握的知识要求更博，“艺多不压身”是个非常形象的比喻。由于测试中经常需要 配置、调试各种测试环境，而且在性能测试中还要对各种系统平台进行分析与调 优，因此测试人员需要掌握更多网络、操作系统、数据库等方面的知识。 在网络方面，测试人员应该掌握基本的网络协议以及网络工作原理。尤其要 掌握一些网络环境的配置知识，这些都是测试工作中经常用到的知识。 操作系统和中间件方面，应该掌握基本的使用及安装、配置等技能。例如， 很多应用系统都是基于 Unix、 linux 来运行的， 这就要求测试人员掌握其基本的操作命令以及相关工具软件的使用。而 WebLogic、Websphere 等中间件的安装与 配置方法也需要掌握一些。 数据库知识则是更应该掌握的基础知识。 现在的应用系统几乎离不开数据库。 因此，不但要掌握基本的安装、配置，还要掌握 SQL。测试人员至少应该掌握 M ysql、MS Sqlserver、Oracle 等常见数据库的使用。 作为一名测试人员，尽管不能精通所有的知识，但要想做好测试工作，应该尽可能地去 学习更多的与测试工作相关的专业知识。 l 行业知识 所谓行业主要指测试人员所在企业涉及的领域。例如很多 IT 企业从事石油、 电信、银行、电子政务、电子商务等行业领域的产品开发。行业知识即专业业务知识，是测 试人员做好测试工作的又一个前提条件。 只有深入了解了产品的业务流程， 才可以判断出开 发人员实现的功能项是否正确。 很多时候，软件运行起来没有异常，但是功能不一定正确。只有掌握了相关 的行业知识，才可以判断出用户的业务需求是否得到了实现。 行业知识与工作经验有一定关系，只有通过一定的时间积累才能达到较高的水平。 l 个人素养 作为一名优秀的测试工程师，首先要对测试工作有兴趣，因为测试工作在很多 时候多少显得有些枯燥。因此，先要热爱测试工作，才能做好测试工作。在个人素养方面， 除了具有前面介绍的专业技能和行业知识外， 测试人员还应该具有一些基本的品质， 即下面 的“五心”： （1） 专心： 主要指测试人员在执行测试任务的时候不可一心二用。 经验表明， 高度集中精神不但能够提高效率，还能发现更多的软件缺陷。团队中业绩最棒的 往往是做事精力最集中的那些成员。 （2）细心：主要指进行测试工作时要认真执行测试，不可以忽略一些细节。 如果不细心，则很难发现某些缺陷，例如一些界面的样式、文字等。 （3） 耐心： 很多测试工作有时候显得非常枯燥， 需要很大的耐心才可以做好。 如果做事情浮躁没有耐心，就不会做到“专心”和“细心”，就会让很多软件缺陷从 眼前逃过。 （4）责任心：责任心是做好工作必备的素质之一，测试工程师更应该高度负 责。如果测试中没有尽到责任，敷衍了事，甚至把测试工作交给用户去完成，这 样很可能引起非常严重的后果。 （5）自信心：自信心是目前多数测试工程师都缺少的一项素质，尤其在面对 测试开发等工作时，往往认为自己做不到。要想获得更好的职业发展，测试工程 师们应该努力学习，建立能“解决一切测试问题”的信心。性能测试人员的要求通 常要高于普通测试人员， 因此更应该努力去学习相关知识， 把测试工作做得更好。企业良好的管理流程、测试工程师的高技术水平仅仅是做好性能测试的必要条件。实际 工作中，性能测试会受其他诸多方面的影响，例如进度与成本压力、测试资源支持度等。但 是，只要我们有信心并为之不懈努力，相信一定能够做好性能测试工作！ 1.5 本章小结 开展性能测试工作，仅有 LoadRunner 是远远不够的，深入地理解性能测试理念是做好 性能测试工作的前提。因此在开始学习 LoadRunner 前，应该先搞清楚“性能测试是怎么一 回事”，并学会如何设计与组织性能测试。 本章首先从性能测试的基本概念入手来介绍性能测试的相关知识， 接着介绍了根据作者 多年经验总结的“全面性能测试模型”。借助本模型，可以更加合理地开展性能测试工作。本 章还介绍了性能测试调整方面的一些知识，以掌握性能测试调优的“度”。 在本章最后，又对如何做好性能测试进行了一些探讨――性能测试不但需要高超的技 能，更需要规范的企业管理流程。 掌握了性能测试的基础知识后，我们将逐步踏入 LoadRunner 的性能测试世界！5.1.1 性能分析基础知识在测试场景执行完成后，很多测试工程师认为最困难的阶段到来了――性能测试结果分 析。因此，本章似乎很自然地就成为了最重要的一章，但作者却认为性能测试分析并不是最 难的工作。所谓“万丈高楼平地起”，也就说明性能分析的准确性同样取决于此前所做的设计 与实施等“地基”是否可靠。 因此可以说， 性能测试分析仅仅是百米赛跑中的最后二十米而已。 当然，这并不是说性能测试分析不重要，因为“最后冲刺的二十米没有跑好”，前面工作做得 再好也是徒劳的。 由此不难理解， 性能测试分析工作开展的根基就是前面测试场景执行的结 果。要想保证性能测试分析的结论是正确的，那么测试结果数据首先就应该是正确的，而这 也意味着测试场景以及测试执行过程都应该是正确的。 实际上，性能测试从始至终都应该是相当严谨的一项工程，各个阶段的工作环环相扣， 因此，性能测试工程师应该认真对待每一个阶段的工作。如果一味地追求找出系统瓶颈，无 疑是舍本逐末的做法。 如果脱离实际应用或仅拿出某些孤立的测试结果来介绍 LoadRunner 的 Analysis 如何使 用，相信很多读者将会一头雾水，仍然不能解决实际问题。因此，本章首先结合案例来讲解如何分析性能测试结果，然后探讨 Analysis 的具体使用细节，这也是本章不同于第 3、4 章 的地方。 本章的主要内容如下： n 如何分析性能测试结果 n 如何从分析图中发现问题 n 分析图的处理方法 n Analysis 分析报告 5.1 如何分析性能测试结果 在 Controller 执行的测试场景结束后，首先要做的是判断采集到的结果数据是否真实有 效。 多数性能测试场景都需要迭代地进行测试， 因此很多测试结果本身就不能反映真正的问 题，而深入分析这样的结果纯属浪费时间。在本书中，主要探讨如何针对有效的测试结果数 据进行分析。 判断测试结果是否有效，通常按下面的步骤进行： 第一步：在整个测试场景的执行过程中，测试环境是否正常。如果在测试过程中出现过 异常，那么这样得出的结果往往不准确，无须进行分析。 例如，在测试执行过程中，测试机的 CPU 利用率经常达到 100%、测试环境的网络不稳 定、一些系统参数配置不正确等等，这样得出的测试结果没有必要进行分析，应该重新设置 测试场景或调整测试环境，再次执行测试。 第二步：测试场景的设置是否正确、合理。测试场景的设置是否正确对测试结果有很大 的影响。因此，当测试出现异常时，我们要对场景设置进行分析。 一些新手在使用 Controller 执行测试时，可能会同时在一台 PC 上加载全部虚拟用户― ―例如同时加载 1000 个虚拟用户，如果客户端来不及处理，就会有很多虚拟用户因不能初 始化而失败。 失败的根本原因不是被测试的应用服务器不能处理， 而是压力根本没有传输过 去。正确的做法是增加更多的 Generator 或逐步加压，使测试场景运行起来。 第三步：测试结果是否直接暴露出系统的一些问题。对测试场景的整个执行过程，没有 必要对压力下系统运行正常的结果进行分析，因为这样的结果不能反映出系统的性能问题， 应该进一步调整场景（比如增大压力）进行测试。在测试过程中使系统表现不正常的测试场景生成的结果则要进行深入分析。 实际上， 分析能够反映性能问题的测试结果才是性能分析 阶段的主要工作。 测试结果直接暴露系统存在性能问题的情形很多， 例如在测试过程中一些用户事务响应 时间过长、系统支持的最大并发用户数过低、系统的应用服务器 CPU 利用率过高或内存不 足等。对这类测试结果，性能测试人员需要借助 Analysis 对其进行深入分析，以发现一些潜 在的性能问题。 本节先介绍性能测试分析的基础知识，然后介绍 LoadRunner Analysis 的使用基础，最 后结合案例介绍如何找出并解决系统的性能问题。 5.1.1 性能分析基础知识 性能分析的基本原则 确定测试结果有效之后，接下来就要开始对测试数据进行深入的挖掘了。面对测试工具 产生的纷繁复杂的原始测试数据，如何来进行分析呢？一个普遍遵循的原则是“由外而内， 由表及里，层层深入”，如图 5-1 所示。图 5-1 性能分析原则示意图 对于一个应用系统，性能开始出现下降的最直接表象就是系统的响应时间变长。于是， 系统响应时间成为分析性能的起点。 性能分析的原则如图 5-1 所示， 首先应该从原始测试数 据中查看系统响应时间，判断它是否满足用户性能的期望。如果不能满足，则说明系统的性 能出现了问题。发现系统存在问题后，就要判断系统在哪个环节出现了瓶颈。 现在的 IT 系统架构极其复杂，任何一个环节出现瓶颈，都会导致系统出现性能问题。 要准确地判断瓶颈在什么地方，的确是一个棘手的问题。不过，任何复杂的系统都分为网络 和服务器两部分。因此要考察的第二个问题就是：系统的瓶颈是出现在网络环节，还是服务 器环节？ 如图 5-2 所示，用户从客户端发起的请求数据包经过网络，传递到应用服务器，最后到 达数据库服务器，服务器处理完毕后按原路返回到客户端。在这个处理过程中，可以把整个时间分为两段：一段是 Tn，即网络的响应时间；一段是 Ts，即服务器的响应时间，包括应 用服务器和数据库服务器的响应时间。对比 Tn 和 Ts，就很容易知道系统在哪些环节的响应 时间比例较大。图 5-2 客户交易分解图 只要判断出系统的瓶颈是出现在网络或是服务器段， 就可以层层推进对相应环节的组件 响应时间进行深入分析，直到最后找到造成性能问题的根本原因。 借助 LoadRunner 的分析组件 Analysis，很容易按照“由外而内，由表及里，层层深入” 的原则进行分析，快速将问题定位。例如从图 5-3 中可以直接看出瓶颈出现在网络上。图 5-3 客户请求第一个 Buffer 的分解示例 性能分析任重而道远 看了前面的内容，也许很多人会以为性能分析非常容易，借助工具即可完成，但实则不 然。即使有了正确的测试结果，也不一定能对系统的性能问题进行正确定位。例如，服务器 的内存不够可能会引起较大的磁盘 I/O， 进而导致 CPU 利用率居高不下， 其根本原因可能是程序内部存在内存泄漏，而不是内存瓶颈。这类问题不但要靠经验，更要靠对系统的深入了 解。 不难看出， 性能测试是难度较大的一项工作， 绝不是一蹴而就的事情。 根据作者的经验， 最好的办法是把性能分析贯穿于性能测试过程的始末，所有人员都应该给予高度关注。 实际上， 性能测试分析从测试场景执行时就开始了， 而不是仅仅在测试结束后才进行的。 例如，在测试执行过程中可以借助分析数据库，观察事务实时响应时间来发现一些问题。 除了这些通用的方法外，性能测试分析人员还应该在测试设计、执行、分析等各阶段把 工作做透，只有这样才能把性能测试工作做好。 5.1.2 Analysis 使用基础 在测试场景执行过程中，LoadRunner 采集了虚拟用户、操作系统、应用服务器等各种 运行数据，这些数据成为分析系统性能的重要参考资料。当测试场景运行结束后，就可以通 过 Analysis 对这些测试结果进行专门的分析，以发现系统的潜在问题。 LoadRunner 的 Analysis 是一个独立模块， 本节将介绍它的主要功能以及基本使用方法。 在后面的 5.2 节中，将详细介绍如何借助各类数据图表来分析系统的性能问题。 Analysis 的基本功能及使用 启动 Analysis 有 4 种方式：在 Controller 启动场景前选中其菜单的“Run→Auto Load A nalysis”；在 Controller 工具栏中点击第一个 图标；在 Controller 工具栏中点击第二个 图标；从开始菜单依次点击“Mercury LoadRunner→Applications→Analysis”。其中，前 两种方式在打开 Analysis 后会自动分析当前场景的运行结果，后两种方式仅打开 Analysis 应用程序，需要手动选择测试结果文件来产生分析图。 在测试结束并完成测试结果数据收集后，就可以启动 Analysis 打开测试结果文件，将其 导入 Microsoft Access 数据库，然后按照设置的模板打开默认的结果分析图。通常的分析器 默认界面如图 5-4 所示。 利用 Analysis 进行分析的第一步是查看分析概要报告（Analysis Summary），图 5-4 中显示的即为分析概要报告。 分析概要报告展示了场景运行的统计信息、 事务响应时间概述、 HTTP 响应概述（对于 Web 测试）等。 在分析概要结果中，重点查看虚拟用户的运行情况和事务综述。对虚拟用户，主要查看 最大并发用户数目；对事务综述，则要查看最大、最小、平均、“90％”事务最大响应时间、 通过事务数量、失败事务数量等。图 5-4 Analysis 的默认分析概要界面 在图 5-4 所示的 Analysis 界面中，点击 界面，在这里可以查看 Analysis 提供的全部分析图。 从图 5-5 中可以看出， 对于一个和 Web 相关的测试结果， Analysis 主要提供了六大类分 析图。下面简要介绍各类分析图的含义及用途。 将进入到图 5-5 所示的新的分析图图 5-5 打开新的分析图界面 虚拟用户（Vusers）图 虚拟用户图分为运行状态的虚拟用户图、虚拟用户概要图和集合点 图 3 类。主要借助其查看场景与会话的虚拟用户行为。Errors 图 Errors 图主要有错误统计、每秒错误数量两类。借助 Errors 图可以发现服务器什 么时间发生错误以及错误的统计信息，可以分析服务器的处理能力。 事务（Transactions）图 Analysis 和事务相关的分析图表有事务综述图、事务平均响应时 间图、每秒通过事务数图、每秒通过事务总数图、事务性能摘要图、事务响应时间与负载分 析图、事务响应时间（百分比）图、事务响应时间分布图等，通过这些图表可以很容易分析 应用系统事务的执行情况。 Web 资源（Web Resources）图 Web 资源图主要有 Web 服务器的吞吐率图、点击率图、 返回的 HTTP 状态代码图、每秒 HTTP 响应数图、每秒重试次数图、重试概述图、服务器连 接数概要图、服务器每秒建立的连接数量图等。借助 Web 资源图，可以深入地分析服务器 的性能。 网页细分（Web Page Breakdown）图 在 Controller 中启动网页细分功能后，才可以在 A nalysis 中查看网页细分图，启动细分功能的具体步骤是：在 Controller 菜单中选择“Diagno stics→Distribution”进入图 5-6 所示的界面，在图 5-6 中同时选中“Enable the following di agnostics”和“Web Page Diagnostics（Max Allowed Distribution 10%）”复选框。图 5-6 启动网页细分图功能 网页细分图主要有页面分解总图、页面组件细分图、页面组件分解（随时间变化）图、 页面下载时间细分图、页面下载时间细分（随时间变化）图、第一次缓冲时间细分图、第一 次缓冲时间细分（随时间变化）图、已下载组件大小图。借助网页细分图可以分析页面元素 是否影响事务响应时间。 系统资源（System Resources）图 系统资源图显示在场景运行期间，由联机监控获得的系 统资源使用情况。要想获得系统资源图，必须预先指定相关的计数器。关于监控系统资源的 方法，可以参考第 3 章的相关内容。 在 5.4 节中，我们将详细介绍如何查看各类具体的分析图。 如何看 Analysis 分析图 面对 Analysis 提供的几十个测试结果分析图，很多人会感到无所适从，不知如何入手。 实际上，性能测试分析要求执行人员更加谨慎和细心，不能放过任何一个缺陷，尤其要深入 到系统内部来进行分析。同时，当分析结果时还应该借助 Analysis 以外的各种分析工具。例 如，可以借助 Oracle 提供的监控与分析工具，也可以借助 WebLogic 提供的监控与分析工具，要想尽一切办法来发现系统瓶颈。在 5.1.3 节的案例中，Oracle 自带的 SQL 分析功能 对性能定位起了至关重要的作用。 下面介绍一些通用的性能测试分析流程。 第一步：从分析 S