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

目录第一章 性能测试基础21.1 性能测试工程师的标准及挑战21.1.1 性能测试工程考评指标21.1.2 性能测试工程师的挑战31.2 性能测试基础51.2.1 性能51.2.2 性能指标161.2.3 性能分析及调优171.2.4 单机软件性能与网络架构软件221.2.5 性能测试的流程231.2.6 性能测试的注意要点241.2.7 性能测试招聘要求25小结26第一章 性能测试基础软件测试逐步成为软件开发过程中一个必不可少的环节，随着功能测试的必要性被认可，自动化测试和性能测试也逐步崭露头角。我们经常会抱怨浏览网页慢、下载文件慢，其实这都是属于性能问题。用户在得益于功能方面的质量提升后，开始对性能有了新的认识和要求，而性能测试并不像功能测试那样可以“低门槛”进行。性能测试的本质是通过编写一个程序去测试另外一个程序，而正是有了这个相对的“高门槛”，性能测试便成了一个“高薪”、“高技术含量”的工作，新人在看到高手指点江山(性能测试)时，充满了羡慕的眼神，摩拳擦掌准备进入这个行业。在开始从事性能测试工作之前，我们先来看看这个职位的考核标准和面临的挑战。1.1 性能测试工程师的标准及挑战当你掌握了性能测试的基本技能，接着就需要找到一家合适的企业，通过劳动换取经济上的回报，那么通常公司如何去招聘一个性能测试工程师，并如何进行绩效考评呢?即性能测试工程师应该达到的工作目标到底是什么?1.1.1 性能测试工程考评指标在介绍性能测试之前，我们回想一下功能测试的考评和工作内容。如果你是一名功能测试经理，该如何考评你的员工呢?当软件测试刚刚进入中国时，我们对测试的理解是通过模拟用户执行，发现用户可能遇到的问题，而缺陷的数目成了考评的唯一指标。例如PM(Project Manager)规定，每个测试人员每天都要发现10个以上的缺陷，否则说明他在工作态度和工作能力上有一定的缺陷。综上，作为一名功能测试工程师，其考评要求可以归结为一条，那就是测试通过的软件不会被用户发现严重的缺陷。而现在，软件测试逐渐正名，我们对测试的理解从证明软件没有错误变为证明软件具备一定的质量，而功能测试工程师的考评标准也随之发生了变化。功能测试工程师的考评指标主要有以下几点：1 缺陷数目缺陷的数目虽然不能作为主要的考评指标，但是从某一个角度也说明了测试工程师发现问题的能力。在成熟的软件开发公司中，我们能够通过历史数据生成的缺陷质量模型准确预估缺陷数目。如果你发现的缺陷数量明显低于预估，则说明你的工作可能存在一定问题。2缺陷质量有量没有质是不行的，由于计件制的压迫，测试人员往往为了达到数目上的指标而凑缺陷，数目是够了，但是所提的缺陷都是鸡毛蒜皮的事情，缺陷的危害等级和优先级都比较低，那么对软件质量的提升效果会相对较差。在缺陷的质量中包含两个概念：·缺陷的严重等级和优先级·对缺陷的描述3工作态度测试工作是一个很容易“偷懒”的工作，是需要个人积极主动、追求完美的工作，对于测试工程师，只有具备善于交流、积极主动、“视公为私”的态度才能对被测对象负责。4工作效率在较短的时间内是否能够高质量完成上级布置任务的能力。5文档编写过去所谓的软件测试工程师只是软件测试执行工程师，现在被称为Tester。现在测试工程师还需要进行测试计划、测试方案及用例等文档的编写工作。6团队协作能力7其他相关技能性能测试在国内刚刚开始流行。一个公司招聘性能测试工程师的主要目的是通过对产品进行专业的性能测试，获得一份性能测试评估报告，从而向用户证明本产品能够满足预期的性能需求。随着性能测试职位的逐渐成熟，对这个职位的要求也越来越严格，性能测试的目的不仅仅是为了获得当前系统的性能评估，而是希望进一步通过性能测试发现系统性能瓶颈并修复性能问题。而性能问题的修复成本一般相对较高，如何使用最低的成本换取最高的性能，从而在性价比上找到黄金分割点，将是性能调优的重点。性能测试工程师的考评指标会包括以下内容：1是否能够独立开发脚本能否使用一种或多种性能测试工具完成用户行为的模拟脚本开发工作。2能否对需求进行性能分析并获得性能需求任何测试都是基于需求的。作为一名性能测试工程师，需要具备一定的性能需求分析能力，从而根据用户的需求进行性能测试，得到被测系统与用户需求之间的差距，从而生成性能报告并提供性能调优方案。3能否设计场景及监控负载系统完成对性能测试的实施和监控工作对性能测试进行实施，设计负载规则并监控负载下各个系统的状态。4能否通过性能测试发现比较具体的性能瓶颈具备一定的性能结果分析及瓶颈定位能力。5文档编写与环境搭建的能力独立编写性能测试文档和搭建测试环境的能力。6团队协作能力7其他相关技能1.1.2 性能测试工程师的挑战作为工作了几年的功能测试工程师来说，大家觉得在功能测试工作中的挑战是什么呢?1公司不重视测试2就我一个人做测试3找不到缺陷4开发工程师不能及时修改测试中发现的缺陷5不熟悉业务6不了解功能测试的方法及流程总结来说就是工作内容略感重复、缺乏技术含量，并且在有限的时间和资源下难以达到理想化的目标。在实际工作中，要确保软件没有缺陷是比较困难的，这是因为：1软件不可能不存在缺陷2测试无法发现所有缺陷3测试在大多数情况下都没有足够的资源和时间(在成本和质量上寻求平衡)所以无法完全保证整个软件在交付时不存在缺陷。虽然可以通过各种方法将严重级别或者优先级别较高的问题发现并修复，但由于个人能力或客观原因还是会遗留某些缺陷。那么作为一个性能测试工程师所面临的挑战又有哪些呢?1对性能测试的理论和技术不熟悉2公司不重视性能测试3就我一个人做性能测试4测试出来的结果不知道怎么分析5不熟悉业务6定位出的性能问题无法修正总结来说，就是如何在有限的时间和资源下，保证提交给用户的软件系统可以达到指定的性能需求指标。从某种角度来说，现在性能测试的功效被过度放大了。以功能测试为例，最初软件是无须测试的，因为软件功能单一，而软件质量是依赖于有经验的开发人员自己进行维护，随着开发规模的逐渐扩大，软件越来越复杂，随之质量逐渐下降，这时功能测试的低成本效果就出现了。各大公司开始大规模地成立测试部门，随着功能测试部门的规模逐渐扩大，其效率开始不断下降，依赖于功能测试提高质量的性价比逐渐降低，而现在大家都认识到功能测试并不是万能的，其主要作用是保证软件达到一定的质量，通过自动化可以降低功能测试的成本。性能测试也处在这样一个过程中，由于客户日趋成熟，逐渐意识到性能是继功能后另一个重要的质量指标，而我们常常错误地认为性能测试就是满足用户性能需求的灵丹妙药，掌握了性能测试仿佛就走在了软件测试技术的最高端，却忽略了去思考性能测试到底能做些什么。性能问题并不像功能问题那么棘手，因为几乎常见的性能问题都可以通过硬件解决，也就是花点儿钱买个更加强力的硬件配置来提高软件的效率，其次通过性能测试后发现了性能瓶颈(一般性能瓶颈都是较为底层的问题)，修复的成本和风险也是需要考虑的问题。好比功能测试在最后的BETA测试中发现了一个异常严重的功能问题，而该问题是由于引擎所导致的，改还是不改呢?功能是必须要进行修改的，如果不修改用户无法正常使用，但是从性能角度来说，系统处理速度慢一点往往还是能够接受的。往往出现花了很多钱进行性能测试，并且发现了性能问题，但是修复该性能缺陷的成本或风险太高，最终不得不放弃。性能测试无非就是以相对较低的成本模拟一个真实环境来了解系统上线后的性能情况，至于定位、分析及调优，这需要一个团队的支持才能完成，所以软件的性能问题不是简简单单靠最后进行几次性能测试就能定位解决的。1.2 性能测试基础1.2.1 性能性能的定义在新华字典中可以查询到这样的解释：性能指器物所具有的性质与效用。这个定义中包括了以下两层含义：1 性质性质是指该器物具有什么特性，能够做什么。2 效用是指该器物能够干得怎么样。在我们身边的性能有哪些呢?1 F1赛事从竞技比赛的角度来说，在比赛中获胜的一方性能较好，那么是不是性能只包括速度呢?不是F1比赛并不是直道跑1000米，而是有很多转弯，而且赛程也较长。车速并不是获得冠军的唯一指标，而车胎的类型、进出站的次数、驾车选手的发挥等条件组合在一起才是一个冠军诞生的基础。2 个人电脑个人电脑的性能指什么呢?用起来比较快?看起来比较漂亮?我们通常说电脑的性能是指运行常用软件的反应迅速，但是仅仅拥有一颗高级的芯，电脑一定能够性能出众吗?不一定，这还取决于存储器、显卡等相关设备。针对CPU来说，主频也并不是说明CPU性能的唯一指标，并不是说CPU的频率越高，其计算速度越快。例如：现在有两块CPU，一块是奔腾V3.0c主频3GHz，另外一块是酷睿2 T7200主频2GHz，显然T7200的性能远远优于奔腾V。3 软件单位时间内能处理的业务、处理一个运算所需要花费的时间、打开该软件需要的时间，都能作为衡量软件性能的指标。例如在相同的电脑配置下分别安装Windows XP和Windows Vista操作系统。在这两个操作系统中复制大量文件至移动硬盘时，就会发现在Vista下进行相同的操作会比XP慢很多，这个时候就会说在该硬件配置下Vista的磁盘读写性能相对XP较差。失败案例为什么突然开始如此重视性能测试呢?那是因为经历了太多惨痛的经历，让我们不得不重视这个以前被忽视的问题。接着来回顾一下发生在2007年的一件由于性能测试不足而导致的惨痛案例奥运会订票系统瘫痪。2008年8月，对于全国人民来说，没有什么比奥运会更大的事情了。买到一张称心如意的门票，也成了很多人的一个梦想。网上购票、先到先得、人人参与的策略，让大家觉得进入鸟巢观看开幕式，见证这历史性的一刻成为可能。然而当大家在奥运官方售票网上抢购门票时，这个梦想却被网上购票系统的瘫痪击成碎片。我们来思考一个问题，作为一个奥运订票系统应该会有多少人去买票呢?看一下当时的新闻报道：境内公众启动第二阶段奥运会门票预售。然而，为了让更多的公众实现奥运梦想的“先到先得，售完为止”的销售政策适得其反，公众纷纷抢在第一时间订票，致使票务官网压力激增，承受了超过自身设计容量8倍的流量，导致系统瘫痪。超出8倍系统容量?那么接着来看看真正的系统容量是多少呢?昨天上午9点，预售一开始，公众提交申请空前踊跃。北京奥运会官方票务网站的浏览量在第一个小时内达到800万次，每秒钟从网上提交的门票申请超过20万张；票务呼叫中心热线的呼入量超过了380万人次。由于瞬间访问数量过大，技术系统应对不畅，造成很多申购者无法及时提交申请。一个小时访问量达到800万次，通过计算可以得到平均每分钟的访问量约是12万次，而每秒约是2000次。对比自身设计的每小时100万次，每秒的访问量预估为250次左右，你是不是发现系统估计的访问量少得可怜?作为一个门户网站，Sina、Sohu每秒的访问量是多少?需求是不是出了问题?作为百年一遇的奥运会盛典，每个炎黄子孙都会希望亲身在鸟巢感受奥运开幕式的盛况，而一张奥运会门票成了炙手可热的香饽饽，由于采取的是先到先得的策略，为了保证自己能够成为第一个进入系统购票的用户，我们需要确保自己以最快的速度进行订单的操作(提前准备用户注册、表单填写、业务熟悉、网络调整、个人反应速度调整、期待好运降临)。当到达北京时间9点整，马上单击订票按钮。有少数人由于最先进入系统，所以他们顺利地订票成功，而更多用户由于网络的延时或者某些别的原因，被堵在了系统的外面。在这种情况下就会产生大量用户并发订票的操作。北京奥运会官方票务网站的浏览量在第一个小时达到800万次，每秒钟从网上提交的订票申请超过20万张。从这句话可以看出，浏览量和门票申请的数量完全不是一个数量级，对应每秒不过2000多次的浏览量，系统却承受了20万张每秒的申请量。这是因为绝大多数购票者都非常有经验，知道不能到9点钟再来填写订票表单，而是应该不断地单击提交按钮将事先输入的订票信息提交给服务器。接着来分析一下如果想要订到奥运会的门票需要做哪些工作：1 用户注册当然要先注册订票网站会员，并顺便把银行卡也准备好，确保支付顺利。2表单的填写在订票开始前，先到奥运会订票系统上去，将要购买的开闭幕式、足球决赛等关键场次的表单都准备好。3熟悉业务整理并熟悉整个购票的流程。4网络调整对于整个开幕式来说，全国可能有几千万的用户在尝试购票，而开幕式的门票一共也就3万多张，对于如此多的需求(接近800万的访问量)只是杯水车薪，所以如果想要在这种供需严重不平衡的情况下获得一张开幕式的门票，网速是一个非常重要的因素。每秒20万的订票申请，也就是平均每毫秒200张。如果一个上海的网友和一个北京的网友同时在9点整购票，那么上海的兄弟就订不到这张票了，因为上海电信到北京网通的平均延时都在200ms，按照刚才的平均值来计算，已经卖掉4万张票了。所以如果想要购买到门票，最好在北京机房进行订票，使用光纤连接，确保订票信息到达服务器的延时在1ms之内，那么成功的概率就会大大提升。5个人反映时间其实提交订票信息也是有讲究的，不同的人对于反映来说都有快慢之分，一般人在接受了信息到反映为动作可能需要0406秒的时间，而通过训练可以提升到0102秒，算算这是200毫秒的差距啊，又是4万张票没了，所以练练手速是很重要的一点，懂一些技术的朋友可能会使用按键精灵、QTP这类自动化工具来实现，将时间更加精准地进行控制，甚至可以考虑做一点抢跑的操作。好，现在万事俱备，时间一到9点，如果你是那个能在最短时间就将请求发送到服务器的人，作为第一个冲入系统的用户，就能顺利地获得想要预订的门票。而如果你很不幸在9点钟打了一个喷嚏，再去提交门票预订申请，那么很抱歉，1秒钟过去了，有20万人在你前面了。虽然整个系统在上线前进行过性能测试，但由于错误的需求导致当出现远远超出系统所能负载的访问量时，系统来不及响应就瘫痪了。错误的需求是整个售票网站瘫痪的最大原因。那么是不是需求做错了，系统瘫痪就是理所当然的呢?我们再来看看当时的新闻解释：从昨天上午8点左右开始，就有不少网民登录票务官网排队等待申购门票。据了解，从上午9点正式开始售票到中午12点的3个小时内，票务网站的浏览次数达到2000万次。这与此次所提供的100万次/小时的流量相差甚远。不停地刷新网页，也是造成网络拥堵的原因之一。”杨力说，不少网民在无法正常登录后便不断刷新，“这就相当于一名申购者变成了若干名申购者，无形中增大网站流量。从技术角度上讲，网站的流量几乎呈几何倍增长，导致其他申购者无法登录。”当大量的用户进行访问时，整个系统由于网络瓶颈或处理瓶颈导致了拥堵，用户无法访问。既然没有有效的网络流量处理能力，如果进行流量控制，问题就会被限制在一个可控的范围内。这好比一个银行有大量人来取款，总不能听之任之，而应该有专人进行协调管理，确保秩序，并告知排在后面的顾客可以考虑改天再来。导致奥运会售票网站瘫痪的原因是综合的。如果当时进行了流量控制，那么可以保证登录到服务器上的用户可以比较正常地访问，而超出服务器处理能力的用户将无法进入系统，从而确保系统不会由于负载过大而停止响应。进一步来说如果剩下的用户需要通过排队的方式来登录服务器进行购票，那么当时尴尬的情况就不会出现。按照系统默认的处理能力，相信在两个小时内肯定能够把所有的票都销售完毕。当然，也需要以平常心来看待这个事情，作为任意一家公司来说，开发和维护一个奥运会门票系统都是有一定困难的，但是问题的出现告诉我们，性能测试不是简单做做就可以的，想要真正地解决性能问题需要注意以下几个问题：1确定需求整个系统到底有多少人会访问?并发量会是多少?访问集中在哪些业务上?根据这些需求进行性能测试，即可保证系统在指定的指标下能够正常工作。如何获得奥运会订票的真实需求呢?其实并不是很难。首先，在奥运会第一次抽签售票的过程中就能了解有多少人有意向购票，由于中签率非常低，那么没有中签的人一定会参加在线购票，所以可以得到一个比较不错的订票访问量预估。其次，可以参考一下往届奥运会售票的经验和数据。最后，可以做一次模拟售票的测试，给予一定的奖励号召大家都来尝试一下(例如：头200名注册的用户可以免费获赠一张门票，或者订票尾号为多少的用户获赠门票)，确保在正常上线的情况下不出问题。奥运会开幕式前就在鸟巢进行了带妆彩排，通过这次性能测试了解了开幕式的真实情况，从而制定了推荐观众在开幕式前及早进入场地且开幕式结束后先等待运动员离场后观众再分批离场的策略，确保不会出现拥堵的情况，这就是通过性能测试发现问题并进行修改的案例。2确保系统的健壮性系统应该能够在极端负载的情况下正常运行。这就好我们，不能因为生活压力大就不工作了，可以工作效率低，但是不能不工作。3制定意外的处理方式在运行过程中有全面的监控，并且针对各种意外制定详细的应急方案，才能确保系统有能力处理各种意外情况。对于可能出现的访问高峰，相信很多网络维护的朋友做过这样的事情，将公司多余的服务器或者不常用的服务器腾出来，加入核心服务器的群集中，并且设置流量阈值，确保整个系统能够正常工作。当出现网络流量过大的情况时，可以通过队列等技术手段进行解决。还记得我在Etang做SQA的时候，每次进行CET查分的时候，公司都会将所有的服务器停下来，全部支持CET查分的业务。所以说，并不是奥运会在线购票的用户请求远远超出了我们的技术能力范围才导致网站瘫痪。一些门户网站在直播神七出仓时，其页面的并发请求会远远高于奥运订票网站的并发请求，但是并没有出现无法访问或者响应时间较长的情况。性能测试上面谈了什么是性能，忽视了性能会带来怎样的结果，那么什么是性能测试呢?性能测试的概念性能测试是系统测试的一种。作为一个优秀的系统测试工程师，需要通过“系统”的视角来分析被测试系统，分析包含以下两点：1功能测试：某个功能点2性能测试：整个系统，包括软件和硬件在软件质量模型中，性能测试是属于效率这一类的。我们先来了解一下这句话涉及的两个概念。质量模型：一组特性及特性之间的关系，它提供规定质量需求和评价质量的基础。软件效率(efficiency)：在规定条件下，相对于所用资源的数量，软件产品可提供适当性能的能力。其中资源可能包括其他软件产品、系统的软件和硬件配置，以及物质材料(如打印纸、磁盘等)。衡量一个软件的性能，需要从软件效率的以下3点考虑：·时间特性在规定条件下，软件产品执行其功能时，提供适当的响应和处理时间以及吞吐率的能力。·资源利用性在规定条件下，软件产品执行其功能时，使用合适数量和类别的资源的能力。·效率依从性软件产品遵循与效率相关的标准或约定的能力。也就是说我们需要确保软件在一定的资源配置条件下达到一定的性能，并且遵守相关的标准或协议。例如我们从来不会奢望一台80386的电脑能够在1分钟内启动完Windows Vista操作系统，因为我们知道其硬件不符合产品的标准。但是如果一台高级的主流配置电脑在1分钟内无法完成Windows Vista操作系统的启动，你就会开始怀疑是不是自己的硬件存在某些问题，如果不是硬件问题，那么就会觉得这个操作系统很慢，性能很差。所以一个性能测试工程师的主要工作目标就是确保系统能够在一定的硬件、软件环境下达到一定的性能指标。而性能测试(Performance Testing)的定义为：在一定的负载情况下，系统的响应时间等特性是否满足特定的性能需求。从某些角度来说，性能其实是功能的一种。什么是负载?本书谈到的性能问题都不是单机性能问题，而是基于网络架构(如C/S架构或者B/S架构)的性能问题。当众多终端用户对系统进行访问时，用户越多，那么服务器需要处理的客户请求也就越多，从而形成了负载，而在这里负载的概念包含以下3点：1系统实际用户可能会有很多人使用同一个系统，但并不是所有的用户都会同时使用该系统，所以系统的实际用户是一个容量的问题，而不是负载的问题。2系统在线用户当系统用户对系统进行操作时，我们认为该用户为在线用户，这些用户对系统形成了负载，在线用户和实际用户的比例是根据系统特性决定的。例如：对于电子邮件系统，每天上班后几乎所有的实际用户都会进行收取邮件的操作，这个时候在线用户几乎等于实际用户。而对于某网络游戏来说，工作时间的在线用户甚至不足所有用户的20。3并发操作用户在线后会对系统产生负载，但是用户和用户之间的操作却不是并发的，这是因为首先用户的操作需要延时等待，其次每个用户的操作并不是完全相同。并发操作会对系统产生很大的负载，当多个用户同时对某个功能进行操作时，服务器必须对这些请求进行队列管理，依次处理。性能测试的分类性能测试的方法很多，名词也很多，从使用方便的角度来说，这里将性能测试分为6大种。负载测试(Load Testing)负载测试是指在一定的软件、硬件及网络环境下，运行一种或多种业务，在不同虚拟用户数量的情况下，测试服务器的性能指标是否在用户的要求范围内，以此确定系统所能承载的最大用户数、最大有效用户数以及不同用户数下的系统响应时间及服务器的资源利用率。负载测试强调的是在一定的环境下系统能够达到的峰值指标，大多数的性能测试都是负载测试。例如在各大网站上看到的各种显卡测试，都是通过运行3D Mark或者某种游戏得到的最终数据，通过这个数据来说明显卡的峰值处理能力，这就是负载测试的一种方式。通过运行EVEREST的性能测试功能对当前硬件平台下CPU Queen进行负载测试，负载结果如图1.1所示，最终得分为8392分。压力测试(Stress Testing)压力测试是指在一定的软件、硬件及网络环境下，模拟大量的虚拟用户向服务器产生负载，使服务器的资源处于极限状态下并长时间连续运行，以测试服务器在高负载情况下是否能够稳定工作。与负载测试获得峰值性能数据不同，压力测试强调在极端情况下系统的稳定性，这个时候处理能力已经不重要了。例如在CPU超频后经常需要对系统的稳定性进行测试，那么可以通过Prime95工具来进行稳定性测试，如图1.2所示，该软件可以让系统的所有资源长时间处于消耗殆尽的状态。通过这样一段时间的“烤机”后，如果没有出现死机等情况，可以认为系统通过了压力测试，即可以在各种情况下稳定地运行。图1.1 EVEREST CPU Queen测试结果 图1.2 压力测试工具Prime95容量测试(Volume Testing)容量测试是指在一定的软件、硬件及网络环境下，在数据库中构造不同数量级别的数据记录，运行一种或多种业务在一定虚拟用户数量的情况下，获取不同数量级别的服务器性能指标，以确定数据库的最佳容量和最大容量。容量测试不仅可以对数据库进行，还可以对硬件处理能力、各种服务器的连接能力等进行，以此来测试系统在不同容量级别下是否能达到指定的性能。容量测试和负载测试的区别在于，容量测试主要关心how much，而负载测试则同时强调how much和how fast。例如测试一个Word2003文档中最多可以存放多少个汉字。容量测试中也包含了可伸缩性测试的概念，可伸缩性可以从硬件和软件两个方面来理解：1硬件的可伸缩性是否可以通过硬件设备的增加来支持更多的用户，比如通过增加CPU个数或者存储器空间大小等。2软件的可伸缩性是否可以通过运行更多的实例或者采用分布式处理来支持更多的用户。再具体一点就是一个可伸缩系统必须具有随负荷增加响应时间也线性增加的特点。这样就可以通过线性增加硬件设备、实例个数或者分布式处理点来处理更多的数据量，也就能更好地在不增加响应时间的前提下支持更多的用户。可伸缩性测试具体的测试过程为：进行负载测试，记录不同负载下的平均响应时间，然后查看平均响应时间是否线性增加。如线性增加，则说明系统具有可伸缩性；否则说明系统可伸缩性较差或者没有可伸缩性配置测试(Configuration Testing)配置测试是指在不同的软件、硬件以及网络环境配置下，运行一种或多种业务，在一定的虚拟用户数量情况下，获得不同配置的性能指标，用f选择最佳的设备及参数配置。通过产生不同的配置，来得到系统性能的变化状况。在购买电脑前，我们通常会参考各种硬件评测，通过这些评测可以得知如何花最少的钱获得最高的性能回报，而这些测试都是通过在相同的平台下切换CPU或者显卡等硬件来获得对应的性能指标。例如可以使用EVEREST Ultimate、Iometer、Sisoft Sandra这类工具来获得当前系统整体或者某个硬件的性能数据。通过配置测试可以将性能缺陷放大，方便定位性能瓶颈。通过EVEREST测试内存读写速度，得出当前系统的内存写入速度为3029MBs，如图1.3所示。图1.3 EVEREST内存写入测试结果基准测试(Benchmark Testing)基准测试是指在一定的软件、硬件及网络环境下，模拟一定数量的虚拟用户运行一种或多种业务，将测试结果作为基线数据，在系统调优或系统评测的过程中，通过运行相同的业务场景比较测试结果，确定调优的结果是否达到预期效果或者为系统的选择提供决策数据。基准测试一般基于配置测试，通过配置测试得到数据，并将这个数据作为基准来比较每次调优后的性能是否有所改善。例如前面通过EVEREST Ultimate工具获得了当前的内存读写速度数据，然后对系统进行调优(修改内存时序)，再做一次相同的测试，如果内存读写速度上升了，就说明前面的调优是正确有效的，反之则说明调优无效。并发测试(Concurrency Testing)并发测试是指通过模拟多个用户并发访问同一个应用、存储过程或数据记录以及其他并发操作，测试是否存在死锁、数据错误等故障。为了避免数据库或函数方法在并发下的错误，需要专门针对每个模块进行并发测试。例如软件系统中有以下类似的存储过程：Create proc newuserunamevarchar(100)AsDeclare ucount intSelect ucount=count(*) from usersIf ucount<5000Insert into USers(uname) values(uname)e1Se-提示VIP用户活动已经结束，会员已满go当大量用户并发运行该存储过程时就会出现注册成功的会员数目大于5000的情况，因为有多个会员能够同时得到系统当前的用户数，而产生多个用户同时插入会员信息的情况，导致功能的最终错误。对于这种情况需要在查询用户数的时候添加查询锁来避免查询功能的并发操作。性能测试进行的时间好比几年前功能测试刚刚起步，其实就是一次出厂验货，却美其名日QA。现在我们知道了功能测试包括单元测试、集成测试、系统测试，知道了需要尽可能早地介入测试，甚至应该对需求进行测试，从而有效地、全方位地保证软件质量。扁鹊见蔡桓公是一篇小学时的课文，相对于看病来说，软件测试也是一种类似的工作，即应该及早进行诊断及预防。现在的性能测试往往都是在项目后期才开始进行的，就算通过性能测试发现系统的性能已经完全无法达到预期的需求，在多数情况下已经于事无补了。一个有效的缺陷就是能够被修复的缺陷!一个软件的缺陷，特别是性能上的缺陷不是简单地改改代码就行。当一栋高楼已经建到第40层，才发现地基打得不够深，没办法继续往下修建了，而主梁的强度也不够，这时除了推倒重建也没什么其他有效的方法了。软件也是如此，当后期才发现存在严重的性能问题时，再想修正它的成本和难度相对功能问题来说要大很多。接着来看看理想情况下性能测试应该在哪些阶段介入，如图1.4所示。图1.4 性能测试的进行时间编码阶段(压力/并发)在编码阶段，当每个函数、方法、存储过程被开发出来并通过单元测试后，都应该进行压力和并发测试，确认接口和被测对象能否健壮地处理极端情况，并且能否正确处理并发请求。在大多数情况下，这个阶段的性能测试都是开发人员自行负责。而作为一个架构设计师，在设计软件时即应该考虑整个系统的性能，并进行建模测试，确保设计的正确。随后程序员对架构进行实现时就需要对自己编写的代码进行并发测试和压力测试。编码一测试之间(容量测试)在系统编码完成时，应该及时进行容量测试，确认系统能否满足在指定容量下的性能需求。例如导入5年的历史数据量，检查在这种容量下系统的性能是否可以接受，进一步再构造未来5年的数据量，检查系统是否正常工作。测试阶段(负载/配置/基准)在进入测试阶段之后，在确保功能正确实现后需要进行负载测试，得到系统在当前硬件及软件环境下的性能指标(响应时间、吞吐量、资源利用率)，进一步形成性能数据基准，然后通过配置测试进行性能瓶颈的定位和优化。在负载测试后可以得到系统的性能，如果该结果满足用户需求，则可以考虑结束性能测试，也可以考虑进一步进行配置和基准测试，定位系统中的性能瓶颈，并进行进一步的优化。1.2.2 性能指标前面了解了什么是性能，忽视性能会带来什么结果以及什么是性能测试，那么性能测试到底要测什么呢?在讨论软件的性能指标之前，请思考一下汽车和家用电脑的性能指标是通过什么数据来说明的。对于一个应用系统来说，我们所需要监控的性能指标主要有以下3点：响应时间响应时间反映完成某个业务所需要的时间。例如从单击登录按钮到登录完成返回登录成功页面需要消耗1秒钟，那么就说这个操作的响应时间是1秒。在性能测试中是通过事务函数来完成对响应时间的统计，事务是指做某件事情的操作，事务函数会记录开始做这件事情和该事情做完之间的时间差，使用Transaction Response Time这个词来说明，也称为事务响应时间。吞吐量吞吐量反映单位时间内能够处理的事务数目。例如对于系统来说一个用户登录需要1秒钟，如果系统同时支持10个用户登录，且响应时间是1秒钟，那么系统的吞吐量就是10个秒。在性能测试工具中，吞吐量也被称为TPS(Transaction Per Second，每秒事务数)也就是说在单位时间内能完成的事务数目。TPS的计算一般是通过的事务数除以时间。服务器资源占用服务器资源占用反映在负载下系统的资源利用率。资源的占用越低，说明系统越优秀。资源并不仅仅指运行系统的硬件，而是支持整个系统运行程序的一切软硬件平台。在性能测试中，我们需要监控系统在负载下的硬件或者软件上各种资源的占用情况，例如CPU的占用率、内存使用率、查询cache命中率等。对于一个终端用户来说，最关心的指标只有响应时间，如果响应时间长了，那么用户就会觉得系统慢。用户并不关心有多少人使用这个系统以及系统的资源是不是足够，所以从某个角度来说，性能测试必须保证在任意情况下终端用户使用的操作响应时间不大于5秒。有调查统计，对于一个用户来说，如果访问某系统的响应时间小于2秒，那么用户会感觉系统很快，比较满意；如果访问某系统的响应时间在25秒，那么用户可以接受，但是对速度有些不满；如果某系统的响应时间超过10秒，用户将无法接受。所以对于一个系统来说，需要尽可能保证每一个操作的响应时间在5秒以内，当然某些特殊的操作可能会大大超出这个响应时间，可以通过Loading Bar的方式来提前告诉用户。1.2.3 性能分析及调优性能测试的目的是为了发现性能瓶颈并解决。性能分析是为了确定导致性能瓶颈的原因，而调优就是用来解决性能瓶颈。通过某些手段来让系统的性能得到提升是性能调优的主要目的。性能分析主要有以下两种方法：·指标达成法将测试结果与用户需求进行比较，如果达到用户需要则测试通过。1系统满足10万注册用户(其中活跃用户数为1万)访问；2系统处理能力：20个注册秒、45个并发浏览秒、30个登录操作秒；3服务器资源利用率在满负荷的情况下，忙时峰值CPU负载不超过75，内存占用不超过80。例如：需要对一个参加100米跑的选手在比赛前进行性能测试，确保其能获得冠军，那么首先需要明确第一名所需要达到的性能目标(100米短跑总时间)，对其进行性能测试，当发现测试结果能够达到冠军所具备的条件后，性能测试即可结束。·最优化分析法通过分析并消除系统性能瓶颈，使系统的处理能力最大化，系统资源实现充分利用。例如：需要对一个参加100米跑的选手进行技术指导，并不在乎他是否能够拿到冠军，而是重点强调能否提升自己的比赛成绩，那么就需要进行系统的训练和指导，如规范起跑动作、强化肌肉及协调性等，最终实现运动成绩的提高。对应的性能调优方法也分为两大方向，如图15所示。图15性能调优方向1应用程序诊断应用程序的诊断是性能测试的最初目的。通过模拟多用户操作形成负载，检验应用程序是否能够满足用户性能需求。如果不能满足，则定位应用瓶颈，并寻找解决该瓶颈的方案，确保系统在修正后能够满足用户需求。对于一个项目来说，一般都以应用诊断为主。2系统调优性能测试的目的不是为了满足用户，而是超越自己，这个时候需要做的是让系统能够比以前更加优秀地运行，通过生成负载，对测试结果进行分析，并且准备大量的软硬件环境进行迭代测试，找出影响性能的要素，最终提升系统的性能。一般产品都会采用系统调优的方式来逐步完善系统性能。常见的性能瓶颈有如下一些情况：1硬件上的性能瓶颈一般指的是CPU、RAM方面的问题，分为服务器硬件瓶颈、网络瓶颈(对局域网可以不考虑)、服务器操作系统瓶颈(参数配置)、中间件瓶颈(参数配置、数据库、Web服务器等)、应用瓶颈(SQL语句、数据库设计、业务逻辑、算法等)。例如：确定了在数据库服务器上需要6个CPU、12GB内存。但是在测试时，发现CPU的持续利用率超过95，这时可以认为在硬件上出现了性能瓶颈。2应用软件上的性能瓶颈一般指的是应用服务器、Web服务器等应用软件，还包括数据库系统。例如：在WebLogic平台上配置了JDBC连接池的参数，最大连接数为50，最小连接数为5，增加量为10。在测试时发现，当负载增加时，现有的连接数不足，系统会动态生成10个新的连接，导致交易处理的响应时间大大增加。这时可以认为在应用软件上出现了性能瓶颈。3应用程序上的性能瓶颈一般指的是开发人员新开发出来的应用程序。例如：某程序员开发了一个缴费处理程序。在测试时发现，这个缴费处理程序在处理用户的并发缴费请求时，只能串行处理，无法并行处理，导致缴费交易的处理响应时间非常长，这时可以认为在应用程序上出现了性能瓶颈。4操作系统上的性能瓶颈一般指的是Windows、UNIX、Linux等操作系统。例如：在Windows操作系统中，对某软件进行性能测试，出现物理内存不足时，如果虚拟内存设置也不合理，虚拟内存的交换效率就会大大降低，从而导致行为的响应时间大大增加。这时可以认为在操作系统上出现了性能瓶颈。5网络设备上的性能瓶颈一般指的是防火墙、动态负载均衡器、交换机等设备。例如：在动态负载均衡器上设置了动态分发负载的机制，当发现某个应用服务器上的硬件资源已经到达极限时，动态负载均衡器将后续的