性能测试进阶指南：Loadrunner实战91-第1章 性能测试基础

1、.：.； 目录 TOC o 1-3 h z u HYPERLINK l _Toc297915338 第一章 性能测试根底 PAGEREF _Toc297915338 h 2 HYPERLINK l _Toc297915339 1.1 性能测试工程师的规范及挑战 PAGEREF _Toc297915339 h 2 HYPERLINK l _Toc297915340 1.1.1 性能测试工程考评目的 PAGEREF _Toc297915340 h 2 HYPERLINK l _Toc297915341 1.1.2 性能测试工程师的挑战 PAGEREF _Toc297915341 h 3 HYPER

2、LINK l _Toc297915342 1.2 性能测试根底 PAGEREF _Toc297915342 h 5 HYPERLINK l _Toc297915343 1.2.1 性能 PAGEREF _Toc297915343 h 5 HYPERLINK l _Toc297915344 1.2.2 性能目的 PAGEREF _Toc297915344 h 16 HYPERLINK l _Toc297915345 1.2.3 性能分析及调优 PAGEREF _Toc297915345 h 17 HYPERLINK l _Toc297915346 1.2.4 单机软件性能与网络架构软件 PAGE

3、REF _Toc297915346 h 22 HYPERLINK l _Toc297915347 1.2.5 性能测试的流程 PAGEREF _Toc297915347 h 23 HYPERLINK l _Toc297915348 1.2.6 性能测试的留意要点 PAGEREF _Toc297915348 h 24 HYPERLINK l _Toc297915349 1.2.7 性能测试招聘要求 PAGEREF _Toc297915349 h 25 HYPERLINK l _Toc297915350 小结 PAGEREF _Toc297915350 h 26第一章 性能测试根底软件测试逐渐成为

4、软件开发过程中一个必不可少的环节，随着功能测试的必要性被认可，自动化测试和性能测试也逐渐崭露头角。我们经常会埋怨阅读网页慢、下载文件慢，其实这都是属于性能问题。用户在得益于功能方面的质量提升后，开场对性能有了新的认识和要求，而性能测试并不像功能测试那样可以“低门槛进展。性能测试的本质是经过编写一个程序去测试另外一个程序，而正是有了这个相对的“高门槛，性能测试便成了一个“高薪、“高技术含量的任务，新人在看到高手指点江山(性能测试)时，充溢了羡慕的眼神，摩拳擦掌预备进入这个行业。在开场从事性能测试任务之前，我们先来看看这个职位的考核规范和面临的挑战。1.1 性能测试工程师的规范及挑战当他掌握了性能

5、测试的根本技艺，接着就需求找到一家适宜的企业，经过劳动换取经济上的报答，那么通常公司如何去招聘一个性能测试工程师，并如何进展绩效考评呢?即性能测试工程师应该到达的任务目的究竟是什么?1.1.1 性能测试工程考评目的在引见性能测试之前，我们回想一下功能测试的考评和任务内容。假设他是一名功能测试经理，该如何考评他的员工呢?当软件测试刚刚进入中国时，我们对测试的了解是经过模拟用户执行，发现用户能够遇到的问题，而缺陷的数目成了考评的独一目的。例如PM(Project Manager)规定，每个测试人员每天都要发现10个以上的缺陷，否那么阐明他在任务态度和任务才干上有一定的缺陷。综上，作为一名功能测试工

6、程师，其考评要求可以归结为一条，那就是测试经过的软件不会被用户发现严重的缺陷。而如今，软件测试逐渐正名，我们对测试的了解从证明软件没有错误变为证明软件具备一定的质量，而功能测试工程师的考评规范也随之发生了变化。功能测试工程师的考评目的主要有以下几点：缺陷数目缺陷的数目虽然不能作为主要的考评目的，但是从某一个角度也阐明了测试工程师发现问题的才干。在成熟的软件开发公司中，我们可以经过历史数据生成的缺陷质量模型准确预估缺陷数目。假设他发现的缺陷数量明显低于预估，那么阐明他的任务能够存在一定问题。2缺陷质量有量没有质是不行的，由于计件制的压迫，测试人员往往为了到达数目上的目的而凑缺陷，数目是够了，但是

7、所提的缺陷都是鸡毛蒜皮的事情，缺陷的危害等级和优先级都比较低，那么对软件质量的提升效果会相对较差。在缺陷的质量中包含两个概念：缺陷的严重等级和优先级对缺陷的描画3任务态度测试任务是一个很容易“偷懒的任务，是需求个人积极自动、追求完美的任务，对于测试工程师，只需具备擅长交流、积极自动、“视公为私的态度才干对被测对象担任。4任务效率在较短的时间内能否可以高质量完成上级布置义务的才干。5文档编写过去所谓的软件测试工程师只是软件测试执行工程师，如今被称为Tester。如今测试工程师还需求进展测试方案、测试方案及用例等文档的编写任务。6团队协作才干7其他相关技艺性能测试在国内刚刚开场流行。一个公司招聘性

8、能测试工程师的主要目的是经过对产品进展专业的性能测试，获得一份性能测试评价报告，从而向用户证明本产品可以满足预期的性能需求。随着性能测试职位的逐渐成熟，对这个职位的要求也越来越严厉，性能测试的目的不仅仅是为了获得当前系统的性能评价，而是希望进一步经过性能测试发现系统性能瓶颈并修复性能问题。而性能问题的修复本钱普通相对较高，如何运用最低的本钱换取最高的性能，从而在性价比上找到黄金分割点，将是性能调优的重点。性能测试工程师的考评目的会包括以下内容：1能否可以独立开发脚本能否运用一种或多种性能测试工具完成用户行为的模拟脚本开发任务。2能否对需求进展性能分析并获得性能需求任何测试都是基于需求的。作为一

