详情
本书从测试项目实战需求出发，介绍了软件测试的分类、测试的流程、性能测试技术和LoadRunner工具应用的实战知识。为有效地解决工作中遇到的问题，将实践中经常遇到的问题总结汇总成几十个解决方案，详细的项目案例，完整的性能测试方案、计划、用例设计、性能总结及相关交付文档为用户做好实际项目提供了强大的参考，同时本书的各个章节都配有练习和实际面试题，为日后走上工作岗位打下良好基础。
书名：软件性能测试与LoadRunner实战教程（第2版）
ISBN：978-7-115-51541-4
本书由人民邮电出版社发行数字版。版权所有，侵权必究。
您购买的人民邮电出版社电子书仅供您个人使用，未经授权，不得以任何方式复制和传播本书内容。
我们愿意相信读者具有这样的良知和觉悟，与我们共同保护知识产权。
如果购买者有侵权行为，我们可能对该用户实施包括但不限于关闭该帐号等维权措施，并可能追究法律责任。
编 著 于 涌
责任编辑 张 涛
人民邮电出版社出版发行 北京市丰台区成寿寺路11号
邮编 100164 电子邮件 315@ptpress.com.cn
网址 http://www.ptpress.com.cn
读者服务热线：(010)81055410
反盗版热线：(010)81055315
本书从测试项目实战需求出发，讲述了软件测试的分类以及测试的流程等，还重点讲述了性能测试技术和LoadRunner 11.0与12.60工具应用的实战知识。书中将实践中经常遇到的问题进行总结汇总成几十个解决方案，详细的项目案例，完整的性能测试方案、计划、用例设计、性能总结及相关交付文档，为读者做好实际项目提供参考和方向引导，同时为了满足培训机构及初学者的需要，本书的各个章节都配有练习题或实际面试题。
本书适合测试初学者、测试人员、测试经理以及开发人员学习，也适合作为大中专院校相关专业师生的学习用书，以及培训机构的教材。
随着计算机行业的蓬勃发展和用户要求的不断提高，现行应用软件的功能已经变得越来越强大，系统也越来越复杂。软件用户关注的内容不再仅仅是功能实现的正确性，系统的性能表现也同样是用户关注的重点，而性能测试是测试系统性能的主要手段，因此它是软件测试的重中之重。另外，性能测试通常和应用程序、操作系统、数据库服务器、中间件服务器、网络设备等有关，如何能够快速、有效地定位并解决性能问题，无疑是性能测试人员面临的一个重要任务。为了帮助测试人员快速掌握软件测试基础、性能测试技术及性能测试工具的实战应用，作者精心编写了本书。
作者编写的《软件性能测试与LoadRunner实战教程》《精通软件性能测试与LoadRunner实战》和《精通软件性能测试与LoadRunner最佳实战》3部作品面市后，受到广大软件测试从业者及很多高校和培训机构的关注与好评，在此向一直以来支持作者的机构和读者表示衷心的感谢。目前LoadRunner 新版本为LoadRunner 12.60，而市场上应用的主流版本为LoadRunner 11.0，故本书以LoadRunner 11.0版本作为主要讲解内容，同时考虑到仍有很多读者对LoadRunner 新版本感兴趣，本书也专门用一章来详细讲述在LoadRunner 12.60版本中出现的一些新技术、新的解决方案。采纳了读者对该书上一版提出的一些好的建议，本次修订增加了章节练习、面试题以及综合性的考题等内容；并对上一版读者提出的所有问题进行了修改、完善。本书在结构和内容上都非常系统化、完整化，实用性非常强，希望通过作者的努力，本书能帮助开阔读者在性能测试方面的视野，提升实战水平。
本书为从事软件测试、性能测试及LoadRunner工具应用的读者答疑解惑，并结合案例讲解性能测试中的实战技术。
第1章介绍软件测试的现状以及发展前景、软件测试相关概念、软件生命周期、软件测试的定义与分类、软件开发与软件测试的关系、性能指标及相关计算公式等内容。
第2章介绍性能测试的基本过程，以及“性能测试需求分析”“性能测试计划”“性能测试用例”“测试脚本编写”“测试场景设计”“测试场景运行”“场景运行监控”“运行结果分析”“系统性能调优”“性能测试总结”的内容与注意事项。
第3章详细介绍了工具及其样例程序的安装过程，重点介绍了工具的运行机制及组成部分，同时结合生动的生活场景深入浅出地讲解工具中集合点、事务、检查点、思考时间等重要概念。
第4章深度解析LoadRunner 11.0相关功能应用，对LoadRunner 11.0工具的VuGen、Controller、Analysis 应用的相关功能和设置的含义及应用方法等内容进行了深入讲解。
第5章以一个Web样例程序作为实例，将工具的VuGen 、Controller、Analysis 三者有机地结合起来，把集合点、事务、检查点、参数化等技术的应用集中在此实例得以体现。介绍了一个小的性能测试案例的需求提出、需求分析、脚本编写和完善、数据准备、场景设计、监控、执行、分析的完整过程。
第6章介绍了LoadRunner脚本语言和C语言开发、LoadRunner关联问题、关联技术应用、动态链接库函数调用、特殊函数应用的注意事项、自定义函数应用等。这部分是软件测试脚本开发的基础，建议读者认真阅读。
第7章结合LoadRunner 新版本LoadRunner 12.60，介绍了Vugen功能改进与实用操作、同步录制和异步录制，以及如何在Controller中实现对JMeter脚本的支持、应用Vugen开发Selenium脚本等实用方法。
第8章结合作者工作经验、学员以及网上论坛经常提出的问题，总结了关于工具设置、工具使用、结果分析等问题的解决方案，旨在举一反三，帮助读者克服实际工作中的难题。
强大的LoadRunner不仅在性能测试方面表现卓越，也是接口测试利器。第9章详细讲解了接口测试的执行过程（包括接口测试需求、接口测试功能性用例设计、测试用例脚本实现、接口性能测试用例设计、接口性能测试脚本实现、性能测试场景执行和性能测试执行结果分析与总结）。
第10章详细介绍了外包性能测试项目及项目性能测试的实施过程，以及“性能测试计划”“性能测试用例”“测试脚本编写”“测试场景设计”“测试场景运行”“场景运行监控”“运行结果分析”“系统性能调优”“性能测试总结”等，并介绍了文档的编写和实施过程中各环节的注意事项。
第11章提供软件性能测试综合模拟试题、LoadRunner性能测试的英文面试题、常考的智力面试题和找测试工作的策略等内容。
本书图文结合，通俗易懂，赠送的学习资料中（www.ptpress.com.cn网站下载）提供了样例程序、脚本代码、各章的PPT，以及一些测试模板文件（具体包括测试计划、测试总结、测试日志、功能测试和性能测试用例等模板）。希望读者在阅读本书的同时，能够边看边实践，深入理解脚本，这样可以提高学习效率，尽快将本书介绍的知识应用于项目的性能测试中。
本书遵循如下行文约定。
| 符号和术语 |
含 义 |
示 例 |
|---|---|---|
| > |
表示按此层次结构，主要应用于菜单项 |
如菜单项【Edit】>【Find】 |
| “” |
表示键入双引号中的文字或引用的系统界面中的术语/表达 |
如在“Update value on”列表中选择一个数据更新方式 |
| 【】 |
表示屏幕对象名（菜单名或按钮） |
如菜单项【Edit】>【Find】 单击【OK】按钮 |
| 【重点提示】 |
知识点总结内容 |
1．事务必须成对出现，即一个事务有事务开始，必然也有事务结束 |
于涌，具有近20年软件开发和软件测试方面的工作经验。先后担任程序员、高级程序员、测试分析师、高级测试经理、测试总监等职位。拥有多年的软件开发、软件测试项目实践和教学经验。尤其擅长自动化测试、工具应用、单元测试等方面的工作。曾为多个软件公司提供软件测试知识、软件性能测试、性能测试工具LoadRunner、功能测试工具QTP、WinRunner、JMeter等内容的培训工作。
如果读者在阅读本书过程中发现有什么错误，欢迎与作者联系，以便作者及时纠正。本书的勘误、更新、答疑信息都可以从作者的博客——测试者家园（http:// tester2test.blog.51cto.com）上获得，答疑QQ群：50788246。如果您在阅读本书过程中，发现错误或者疑问，也可以和本书编辑联系，联系邮箱为zhangtao@ptpress.com.cn。
本书内容建立在前人研究成果的基础上。因此，在本书完成之际，我对那些为本书提供帮助的读者和朋友表示衷心的感谢。目前已经有很多高校使用作者之前写作的图书作为性能测试课程的教材，这令我非常骄傲和自豪。本书配有各章节的PPT课件和章节练习、综合练习等丰富内容，适合作为高校及培训机构性能测试相关课程的教材。我衷心希望通过高校老师和我的共同努力，不断增强学生的综合能力，使得理论学习和实际工作应用齐头并进，让毕业生尽快融入测试工作并成为企业的中坚力量。
在本书编写过程中，很多测试同行为本书的编写提供了很多宝贵建议，我的学员和网友提供了很多写作素材和资料，在此表示感谢。同时参加编写的还有于跃、张书铭、岳玉清、于来河等。
作者
本书由异步社区出品，社区（https://www.epubit.com/）为您提供相关资源和后续服务。
本书提供如下资源：
要获得以上配套资源，请在异步社区本书页面中点击
，跳转到下载界面，按提示进行操作即可。注意：为保证购书读者的权益，该操作会给出相关提示，要求输入提取码进行验证。
如果您是教师，希望获得教学配套资源，请在社区本书页面中直接联系本书的责任编辑。
作者和编辑尽最大努力来确保书中内容的准确性，但难免会存在疏漏。欢迎您将发现的问题反馈给我们，帮助我们提升图书的质量。
当您发现错误时，请登录异步社区，按书名搜索，进入本书页面，点击“提交勘误”，输入勘误信息，点击“提交”按钮即可。本书的作者和编辑会对您提交的勘误进行审核，确认并接受后，您将获赠异步社区的100积分。积分可用于在异步社区兑换优惠券、样书或奖品。
我们的联系邮箱是contact@epubit.com.cn。
如果您对本书有任何疑问或建议，请您发邮件给我们，并请在邮件标题中注明本书书名，以便我们更高效地做出反馈。
如果您有兴趣出版图书、录制教学视频，或者参与图书翻译、技术审校等工作，可以发邮件给我们；有意出版图书的作者也可以到异步社区在线提交投稿（直接访问www.epubit.com/selfpublish/submission即可）。
如果您是学校、培训机构或企业，想批量购买本书或异步社区出版的其他图书，也可以发邮件给我们。
如果您在网上发现有针对异步社区出品图书的各种形式的盗版行为，包括对图书全部或部分内容的非授权传播，请您将怀疑有侵权行为的链接发邮件给我们。您的这一举动是对作者权益的保护，也是我们持续为您提供有价值的内容的动力之源。
“异步社区”是人民邮电出版社旗下IT专业图书社区，致力于出版精品IT技术图书和相关学习产品，为作译者提供优质出版服务。异步社区创办于2015年8月，提供大量精品IT技术图书和电子书，以及高品质技术文章和视频课程。更多详情请访问异步社区官网https://www.epubit.com。
“异步图书”是由异步社区编辑团队策划出版的精品IT专业图书的品牌，依托于人民邮电出版社近30年的计算机图书出版积累和专业编辑团队，相关图书在封面上印有异步图书的LOGO。异步图书的出版领域包括软件开发、大数据、AI、测试、前端、网络技术等。
异步社区
微信服务号
随着互联网的蓬勃发展，软件的性能测试已经越来越受到软件开发商、用户的重视。一个软件前期用户较少，随着用户的逐步增长，以及宣传力度的加强，软件的用户可能会成几倍、几十倍，甚至几百倍数量级增长，如果不经过性能测试，通常软件系统在该情况下可能会崩溃，所以性能测试是非常重要的。那么通常在什么情况下需要引入性能测试呢？
下面是需要进行性能测试的一些场景。
软件系统从早期的单机系统、客户端/服务器系统到现在被广泛应用的分布式系统，在满足用户强大功能需求的同时，在其系统的架构和实现等方面也变得更加复杂。系统功能越来越庞大，系统实现越来越复杂，系统用户越来越多，但是系统用户对系统的要求却变得越来越高，通常系统用户在软件性能最关注的两个方面是耗费成本和处理能力。耗费成本：系统的运行环境，即软件、硬件配置要求不是很高，购买成本较低，间接其实意味着系统在运行时使用较少的CPU、内存、网络等资源。处理能力：系统的业务处理能力，包括单位时间内处理的业务数量、每个业务处理的时间、能支持多少用户同时做业务、系统能否长时间稳定提供服务等，这也就是后续将会介绍性能指标方面的一些内容，这些内容也是最直接和最真实的系统用户感受。
系统用户只关注软件系统的性能表现和整个系统耗费的软件、硬件成本，而不关注软件、硬件系统的部署和内部实现的问题。这里需要指出的是，随着Ajax（异步JavaScript和XML）等技术的广泛应用，其客户端展现的数据有可能会出现少部分数据返回之后就立刻将数据呈现在用户面前，这样无疑会带给用户良好的性能感受，但是从中也会发现有时看到的响应时间在一定程度上有一些的主观色彩。
作为软件开发群体，他们是系统产品的缔造者，如果把软件系统看成一个孩子的话，那么软件开发群体无疑就是这个“孩子”的“父母”，每个孩子的父母无疑都希望自己的孩子既聪明、漂亮，又健康。作为软件来讲，“健康”体现在系统能够持续稳定的运行；“聪明”体现在系统的性能表现良好，业务响应速度准确、快速；“漂亮”则体现在系统的功能强大，易用性、兼容性等方面突出，这样的“孩子”相信一定会人见人爱。结合性能测试方面来看，业务操作正常、系统响应快速、稳定运行是开发人员最关注的内容。要想设计出一款好的软件系统并不容易，它不仅需要好的架构师从架构设计方面具有良好的规划和选择，还要具有丰富经验的设计人员在应用程序和数据库的结构设计、算法实现等方面都充分考虑整个系统的执行效率和可扩展性，避免设计和实现过程中产生错误和漏洞。通常，采用哪种架构和技术，其性能也就注定了只能在一定的范围内变动，如果选择失误，则软件系统必将在性能方面有缺陷。此外，数据库的设计、存储过程、SQL语句等的执行效率、程序代码、算法的执行效率等也直接影响到系统的性能表现，丰富的工作经验也会对系统性能稳定性和执行效率有较大的帮助。
软件开发群体更注重系统的框架设计、程序设计、数据库设计、代码和SQL语句等的执行效率，这也是系统良好性能的根本所在。
系统维护人员更注重应用服务器、数据库服务器等软硬件的配置及网络硬件设备配置、拓扑结构等方面的内容，通过更换、调整软硬件及网络结构的配置能否使得系统性能更好。网络的拓扑结构及网络通信传输介质、方式等会影响到网络部分的性能，负载均衡无疑也是改善性能的一种很重要的方式。像具有内存、CPU、高速硬盘等硬件设备的服务器，无疑会给系统带来一定范围的性能提升。此外，操作系统、数据库、中间件等软件的版本和对应设置也是很重要的内容。在作者经历的一些项目中，除了处理网络结构、硬件设备差异等原因引起的性能测试问题外，有相当数量的重要原因就是因为操作系统、数据库、中间件等的配置不合理而引起的性能问题。例如，由于数据库网络连接数和操作系统终端连接数设置得过小等原因，引起的性能瓶颈。关于常见的性能指标、相关指标的含义和阈值等内容和性能测试过程涉及的一些专业术语，将在后续章节进行介绍，这里不赘述。
很难说是功能测试重要，还是性能测试重要，一款优秀的软件产品，无疑是在功能上正确实现了用户需要的业务功能，且操作方便、交互界面良好，在性能方面表现为及时、快速地响应了所有用户的业务操作请求，所以经过严格的功能测试和性能测试是一款成功软件产品的重要环节。功能测试和性能测试密不可分的，没有实现正确业务功能的软件产品做性能测试是没有意义的，一款软件产品即使业务功能实现了，但是业务处理能力低下，也必将被淘汰。
经常会听到很多人问一个问题：是先做功能测试，还是先做性能测试呢？其实这个问题很简单，这要看做性能测试的目标是什么。如果要测试的是一款软件产品，通常情况下，是在每个大版本的功能测试完成后，进行性能测试。因为只有保证正确实现了用户要求的功能后，做性能测试才会有意义。功能实现不正确，就意味着后续势必要重新进行代码或数据等方面的修改，每一次代码、数据等方面的变更都有可能对系统性能造成影响，所以必须了解每个大版本完成后，相关的功能和性能表现是否符合预期。但是，在有些情况下，性能测试工作必须提前，如同一系统可以采用Java和.Net两种构架，决定用哪个。同样的系统用不同的语言、框架实现效果也会有所不同。为了系统的性能更好，在系统实现前期，可以考虑设计一个小的Demo，满足系统的关键性功能即可，界面和功能不需要做得完美，设计同样的场景，实际考察不同语言、不同框架之间的性能差异，然后选择性能好的语言、框架开发软件产品。在上述情况下，既可缩短选型的时间，又保证有效地了解后续产品的性能情况。
综上所述，功能测试和性能测试是相辅相成的，对于一款优秀的软件产品来讲，它们是不可缺少的两个重要测试环节，但根据不同目标的性能测试情况，要因地制宜，结合实际需求，选择合适的时间点进行，减少不必要的人力、物力浪费，实现利益最大化。
系统的性能是一个很大的概念，覆盖面非常广泛，软件系统的性能包括执行效率、资源占用、系统稳定性、安全性、兼容性、可靠性、可扩展性等。性能测试是为描述测试对象与性能相关的特征并对其进行评价而实施和执行的一类测试。性能测试主要通过自动化的测试工具模拟多种正常、峰值以及异常负载条件来对系统的各项性能指标进行测试。通常把性能测试、负载测试、压力测试等统称为性能测试。
负载测试是通过逐步增加系统负载，测试系统性能的变化，并最终确定在满足系统性能指标的前提下，系统所能够承受的最大负载量的测试。简而言之，负载测试是通过逐步加压的方式来确定系统的处理能力和能够承受的各项阈值。例如，通过逐步加压得到“响应时间不超过10秒”“服务器平均CPU利用率低于85%”等指标的阈值。
压力测试是通过逐步增加系统负载，测试系统性能的变化，并最终确定在什么负载条件下系统性能处于失效状态来获得系统能提供的最大服务级别的测试。
配置测试主要是通过对被测试软件的软硬件配置的测试，找到系统各项资源的最优分配原则。配置测试能充分利用有限的软硬件资源，发挥系统的最佳处理能力，同时可以将其与其他性能测试类型联合应用，从而为系统调优提供重要依据。
并发测试是测试多个用户同时访问同一个应用、同一个模块或者数据记录时是否存在死锁或者其他性能问题，所以几乎所有的性能测试都会涉及一些并发测试。因为并发测试对时间的要求比较苛刻，通常并发用户的模拟都是借助于工具，采用多线程或多进程方式来模拟多个虚拟用户的并发性操作。在后续介绍LoadRunner 工具时，有一个集合点的概念，它就是用来模拟并发的，可以在VuGen中设置集合点，在Controller中设置其对应的策略来模拟用例设计的场景。
容量测试是在一定的软件、硬件条件下，在数据库中构造不同数量级的记录数量，通过运行一种或多种业务场景，在一定虚拟用户数量的情况下，获取不同数量级别的性能指标，从而得到数据库能够处理的最大会话能力、最大容量等。系统可处理同时在线的最大用户数，通常和数据库有关。
可靠性测试是通过给系统加载一定的业务压力（如CPU资源在70%～90%的使用率）的情况下，运行一段时间，检查系统是否稳定。因为运行时间较长，所以通常可以测试出系统是否有内存泄露等问题。
在实际的性能测试过程中，也许用户经常会碰到要求7 × 24小时，稳定运行的系统性能测试需求，对于这种稳定性要求较高的系统，可靠性测试尤为重要，但通常一次可靠性测试不可能执行1年时间，因此在多数情况下，可靠性测试是执行一段时间，如24小时、3 × 24小时或7 × 24小时来模拟长时间运行，通过长时间运行的相关监控和结果来判断能否满足需求，平均故障间隔时间（MTBF）是衡量可靠性的一项重要指标。
对于有冗余备份和负载均衡的系统，通过失败测试来检验如果系统局部发生故障，用户能否继续使用系统，用户受到多大的影响，如几台机器做均衡负载，一台或几台机器垮掉后系统能够承受的压力。
性能测试中有很多非常重要的概念，如吞吐量、最大并发用户数、最大在线用户数等。有很多读者也非常关心，如何针对自身的系统确定当前系统，在什么情况下可以满足系统吞吐量、并发用户数等指标要求。下面针对这些概念进行介绍。
吞吐量（throughput）是指单位时间内处理的客户端请求数量，直接体现软件系统的性能承载能力。通常情况下，吞吐量用“请求数/秒”或“页面数/秒”来衡量。从业务角度来看，吞吐量也可以用“业务数/小时”“业务数/天”“访问人数/天”和“页面访问量/天”来衡量。从网络角度来看，还可以用“字节数/小时”和“字节数/天”等来衡量网络的流量。
吞吐量是大型门户网站以及各种电子商务网站衡量自身负载能力的一个很重要的指标，一般吞吐量越大，系统单位时间内处理的数据越多，系统的负载能力就越强。
吞吐量是衡量服务器承受能力的重要指标。在容量测试中，吞吐量是重点关注的指标，因为它能够说明系统的负载能力，而且在性能调试过程中，吞吐量也具有非常重要的价值。例如，Empirix公司在报告中声称，在他们所发现的性能问题中，有80%是因为吞吐的限制而引起性能问题。
显而易见，吞吐量指标在性能测试中占有重要地位。那么吞吐量会受到哪些因素影响，该指标和虚拟用户数、用户请求数等指标有何关系呢？吞吐量和很多因素有关，如服务器的硬件配置、网络的拓扑结构、网络传输介质、软件的技术架构等。此外，吞吐量和并发用户数之间存在一定的联系。通常在没有遇到性能瓶颈时，吞吐量可以采用下面的公式计算。
这里，F表示吞吐量；
表示并发虚拟用户（concurrency virtual user）数，R表示每个VU（Virtual User）发出的请求数量，T表示性能测试所用的时间。但如果遇到了性能瓶颈，则吞吐量和VU数量之间就不再符合给出公式的关系。
并发（concurrency）最简单的描述是指多个同时发生的业务操作。例如，100个用户同时单击登录页面的“登录”按钮操作。通常，应用系统会随着用户同时应用某个具体的模块，而导致资源争用的问题，例如，50个用户同时执行统计分析操作，由于统计业务涉及很多数据提取和科学计算问题，所以这时内存和CPU很有可能会出现瓶颈。并发性测试描述的是多个客户端同时向服务器发出请求，考察服务器端承受能力的一种性能测试方式。
有很多用户在进行性能测试过程中，对“系统用户数”“在线用户数”“并发用户数”的概念不是很清楚，这里举一个例子来对这几个概念进行说明。假设一个综合性的网站，用户只有注册后登录系统才能够享有新闻、论坛、博客、免费信箱等服务内容。通过数据库统计可以知道，系统的用户数量为4000，4000即“系统用户数”。通过操作日志可以知道，系统最高峰时有500个用户同时在线，关于在线用户有很多第三方插件可以进行统计读者可以自行搜索相关插件。这500个用户的需求肯定是不尽相同的，有的人喜欢看新闻，有的人喜欢写博客、收发邮件等。假设这500个用户中有70%在论坛看邮件、帖子、新闻以及他人的博客（有一点需要提醒大家的是，“看”这个操作是不会对服务器端造成压力的）；有 10%在写邮件和发布帖子（用户仅在发送或者提交写的邮件或者发布新帖时，才会对系统服务器端造成压力）；有 10%的用户什么都没有做；有 10%的用户不停地从一个页面跳到另一个页面。在这种场景下，通常我们说有 10%的用户真正对服务器构成了压力（即 10%不停地在网页间跳转的用户），极端情况下，可以把写邮件和发布帖子的另外 10%的用户加上（此时假设这些用户不间断地发送邮件或发布帖子），也就是说此时有20%的用户对服务器造成压力。从上面的例子可以看出，服务器承受的压力不仅取决于业务并发用户数，还取决于用户的业务场景。
那么如何获得在性能测试过程中大家都很关心的并发用户数呢？下面给出《软件性能测试过程详解与案例剖析》一书中的一些用于估算并发用户数的公式。
（1）
（2）
在式（1）中，C是平均的并发用户数；n是login session的数量；L是login session的平均长度；T是考察的时间段长度。
式（2）给出了并发用户数峰值的计算公式，其中，
是指并发用户数的峰值，C就是式（1）中得到的平均的并发用户数。该公式是假设用户的login session产生符合泊松分布而估算得到的。
下面通过一个实例介绍公式的应用。假设有一个OA系统，该系统有3000个用户，平均每天大约有400个用户要访问该系统，对于一个典型用户来说，一天之内用户从登录到退出系统的平均时间为4小时，在一天的时间内，用户只在8小时内使用该系统。则根据式（1）和式（2），可以得到
，
。
除了上述方法以外，还有一种应用更为广泛的估算方法，当然这种方法的精度较差，这种公式的计算是由平时经验的积累得到，相应经验公式为：
和
。通常，用访问系统用户最大数量的10%作为平均的并发用户数，并发用户数的最大数量可以通过并发数乘以一个调整因子r得到，r的取值在不同的行业可能会有所不同，通常r的取值为2～3。系统用户最大数量可以通过系统操作日志或者系统全局变量分析得到，在没有系统日志等技术时，也可以根据同类型的网站分析或者估算得到（这种方法存在一定的偏差，用户应该酌情选择）。现在很多网站都提供非常好的网站访问量统计，如http://www.51.la统计网站，用户可以申请一个账户，然后只要把该网站提供的代码嵌入网站，就可以通过访问该网站来查看每天的访问量、每月的访问量等信息。r（调整因子）不是一朝一夕就可以确定的，通常需要根据多次性能测试的数据，才能够得出比较准确的取值。因此，用户在平时进行并发测试过程中，一定要注意数据的积累，针对本行业的特点，确定一个比较合理的 r值。如果能知道平均每个用户发出的请求数量（假设为u），则系统接受的总请求数就可以通过u × C估算出来，这个值也就是平时所说的吞吐量。
思考时间（think time）就是在录制脚本过程中，每个请求之间的时间间隔，即操作过程中停顿的时间。在实际应用系统时，不会一个接一个不停地发送请求，通常在发出一个请求以后，都会停顿一定的时间来发送下一个请求。
为了真实描述用户操作的实际场景，在录制脚本的过程中，通常LoadRunner也会录制这些思考时间，在脚本中，lr_think_time()函数就是实现前面所说的思考时间，它实现了在两个请求之间的停顿。
在实际的性能测试过程中，作为一名性能测试人员，可能非常关心怎样设置思考时间才能最符合实际情况。其实，思考时间与迭代次数、并发用户数以及吞吐量存在一定的关系。
如
说明吞吐量是VU，数量是
、每个用户发出请求数
和时间
的函数，而其中的又可以用时间和用户的思考时间
计算得出，
，由此可得，吞吐量与成正比，与成反比。
那么，究竟如何选择合适的思考时间呢？下面给出计算思考时间的一般步骤。
（1）计算出系统的并发用户数。
（2）统计出系统平均的吞吐量。
（3）统计出平均每个用户发出的请求数量。
（4）计算出思考时间。
为了使性能测试的场景更加符合真实的情况，可以考虑在公式
的基础上再乘以一个比例因子，或者指定一个动态随机变化的范围来仿真实际情况。
经常会在网络上看到有很多做性能测试是否引入思考时间的争论。作者认为思考时间是为了模拟真实的操作应运而生的，所以如果要模拟真实场景的性能测试，建议还是应用思考时间。但是，如果要考察一个系统能够处理的压力——极限处理能力，则可以将思考时间删除或者注释掉，从而达到最大限度地发送请求，考察系统极限处理能力的目的。
响应时间是指用户从客户端发起一个请求开始，到客户端接收到从服务器端返回结果的响应结束，结果信息展现在客户端整个过程所耗费的时间。
在图1-1中可以看到，页面的响应时间=网络传输时间+Web应用服务器处理延迟时间+数据库服务器处理延迟时间，这个响应时间可以分解为“网络传输时间”（N1+N2+N3+N4）和“应用延迟时间”（A1+A2+A3），而“应用延迟时间”又可以分解为“数据库处理延迟时间”（A2）和“Web应用服务器处理延迟时间”（A1+A3）。之所以要对响应时间进行这些分解，主要目的是更好定位性能瓶颈的所在。这里需要说明的是，上述响应时间考虑的主要是服务器处理响应时间，从严格意义上讲，响应时间还应该包括客户端处理部分的响应时间。例如，在服务器处理完请求后，通过网络传送给客户端，客户端还需要进行页面渲染、脚本执行、数据展现等方面的工作，这部分内容的处理时间则为花费在客户端的处理延迟时间。关于浏览器客户端的性能测试方面有很多工具，如HttpWatch、FireBug、YSlow等，关心这些工具使用的读者可以参看作者的另一本书《精通软件性能测试与loadrunner最佳实战》。如果将这部分时间也考虑进去的话，响应时间=网络传输时间+Web应用服务器处理延迟时间+数据库服务器处理延迟时间+客户端处理延迟时间。
图1-1 Web应用的页面响应时间分解
在进行性能测试时，响应时间是考察的一个重要指标，结合LoadRunner工具的使用，如果要考察某一个业务或一系列业务的响应时间，则需要定义事务，关于事务的概念将在第3章讲解，事务的应用示例将在第4章进行讲解。
通常我们最关心的是平均响应时间，它是指系统稳定运行时间段内，同一业务的平均响应时间。在不特殊说明的情况下，一般而言，响应时间是指平均响应时间。当然，如果分析结果需要，也可以考察最小和最大的响应时间信息。
在通常情况下，平均响应时间指标值应根据不同的行业、业务分别设定标准。一般情况下，复杂业务响应时间、简单业务响应时间、特殊业务响应时间均指定明确的标准值，以对后续结果进行比对，达到标准值即为通过，否则为不通过。
点击数是衡量Web服务器处理能力的一个重要指标。它的统计是根据客户端向Web服务器发了多少次HTTP请求计算的。这里需要说明的是，点击数不是通常一般人认为的访问一个页面就是1次点击，点击数是该页面包含的元素（如图片、链接、框架等）向Web服务器发出的请求次数。通常也用每秒点击次数（hits per second）指标来衡量Web服务器的处理能力。
性能计数器（counter）是描述相关服务器（如数据库服务器、应用服务器等）或操作系统、中间件等性能的一些数据指标。例如，对于Windows系统来说，内存数（memory in usage）、进程时间（total process time）等都是常见的计数器。
计数器在性能测试中发挥着“监控和分析”的关键作用，尤其是在分析系统的可扩展性、进行性能瓶颈的定位时，对计数器取值的分析非常关键。但必须说明的是，单一的性能计数器只能体现系统性能的某一个方面，对性能测试结果的分析必须基于多个不同的计数器。
也许用户在做性能测试时，经常会看到或听到“系统要求在200用户并发访问时稳定运行，CPU利用率不超过75%，可用内存不低于50%，磁盘利用率不超过70%”等这样的描述信息，那么“75%”“50%”和“70%” 就是资源利用率。资源利用率是指系统各种资源的使用情况，一般用“资源的使用量/总的资源可用量 × 100%”形成资源利用率的数据。
在性能测试中，常用资源利用率与其他图表相结合，如虚拟用户数、响应时间图表来分析定位系统的瓶颈。其符合木桶原理，盛水的木桶是由许多块木板箍成的，盛水量也是由这些木板共同决定的。若其中一块木板很短，则此木桶的盛水量就被短板所限制。这块短板就成了这个木桶盛水量的“限制因素”（或称“短板效应”）。若要使此木桶盛水量增加，只能换掉短板或将短板加长。人们把这一规律总结为“木桶原理”或“木桶定律”，又称“短板理论”。例如，系统CPU的使用率达到了接近100%，而内存、磁盘、网络等其他资源的利用率都比较低，从木桶原理可以得出CPU就是一块“短板”，很有可能就是系统的一个性能瓶颈，为改善系统性能，可以尝试更换更高性能的CPU。
通常，系统资源的利用率结合不同行业系统的需求也有所不同。例如，银行行业对系统的稳定性要求比较严格，结合CPU利用率来讲，其要求不高于60%，而其他行业的系统要求不是很严格，CPU利用率不高，80%即可，当然依据行业和系统需求的不同，这些阈值可能会有所不同。在做性能测试时，应以实际需求为准。
网络吞吐量是指在网络工作正常的情况下，单位时间内通过网络的数据数量。通常，该指标用于衡量系统对于网络设备或链路传输能力的需求。当网络吞吐量指标接近网络设备或链路最大传输能力时，需要考虑升级网络设备，以提升网络处理吞吐量。
错误率是指系统在负载情况下，失败交易的概率。错误率=（失败交易数/交易总数） × 100%。不同系统对错误率的要求不同，但一般不超出千分之五。
稳定性较好的系统，其错误率应该由超时引起，即为超时率。
系统稳定性是在进行性能测试时，用户经常提出的一项重要指标，特别是涉及人身安全、金钱等方面的重要系统，基于系统本身的重要性，通常要求非常高，要求365 × 24小时无故障运行，通常系统稳定性关注的内容是稳定运行时间，该指标表示系统在标准压力（系统的预期日常压力）情况下，能够稳定运行的时间。
因为稳定性测试运行时间长，通常至少连续运行24小时以上，所以平时手工测试或短时间性能测试发现不了的问题，可以在该类型的性能测试过程中发现，如内存泄露等问题。
本章首先介绍典型的性能测试场景，让初学者对性能测试的实际应用场景有了基本的认识；然后从不同用户群的角度阐述了他们眼中的性能测试，进一步加强对性能测试内容的理解；接下来，针对功能测试和性能测试的关系进行了阐述。
其中，1.4节和1.5节为本章重点章节，1.4节介绍了性能测试的8大类，1.5节介绍了性能测试过程中涉及的重要性能指标及其部分相关指标的计算公式。
1．简述性能测试的8大类，并对这8大类进行描述。
2．简述以下性能指标。
（1）响应时间
（2）吞吐量
（3）并发用户数量
（4）点击数
（5）性能计数器
（6）系统稳定性
3．根据性能指标的计算公式，补充相关公式元素的含义。
（1）已知吞吐量可以采用公式计算，其中，F表示吞吐量；表示 ，R表示 ，T表示 。
（2）在公式
中，C是平均的并发用户数；n是 ；L是 ；T是 。
（3）在公式
中，是并发用户数的峰值，C是 。
4．假设一个OA系统有5000个用户，平均每天大约有800个用户要访问该系统，对于一个典型用户来说，一天之内用户从登录到退出系统的平均时间为4小时，用户只在一天的8小时内使用该系统，则平均的并发用户数和并发用户数峰值各为多少？
1．简述至少2个典型的性能测试场景。
2．简述功能测试与性能测试的关系。
1．简述性能测试的8大类，并对这8大类进行描述。
答：性能测试的8大类包括：性能测试、负载测试、压力测试、配置测试、并发测试、容量测试、可靠性测试、失败测试。
性能测试：性能测试是为描述测试对象与性能相关的特征并对其进行评价而实施和执行的一类测试。它主要通过自动化的测试工具模拟多种正常、峰值以及异常负载条件来对系统的各项性能指标进行测试。通常把性能测试、负载测试、压力测试等统称为性能测试。
负载测试：是通过逐步增加系统负载，测试系统性能的变化，并最终确定在满足系统性能指标的情况下，系统所能够承受的最大负载量的测试。简而言之，负载测试是通过逐步加压的方式来确定系统的处理能力和能够承受的各项阈值。
压力测试：是通过逐步增加系统负载，测试系统性能的变化，并最终确定在什么负载条件下系统性能处于失效状态，并获得系统能提供的最大服务级别的测试。压力测试是逐步增加负载，使系统某些资源达到饱和甚至失效。
配置测试：主要是通过对被测试软件的软硬件配置进行测试，找到系统各项资源的最优分配原则。配置测试能充分利用有限的软硬件资源，发挥系统的最佳处理能力，同时可以将其与其他性能测试类型联合应用，从而为系统调优提供重要依据。
并发测试：测试多个用户同时访问同一个应用、同一个模块或者数据记录时是否存在死锁或者其他性能问题，几乎所有的性能测试都会涉及一些并发测试。
容量测试：在一定的软、硬件条件下，在数据库中构造不同数量级的记录数量，通过运行一种或多种业务场景在一定虚拟用户数量的情况下，获取不同数量级别的性能指标，从而得到数据库能够处理的最大会话能力、最大容量等。系统可处理同时在线的最大用户数，通常和数据库有关。
可靠性测试：通过给系统加载一定的业务压力（如CPU资源在70%～90%的使用率）的情况下，运行一段时间，检查系统是否稳定。因为运行时间较长，通常可以测试出系统是否有内存泄露等问题。
失败测试：对于有冗余备份和负载均衡的系统，通过失败测试来检验如果系统局部发生故障，用户能否继续使用系统，用户受到多大的影响，如几台机器做均衡负载，一台或几台机器垮掉后系统能够承受的压力。
2．简述以下性能指标。
（1）响应时间
答：响应时间是指用户从客户端发起一个请求开始，到客户端接收到从服务器端返回结果的响应结束，结果信息展现在客户端整个过程所耗费的时间。响应时间=网络传输时间+Web应用服务器处理延迟时间+数据库服务器处理延迟时间+客户端处理延迟时间。在进行性能测试时，响应时间是考察的一个重要指标，结合LoadRunner工具的使用来讲，如果要考察某一个业务或一系列业务的响应时间，则需要定义事务，在不特殊说明的情况下，一般而言，响应时间是指平均响应时间。
（2）吞吐量
答：是指单位时间内处理的客户端请求数量，直接体现软件系统的性能承载能力。通常情况下，吞吐量用“请求数/秒”或“页面数/秒”来衡量。从业务角度来看，吞吐量也可以用“业务数/小时”“业务数/天”“访问人数/天”“页面访问量/天”来衡量。从网络角度来看，还可以用“字节数/小时”“字节数/天”等来衡量网络的流量。吞吐量是大型门户网站以及各种电子商务网站衡量自身负载能力的一个很重要的指标，一般吞吐量越大，系统单位时间内处理的数据越多，系统的负载能力也就越强。
（3）并发用户数量
答：它最简单的描述就是指多个同时发生的业务操作。例如，100个用户同时单击登录页面的“登录”按钮操作。通常，应用系统会随着用户同时应用某个具体的模块，而导致资源的争用问题。例如，50个用户同时执行统计分析的操作，由于统计业务涉及很多数据提取和科学计算问题，所以这时很有可能内存和CPU会出现瓶颈。并发性测试描述的是多个客户端同时向服务器发出请求，考察服务器端承受能力的一种性能测试方式。
（4）点击数
答：点击数是衡量Web服务器处理能力的一个重要指标。它的统计根据客户端向Web服务器发了多少次HTTP请求计算的。这里需要说明的是，点击数不是通常一般人认为的访问一个页面就是1次点击，点击数是该页面包含的元素（如图片、链接、框架等）向Web服务器发出的请求次数。通常也用每秒点击次数（hits per second）指标来衡量Web服务器的处理能力。
（5）性能计数器
答：性能计数器（counter）是描述相关服务器（如数据库服务器、应用服务器等）或操作系统、中间件等性能的一些数据指标。例如，对Windows系统来说，使用内存数（memory in usage）、进程时间（total process time）等都是常见的计数器。计数器在性能测试中发挥着“监控和分析”的关键作用，尤其是在分析系统的可扩展性、进行性能瓶颈的定位时，对计数器取值的分析非常关键。但必须说明的是，单一的性能计数器只能体现系统性能的某一个方面，对性能测试结果的分析必须基于多个不同的计数器。
（6）系统稳定性
答：系统稳定性是在进行性能测试时，用户经常提出的一项重要指标，特别是涉及人身安全、财产等方面的重要系统，基于系统本身的重要性，通常要求非常高，要求365 × 24小时无故障运行，通常系统稳定性关注的内容是稳定运行时间，该指标表示系统在标准压力（系统的预期日常压力）情况下，能够稳定运行的时间。因为稳定性测试运行时间长，通常至少连续运行24小时以上，所以平时手工测试或短时间性能测试发现不了的问题，可以在该类型的性能测试过程中发现，如内存泄露等问题。
3．根据性能指标的计算公式，补充相关公式元素的含义。
（1）已知吞吐量可以采用公式计算，其中，F表示吞吐量；表示并发虚拟用户数，R表示每个VU发出的请求数量，T表示性能测试所用的时间。
（2）在公式中，C是平均的并发用户数；n是login session的数量；L是login session的平均长度；T是考察的时间段长度。
（3）在公式中，
是并发用户数的峰值，C是平均的并发用户数。
4．假设一个OA系统有5000个用户，平均每天大约有800个用户要访问该系统，对于一个典型用户来说，一天之内用户从登录到退出系统的平均时间为4小时，用户只在一天的8小时内使用该系统，则平均的并发用户数和并发用户数峰值各为多少？
答：依据前面章节的公式和，平均并发用户数=800 × 4/8=400，并发用户峰值=400+3 × 20=460。
1．简述至少2个典型的性能测试场景。
答：对于有经验的测试人员可以结合自己以前做过的一些实际项目进行描述，可以深入一些，也可以结合本书中的例子进行简单描述例如：
当然，上述内容仅仅是举例，面试人员应该根据自己的学习和工作情况，举一反三，将问题描述得越清晰透彻，就会取得越好的效果。
2．简述功能测试与性能测试的关系。
答：功能测试和性能测试是相辅相成的，对于一款优秀的软件产品来讲，它们是不可缺少的2个重要测试环节，但依据不同目标的性能测试情况，测试时要因地制宜，结合实际需求，选择合适的时间点进行，减少不必要的人力、物力浪费，实现利益最大化。
有的公司招聘性能测试人员时，经常会问一个问题“您能否简单地介绍一下性能测试的过程？”多数应聘者的回答差强人意，原因是很多人不是十分清楚性能测试，以至于回答问题的思路混乱。其实，大家在应聘性能测试职位时，必须清楚这个职位具体是做哪些工作的，并按照工作的流程把每一个环节都表述清楚。下面笔者结合自己多年的工作经验介绍，性能测试的过程。
典型的性能测试过程如图2-1所示。
图2-1 典型的性能测试过程
注意
方框区域为可能存在多次进行的操作部分。
下面对性能测试过程的每个部分进行详细介绍。当测试人员拿到“用户需求规格说明书”以后，文档中会包含功能、性能以及其他方面的要求，性能测试人员最关心的内容就是性能测试相关部分的内容描述。
性能测试的目的是明确客户的真正需求，这是性能测试最关键的部分。很多客户对性能测试不了解，测试人员可能会因为客户提出的“我们需要贵单位对所有的功能都进行性能测试”“系统用户登录响应时间小于3秒”“系统支持10万用户并发访问”等要求所困扰。不知道读者是不是看出了上面几个要求存在的问题，下面让我们逐一来分析这几句话。
从客户的角度来看，肯定都是希望所有的系统应用都有好的系统性能表现，那么是不是所有的功能都要经过性能测试呢？答案当然是否定的，因为通常性能测试周期较长。首先，全部功能模块都进行性能测试需要非常长的时间；其次，根据80-20原则，通常系统用户经常使用的功能模块大概占用系统整个功能模块数目的20%，像“参数设置”等类似的功能模块，通常仅需要在应用系统时由管理员进行一次性设置，针对这类设置进行性能测试也是没有任何意义的。通常，性能测试是由客户提出需求内容，性能测试人员针对客户的需求进行系统和专业的分析后，提出相应的性能测试计划、解决方案、性能测试用例等与用户共同分析确定最终的性能测试计划、解决方案、性能测试用例等，性能测试的最终测试内容通常也是结合客户真实的应用场景，客户应用最多、使用最频繁的功能。所以说，“对所有的功能都进行性能测试”是不切实际，也是不科学的做法，作为性能测试人员必须清楚这一点。
从表面看这句话似乎没有什么问题，仔细看看是不是看出点什么门道呢？其实这句话更像一个功能测试的需求，因为其没有指明是在多少用户访问时，系统的响应时间小于3秒。作为性能测试人员必须清楚客户的真实需求，消除不明确的因素。
从表面看这句话似乎也没有什么问题。在进行性能测试时，系统的可扩展性是需要考虑的一个重要内容。例如，一个门户网站，刚开始投入市场时，只有几百个用户，随着广告、推荐等系统宣传力度的加大，在做系统性能测试时，需要对未来两三年内系统的应用用户有初步预期，使系统在两三年后仍然能够提供良好的性能体验。但是，如果系统每天只有几十个用户，在未来的5～10年内，也不过几百个用户，那么还需要进行10万级用户并发访问的性能测试吗？作者的建议是把这种情况向客户表达清楚，在满足当前和未来用户应用系统性能要求的前提下进行测试，能够节省客户的投入，无疑客户会觉得你更加专业，也真正从客户的角度出发，相信一定会取得更好的效果。如果系统用户量很大，考虑到可扩展性需求，确实需要进行10万级用户这种情况的性能测试，我们也需要清楚10万级用户的典型应用场景，以及不同操作人员的比例，这样的性能测试才会更有意义。
性能测试计划是性能测试的重要环节。在对客户提出的需求经过认真分析后，性能测试管理人员需要编写的第一份文档就是性能测试计划。性能测试计划非常重要，需要阐述产品、项目的背景，明确前期的测试性能需求，并落实到文档中。指出性能测试可参考的一些文档，并将这些文档的作者、编写时间、获取途径逐一列出，形成一个表格，这些文档包括：用户需求规格说明书、会议纪要（内部讨论、与客户讨论等最终确定的性能测试内容）等性能测试相关需求内容文档。性能测试也是依赖于系统正式上线的软、硬件环境的，因此包括网络的拓扑结构、操作系统、应用服务器、数据库等软件的版本信息、数据库服务器、应用服务器等具体硬件配置，如CPU、内存、硬盘、网卡、网络环境等信息也应该描述。系统性能测试的环境要尽量和客户上线的环境条件相似，在软、硬件环境相差巨大的情况下，对于真正评估系统上线后的性能有一定偏差，有时甚至更坏。为了能够得到需要的性能测试结果，性能测试人员需要认真评估要在本次性能测试中应用的工具， 该工具能否对需求中描述的相关指标进行监控，并得到相关的数据信息。性能测试结果数据信息是否有良好的表现形式，并且可以方便地输出？项目组性能测试人员是否会使用该工具？工具是否简单易用等。当然在条件允许的情况下，把复杂的性能测试交给第三方专业测试机构也是一个不错的选择。人力资源和进度的控制，需要性能测试管理人员认真考虑。很多失败的案例告诉我们，由于项目前期研发周期过长，项目开发周期延长，为了保证系统能够按时发布，人们不得不缩短测试周期，甚至取消测试，这样的项目质量是得不到保证的，通常其结果也必将以失败而告终。所以要合理安排测试时间和人员，监控并及时修改测试计划，使管理人员和项目组成员及时了解项目测试的情况，及时修正在测试过程中遇到的问题。除了在计划中考虑上述问题以外，还应该考虑如何规避性能测试过程中可能会遇到的一些风险。在性能测试过程中，有可能会遇见一些将会发生的问题，为了保证后期在实施过程中有条不紊，应该考虑如何尽量避免这些风险的发生。当然，性能测试计划中还应该包括性能测试准入、准出标准以及性能测试人员的职责等。一份好的性能测试计划为性能测试成功打下了坚实的基础，所以请读者认真分析测试的需求，将不明确的相关内容弄清楚，制订出一份好的性能测试计划，然后按照此计划执行，如果执行过程与预期不符，则及时修改计划，不要仅仅将计划作为一份文档，而要将其作为性能测试行动的指导性内容。
性能测试需求最终要体现在性能测试用例设计中，应结合用户应用系统的场景，设计出相应的性能测试用例，用例应能覆盖到测试需求。很多人在设计性能测试用例时，有束手无策的感觉。这时，需要考虑是否存在以下几个方面的问题。
（1）你是否更加关注于工具的使用，而忽视了性能测试理论知识的补充。
（2）你是否对客户应用该系统经常处理哪些业务不是很清楚。
（3）你是否对应用该系统的用户数不是很了解。
（4）你是否也陷入公司没有性能测试相关人员可以交流的尴尬境地。
当然，上面只列出了一些典型的问题，实际中可能会碰到更多的问题。这里，作者想和诸位朋友分享一下工作心得。在刚开始从事性能测试工作时，肯定会碰到很多问题。一方面，由于性能测试是软件测试行业的一个新兴分类，随着企业的飞速发展，各种系统规模的日益庞大，软件企业也更加注重性能测试，从招聘网上搜索“性能测试工程师”，可以搜索到几百条招聘性能测试工程师相关职位的信息，如图2-2所示。
图2-2 招聘性能测试工程师相关职位信息
但是，由于性能测试工作在国内刚起步，性能测试方面的知识也不是很多，加之很多单位在招聘性能测试工程师岗位时，对工具的要求更多一些（如图2-3所示的“高级性能测试工程师”岗位要求信息），使很多测试人员对性能测试工作产生了误解——觉得性能测试的主要工作就是应用性能测试工具，如果性能测试工具方面的知识学得好，做性能测试工作就没有问题。其实，工具是为人服务的，真正指导性能测试工作的还是性能测试的理论和实践知识，要做好性能测试，需要运用工具将学习到的理论知识和深入理解的用户需求这些思想体现出来，做好执行、分析以及调优工作，这样才能够做好测试。性能测试人员可能会遇到客户需求不明确，对客户应用业务不清楚等情况，这时，需要与公司内部负责需求、业务的专家和客户进行询问、讨论，把不明确的内容弄清楚，最重要的是一定要明确用户期望的相关性能指标。在设计用例时，通常需要编写如下内容：测试用例名称、测试用例标识、测试覆盖的需求（测试性能特性）、应用说明、（前置/假设）条件、用例间依赖、用例描述、关键技术、操作步骤、期望结果（明确的指标内容）、记录实际运行结果等内容，当然，上面的内容可以依据需要适当裁减。
图2-3 招聘性能测试工程师岗位要求信息
性能测试用例编写完成后，接下来需要结合用例的需要，编写测试脚本。本书后面将介绍有关LoadRunner协议选择和脚本编写的知识。关于测试脚本的编写，这里着重强调以下几点。
（1）协议的选用关系到脚本能否正确录制与执行，十分重要。因此在进行程序的性能测试之前，测试人员必须明确被测试程序使用的协议。
（2）测试脚本不仅可以使用性能测试工具来完成，在必要时，可以使用其他语言编程来完成同样的工作。
（3）通常，在应用工具录制或者编写脚本完成以后，还需要去除脚本不必要的冗余代码，对脚本进行完善，加入集合点、检查点、事务以及对一些数据进行参数化、关联等处理。在编写脚本时，需要注意的还有脚本之间的前后依赖性，如一个进销存管理系统，在销售商品之前，只有先登录系统，对系统进行进货处理，才能够进行销售（本系统不支持负数概念，即不允许负库存情况发生）。这就是前面所讲的脚本间依赖的一个实例。因此在有类似情况发生时，应该考虑脚本的执行顺序，在本例中是先执行登录脚本，再执行业务脚本进货，最后进行销售，系统登出。当然有两种处理方式，一种是录制4个脚本，另一种方式是在一个脚本中进行处理，将登录部分放在vuser_init()，进货、销售部分代码可以放在Acition中，最好建立两个Acition分别存放，而将登出脚本放在vuser_end()部分。参数化时，也要考虑前后数据的一致性。关于参数化相关选项的含义，请参见4.4节。
（4）在编写测试脚本时，还需要注意编码的规范和代码的编写质量问题。软件性能测试不是简单地录制与回放，一名优秀的性能测试人员可能经常需要自行编写脚本，这一方面要提高自己的编码水平，不要使编写的脚本成为性能测试的瓶颈。很多测试人员，由于不是程序员出身，对程序的理解也不够深入，经常会出现如申请内存不释放、打开文件不关闭等情况，却不知这些情况会造成内存泄露。所以要加强编程语言的学习，努力使自己成为一名优秀的“高级程序员”。另一方面，也要加强编码的规范。测试团队少则几人，多则几十人、上百人，如果大家编写脚本时，标新立异，脚本的可读性势必很差，加之IT行业人员流动性很大，所以测试团队有一套标准的脚本编写规范势在必行。在多人修改维护同一个脚本的情况下，还应该在脚本中记录修改历史。好的脚本应该是不仅自己能看懂，别人也能看懂。
（5）经常听到很多同事追悔莫及地说，“我的那个脚本哪去了，这次性能测试的内容和以前做过的功能一模一样啊！”“以前便写过类似脚本，可惜被我删掉了！”等。因为企业开发的软件在一定程度上存在类似的功能，所以脚本的复用情况会经常发生，历史脚本的维护同样是很重要的一项工作。作者建议将脚本纳入配置管理，配置管理工具有很多，如Visual Source Safe、Firefly、PVCS、CVS、Havest等都是不错的。
性能测试场景设计以性能测试用例、测试脚本编写为基础，脚本编写完成后需要进行如下操作：如需进行并发操作，则加入集合点；如需考察某一部分业务处理响应时间，则插入事务；为检查系统是否正确执行相应功能而设置的检查点；输入不同的业务数据，则需要进行参数化。测试场景设计的一个重要原则就是依据测试用例，把测试用例设计的场景展现出来。目前性能测试工具有很多，既有开源性能测试工具、免费性能测试工具，也有功能强大的商业性能测试工具，如表2-1～表2-3所示。
表2-1 开源性能测试工具
| 工具名称 |
功能简介 |
|---|---|
| Jmeter |
Jmeter可以完成针对静态资源和动态资源（Servlets、Perl脚本、Java对象、数据查询、FTP服务等）的性能测试，可以模拟大量的服务器负载、网络负载、软件对象负载，通过不同的加载类型全面测试软件的性能、提供图形化的性能分析 |
| OpenSTA |
OpenSTA可以模拟大量的虚拟用户，结果分析包括虚拟用户响应时间、Web服务器的资源使用情况、数据库服务器的使用情况，可以精确地度量负载测试的结果 |
| DbMonster |
DBMonster是一个生成随机数据，用来测试SQL数据库压力的测试工具 |
| TpTest |
TPTest提供测试Internet连接速度的简单方法 |
| …… |
…… |
表2-2 商业性能测试工具
| 工具名称 |
功能简介 |
|---|---|
| HP LoadRunner |
HP LoadRunner是一种预测系统行为和性能的工业级标准性能测试和负载测试工具。通过模拟上千万用户实施并发负载及实时性能监测的方式来确认和查找问题。LoadRunner能够对整个企业架构进行测试，支持Web（HTTP/HTML）、Windows Sockets、File Transfer Protocol（FTP）、Media Player（MMS）、ODBC、MS SQL Server等协议 |
| IBM Rational Performance Tester |
适用于团队验证Web应用程序的可伸缩性的负载和性能测试工具，引入了新的技术进行负载测试的创建、修改、执行和结果分析 |
| …… |
…… |
表2-3 免费性能测试工具
| 工具名称 |
功能简介 |
|---|---|
| Microsoft Application Center Test |
可以对Web服务器进行强度测试，分析Web应用程序（包括ASPX页及其使用的组件）的性能和可伸缩性问题。通过打开多个服务器连接并迅速发送HTTP请求，Application Center Test可以模拟大量用户 |
| Microsoft Web Application Stress Tool |
由Microsoft公司的网站测试人员开发，专门用来进行实际网站压力测试的一套工具。可以以数种不同的方式建立测试指令：包含以手工、录制浏览器操作的步骤，或直接录入IIS的记录文件、网站的内容及其他测试程序的指令等方式 |
| …… |
…… |
不同性能测试工具的操作界面和应用方法有很大的区别，但是其工作原理有很多相似的地方。关于测试场景的设计这里着重强调以下几点。
（1）性能测试工具都是用进程或者线程来模拟多个虚拟用户的。如果按进程运行每个虚拟用户（Vuser），则对于每个Vuser实例，都将反复启动同一驱动程序并将其加载到内存中。将同一驱动程序加载到内存中会占用大量随机存取存储器（RAM）及其他系统资源。这就限制了可以在任意负载生成器上运行的Vuser的数量。如果按线程运行每个Vuser，这些线程Vuser将共享父驱动进程的内存段。这就消除了多次重新加载驱动程序/进程的需要，节省了大量内存空间，从而可以在一个负载生成器上运行更多的Vuser。在应用线程安全的协议时，笔者推荐使用线程模式。
（2）如果存在有执行次序依赖关系的脚本，则注意在场景设计时顺序不要弄错。
（3）场景的相关设置项也是需要关注的重要内容，这里仅以LoadRunner为例。如果应用虚拟IP时，需要选中
项。如果应用了集合点，则需要单击
选项，设定集合点策略。如果需要多台负载机进行负载，则可以单击
进行负载机的连接测试。此外，还可以为接下来的场景运行、监控、分析设置一些参数，如连接超时、采样频率、网页细分等。
测试场景运行是关系到测试结果是否准确的一个重要过程。经常有很多测试人员花费了大量的时间和精力去做性能测试，可是做出来的测试结果不理想。原因是什么呢？关于测试场景的设计这里着重强调以下几点。
（1）性能测试工具都是用进程或者线程来模拟多个虚拟用户的，每个进程或者线程都需要占用一定的内存，因此要保证负载的测试机足够跑完设定的虚拟用户数，如果内存不够，则用多台负载机分担进行负载。
（2）在进行性能测试之前，需要先将应用服务器“预热”，即先运行应用服务器的功能。这是为什么呢？高级语言翻译成机器语言，计算机才能执行高级语言编写的程序。翻译的方式有两种：编译和解释。这两种方式只是翻译的时间不同。编译型语言程序执行前，需要一个专门的编译过程，把程序编译成为机器语言的文件，如可执行文件，以后再运行就不用重新翻译了，直接使用编译的结果文件执行（EXE）即可。因为翻译只做了一次，运行时不需要翻译，所以编译型语言的程序执行效率高。解释型语言则不同，解释型语言的程序不需要编译，省了一道工序，解释性语言在运行程序时才翻译，如解释型语言JSP、ASP、Python等，专门有一个解释器能够直接执行程序，每个语句都是执行时才翻译。这样解释型语言每执行一次就要翻译一次，效率比较低。这也就是很多测试系统的响应时间很长的一个原因，就是没有实现运行测试系统，导致第一次执行编译需要较长时间，从而影响了性能测试结果。
（3）在有条件的情况下，尽量模拟用户的真实环境。经常收到一些测试同行的来信说：“为什么我们性能测试的结果每次都不一样啊？”，经过询问得知，性能测试环境竟与开发环境为同一环境，且同时被应用。很多软件公司为了节约成本，开发与测试使用同一环境，这种模式有很多弊端。进行性能测试时，若研发和测试共用系统，性能测试周期通常少则几小时，多则几天，这不仅给研发和测试人员使用系统资源带来一定的麻烦，而且容易导致测试与研发的数据相互影响，所以尽管经过多次测试，但每次测试结果各不相同。随着软件行业的蓬勃发展，市场竞争也日益激励，希望软件企业能够从长远角度出发，为测试部门购置一些与客户群基本相符的硬件设备，如果买不起服务器，可以买一些配置较高的PC代替，但是环境的部署一定要类似。如果条件允许，也可以在客户实际环境进行性能测试。总之，一定要注意测试环境的独立性，以及网络，软、硬件测试环境与用户实际环境的一致性，这样测试的结果才会更贴近真实情况，性能测试才会有意义。
（4）测试工作并不是一个单一的工作，测试人员应该和各个部门保持良好的沟通。例如，在遇到需求不明确时，需要和需求人员、客户以及设计人员进行沟通，把需求弄清楚。在测试过程中，如果遇到自己以前没有遇到过的问题，也可以与同组的测试人员、开发人员进行沟通，及时明确问题产生的原因，进而解决问题。点滴的工作经验积累对测试人员很有帮助，这些经验也是日后问题推测的重要依据。在测试过程中，也需要部门之间相互配合，这就需要开发人员和数据库管理人员与测试人员相互配合完成1年业务数据的初始化工作。因此，测试工作并不是孤立的，需要和各部门进行及时沟通，在需要帮助的时候，一定要及时提出，否则可能会影响项目工期，甚至导致项目失败。在测试中我一直提倡“让最擅长的人做最擅长的事”，在项目开发周期短，人员不是很充足的情况下，尤其要坚持这一点，不要浪费大量的时间在自己不擅长的事情上。
（5）性能测试的执行，在时间充裕的情况下，最好同样一个性能测试用例执行3次，然后分析结果，只有结果相接近，才可以证明此次测试是成功的。
场景运行监控可以在场景运行时决定要监控哪些数据，便于后期分析性能测试结果。应用性能测试工具的重要目的就是提取本次测试关心的数据指标内容。性能测试工具利用应用服务器、操作系统、数据库等提供的接口，取得在负载过程中相关计数器的性能指标。关于场景的监控有以下几点需要大家在性能测试过程中注意。
（1）性能测试负载机可能有多台，负载机的时钟要一致，以保证监控过程中的数据是同步的。
（2）场景的运行监控也会给系统造成一定的负担，因为在操作过程中需要搜集大量的数据，并存储到数据库中，所以尽量搜集与系统测试目标相关的参数信息，无关内容不必进行监控。
（3）通常只有管理员才能够对系统资源等进行监控，因此，很多朋友会问：“为什么我监控不到数据？为什么提示我没有权限？”等类似问题，作者的建议是：以管理员的身份登录后，如果监控不了相关指标，再去查找原因，不要耗费过多精力做无用功。
（4）运行场景的监控是一门学问，需要对要监控的数据指标有非常清楚的认识，同时还要求非常熟悉性能测试工具。当然这不是一朝一夕的事情，作为性能测试人员，我们只有不断努力，深入学习这些知识，不断积累经验，才能做得更好。
在性能测试执行过程中，性能测试工具搜集相关性能测试数据，待执行完成后，这些数据会存储到数据表或者其他文件中。为了定位系统性能问题，需要系统分析这些性能测试结果。性能测试工具自然能帮助我们生成很多图表，也可以进一步对这些图表进行合并等操作来定位性能问题。是不是在没有专业性能测试工具的情况下，就无法完成性能测试呢？答案是否定的，其实在很多情况下，性能测试工具会受到一定的限制，这时，需要编写一些测试脚本来完成数据的搜集工作，当然数据存储的介质通常也是数据库或者其他格式的文件，为了便于分析数据，需要先对这些数据进行整理再分析。如何将数据库、文件的杂乱数据变成直观的图表，请参见4.15节～4.18节的内容。
目前，被广泛应用的性能分析方法是“拐点分析”。“拐点分析”是一种利用性能计数器曲线图上的拐点进行性能分析的方法。它的基本思想是性能产生瓶颈的主要原因是某个资源的使用达到了极限，此时表现为随着压力的增大，系统性能急剧下降，从而产生了“拐点”现象。只要得到“拐点”附近的资源使用情况，就能定位出系统的性能瓶颈。例如，系统随着用户的增多，事务响应时间缓慢增加，当达到100个虚拟用户时，系统响应时间急剧增加，表现为一个明显的“折线”，这就说明系统承载不了如此多的用户做这个事务，也就是存在性能瓶颈。
性能测试分析人员经过分析结果以后，有可能找出系统存在性能瓶颈。这时相关开发人员、数据库管理员、系统管理员、网络管理员等就需要根据性能测试分析人员提出的意见与性能分析人员共同分析确定更细节的内容，相关人员对系统进行调整以后，性能测试人员继续进行第二轮、第三轮……的测试，与以前的测试结果进行对比，从而确定经过调整以后系统的性能是否有提升。有一点需要提醒大家，就是在进行性能调整时，最好一次只调整一项内容或者一类内容，避免一次调整多项内容而引起性能提高却不知道是由于调整哪项关键指标而改善性能的。在系统调优过程中，好的策略是按照由易到难的顺序对系统性能进行调优。系统调优由易到难的先后顺序如下。
（1）硬件问题。
（2）网络问题。
（3）应用服务器、数据库等配置问题。
（4）源代码、数据库脚本问题。
（5）系统构架问题。
硬件发生问题是最显而易见的，如果CPU不能满足复杂的数学逻辑运算，就可以考虑更换CPU，如果硬盘容量很小，承受不了很多的数据，就可以考虑更换高速、大容量硬盘等。如果网络带宽不够，就可以考虑对网络进行升级和改造，将网络更换成高速网络。还可以将系统应用与平时公司日常应用进行隔离等方式，达到提高网络传输速率的目的。很多情况下，系统性能不是十分理想的一个重要原因就是，没有对应用服务器、数据库等软件进行调优和设置，如对Tomcat系统调整堆内存和扩展内存的大小，数据库引入连接池技术等。源代码、数据库脚本是在上述调整无效的情况下，可以选择的一种调优方式，但是因为对源代码的改变有可能会引入缺陷，所以在调优以后，不仅需要性能测试，还要对功能进行验证，以验证是否正确。这种方式需要通过对数据库建立适当的索引，并且运用简单的语句替代复杂的语句，从而达到提高SQL语句运行效率的目的，还可以在编码过程中选择好的算法，减少响应时间，引入缓存等技术。在上述尝试都不见效的情况下，就需要考虑现行的构架是否合适，选择效率高的构架，但由于构架的改动比较大，所以应该慎重对待。
性能测试工作完成以后，需要编写性能测试总结报告。
性能测试总结不仅使我们能够了解如下内容：性能测试需求覆盖情况，性能测试过程中出现的问题，又是如何去分析、调优、解决的，测试人员、进度控制与实际执行偏差，性能测试过程中遇到的各类风险是如何控制的，经过该产品/项目性能测试后，有哪些经验和教训等内容。随着国内软件企业的发展、壮大，越来越多的企业重视软件产品的质量，而好的软件无疑和良好的软件生命周期过程控制密不可分。在这个过程中，不断规范化软件生命周期各个过程、文档的写作，以及各个产品和项目测试经验的总结是极其重要的。通常一份性能测试总结报告要描述如下内容。
需要阐述产品、项目的背景，将前期的性能测试需求明确，并落实到文档中。指出性能测试可参考的一些文档，并将这些文档的作者、编写时间、获取途径逐一列出，形成一个表格。这些文档包括：用户需求规格说明书、会议纪要（内部讨论、与客户讨论等最终确定的关于性能测试内容）等与性能测试相关的需求内容文档。因为性能测试也依赖于系统正式上线的软、硬件环境，所以包括网络的拓扑结构、操作系统、应用服务器、数据库等软件的版本信息，数据库服务器、应用服务器等具体硬件配置（CPU、内存、硬盘、网卡等），网络环境等信息也应该描述。应明确标识出实测环境的相关信息。系统性能测试的环境要尽量和客户软件上线的环境条件相似，在软、硬件环境相差巨大的情况下，测试的结果和系统上线后的性能有一定偏差，有时甚至更坏。在测试执行过程中应用的性能测试相关的工具名称、版本等，如果您有部分内容由第三方专业的测试机构完成，则应让其提供明确的结论性输出物和执行过程相关脚本代码、场景、日报/周报、监控数据等相关文档资料。性能测试总结一定要结合性能测试计划内容来进行比对，实际执行过程的相关需提交文档、准入准出条件、场景设计、性能指标、测试环境、性能测试相关工具应用、执行进度等都是需要考量的内容。如果实际执行过程和测试计划有偏差，则要分析产生偏差的原因，以及是否对结果影响。
“不积跬步无以至千里，不积小流无以成江海”。性能测试总结不仅是对本次性能测试执行全过程以及本次性能测试是否达标的一个总结，它应该也是团队总结在项目实施过程中经验和教训（包括时间安排、技术难点、分析方法、沟通协调、团队协作、工具选择等）的积累。
本章概要介绍了性能测试的基本过程，然后详细介绍了性能测试基本过程的各个环节。
执行性能测试的基本过程对于做好性能测试工作具有积极和重要意义，特别是刚开始接触性能测试的人员，请务必在性能测试实施初始阶段就坚持、保持良好的流程规范，做好每一个关键步骤，认真总结在性能测试实施过程中的得与失，为后续工作积累更多的经验。
性能测试的理论知识是指导性能测试整个实施过程的重要依据，也是保证性能测试能够顺利实施并取得良好效果的基础，本章的所有内容都非常重要，请认真掌握。
1．请依据典型的性能测试过程，补全图2-4中空白方框的内容。
图2-4 待补充完整的典型的性能测试过程
2．如果在性能测试需求分析阶段，客户提出了“我们需要贵单位对所有的功能都进行性能测试”的需求，要如何处理？
3．简述在性能测试执行过程中场景运行监控环节，以及应该注意的问题。
1．简述典型的性能测试的基本过程及各过程需要做的工作。
2．在性能测试分析阶段，“拐点分析”方法被大家广泛应用，请说明该方法的基本思想是什么？
1．请依据典型的性能测试过程，补全图2-4中空白方框的内容。
答：如图2-5所示。
2．如果在性能测试需求分析阶段，客户提出了“我们需要贵单位对所有的功能都进行性能测试”的需求，要如何处理？
答：首先，全部功能模块都进行性能测试需要非常长的时间；其次，根据80-20原则，通常系统用户经常使用的功能模块大概占系统整个功能模块数的20%，像“参数设置”等类似的功能模块，通常仅需要在应用系统时，由管理员一次性设置，针对这类设置进行性能测试也是没有任何意义的。所以说，“对所有的功能都进行性能测试”是不切实际，也是不科学的做法。通常，性能测试是由客户提出需求内容，性能测试人员针对客户的需求进行系统和专业的分析后，提出相应的性能测试计划、解决方案、性能测试用例等与用户共同分析确定最终的性能测试计划、解决方案、性能测试用例等。性能测试的最终测试内容通常也是结合客户真实的应用场景，即客户应用最多，使用最频繁的功能。
3．简述在性能测试执行过程中场景运行监控环节，以及应该注意的问题。
答：关于场景的监控有以下几点需要在性能测试过程中注意。
1．简述典型的性能测试的基本过程及各过程需要做的工作。
答：性能测试的基本过程如图2-5所示，关于各过程需要做哪些工作，在这里只做简单的阐述，详细的具体内容请读者阅读相关过程内容。
图2-5 补充完整的典型的性能测试过程
性能测试的目的就是理解客户的真正需求，这是性能测试最关键的过程。性能测试的最终测试内容通常要应用80-20原则，即结合客户真实的应用场景，以及客户应用最多，使用最频繁的功能，明确在相应的软、硬件环境下，不同级别的用户数量、数据量等情况下，用户期望的具体业务和性能指标。
性能测试计划是性能测试的重要过程。在认真分析客户提出的需求后，性能测试管理人员需要编写的第一份文档就是性能测试计划。性能测试计划非常重要，在性能测试计划中，需要阐述产品、项目的背景，明确前期需要测试的性能，并落实到文档中。一份好的性能测试计划为成功进行性能测试打下了坚实的基础，所以要认真分析测试的需求，将不明确的相关内容弄清楚，制订出一份好的性能测试计划，然后按照此计划执行。如果执行过程与预期不符，则及时修改计划，不要仅仅将计划作为一份文档，而要将其作为性能测试行动的指导性内容。
客户的性能测试需求最终要体现在性能测试用例设计中，性能测试用例应结合用户应用系统的场景，设计出相应的性能测试用例，用例应能覆盖到测试需求。
选择正确的协议关系到脚本能否正确录制与执行，十分重要。因此在进行程序的性能测试之前，测试人员必须弄清楚，被测试程序使用的协议。还要注意脚本的代码编写规范、代码的编写质量，以及脚本存放到配置管理工具中，做好保存和备份工作。
性能测试场景设计是以性能测试用例、测试脚本编写为基础，脚本编写完成，需要在脚本中进行如下处理，如需进行并发操作，则加入集合点；如要考察某一部分业务处理响应时间，则插入事务；为检查系统是否正确执行相应功能而设置的检查点；如需输入不同的业务数据，则需要进行参数化。设计测试场景的一个重要原则就是依据测试用例，把测试用例设计的场景展现出来。
在有条件的情况下，尽量模拟用户的真实环境。性能测试工具都是用进程或者线程来模拟多个虚拟用户，每个进程或者线程都需要占用一定的内存，因此要保证负载的测试机足够跑完设定的虚拟用户数，如果内存不够，则用多台负载机分担进行负载。在进行性能测试之前，需要先将应用服务器“预热”，即先运行应用服务器的功能。测试工作并不是一个单一的工作，测试人员应该和各个部门保持良好的沟通。
场景运行监控可以在场景运行时决定要监控的数据，便于后期分析性能测试结果。性能测试负载机可能有多台，负载机的时钟要一致，以保证在监控过程中的数据是同步的。尽量搜集与系统测试目标相关的参数信息，无关内容不必进行监控。以管理员的身份登录后，如果监控不了相关指标，再去查找原因，不要耗费过多精力做无用功。运行场景的监控是一门学问，需要对要监控的数据指标和性能测试工具非常熟悉。
为了定位系统性能问题，需要系统分析这些性能测试结果。性能测试工具可以帮助我们生成很多图表，也可以进一步对这些图表进行合并等操作来定位性能问题。目前，被广泛应用的性能分析方法是“拐点分析”。“拐点分析”是一种利用性能计数器曲线图上的拐点进行性能分析的方法。它的基本思想是性能产生瓶颈的主要原因是某个资源的使用达到了极限，此时表现为随着压力的增大，系统性能急剧下降，从而产生 “拐点”现象。只要得到“拐点”附近的资源使用情况，就能定位出系统的性能瓶颈。例如，系统随着用户的增多，事务响应时间缓慢增加，当达到100个虚拟用户时，系统响应时间急剧增加，表现为一个明显的“折线”，这就说明系统承载不了如此多的用户做这个事务，也就是存在性能瓶颈。
在进行性能调整时，最好一次只调整一项内容或者一类内容，避免一次调整多项内容而引起性能提高却不知道是由于调整哪项关键指标而改善性能的。在系统调优过程中，好的策略是按照由易到难的顺序对系统性能进行调优。
性能测试总结不仅使我们能够了解到如下内容：性能测试需求覆盖情况，性能测试过程中出现的问题，以及如何去分析、调优、解决的，测试人员、进度控制与实际执行偏差，性能测试过程中遇到的各类风险是如何控制的，以及该产品/项目性能测试后的经验和教训等内容。
2．在性能测试分析阶段，“拐点分析”方法被大家广泛应用，请说明该方法的基本思想是什么？
答：基本思想就是性能产生瓶颈的主要原因是某个资源的使用达到了极限，此时表现为随着压力的增大，系统性能急剧下降，从而产生“拐点”现象。只要得到“拐点”附近资源的使用情况，就能定位出系统的性能瓶颈。
