作者：陈绍英,周志龙,金成姬
出版社：电子工业出版社
格式: AZW3, DOCX, EPUB, MOBI, PDF, TXT
大型IT系统性能测试入门经典试读：
前言
从前我们很少看到“软件亚健康”或“亚健康软件”这样的概念，之所以提出这个概念，是因为现在亚健康不但威胁着IT人的生活质量，也威胁很多应用系统的性能。
伴随着IT行业的高速发展，软件开发方法也越来越先进，实现的功能也越来越强大，应用软件几乎涉及了国计民生的各个领域。而与之相反的是，这些应用系统的整体性能却越来越低，尤其是一些涉及多用户并发的大型应用系统。因此，近几年软件性能测试工作显得越来越重要，各种性能测试工具也应需而生。“软件亚健康”和“亚健康软件”概念就是在这种背景下提出的。“软件亚健康”绝非危言耸听。作者曾亲身经历了多个由于性能不合格而终止上线的项目，其中一个项目曾是某国外公司为国内某大型银行开发的一套“银行信用卡申请审批系统”，此系统历经用户三次测试，每次均以数据库服务器崩溃而告终，最后银行只好忍痛让此公司出局。
本书以大型IT系统作为背景来研究性能测试的规划与设计、管理与实施方法，探讨如何通过规范的性能测试来解决IT系统的亚健康问题。
下面先从“亚健康软件”开始本书的讨论。
亚健康IT人与亚健康软件
亚健康IT人定义：记得2005年8月的某一天，作者和几位测试同行一起爬了次香山，结果第二天几个人累得几乎下不了床，一个星期之后，才觉得走路时的腿是自己的。无疑我们这几个人的身体都已进入“亚健康”状态。当时躺在床上忽然想到亚健康IT人就是“爬了一次香山需要休息一个星期才能恢复正常的从事IT行业的人”。
类似也可以做如下的定义：
超级健康IT人——爬了一次香山之后没有什么感觉的IT人，这类人应该属于具有运动员素质的IT人。
健康IT人——爬了一次香山之后休息一两天就恢复正常的IT人。
不健康IT人——爬了一次香山之后需要休息一个月甚至更长时间的人。
在软件领域中，判定软件性能高低的依据是其满足用户性能需求的程度以及是否存在一定的扩展空间，所以评价软件性能不要脱离具体用户背景，用户的性能需求与软件是否健康有着很大的关系，这一点与人的健康分类是有很大的区别的。例如对于电子政务系统，可以认为速度达到“自行车的性能”就是健康的，而银行或者电信的应用系统，速度至少要达到“飞机的性能”才是健康的。
与四类IT人的健康分类相对应，软件也可按其性能高低划分为四类。
超级健康软件——UNIX是“超级健康软件”的典型，“体魄”像运动员一样，非常“抗折腾”。
健康软件——性能稳定，可以满足用户现在以及将来一定时期内的扩展需求。例如我们日常用到的数据库管理系统。
亚健康软件——软件性能很一般，就像亚健康IT人正常上下班一样，能满足使用要求，但是扩展性、稳定性都很一般，只要环境发生变化，极有可能成为“不健康软件”。
不健康软件——性能很差，甚至存在严重性能问题的软件。
毫无疑问，开发人员应以做出超级健康或健康的软件为目标。但是现实恰恰相反，就像很多IT人都处于亚健康状态一样，超级健康和健康软件的比例很低，多数软件都存在性能问题。
亚健康软件是大多数公司赶进度和压缩成本的产物，也是本书讨论的重点。亚健康软件的例子很多：下面是某电子政务系统进行并发测试时，5个用户与50个用户的一些事务对比测试结果。某OA系统不同用户并发的响应时间对比(单位：秒)续表
这个电子政务系统是亚健康软件的典型。可以看出在50个用户并发时，其响应时间是5个用户并发时的几十倍，甚至上百倍。这套系统倒是与我们这些IT人很类似，平时上班走路根本看不出什么，可是爬一爬山，是否健康就见分晓了。
本书首次针对性能测试提出了“全面性能测试方案”，和读者共同探讨如何更加有效地诊断与治疗应用系统性能低下的“亚健康”问题。
亚健康软件良药——全面性能测试方案
不言而喻，软件亚健康问题将会越来越突出，因此我们应该尽早寻找诊断和治疗这一问题的方法。为了达到上述目的，本书提出了“全面性能测试方案”，期望能够成为解决软件亚健康问题的一剂“良药”。“全面性能测试方案”包含性能测试策略制定原则、测试场景设计通用模型、五一测试场景设计模型、全面性能测试方案使用方法四部分内容，基本覆盖了性能测试规划和设计的相关内容，为开展系统性能测试提供了一套完整可行的方案。“全面性能测试方案”主要特点如下。
●来自实践领域，适用范围广： “全面性能测试方案”是综合了大量项目的性能测试经验而提出的性能测试模型，可以满足银行、电信、OA、互联网等诸多领域应用系统的性能测试需要。
●测试工具无关性：目前性能测试工具的使用已经不再是难题，比较困难的是有了工具去测试什么场景、如何管理与实施性能测试以及如何分析测试结果。“全面性能测试方案”不是依赖于某一特定性能测试工具而提出的，而是一种通用的性能测试方法，它的目标是为使用性能测试工具的人员解决上面的难题。测试人员掌握“全面性能测试方案”后，设计和执行测试时可以选择JMeter、LoadRunner等任何一种性能测试工具。
●根据策略来裁剪测试内容：五一测试场景设计模型按照由浅入深的顺序设计，因此可以根据测试策略进行灵活的裁剪。可以裁剪的特点使模型更加灵活，测试设计人员可以根据实际情况选择对应的测试场景部分进行设计，简介节约了测试成本。
对于很多项目，性能测试是一项需要大量时间和成本投入的工作，因此有了“全面性能测试方案”，并不意味着可以杜绝亚健康软件的产生。但是建议有能力的公司，应该进行合理的投入开发出健康的软件，否则只能经常祈祷“不要发生性能问题”！如果一旦发生严重性能问题，将意味着更高的修复成本，防患于未然才是上策！
最后祝所有IT人都摆脱亚健康状态，开发出超健康的软件！
配套视频
本书免费提供了作者录制的两门LoadRunner学习视频课程：《LoadRunner性能测试快速入门》、《LoadRunner Controller使用基础》，共计14学时。
读者可以使用微信扫描下面的二维码来学习课程：
借助上面的视频课程，读者可以很容易掌握LoadRunner这一强大性能测试工具的基础用法，从而快速在性能测试中应用LoadRunner。
建议读者可以先学习视频中的内容，大致了解LoadRunner性能测试的测试过程，然后再开始学习本书的理论知识，这样更容易领悟本书的精髓，最终实现融会贯通的效果。
关于本书
本书分为三部分，包括了性能测试设计理论、实施和分析方法、性能测试实施案例等内容。
第一部分：兵法篇，即第1、2章。第1章主要介绍性能测试基础理论，是做好性能测试工作的必备知识，主要内容有性能测试简介、性能测试种类、性能测试误区、系统调整等；第2章介绍全面性能测试方案，是全书的核心部分，主要讲解性能测试策略制定、测试场景设计模型、测试方案使用方法等。
第二部分：战术篇，即第3、4章。第3章主要探讨如何在性能测试工作中设计与实施性能测试，包含了性能测试的启动、计划、实施、控制、收尾等内容；第4章介绍性能测试分析的基础方法。
第三部分：技术篇，即第5、6章。第5章主要探讨性能测试基本的调优技术与方法；第6章主要讲解性能测试工具JMeter的用法。
第四部分：案例篇，即第7、8、9章，详细讨论了一些涉及银行、电子政务等不同领域的性能测试案例，介绍了如何在实际中应用前面的理论。
致谢
感谢林锐博士，本书的前一版在林老师的大力推荐下得以顺利地出版；
感谢电子工业出版社的郭立、孙学瑛两位老师，她们对本书的出版提供了非常大的支持；
感谢本书合作者周志龙、金成姬、刘蕙兰、刘建华，本书的写作过程占用了大家大量的休息时间；
感谢电子工业出版社为本书辛勤付出的所有朋友们；
尤其要感谢夫人金成姬和宝贝女儿米菲，夫人通篇审校了本书并润色了那些难于理解的句子，还一起和米菲提供了大量本来可以陪她们的时间来让我写作。
联系方式
相信本书在出版后会有很多读者想与我们交流，读者可以通过下面的联系方式与我们进行沟通。
电子邮件：peaksoftchen@163.com。关于作者陈绍英15年以上IT系统开发与测试经验。现就职于中国民生银行信息科技部测试管理中心。本人拥有银行、互联网、电子政务等领域IT系统的测试管理与实施经验，目前主要专注银行系统的性能测试与自动化测试。现负责所在银行 IT 系统的性能测试管理、智能一体化测试平台 DT的设计、开发与推广等工作，曾经带领团队完成了民生银行新一代系统中100多个系统的性能测试组织管理与实施工作。
本人在软件测试理论与实践方面进行了非常深入的研究和探索，目前已出版原创图书作品三部：《Web性能测试实战》(2006年，国内第一本性能测试理论方面的作品)、《LoadRunner 性能测试实战》(2007 年，国内第一本讲解 LoadRunner的作品)、《LoadRunner虚拟用户开发指南》(2009年)三部；翻译作品一部：《软件测试与持续质量改进》第二、三版(2008年、2011年)；在《金融科技治理与研究》、《程序员》等杂志上发表过《银行IT系统功能&性能一体化测试理论及应用》、《性能测试》、《治疗软件亚健康》、《性能测试兵法》、《架构设计阶段的性能测试》、《中小型IT企业产品测试案例解析》等多篇文章。
本人在性能测试方面的研究，丰富了国内IT领域性能测试相关的理论体系，从理论与实践推动了性能测试在国内的发展。已经出版的图书、视频等作品，把一批人带入了性能测试领域，并指导了很多项目经理、测试工程师非常系统地的规划、设计、实施性能测试工作。《Web性能测试实战》一书中提出的“全面性能测试模型”，成为很多测试团队组织与开展性能测试工作的指导原则。周志龙现就职于中国民生银行信息科技部测试管理中心。拥有近10年IT系统开发与测试经验。在银行、电信、互联网等领域 IT 系统有着丰富的性能测试项目经验和测试管理经验，擅长性能测试分析及调优。曾参与编写《性能测试进阶指南》一书，承担过中国移动、中国电信、中国网通、中国建设银行、中国民生银行等相关系统的性能测试实施项目。
目前主要专注银行系统的性能测试与自动化测试。金成姬北京大学光华管理学院在读MBA。10年以上IT行业从业经验，擅长测试团队管理，拥有丰富的软件测试管理与实施经验。曾参与编写《Web性能测试实战》《LoadRunner性能测试实战》《LoadRunner虚拟用户开发指南》等作品。兵法篇第1章系统性能测试基础
下面是很多公司常见的和性能测试相关的工作安排：
预计有3000人使用系统，去测试一下系统1000个用户的并发情况！
系统开发完了，测试一下系统性能！
系统准备到用户那里实施了，测试一下性能吧！
系统要验收了，做个压力测试！
系统在公司内部开发环境已经完成，接下来准备测试一下系统性能瓶颈！
这个系统在开发环境下测试出了性能瓶颈，需要进行大的调整!
……
相信上面这些工作安排现在仍然会有很多测试人员遇到，甚至将来也可能会在很多公司继续发生。实际上，这些做法都或多或少存在一些问题。就作者对测试行业的了解而言，性能测试在国内软件公司存在的问题是非常多的。
本章重点介绍性能测试的基础知识。通过本章的学习，读者可以对软件性能测试形成一个正确的认识。本章主要内容如下：
●软件性能测试简介。
●软件性能测试种类。
●常见性能测试误区。
●系统性能调整基础。1.1 性能测试简介
在软件系统日益复杂的今天，性能已经成为软件质量重要的衡量标准之一。这一点尤其体现在大型IT系统上。目前IT系统几乎无处不在，在给用户带来方便的同时，也对开发和测试人员提出了新的要求。性能测试对测试人员素质要求很高，不但要求测试人员有很强的技术能力，还要具备综合分析问题的能力。
本节主要介绍一下性能测试需要的基础知识。性能测试是最能体现测试工程师能力的测试工作之一，要求测试人员具有多方面的技能。例如，常见所需的技能有以下几个。
(1)掌握LoadRunner、JMeter等性能测试工具的使用。
(2)具备一定的程序开发能力，例如，C、.NET、Java。
(3)掌握Oracle、DB2等主流数据库的使用和基础调优方法。
(4)掌握UNIX/Linux操作系统的使用和基础调优方法。
(5)掌握Weblogic/Websphere等应用服务器的使用和基础调优方法。
(6)综合分析与定位系统性能问题的能力。
在具有上述各项能力的同时，还要制订出合适的性能测试策略以及性能测试方案才算具备了做好性能测试工作的基础条件。之后，还要按照性能测试方案对系统进行全面的测试和分析，才可能发现并定位问题的真正原因。
接下来介绍一些性能测试中的术语，都是性能测试中出现频率比较高的词汇。掌握了这些基础的性能测试知识，可以更好地开展测试工作。典型的术语主要有并发用户、并发用户数量、请求响应时间、事务响应时间、吞吐量、吞吐率、TPS、点击率、资源利用率等。
并发用户：并发一般分两种情况。一种是严格意义的并发，即所有的用户在同一时刻做同一件事情或者操作，这种操作一般是指做同一类型的业务，例如，在贷款审批业务中，一定数目的用户在同一时刻对已经完成的审批业务进行提交(操作的不是同一记录)；还有一种是特例，即所有用户进行完全一样的操作。例如，在三方存管业务中，所有的用户可能会一起进行银证转账业务，测试操作同一个券商账户时的性能，模拟这类并发用户目的是为了测试数据库和程序对并发操作的处理。
另外一种并发是广义范围的并发。这种并发与前一种并发的区别是尽管多个用户对系统发出了请求或者进行了操作，但是这些请求或者操作既可以是相同的，也可以是不同的。对整个系统而言，仍然有很多用户同时对系统进行操作，因此属于并发的范畴。
可以看出，后一种并发是包含前一种并发的。实际上，后一种并发更接近用户的实际使用情况，因为对于大多数的系统，只有数量很少的用户进行“严格意义上并发”。对于性能测试而言，这两种并发情况一般都需要进行测试，通常的做法是先进行严格意义上的并发测试。严格意义上的用户并发一般发生在使用比较频繁的模块中，尽管发生的概率不是特别高，但是一旦发生性能问题，后果很可能会非常严重。严格意义上的并发测试往往和功能测试关联起来，因为并发功能遇到异常通常都是程序的问题，这种测试也是健壮性和稳定性测试的一部分。
用户并发数量：关于用户并发数量，有两种常见的不切实际的观点。一种观点是把并发用户数量理解为使用系统的全部用户的数量，理由是这些用户可能同时使用系统；还有一种比较观点是把在线用户数量理解为并发用户数量。实际上在线用户不一定会和其他用户发生并发，例如正在浏览网页信息的用户，对服务器没有任何影响。但是，在线用户数量是计算并发用户数量的主要依据之一。
并发主要针对应用服务器或数据库服务器而言，是否并发的关键是看用户的操作是否对服务器产生了影响。因此用户并发数量的正确理解是在同一时刻与服务器进行交互的在线用户数量。这些用户的最大特征是和服务器发生了交互，这种交互既可以是单向传送数据包，也可以是双向传送数据报文。
用户并发数量的统计方法目前还没有统一的公式，不同特点的系统会有不同的计算方法，主要通过一些经验公式来评估，基本原则是“宁可多算，不可少算”。例如，OA系统统计并发用户数量的经验公式为：使用系统的用户数量×(5%～10%)。对于经验公式，没有必要拘泥于计算出来的结果，因为为了保证系统的扩展空间，测试时的并发用户数量都会稍稍多一些，除非要测试系统能承受的最大并发用户数量。举例说明：如果一个系统期望用户1000个，则在100个以内并发条件下测试系统的响应时间和TPS是否满足性能需求即可。
请求响应时间：请求响应时间指的是客户端发出请求到得到响应的整个过程的时间。这个过程是从客户端发起一个请求开始计时，到客户端接收到从服务器端返回的响应结果为止计时结束。在某些工具中，请求响应时间通常会被称为TTLB，即Time to Last Byte，意思是从发起一个请求开始，到客户端收到最后一个字节的响应所耗费的时间。请求响应时间的单位一般为“秒(s)”或者“毫秒(ms)”。请求响应时间的分解如图1-1所示。图1-1 Web请求过程分解图
从图1-1可以看出，请求响应时间为“网络响应时间”和“应用程序与系统响应时间”之和，具体由七个部分组成，即(N1+N2+N3+N4)+(A1+A2+A3)。
事务响应时间：事务可能由一系列请求组成，事务的响应时间主要是针对用户而言，属于宏观上的概念，主要为了向用户说明业务响应时间而提出的。例如：跨行取款事务的响应时间就是由一系列的请求组成。事务响应时间和后面的业务吞吐率都是直接衡量系统性能的参数。
吞吐量：是指在一次性能测试过程中网络上传输的数据流量的总和。吞吐量/传输时间，就是吞吐率。
吞吐率(Throughput)：通常用来指单位时间内网络上传输的数据流量，特定条件下也可以用来指单位时间内处理的客户端请求数量，它是衡量网络传输性能的重要指标。通常情况下，吞吐率可以用“字节数/秒”“请求数/秒”或者“页面数/秒”来衡量，在LoadRunner中则用每秒传输的字节数来衡量。
但是从业务角度来看，吞吐率也可以用来指系统的业务吞吐能力，例如“业务数/小时或天” “访问量/天” “页面访问量/天”来衡量。例如在银行卡审批系统中，可以用“千件/每小时”来衡量系统的业务处理能力。
TPS(Transaction Per Second)：是指每秒钟系统能够处理的交易或者事务的数量，用来衡量系统业务处理能力的重要指标。
对于一些日交易量比较大的系统，通常在测试报告中用每小时完成多少万笔或8/12/24小时完成多少万笔交易来描述系统的业务处理能力，这样可以感觉更直观。
点击率(Hit Per Second)：每秒钟用户向服务器提交的 HTTP 请求数。这个指标是Web应用特有的一个指标。Web应用是“请求—响应”模式，用户发出一次申请，服务器就要处理一次，所以点击是Web应用能够处理的交易的最小单位。如果把每次点击定义为一个交易，点击率和TPS就是一个概念。容易看出，点击率越大，对服务器的压力也越大。点击率只是一个性能参考指标，重要的是分析点击产生时的影响。
需要注意的是，这里的点击不是指鼠标的一次“单击”操作，因为在一次“单击”操作中，客户端可能向服务器发出多个HTTP请求。
资源利用率：资源利用率指的是对不同系统资源的使用程度，例如服务器的CPU利用率、磁盘利用率等。资源利用率是分析系统性能指标进而改善性能的主要依据，因此是Web性能测试工作的重点。
资源利用率主要针对Web应用服务器、操作系统、数据库服务器、网络等，是测试和分析瓶颈的主要参考。在性能测试中，要根据分析需要采集相应的参数进行分析。
本节介绍了性能测试的一些基本内容及常见的概念术语，希望读者认真理解，为进一步阅读和研究后续章节打好基础。1.2 性能测试种类
系统性能测试包含很多内容、种类，例如峰值测试、负载测试、压力测试、强度测试都属于性能测试的范畴。本节主要探讨一下在测试工作中，性能测试主要的常见的种类。在第2.1节中，将会对这些性能测试内容进行整合，提出“全面性能测试理论”。
在通常的系统性能测试工作中，可能涉及的性能测试种类主要有峰值测试、压力测试、负载测试、强度测试、容量测试、并发测试、可靠性测试、配置测试，以及狭义范围的性能测试等。多数团队中，这些种类的性能测试很少单独一一实施，一般会结合起来实施或选择其中几种来实施。对于初学者很多时候这些名词会误导初学者，搞不清这些测试种类的区别和关系，又不知道如何开展工作。实际上，上面提到的性能测试基本属于联机交易的性能测试范畴，而这些性能测试种类的本质都是并发用户的性能测试：或者调整加压方式、或者调整加压时间、或者调整压力大小，再配合一些诸如测试环境、测试参数的调整，就得到了不同种类的性能测试。
因此本书的核心理论主张不必理会这些概念，根据性能测试的本质从技术和业务两个角度来定义性能测试种类，第2章将深入探讨性能测试种类的划分。
下面介绍一下各类测试的主要内容和特点。
压力测试：对系统不断施加压力的测试，是通过确定一个系统的瓶颈或者不能接收用户请求的性能点，来获得系统能提供的最大服务级别的测试。例如，测试一个Web站点在大量的负荷下，何时系统的事务响应时间会变得不可接受或者事务不能正常执行。
压力测试是为了发现在什么条件下应用程序的性能会变得不可接受，主要通过改变应用程序的输入以对应用程序施加越来越大的负载，直到发现应用程序性能下降的拐点。压力测试和负载测试有些类似，但是通常把负载测试描述成一种特定类型的压力测试—例如不断增加用户数量以对应用程序进行压力测试。
负载测试：通过在被测系统上不断增加压力，直到性能指标达到极限，例如响应时间超过预定指标或者某种资源已经达到饱和状态。这种测试可以找到系统的处理极限，为系统调优提供依据。
通常情况下，压力测试侧重测试系统在不同压力下的表现，重点关注压力大小；负载测试则侧重测试系统在较大压力下长时间进行加压时的表现，重点关注加压时间。
实际的测试工作中，压力测试和负载测试并没有进行严格区分：很多称为压力测试的场景也会长时间加压，很多称为负载测试的场景也会不断改变负载的压力大小，因为项目干系人根本搞不清楚概念上细节的差别，所以这些名词成了性能测试的一个叫法而已。
对于这些概念，最好的方式仍然是回归本质，不以这些互相存在关联关系的名词来划分测试种类。
强度测试：强度测试主要是为了测试系统在异常情况下的处理能力，例如测试系统在较低的资源配置下的性能。下面是一些强度测试的实际案例。
●正常压力下用户点击率为“1000次/秒”，运行点击率为“2000次/秒”场景。
●运行CPU或内存利用率在90%以上的场景。
●运行可能导致磁盘数据存取异常频繁的场景。
强度测试是特别重要的测试，对评估系统的稳定性、健壮性、扩展性均具有重要的意义。这种在特殊条件下的测试，更容易发现系统深层次的性能问题。
并发测试：主要用来测试多用户同时访问同一系统/同一模块/同一业务功能/同一数据记录时是否存在性能问题，几乎所有的性能测试都会涉及并发测试。
大数据量测试：大数据量测试重点分为两种，一种是针对某些系统的新建记录、统计查询等业务进行的运行时大数据量测试；另一种是历史大数据量测试，测试存量数据达到一定量级下的性能。
配置测试：配置测试主要是通过测试找到系统各项资源的最优分配原则，其测试结果是系统生产环境参数配置的重要依据。例如，可以通过测试不断调整应用服务器各项参数，使之达到一个较好的性能。
可靠性测试：测试系统在一定压力下长时间运行后是否稳定可靠，主要用来测试系统是否可以长时间稳定对外提供可靠的服务。例如可以进行使CPU保持70%～90%利用率的压力，连续对系统加压7×24小时的测试，然后根据结果分析系统是否稳定可靠。
狭义性能测试：主要用来描述常规的性能测试，通过模拟生产运行时的使用场景和业务压力来测试系统的性能是否满足生产性能要求。例如可以投产环境来进行测试，测试出系统的最大业务处理能力等指标，为接下来的投产运维提供参考。性能测试是一种“正常压力”下的测试，主要是测试正常使用时是否满足性能要求，同时可能为了保留系统的扩展空间而进行一些稍稍超出“正常压力”范围的测试。
通过深入了解上面的各个测试种类，可以看出实际上它们大多是密切相关的。例如，连续加压24小时可靠性测试，可能包含了强度测试、并发测试、性能测试和负载测试等。因此，在进行性能测试规划与设计时决不能忽略它们的内部联系，而是抓住本质后以一种高效率的方式来组织性能测试。1.3 性能测试误区
性能测试以其独特的地位和重要性越来越为软件测试人员、开发人员和用户所重视，但是在实施性能测试方面，不管是测试人员还是开发人员，仍然存在一些认识上的不足，存在这样或者那样的问题。本节列举的问题都是日常性能测试工作中相关人员经常进入的一些误区，这些观点往往只在极其特殊的情况下才正确。希望读者了解这些常见的性能测试误区后，能在以后的工作中避免类似的情况发生。
误区1：提高硬件配置就可以提高性能了，因此性能测试不重要。
这是以前系统规模较小时期留下来的认识。早期的DOS时代以及后来管理信息系统刚刚流行的时期，软件规模一般较小，而硬件的更新确实日新月异，软件的性能一般不是突出问题，因为只要升级硬件，性能问题很容易得到解决。
现在随着软件规模的扩大，提高硬件配置只是解决性能问题的一个基本手段。因为如果软件自身存在性能问题，再多的资源可能也不够用，例如内存泄漏问题，随着时间的增加，内存终究会被耗尽，最后导致系统崩溃。
因此，如果用户对软件的性能要求较高，这将意味着不但要从硬件方面来提供性能，还要从数据库、应用服务器、操作系统等多方面入手来提高性能，尤其要对开发的软件系统本身进行优化，从而全面提高系统的性能。
误区2：性能测试在所有其他测试完成后，测试一下看看就可以了。
这是非常普遍的做法，主要是项目负责人忽略了性能测试的重要性引起的。这种做法最严重的后果是一些性能问题可能在后期无法彻底解决，例如架构设计方面的失误，可能意味着要么系统“将就”上线，要么系统“推倒重来”。
作者亲身经历过一个银行项目，由于数据库表设计不合理，最终导致整个项目的核心功能推倒重来。在那个应用系统中，由于数据库设计的一个巨大缺陷——大量内容放在一张表上，导致当并发用户较多时，数据库服务器无法及时并行处理用户请求，最后停止提供服务。这种问题一般在开发环境下不经过测试或者详细的审核论证是很难发现的，而一旦发生，几乎没有什么太有效的补救措施。
当然这并不意味所有的性能测试都要尽早进行。第 2.2 节将会专门讨论性能测试的策略问题，性能测试的启动时间由系统自身的特点和性能需求来决定。
误区3：性能测试独立于功能测试。
性能测试和功能测试是紧密联系在一起的，首先是因为很多性能问题是由软件自身功能的设计缺陷引起的。如果应用系统功能设计不完善或者代码运行效率低下，通常会带来一些性能问题。功能测试通常要先于性能测试执行或者同步进行，功能测试进行顺利才能保证性能测试顺利开展。
其次功能测试可以发现性能问题，性能测试也能发现功能问题。例如，并发用户测试就能发现一些算法设计上的问题。在一些业务处理上，通常采用多线程同步算法，通过并发用户测试很容易发现算法中存在的一些功能缺陷。
此外，如果一些系统的性能要求比较高，则性能测试和功能测试会同步进行，因为后发现的性能问题可能无法补救。
误区4：性能测试就是用户并发测试。
仍然有很多技术人员一提到性能测试，就会联想到并发用户测试，进而认为性能测试就是“测试一下多用户并发使用系统时的性能表现”。尽管性能测试是以用户并发测试为主的测试，但实际上性能测试还包含峰值测试、疲劳强度测试和大数据量测试等许多测试种类。
实际上，性能测试属于项目范畴，应该按照“启动—计划—实施—控制—收尾”的项目管理过程来开展工作，而不是简单地测试一下就完成任务了。
误区5：在开发环境下进行一下性能测试就可以了。
很多时候，在系统开发完成后会进行性能测试，在开发环境“看一看”软件的性能。而实际上大多数的开发环境因为硬件条件比较差，所以反映不了系统的真正性能。这是因为系统的性能表现通常依赖于硬件，一些系统在资源不足的情况下可能运行缓慢，这类问题往往提高一下硬件配置就可以解决问题。对于一些在资源不足条件下发现的性能问题，主要通过优化程序来解决，则可能需要花费非常高的人力成本。当然，对于一些算法方面的缺陷、内存泄漏、低效SQL等问题，则无论任何环境下都应该修正程序来解决。
性能测试的最终目的是为了发现系统的软件和硬件瓶颈，因此性能测试尽量在软件和硬件尽可能接近用户投产的环境下来进行。但是有两种可以例外的情况：一种是为了发现某些功能方面的问题，例如为了发现并发算法的一些缺陷；另外一种就是有非常好的硬件资源或者实验室作为开发环境。
以作者负责的银行系统性能测试为例，几乎不会在开发环境下开展性能测试，多数会在准生产环境下或独立的接近生产的性能环境来开展性能测试工作。
误区6：系统存在瓶颈，不可以使用。
系统发现了瓶颈，的确是很让人担心的一件事情。不过不要紧，很多的瓶颈可以不必去投入成本进行调优。一些性能问题或瓶颈是否要进行调优取决于是否会影响用户的正常使用，部分性能问题只是从技术角度上看是问题而已，从用户性能需求角度看则不是当下需要解决的问题。了解系统的已知瓶颈问题可以更好地掌握系统性能特性，为改善和扩展系统提供依据。
举个例子：如果距离工作单位只有10分钟的路程，相信大多数人会步行上班，部分人可能会骑着自行车上班，但是很少有人开汽车上班——这样纯属资源浪费。做性能测试也是这样，只要系统在性能方面能满足用户的需求并留有 30%～50%的扩展空间即可。一个系统预估一两年内最大并发用户500个左右，测试时发现当前资源下1000个用户并发时开始运行缓慢，这样的性能问题可以不必处理，但如果600个左右并发出现性能问题，则应该对系统进行调优。
误区7：不切实际的性能指标。
这种现象主要归结于对系统性能需求的不了解。很多时候，尤其是用户会提出很多不切实际的性能指标，例如，针对500个用户使用的OA系统，可能有的业务负责人会提出要满足100个，甚至500个用户并发的性能目标，而实际并发数量不会高于50个。这种情况需要和用户进行沟通来确定合理的性能需求。
总之对待性能问题要根据实际情况来决定，对于系统的性能要把握合适的“度”，一个系统投产版本的性能在其生命周期能够满足性能需求即可。1.4 性能调整基础
在性能测试工作中经常会提到“性能调优”或者“系统调优”等概念，实际上“性能调优”或者“系统调优”都属于性能调整的范畴。性能调整是比性能调优更准确的说法，例如可能为了让某些部分“更优”而把某些部分调得“不优”，因此本节中使用性能调整这一叫法。
所谓性能调整是为了改变系统特性而对系统软件或者硬件进行的修改，性能调整不是测试人员的职责，性能测试工程师的主要任务是发现并定位性能问题。对于性能测试中发现的问题，通常由性能测试工程师、DBA、系统管理员、开发人员共同来解决，但是对于测试人员，了解调整的相关知识则是十分必要的。
本节主要讨论性能调整的基础知识。性能调整应该按照一定的顺序进行，主要包括下面五个步骤。
1)确定问题
通常情况下，首先确定系统是否存在问题，并对问题进行正确的定位，重点是发现系统的瓶颈。通常，确定系统问题从下面几个方面入手。
●应用程序代码：通常情况下，很多程序的性能问题都是写出来的，因此对于发现瓶颈的模块，应该首先检查一下代码；
●数据库配置：数据库配置经常会引起整个系统运行缓慢，一些诸如Oracle的大型数据库都是需要DBA进行正确的参数调整才能投产的。
●操作系统配置：操作系统配置不合理也可能引起系统瓶颈。
●硬件设置：磁盘速度、内存大小等都是容易引起瓶颈的原因，因此这些都是分析的重点。
●网络：网络负载过重会导致网络冲突和网络延迟。
同时，还要对系统的使用情况进行调查，例如，以下几种情况。
●是否听到了很多用户的抱怨？
●是否某些操作的响应时间会随着使用时间越来越长？
●CPU的使用率是否很低而I/O的使用率却很高？
●使用过程中性能是否稳定？
系统性能问题不是显而易见的，要进行仔细的查找才能够进行正确的定位。
2)确定原因
确定系统存在问题后就要仔细分析，确定引起问题的原因。确定原因很大程度上靠的是个人经验，涉及的知识有操作系统、数据库、网络和程序开发等许多方面。
和确定性能问题一样，确定原因仍然要广泛地搜集信息。通常要进行如下的分析。
●问题的影响是什么，是响应时间还是业务吞吐量，或者是其他问题？
●是大多数用户还是少数用户遇到了问题，如果是少数用户，这几个用户与其他用户的操作有什么不同？
●系统资源监控的结果是否正常：CPU的使用是否到了极限？I/O情况如何？
●问题是否集中在某一类模块中？
●是客户端还是服务器出现了问题？
●系统硬件配置是否够用？
●是否实际负载超过了系统的负载能力？
●是否未对系统进行优化？
通过这些分析以及一些具体系统相关的问题，可以对系统瓶颈有更深入的了解，进而分析出真正的原因。
3)确定调整目标和解决方案
在分析出问题的原因后，测试人员和其他系统调整人员首先要确定调整目标，然后设计解决方案。确定调整目标的主要作用是明确何时停止调整系统，否则工作将永无尽头。
每个系统都有不同的特点，因此调整目标可能不同。例如，下面这些都是系统的调整目标。
●提高系统吞吐量。
●缩短响应时间。
●更好地支持并发。
设计解决方案的主要依据就是这些调整目标，有了明确的方案和目标，就可以进行后面的工作了。
4)测试解决方案
实施解决方案后，就要对方案进行测试。测试人员可以使用以前的测试场景来进行测试，验证系统是否解决了性能问题。测试解决方案尽量在仿真测试环境下进行，因为在生产环境下可能会带来破坏，除非充分估计了测试的风险，并且准备了充分的补救方案。
5)分析调整结果
性能调整的最后一步是分析调整结果，如果没有解决问题，则要重复前面的工作。在测试系统调整方案过程中，要经常分析所做的工作，例如没能准确定位问题或调整方案不正确，预期目标可能不会达到，尽早发现这些问题可以使工作方向正确。
分析结果主要考虑下面的问题。
●系统调整是否达到或者超出了预定目标？
●系统是整体性能得到了改善，还是牺牲某部分性能来解决问题？
●调整是否可以结束了？
最后，如果达到了预期目标，则调整工作完成。1.5 小结
本章首先介绍了性能测试的基础知识，包括性能测试基础概念、性能测试目的等。读者要正确理解这些概念，为深入学习性能测试打好基础。
接下来介绍了性能测试的种类和常见的性能测试误区。性能测试是一个大的范畴，只有正确理解这些概念并综合运用才能正确开展，性能测试工作。
最后简要介绍了性能测试调整的基本方法。调整最重要的是确定调整目标，然后不断地改善系统性能，直到达到预期目标。
总之要想做好性能测试，一定不能拘泥于“压力测试”“负载测试”“强度测试”等概念，应该重点关注如何通过性能测试来发现系统的性能问题。
第2章要讲解如何通过本书提出的“全面性能测试方案”来规划性能测试，使系统尽可能避免在开发阶段发现和解决性能问题。第2章全面性能测试方案
性能测试、压力测试、负载测试、强度测试、稳定性测试、健壮性测试……这么多眼花缭乱的性能测试类型名称，估计很少有人能准确地区分并说出定义来。至于如何制订合理的性能测试策略，同时把这些性能测试组织起来，并设计对应的测试场景，就更具有挑战了。
因此，性能测试的规划与设计、组织与实施没有相对统一的规范与流程，例如很多项目尽管设计了测试场景，但执行性能测试时又不按照设计好的场景来执行，甚至设计的测试场景根本不具有“可执行性”，执行测试时人为来决定如何执行场景，造成了测试设计与测试执行相脱节。
为了解决这些问题，本章提出了“全面性能测试方案”，主要讲解在企业的实际工作中，如何比较全面地开展系统性能测试工作，使性能测试工作更加合理、高效率地开展。
本章重点讲解全书的理论核心“全面性能测试方案”，主要包含如下的内容。
●性能测试策略制订原则。
●测试场景设计通用模型。
●五一测试场景设计模型。
●全面性能测试方案应用。
注：本章的全面性能测试方案主要是针对系统测试阶段的性能测试而提出的，单元测试阶段的性能测试一般由测试人员配合开发人员进行，可以划分到单元测试阶段，不在本书研究之列。2.1 全面性能测试方案简介
通过第1章的学习可以看出，性能测试的很多种类都是关联的。这就为我们提供了一个思路：很多种类的性能测试可以打通关联关系统一组织来进行。统一组织性能测试的巨大好处是可以按照层次由浅入深对系统进行测试，进而减少不必要的工作量，以实现节约测试成本的目的。为此，本章提出了“全面性能测试方案”。“全面性能测试方案”提出的主要依据是一种类型的性能测试可以在某些条件下转化成为另外一种类型的性能测试，而这些类型测试的实施基本相似。例如：针对一个网站进行测试，模拟10～50个用户就是在进行常规性能测试，用户增加到1000个，乃至上万个时，就变成了压力/负载测试；如果同时对系统进行大量的数据查询操作，就包含了强度测试和大数据量测试。
在“全面性能测试方案”中，把性能测试分为八个类别，然后结合测试工具把性能测试场景分为五大类。第 2.4 节将会展开讨论“全面性能测试方案”的测试场景设计方法。下面首先介绍8个性能测试类别的主要内容。
(1)预期指标的性能测试：系统在需求分析和设计阶段都会提出一些性能指标，完成和这些指标相关的测试是性能测试的首要工作之一。把针对预先确定的一些性能指标而进行的测试称为预期指标的性能测试。
这些指标主要指诸如“系统可以支持并发用户 1000”“系统响应时间不得高于 3 秒”等在产品说明书等文档中十分明确的内容。对这种预先承诺的性能要求，性能测试团队应该首先进行测试验证。
(2)独立业务性能测试：独立业务实际是指一些核心业务模块对应的业务，这些模块通常具有功能比较复杂、使用比较频繁、属于核心业务等特点。这类特殊的、功能比较独立的业务模块始终都是性能测试的重点。因此不但要测试这类模块和性能相关的一些算法，还要测试这类模块对并发用户的响应情况。
核心业务模块在需求阶段就可以确定，在系统测试阶段开始单独测试其性能。如果是系统类软件或者特殊应用领域的软件，通常从单元测试阶段就开始进行测试，并在后继的集成测试、系统测试和验收测试中进一步进行测试，以保证核心业务模块的性能稳定。何时开始测试核心模块主要由性能测试策略决定，读者可以参考第 2.2 节“全面性能测试策略制定原则”部分。
用户并发测试是核心业务模块的重点测试内容。“并发”主要内
试读结束[说明：试读内容隐藏了图片]