9、名性能测试工程师，需求具备一定的性能需求分析才干，从而根据用户的需求进展性能测试，得到被测系统与用户需求之间的差距，从而生成性能报告并提供性能调优方案。3能否设计场景及监控负载系统完成对性能测试的实施和监控任务对性能测试进展实施，设计负载规那么并监控负载下各个系统的形状。4能否经过性能测试发现比较详细的性能瓶颈具备一定的性能结果分析及瓶颈定位才干。5文档编写与环境搭建的才干独立编写性能测试文档和搭建测试环境的才干。6团队协作才干7其他相关技艺1.1.2 性能测试工程师的挑战作为任务了几年的功能测试工程师来说，大家觉得在功能测试任务中的挑战是什么呢?1公司不注重测试2就我一个人做测试3找不到缺陷

10、4开发工程师不能及时修正测试中发现的缺陷5不熟习业务6不了解功能测试的方法及流程总结来说就是任务内容略感反复、缺乏技术含量，并且在有限的时间和资源下难以到达理想化的目的。在实践任务中，要确保软件没有缺陷是比较困难的，这是由于：1软件不能够不存在缺陷2测试无法发现一切缺陷3测试在大多数情况下都没有足够的资源和时间(在本钱和质量上寻求平衡)所以无法完全保证整个软件在交付时不存在缺陷。虽然可以经过各种方法将严重级别或者优先级别较高的问题发现并修复，但由于个人才干或客观缘由还是会遗留某些缺陷。那么作为一个性能测试工程师所面临的挑战又有哪些呢?1对性能测试的实际和技术不熟习2公司不注重性能测试3就我一个

11、人做性能测试4测试出来的结果不知道怎样分析5不熟习业务6定位出的性能问题无法修正总结来说，就是如何在有限的时间和资源下，保证提交给用户的软件系统可以到达指定的性能需求目的。从某种角度来说，如今性能测试的效果被过度放大了。以功能测试为例，最初软件是无须测试的，由于软件功能单一，而软件质量是依赖于有阅历的开发人员本人进展维护，随着开发规模的逐渐扩展，软件越来越复杂，随之质量逐渐下降，这时功能测试的低本钱效果就出现了。各大公司开场大规模地成立测试部门，随着功能测试部门的规模逐渐扩展，其效率开场不断下降，依赖于功能测试提高质量的性价比逐渐降低，而如今大家都认识到功能测试并不是万能的，其主要作用是保证软

12、件到达一定的质量，经过自动化可以降低功能测试的本钱。性能测试也处在这样一个过程中，由于客户日趋成熟，逐渐认识到性能是继功能后另一个重要的质量目的，而我们经常错误地以为性能测试就是满足用户性能需求的灵丹妙药，掌握了性能测试仿佛就走在了软件测试技术的最高端，却忽略了去思索性能测试究竟能做些什么。性能问题并不像功能问题那么棘手，由于几乎常见的性能问题都可以经过硬件处理，也就是花点儿钱买个更加强力的硬件配置来提高软件的效率，其次经过性能测试后发现了性能瓶颈(普通性能瓶颈都是较为底层的问题)，修复的本钱和风险也是需求思索的问题。好比功能测试在最后的BETA测试中发现了一个异常严重的功能问题，而该问题是由

13、于引擎所导致的，改还是不改呢?功能是必需求进展修正的，假设不修正用户无法正常运用，但是从性能角度来说，系统处置速度慢一点往往还是可以接受的。往往出现花了很多钱进展性能测试，并且发现了性能问题，但是修复该性能缺陷的本钱或风险太高，最终不得不放弃。性能测试无非就是以相对较低的本钱模拟一个真实环境来了解系统上线后的性能情况，至于定位、分析及调优，这需求一个团队的支持才干完成，所以软件的性能问题不是简简单单靠最后进展几次性能测试就能定位处理的。1.2 性能测试根底1.2.1 性能性能的定义在新华字典中可以查询到这样的解释：性能指器物所具有的性质与成效。这个定义中包括了以下两层含义：性质性质是指该器物具

14、有什么特性，可以做什么。成效是指该器物可以干得怎样样。在我们身边的性能有哪些呢?F1赛事从竞技竞赛的角度来说，在竞赛中获胜的一方性能较好，那么是不是性能只包括速度呢?不是F1竞赛并不是直道跑1000米，而是有很多转弯，而且赛程也较长。车速并不是获得冠军的独一目的，而车胎的类型、进出站的次数、驾车选手的发扬等条件组合在一同才是一个冠军诞生的根底。个人电脑个人电脑的性能指什么呢?用起来比较快?看起来比较美丽?我们通常说电脑的性能是指运转常用软件的反响迅速，但是仅仅拥有一颗高级的芯，电脑一定可以性能出众吗?不一定，这还取决于存储器、显卡等相关设备。针对CPU来说，主频也并不是阐明CPU性能的独一目的

15、，并不是说CPU的频率越高，其计算速度越快。例如：如今有两块CPU，一块是奔腾V3.0c主频3GHz，另外一块是酷睿2 T7200主频2GHz，显然T7200的性能远远优于奔腾V。软件单位时间内能处置的业务、处置一个运算所需求破费的时间、翻开该软件需求的时间，都能作为衡量软件性能的目的。例如在一样的电脑配置下分别安装Windows XP和Windows Vista操作系统。在这两个操作系统中复制大量文件至挪动硬盘时，就会发如今Vista下进展一样的操作会比XP慢很多，这个时候就会说在该硬件配置下Vista的磁盘读写性能相对XP较差。失败案例为什么忽然开场如此注重性能测试呢?那是由于阅历了太多惨

16、痛的阅历，让我们不得不注重这个以前被忽视的问题。接着来回想一下发生在2007年的一件由于性能测试缺乏而导致的惨痛案例奥运会订票系统瘫痪。2021年8月，对于全国人民来说，没有什么比奥运会更大的事情了。买到一张称心如意的门票，也成了很多人的一个梦想。网上购票、先到先得、人人参与的战略，让大家觉得进入鸟巢观看开幕式，见证这历史性的一刻成为能够。然而当大家在奥运官方售票网上抢购门票时，这个梦想却被网上购票系统的瘫痪击成碎片。我们来思索一个问题，作为一个奥运订票系统应该会有多少人去买票呢?看一下当时的新闻报道：境内公众启动第二阶段奥运会门票预售。然而，为了让更多的公众实现奥运梦想的“先到先得，售完为止

17、的销售政策适得其反，公众纷纷抢在第一时间订票，致使票务官网压力激增，接受了超越本身设计容量8倍的流量，导致系统瘫痪。超出8倍系统容量?那么接着来看看真正的系统容量是多少呢?昨天上午9点，预售一开场，公众提交恳求空前积极。北京奥运会官方票务网站的阅读量在第一个小时内到达800万次，每秒钟从网上提交的门票恳求超越20万张；票务呼叫中心热线的呼入量超越了380万人次。由于瞬间访问数量过大，技术系统应对不畅，呵斥很多申购者无法及时提交恳求。一个小时访问量到达800万次，经过计算可以得到平均每分钟的访问量约是12万次，而每秒约是2000次。对比本身设计的每小时100万次，每秒的访问量预估为250次左右，

18、他是不是发现系统估计的访问量少得可怜?作为一个门户网站，Sina、Sohu每秒的访问量是多少?需求是不是出了问题?作为百年一遇的奥运会盛典，每个炎黄子孙都会希望亲身在鸟巢感受奥运开幕式的盛况，而一张奥运会门票成了炙手可热的香饽饽，由于采取的是先到先得的战略，为了保证本人可以成为第一个进入系统购票的用户，我们需求确保本人以最快的速度进展订单的操作(提早预备用户注册、表单填写、业务熟习、网络调整、个人反响速度调整、等待好运降临)。当到达北京时间9点整，马上单击订票按钮。有少数人由于最先进入系统，所以他们顺利地订票胜利，而更多用户由于网络的延时或者某些别的缘由，被堵在了系统的外面。在这种情况下就会产

19、生大量用户并发订票的操作。北京奥运会官方票务网站的阅读量在第一个小时到达800万次，每秒钟从网上提交的订票恳求超越20万张。从这句话可以看出，阅读量和门票恳求的数量完全不是一个数量级，对应每秒不过2000多次的阅读量，系统却接受了20万张每秒的恳求量。这是由于绝大多数购票者都非常有阅历，知道不能到9点钟再来填写订票表单，而是应该不断地单击提交按钮将事先输入的订票信息提交给效力器。接着来分析一下假设想要订到奥运会的门票需求做哪些任务：用户注册当然要先注册订票网站会员，并顺便把银行卡也预备好，确保支付顺利。2表单的填写在订票开场前，先到奥运会订票系统上去，将要购买的开闭幕式、足球决赛等关键场次的表

20、单都预备好。3熟习业务整理并熟习整个购票的流程。4网络调整对于整个开幕式来说，全国能够有几千万的用户在尝试购票，而开幕式的门票一共也就3万多张，对于如此多的需求(接近800万的访问量)只是杯水车薪，所以假设想要在这种供需严重不平衡的情况下获得一张开幕式的门票，网速是一个非常重要的要素。每秒20万的订票恳求，也就是平均每毫秒200张。假设一个上海的网友和一个北京的网友同时在9点整购票，那么上海的兄弟就订不到这张票了，由于上海电信到北京网通的平均延时都在200ms，按照刚刚的平均值来计算，曾经卖掉4万张票了。所以假设想要购买到门票，最好在北京机房进展订票，运用光纤衔接，确保订票信息到达效力器的延时

21、在1ms之内，那么胜利的概率就会大大提升。5个人反映时间其实提交订票信息也是有讲究的，不同的人对于反映来说都有快慢之分，普通人在接受了信息到反映为动作能够需求0406秒的时间，而经过训练可以提升到0102秒，算算这是200毫秒的差距啊，又是4万张票没了，所以练练手速是很重要的一点，懂一些技术的朋友能够会运用按键精灵、QTP这类自动化工具来实现，将时间更加精准地进展控制，甚至可以思索做一点抢跑的操作。好，如今万事俱备，时间一到9点，假设他是那个能在最短时间就将恳求发送到效力器的人，作为第一个冲入系统的用户，就能顺利地获得想要预订的门票。而假设他很不幸在9点钟打了一个喷嚏，再去提交门票预订恳求，那

22、么很负疚，1秒钟过去了，有20万人在他前面了。虽然整个系统在上线前进展过性能测试，但由于错误的需求导致当出现远远超出系统所能负载的访问量时，系统来不及呼应就瘫痪了。错误的需求是整个售票网站瘫痪的最大缘由。那么是不是需求做错了，系统瘫痪就是理所当然的呢?我们再来看看当时的新闻解释：从昨天上午8点左右开场，就有不少网民登录票务官网排队等待申购门票。据了解，从上午9点正式开场售票到中午12点的3个小时内，票务网站的阅读次数到达2000万次。这与此次所提供的100万次/小时的流量相差甚远。不停地刷新网页，也是呵斥网络拥堵的缘由之一。杨力说，不少网民在无法正常登录后便不断刷新，“这就相当于一名申购者变成

23、了假设干名申购者，无形中增大网站流量。从技术角度上讲，网站的流量几乎呈几何倍增长，导致其他申购者无法登录。当大量的用户进展访问时，整个系统由于网络瓶颈或处置瓶颈导致了拥堵，用户无法访问。既然没有有效的网络流量处置才干，假设进展流量控制，问题就会被限制在一个可控的范围内。这好比一个银行有大量人来取款，总不能听之任之，而应该有专人进展协调管理，确保次序，并告知排在后面的顾客可以思索改天再来。导致奥运会售票网站瘫痪的缘由是综合的。假设当时进展了流量控制，那么可以保证登录到效力器上的用户可以比较正常地访问，而超出效力器处置才干的用户将无法进入系统，从而确保系统不会由于负载过大而停顿呼应。进一步来说假设

24、剩下的用户需求经过排队的方式来登录效力器进展购票，那么当时为难的情况就不会出现。按照系统默许的处置才干，置信在两个小时内一定可以把一切的票都销售终了。当然，也需求以平常心来对待这个事情，作为恣意一家公司来说，开发和维护一个奥运会门票系统都是有一定困难的，但是问题的出现通知我们，性能测试不是简单做做就可以的，想要真正地处理性能问题需求留意以下几个问题：1确定需求整个系统究竟有多少人会访问?并发量会是多少?访问集中在哪些业务上?根据这些需求进展性能测试，即可保证系统在指定的目的下可以正常任务。如何获得奥运会订票的真实需求呢?其实并不是很难。首先，在奥运会第一次抽签售票的过程中就能了解有多少人有意向

25、购票，由于中签率非常低，那么没有中签的人一定会参与在线购票，所以可以得到一个比较不错的订票访问量预估。其次，可以参考一下往届奥运会售票的阅历和数据。最后，可以做一次模拟售票的测试，给予一定的奖励号召大家都来尝试一下(例如：头200名注册的用户可以免费获赠一张门票，或者订票尾号为多少的用户获赠门票)，确保在正常上线的情况下不出问题。奥运会开幕式前就在鸟巢进展了带妆彩排，经过这次性能测试了解了开幕式的真实情况，从而制定了引荐观众在开幕式前及早进入场地且开幕式终了后先等待运发动离场后观众再分批离场的战略，确保不会出现拥堵的情况，这就是经过性能测试发现问题并进展修正的案例。2确保系统的强壮性系统应该可

26、以在极端负载的情况下正常运转。这就好我们，不能由于生活压力大就不任务了，可以任务效率低，但是不能不任务。3制定不测的处置方式在运转过程中有全面的监控，并且针对各种不测制定详细的应急方案，才干确保系统有才干处置各种不测情况。对于能够出现的访问顶峰，置信很多网络维护的朋友做过这样的事情，将公司多余的效力器或者不常用的效力器腾出来，参与中心效力器的群集中，并且设置流量阈值，确保整个系统可以正常任务。当出现网络流量过大的情况时，可以经过队列等技术手段进展处理。还记得我在Etang做SQA的时候，每次进展CET查分的时候，公司都会将一切的效力器停下来，全部支持CET查分的业务。所以说，并不是奥运会在线购

27、票的用户恳求远远超出了我们的技术才干范围才导致网站瘫痪。一些门户网站在直播神七出仓时，其页面的并发恳求会远远高于奥运订票网站的并发恳求，但是并没有出现无法访问或者呼应时间较长的情况。性能测试上面谈了什么是性能，忽视了性能会带来怎样的结果，那么什么是性能测试呢?性能测试的概念性能测试是系统测试的一种。作为一个优秀的系统测试工程师，需求经过“系统的视角来分析被测试系统，分析包含以下两点：1功能测试：某个功能点2性能测试：整个系统，包括软件和硬件在软件质量模型中，性能测试是属于效率这一类的。我们先来了解一下这句话涉及的两个概念。质量模型：一组特性及特性之间的关系，它提供规定质量需求和评价质量的根底。

28、软件效率(efficiency)：在规定条件下，相对于所用资源的数量，软件产品可提供适当性能的才干。其中资源能够包括其他软件产品、系统的软件和硬件配置，以及物质资料(如打印纸、磁盘等)。衡量一个软件的性能，需求从软件效率的以下3点思索：时间特性在规定条件下，软件产品执行其功能时，提供适当的呼应和处置时间以及吞吐率的才干。资源利用性在规定条件下，软件产品执行其功能时，运用适宜数量和类别的资源的才干。效率依从性软件产品遵照与效率相关的规范或商定的才干。也就是说我们需求确保软件在一定的资源配置条件下到达一定的性能，并且遵守相关的规范或协议。例如我们从来不会奢望一台80386的电脑可以在1分钟内启动完

29、Windows Vista操作系统，由于我们知道其硬件不符合产品的规范。但是假设一台高级的主流配置电脑在1分钟内无法完成Windows Vista操作系统的启动，他就会开场疑心是不是本人的硬件存在某些问题，假设不是硬件问题，那么就会觉得这个操作系统很慢，性能很差。所以一个性能测试工程师的主要任务目的就是确保系统可以在一定的硬件、软件环境下到达一定的性能目的。而性能测试(Performance Testing)的定义为：在一定的负载情况下，系统的呼应时间等特性能否满足特定的性能需求。从某些角度来说，性能其实是功能的一种。什么是负载?本书谈到的性能问题都不是单机性能问题，而是基于网络架构(如C/S

30、架构或者B/S架构)的性能问题。当众多终端用户对系统进展访问时，用户越多，那么效力器需求处置的客户恳求也就越多，从而构成了负载，而在这里负载的概念包含以下3点：1系统实践用户能够会有很多人运用同一个系统，但并不是一切的用户都会同时运用该系统，所以系统的实践用户是一个容量的问题，而不是负载的问题。2系统在线用户当系统用户对系统进展操作时，我们以为该用户为在线用户，这些用户对系统构成了负载，在线用户和实践用户的比例是根据系统特性决议的。例如：对于电子邮件系统，每天上班后几乎一切的实践用户都会进展收取邮件的操作，这个时候在线用户几乎等于实践用户。而对于某网络游戏来说，任务时间的在线用户甚至缺乏一切用

31、户的20。3并发操作用户在线后会对系统产生负载，但是用户和用户之间的操作却不是并发的，这是由于首先用户的操作需求延时等待，其次每个用户的操作并不是完全一样。并发操作会对系统产生很大的负载，当多个用户同时对某个功能进展操作时，效力器必需对这些恳求进展队列管理，依次处置。性能测试的分类性能测试的方法很多，名词也很多，从运用方便的角度来说，这里将性能测试分为6大种。负载测试(Load Testing)负载测试是指在一定的软件、硬件及网络环境下，运转一种或多种业务，在不同虚拟用户数量的情况下，测试效力器的性能目的能否在用户的要求范围内，以此确定系统所能承载的最大用户数、最大有成效户数以及不同用户数下的

32、系统呼应时间及效力器的资源利用率。负载测试强调的是在一定的环境下系统可以到达的峰值目的，大多数的性能测试都是负载测试。例如在各大网站上看到的各种显卡测试，都是经过运转3D Mark或者某种游戏得到的最终数据，经过这个数据来阐明显卡的峰值处置才干，这就是负载测试的一种方式。经过运转EVEREST的性能测试功能对当前硬件平台下CPU Queen进展负载测试，负载结果如图1.1所示，最终得分为8392分。压力测试(Stress Testing)压力测试是指在一定的软件、硬件及网络环境下，模拟大量的虚拟用户向效力器产生负载，使效力器的资源处于极限形状下并长时间延续运转，以测试效力器在高负载情况下能否可

33、以稳定任务。与负载测试获得峰值性能数据不同，压力测试强调在极端情况下系统的稳定性，这个时候处置才干曾经不重要了。例如在CPU超频后经常需求对系统的稳定性进展测试，那么可以经过Prime95工具来进展稳定性测试，如图1.2所示，该软件可以让系统的一切资源长时间处于耗费殆尽的形状。经过这样一段时间的“烤机后，假设没有出现死机等情况，可以以为系统经过了压力测试，即可以在各种情况下稳定地运转。图1.1 EVEREST CPU Queen测试结果 图1.2 压力测试工具Prime95容量测试(Volume Testing)容量测试是指在一定的软件、硬件及网络环境下，在数据库中构造不同数量级别的数据记录，

34、运转一种或多种业务在一定虚拟用户数量的情况下，获取不同数量级别的效力器性能目的，以确定数据库的最正确容量和最大容量。容量测试不仅可以对数据库进展，还可以对硬件处置才干、各种效力器的衔接才干等进展，以此来测试系统在不同容量级别下能否能到达指定的性能。容量测试和负载测试的区别在于，容量测试主要关怀how much，而负载测试那么同时强调how much和how fast。例如测试一个Word2003文档中最多可以存放多少个汉字。容量测试中也包含了可伸缩性测试的概念，可伸缩性可以从硬件和软件两个方面来了解：1硬件的可伸缩性能否可以经过硬件设备的添加来支持更多的用户，比如经过添加CPU个数或者存储器空

35、间大小等。2软件的可伸缩性能否可以经过运转更多的实例或者采用分布式处置来支持更多的用户。再详细一点就是一个可伸缩系统必需具有随负荷添加呼应时间也线性添加的特点。这样就可以经过线性添加硬件设备、实例个数或者分布式处置点来处置更多的数据量，也就能更好地在不添加呼应时间的前提下支持更多的用户。可伸缩性测试详细的测试过程为：进展负载测试，记录不同负载下的平均呼应时间，然后查看平均呼应时间能否线性添加。如线性添加，那么阐明系统具有可伸缩性；否那么阐明系统可伸缩性较差或者没有可伸缩性配置测试(Configuration Testing)配置测试是指在不同的软件、硬件以及网络环境配置下，运转一种或多种业务，

36、在一定的虚拟用户数量情况下，获得不同配置的性能目的，用f选择最正确的设备及参数配置。经过产生不同的配置，来得到系统性能的变化情况。在购买电脑前，我们通常会参考各种硬件评测，经过这些评测可以得知如何花最少的钱获得最高的性能报答，而这些测试都是经过在一样的平台下切换CPU或者显卡等硬件来获得对应的性能目的。例如可以运用EVEREST Ultimate、Iometer、Sisoft Sandra这类工具来获得当前系统整体或者某个硬件的性能数据。经过配置测试可以将性能缺陷放大，方便定位性能瓶颈。经过EVEREST测试内存读写速度，得出当前系统的内存写入速度为3029MBs，如图1.3所示。图1.3 E

37、VEREST内存写入测试结果基准测试(Benchmark Testing)基准测试是指在一定的软件、硬件及网络环境下，模拟一定数量的虚拟用户运转一种或多种业务，将测试结果作为基线数据，在系统调优或系统评测的过程中，经过运转一样的业务场景比较测试结果，确定调优的结果能否到达预期效果或者为系统的选择提供决策数据。基准测试普通基于配置测试，经过配置测试得到数据，并将这个数据作为基准来比较每次调优后的性能能否有所改善。例如前面经过EVEREST Ultimate工具获得了当前的内存读写速度数据，然后对系统进展调优(修正内存时序)，再做一次一样的测试，假设内存读写速度上升了，就阐明前面的调优是正确有效的

38、，反之那么阐明调优无效。并发测试(Concurrency Testing)并发测试是指经过模拟多个用户并发访问同一个运用、存储过程或数据记录以及其他并发操作，测试能否存在死锁、数据错误等缺点。为了防止数据库或函数方法在并发下的错误，需求专门针对每个模块进展并发测试。例如软件系统中有以下类似的存储过程：Create proc newuserunamevarchar(100)AsDeclare ucount intSelect ucount=count(*) from usersIf ucount5000Insert into USers(uname) values(uname)e1Se-提示VI

39、P用户活动曾经终了，会员已满go当大量用户并发运转该存储过程时就会出现注册胜利的会员数目大于5000的情况，由于有多个会员可以同时得到系统当前的用户数，而产生多个用户同时插入会员信息的情况，导致功能的最终错误。对于这种情况需求在查询用户数的时候添加查询锁来防止查询功能的并发操作。性能测试进展的时间好比几年前功能测试刚刚起步，其实就是一次出厂验货，却美其名日QA。如今我们知道了功能测试包括单元测试、集成测试、系统测试，知道了需求尽能够早地介入测试，甚至应该对需求进展测试，从而有效地、全方位地保证软件质量。是一篇小学时的课文，相对于看病来说，软件测试也是一种类似的任务，即应该及早进展诊断及预防。如

40、今的性能测试往往都是在工程后期才开场进展的，就算经过性能测试发现系统的性能曾经完全无法到达预期的需求，在多数情况下曾经于事无补了。一个有效的缺陷就是可以被修复的缺陷!一个软件的缺陷，特别是性能上的缺陷不是简单地改改代码就行。当一栋高楼曾经建到第40层，才发现地基打得不够深，没方法继续往下建筑了，而主梁的强度也不够，这时除了推倒重建也没什么其他有效的方法了。软件也是如此，当后期才发现存在严重的性能问题时，再想修正它的本钱和难度相对功能问题来说要大很多。接着来看看理想情况下性能测试应该在哪些阶段介入，如图1.4所示。图1.4 性能测试的进展时间编码阶段(压力/并发)在编码阶段，当每个函数、方法、存

41、储过程被开发出来并经过单元测试后，都应该进展压力和并发测试，确认接口和被测对象能否强壮地处置极端情况，并且能否正确处置并发恳求。在大多数情况下，这个阶段的性能测试都是开发人员自行担任。而作为一个架构设计师，在设计软件时即应该思索整个系统的性能，并进展建模测试，确保设计的正确。随后程序员对架构进展实现时就需求对本人编写的代码进展并发测试和压力测试。编码一测试之间(容量测试)在系统编码完成时，应该及时进展容量测试，确认系统能否满足在指定容量下的性能需求。例如导入5年的历史数据量，检查在这种容量下系统的性能能否可以接受，进一步再构造未来5年的数据量，检查系统能否正常任务。测试阶段(负载/配置/基准)

42、在进入测试阶段之后，在确保功能正确实现后需求进展负载测试，得到系统在当前硬件及软件环境下的性能目的(呼应时间、吞吐量、资源利用率)，进一步构成性能数据基准，然后经过配置测试进展性能瓶颈的定位和优化。在负载测试后可以得到系统的性能，假设该结果满足用户需求，那么可以思索终了性能测试，也可以思索进一步进展配置和基准测试，定位系统中的性能瓶颈，并进展进一步的优化。1.2.2 性能目的前面了解了什么是性能，忽视性能会带来什么结果以及什么是性能测试，那么性能测试究竟要测什么呢?在讨论软件的性能目的之前，请思索一下汽车和家用电脑的性能目的是经过什么数据来阐明的。对于一个运用系统来说，我们所需求监控的性能目的

43、主要有以下3点：呼应时间呼应时间反映完成某个业务所需求的时间。例如从单击登录按钮到登录完成前往登录胜利页面需求耗费1秒钟，那么就说这个操作的呼应时间是1秒。在性能测试中是经过事务函数来完成对呼应时间的统计，事务是指做某件事情的操作，事务函数会记录开场做这件事情和该事情做完之间的时间差，运用Transaction Response Time这个词来阐明，也称为事务呼应时间。吞吐量吞吐量反映单位时间内可以处置的事务数目。例如对于系统来说一个用户登录需求1秒钟，假设系统同时支持10个用户登录，且呼应时间是1秒钟，那么系统的吞吐量就是10个秒。在性能测试工具中，吞吐量也被称为TPS(Transacti

44、on Per Second，每秒事务数)也就是说在单位时间内能完成的事务数目。TPS的计算普通是经过的事务数除以时间。效力器资源占用效力器资源占用反映在负载下系统的资源利用率。资源的占用越低，阐明系统越优秀。资源并不仅仅指运转系统的硬件，而是支持整个系统运转程序的一切软硬件平台。在性能测试中，我们需求监控系统在负载下的硬件或者软件上各种资源的占用情况，例如CPU的占用率、内存运用率、查询cache命中率等。对于一个终端用户来说，最关怀的目的只需呼应时间，假设呼应时间长了，那么用户就会觉得系统慢。用户并不关怀有多少人运用这个系统以及系统的资源是不是足够，所以从某个角度来说，性能测试必需保证在恣意

45、情况下终端用户运用的操作呼应时间不大于5秒。有调查统计，对于一个用户来说，假设访问某系统的呼应时间小于2秒，那么用户会觉得系统很快，比较称心；假设访问某系统的呼应时间在25秒，那么用户可以接受，但是对速度有些不满；假设某系统的呼应时间超越10秒，用户将无法接受。所以对于一个系统来说，需求尽能够保证每一个操作的呼应时间在5秒以内，当然某些特殊的操作能够会大大超出这个呼应时间，可以经过Loading Bar的方式来提早通知用户。1.2.3 性能分析及调优性能测试的目的是为了发现性能瓶颈并处理。性能分析是为了确定导致性能瓶颈的缘由，而调优就是用来处理性能瓶颈。经过某些手段来让系统的性能得到提升是性能

46、调优的主要目的。性能分析主要有以下两种方法：目的达成法将测试结果与用户需求进展比较，假设到达用户需求那么测试经过。1系统满足10万注册用户(其中活泼用户数为1万)访问；2系统处置才干：20个注册秒、45个并发阅读秒、30个登录操作秒；3效力器资源利用率在满负荷的情况下，忙时峰值CPU负载不超越75，内存占用不超越80。例如：需求对一个参与100米跑的选手在竞赛前进展性能测试，确保其能获得冠军，那么首先需求明确第一名所需求到达的性能目的(100米短跑总时间)，对其进展性能测试，当发现测试结果可以到达冠军所具备的条件后，性能测试即可终了。最优化分析法经过分析并消除系统性能瓶颈，使系统的处置才干最大

47、化，系统资源实现充分利用。例如：需求对一个参与100米跑的选手进展技术指点，并不在乎他能否可以拿到冠军，而是重点强调能否提升本人的竞赛成果，那么就需求进展系统的训练和指点，如规范起跑动作、强化肌肉及协调性等，最终实现运动成果的提高。对应的性能调优方法也分为两大方向，如图15所示。图15性能调优方向1运用程序诊断运用程序的诊断是性能测试的最初目的。经过模拟多用户操作构成负载，检验运用程序能否可以满足用户性能需求。假设不能满足，那么定位运用瓶颈，并寻觅处理该瓶颈的方案，确保系统在修正后可以满足用户需求。对于一个工程来说，普通都以运用诊断为主。2系统调优性能测试的目的不是为了满足用户，而是超越本人，

48、这个时候需求做的是让系统可以比以前更加优秀地运转，经过生成负载，对测试结果进展分析，并且预备大量的软硬件环境进展迭代测试，找出影响性能的要素，最终提升系统的性能。普通产品都会采用系统调优的方式来逐渐完善系统性能。常见的性能瓶颈有如下一些情况：1硬件上的性能瓶颈普通指的是CPU、RAM方面的问题，分为效力器硬件瓶颈、网络瓶颈(对局域网可以不思索)、效力器操作系统瓶颈(参数配置)、中间件瓶颈(参数配置、数据库、Web效力器等)、运用瓶颈(SQL语句、数据库设计、业务逻辑、算法等)。例如：确定了在数据库效力器上需求6个CPU、12GB内存。但是在测试时，发现CPU的继续利用率超越95，这时可以以为在

49、硬件上出现了性能瓶颈。2运用软件上的性能瓶颈普通指的是运用效力器、Web效力器等运用软件，还包括数据库系统。例如：在WebLogic平台上配置了JDBC衔接池的参数，最大衔接数为50，最小衔接数为5，添加量为10。在测试时发现，当负载添加时，现有的衔接数缺乏，系统会动态生成10个新的衔接，导致买卖处置的呼应时间大大添加。这时可以以为在运用软件上出现了性能瓶颈。3运用程序上的性能瓶颈普通指的是开发人员新开发出来的运用程序。例如：某程序员开发了一个缴费处置程序。在测试时发现，这个缴费处置程序在处置用户的并发缴费恳求时，只能串行处置，无法并行处置，导致缴费买卖的处置呼应时间非常长，这时可以以为在运用

50、程序上出现了性能瓶颈。4操作系统上的性能瓶颈普通指的是Windows、UNIX、Linux等操作系统。例如：在Windows操作系统中，对某软件进展性能测试，出现物理内存缺乏时，假设虚拟内存设置也不合理，虚拟内存的交换效率就会大大降低，从而导致行为的呼应时间大大添加。这时可以以为在操作系统上出现了性能瓶颈。5网络设备上的性能瓶颈普通指的是防火墙、动态负载平衡器、交换机等设备。例如：在动态负载平衡器上设置了动态分发负载的机制，当发现某个运用效力器上的硬件资源曾经到达极限时，动态负载平衡器将后续的买卖恳求发送到其他负载较轻的运用效力器上。在测试时发现，动态负载平衡机制没有起到相应的作用，这时可以以

51、为在网络设备上出现了性能瓶颈。性能瓶颈出现的缘由及其定位是非常复杂的，这里只是简单引见一下常见的几种瓶颈类型和特征，而性能测试所需求做的就是根据各种情况要素综合思索，然后协助开发人员一同定位性能瓶颈。普通性能问题调优的步骤Step1 确定问题运用程序代码：在通常情况下，很多程序的性能问题都是写出来的，因此对于发现瓶颈的模块，应该首先检查一下代码。数据库配置：数据库配置经常引起整个系统运转缓慢，一些诸如Oracle的大型数据库都是需求DBA进展正确的参数调整才干投产的。操作系统配置：操作系统配置不合理也能够引起系统瓶颈。硬件设置：硬盘速度、内存大小等都是容易引起瓶颈的缘由，因此这些都是分析的重点

52、。网络：网络负载过重导致网络冲突和网络延迟。Step2 确定缘由当确定了问题之后，我们要明确这个问题影响的是呼应时间吞吐量，还是其他问题?是多数用户还是少数用户遇到了问题？假设是少数用户，这几个用户与其他用户的操作有什么不同?系统资源监控的结果能否正常？CPU的运用能否到达极限？I/O情况如何?问题能否集中在某一类模块中？是客户端还是效力器出现问题？系统硬件配置能否够用？实践负载能否超越了系统的负载才干？能否未对系统进展优化？经过这些分析以及一些与系统相关的问题，可以对系统瓶颈有更深化的了解，进而分析出真正的缘由。Step3 确定调整目的和处理方案提高系统吞吐量；缩短呼应时间；更好地支持并发。

53、Step 4 测试处理方案对经过处理方案调优后的系统进展基准测试。Step 5 分析调优结果系统调优能否到达或者超出了预定目的？系统是整体性能得到了改善，还是以牺牲某部分性能来处理其他问题。调优能否可以终了了？最后，假设到达了预期目的，调优任务就根本可以终了了。性能问题分析原那么原那么1：把现实与推测分开，总是用实践的证据来证明他的推测。原那么2：在没有足够证据之前，不对程序进展优化。原那么3：优先验证简单的假设。原那么4：日志文件中没有错误并不代表真的没有错误。原那么5：从系统到运用、从外到内进展层层剥离，减少范围。确认是系统级问题还是运用级问题；确认能否为外部系统问题(如密码鉴权问题、EJ

54、B问题等)；确认是运用程序问题还是数据库问题。原那么6：范围减少后，再分割成多个小单元，对每个小单元反复进展压力测试，来确定是哪个单元引起性能问题。诊断性能问题，最常见的也是较难的判别的问题是：是运用程序还是数据库出了问题？或者两者都有？这是由于运用程序、数据库、WebLogic Server(Tomcat)都不是孤立运转的。因此脱离运用架构单独运转测试(如SQL计时、JDBC计时、线程计时等)几乎没有作用。关键是对相互作用的了解。要熟知系统的性能度量方法，了解SQL的构造，了解用户发出的恳求在跨越整个系统时的端对端点对点计时、SQL的计时等；了解用户发出恳求后所关联的线程、JDBC衔接、数据

55、库的活动及其之间的交互关系。运用数据库典型的三大类性能问题分析如下。1过量的数据库调用问题：常见的性能瓶颈过量的数据库调用，引发这些问题不一定是SQL查询的Execute()或Update()，而是运用程序与数据库的交互有关，例如Result Set操作，常见的问题是指定了过于精细的查询条件，然后运用Result SetNext()详细搜索前往的数据。处理方法：从数据库中大量获得所要求的数据，防止运用程序反复回调数据库。2数据库衔接池问题问题1：衔接池资源走漏虽然可以经过WebLogic自带工具、Jprofiler工具或自编工具检测到数据库衔接池资源走漏，但是很难在运用程序代码本身准确定位走漏

56、的源头!处理方法：仔细分析程序代码，能否没有close()衔接？能否脱漏了finally块？或者虽然有close()但并没有胜利？问题2：衔接池大小衔接池过小会导致衔接池满后，新的客户无法衔接上系统，在日志中出现错误信息。普通的处理方法是增大衔接池。但另一方面，衔接池过大会呵斥资源无效损耗，能够会出现新的性能问题，那么衔接池调到多大比较适宜呢？处理方法：阅历法那么1：数据库衔接池数=线程池数每个线程需求衔接数据库的平均数x1.1(1.1的含义是添加10的峰值期负载)，通常每个线程需求衔接数据库的平均数是1，即当线程池数为120时，数据库衔接池数就是132。阅历法那么2：设置最初池大小=最大池大

57、小。3：SQL语句及其索引或锁定属性问题问题：SQL语句及其索引或锁定属性不合理能够引发DISK IO过忙(磁盘读写数据)或者CPU过忙(在内存中索引排序)，呵斥执行时间过长，阻塞线程的执行，最终引发系统挂起或者执行超时引发系统挂起，例如错误信息：Oracle.jdbc.driver.OracleStatement.doExecuteWithTimeout(OracleStatement.java:2857) at oracle.jdbc.driver.OraclePreparedStatement.executeUpdate死锁引发系统挂起，例如错误信息：Java.sql.SQLExcept

58、ion:ORA-00060:Deadlockdetectedwhilewaitingforresourceatoracle.jdbc.dbaccess.DBError.throwSqlException(DBError.java:170)处理方法：优化SQL语句及其索引或锁定属性。性能调优应该留意的要点要点1：在运用系统的设计开发过程中，应一直把性能放在思索的范围内。要点2：确定明晰明确的性能目的是关键。要点3：必需保证调优后的程序运转正确。要点4：系统的性能更大程度上取决于良好的设计，调优技巧只是一个辅助手段。要点5：调优过程是迭代渐进的过程，每次调优的结果都要反响到后续的代码开发中去要点6

59、：性能调优不能以牺牲代码的可读性和可维护性为代价。性能调优是一个很复杂的过程，就好比一个人每天在上班路上需求耗费1个半小时，如何调优让这个人上班路上开销的时间变小。性能调优需求有全面的知识和背景，需求对被调优对象有全面的了解和跟踪，才干逐渐抽丝剥茧找到某块短板，将这块短板加长后，再找到下一块短板，以此类推。很多公司在招聘性能测试工程师的时候都会提及性能调优这个职责，但是只靠一个性能测试专家是很难的，由于假设他想要对一个三层架构的网络运用进展调优，那么需求对网络架构、www效力、APP运用、DB数据库都相当知晓，才干完成所谓的调优任务，而这样的人曾经可以胜任架构设计师的职位了，假设让他去做性能测

60、试工程师能否有些大材小用了呢？不过作为一个性能测试工程师，在生长的初期需求对性能测试调优的各个对象都有所了解，经过相关部门的人员协助完成调优任务，随后就是逐渐加深，并且选择一个详细的方向进展深化并成为某一方面的性能测试及调优专家。1.2.4 单机软件性能与网络架构软件性能在性能测试初期，测试对象都是单机软件，测试目的是确认一个软件在一定的配置下可以以多快的速度完成一个义务，甚至同时完成几个义务。例如测试Windows下的计算器计算999999的999999次方需求耗费的时间。假设需求对单机软件进展性能测试，关注的目的普通为：1能否存在内存走漏？有没有恳求一些没必要的资源？资源的释放能否完全？2