|
|
知识路径： > 测试技术的分类 > 应用负载压力测试 >
|
被考次数：12次
被考频率：高频率
总体答错率：36%
知识难度系数： 
|
由 软考在线 用户真实做题大数据统计生成
|
|
考试要求：掌握
相关知识点：142个
|
|
|
|
|
|
|
系统的负载压力是指系统在某种指定软件、硬件以及网络环境下承受的流量，例如并发用户数、持续运行时间、数据量等，其中并发用户数是负载压力的重要体现。例如当一个应用程序在少量用户同时使用的时候，程序可能会正常运行，然而，当有大量用户同时使用时，可能会出现功能失效、性能衰减，甚至系统崩溃的现象。
|
|
|
|
|
|
负载压力测试是指在一定约束条件下测试系统所能承受的并发用户量、运行时间、数据量，以确定系统所能承受的最大负载压力。
|
|
|
|
负载压力测试有助于确认被测系统是否能够支持性能需求，以及预期的负载增长等。负载压力测试不只是关注不同负载场景下的响应时间等指标，它也要通过测试来发现在不同负载场景下会出现的，例如速度变慢、内存泄漏等问题的原因。因此，应该在开发过程中尽可能早地进行负载压力测试。
|
|
|
|
负载压力测试是性能测试的重要组成部分，负载压力测试包括并发性能测试、疲劳强度测试、大数据量测试等内容。下面分别介绍这些概念。
|
|
|
|
|
|
系统的性能是一个很大的概念，覆盖面非常广泛，对一个软件系统而言，包括执行效率、资源占用、稳定性、安全性、兼容性、可扩展性、可靠性等，我们这里重点讨论的负载压力是系统性能的一个重要方面。性能测试用来保证产品发布后系统的性能能够满足用户需求。性能测试在软件质量保证中起重要作用。通常情况下存在性能调优与性能评测两种性能测试策略。
|
|
|
|
|
|
|
|
. 在真实环境下，检查系统服务等级的满足情况，评估并报告整个系统的性能。
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
在通常情况下，性能调优的过程是上述步骤循环执行的过程，以实现目标。
|
|
|
|
|
|
负载测试是通过逐步增加系统负载，测试系统性能的变化，并最终确定在满足性能指标的情况下，系统所能承受的最大负载量的测试。
|
|
|
|
|
|
压力测试是通过逐步增加系统负载，测试系统性能的变化，并最终确定在什么负载条件下系统性能处于失效状态，并以此来获得系统能提供的最大服务级别的测试。通俗地讲，压力测试是为了发现在什么条件下系统的性能会变得不可接受。
|
|
|
|
可见，压力测试是一种特定类型的负载测试。例如，访问一个页面的响应时间规定为不超过1秒，负载测试就是测试在响应时间为1秒时，系统所能承受的最大并发访问用户的数量，而压力测试就是测试系统在多大的并发访问用户数量下，响应时间不可接受，例如超过1分钟（定义为失效状态）。
|
|
|
|
|
|
并发性能测试的过程，是一个负载测试和压力测试的过程。即逐渐增加并发用户数负载，直到系统的瓶颈或者不能接收的性能点，通过综合分析交易执行指标、资源监控指标等来确定系统并发性能的过程。并发性能测试是负载压力测试中的重要内容。
|
|
|
|
从一个完整解决方案的角度考虑，并发性能测试概括为以下3类。
|
|
|
|
|
|
|
|
|
|
|
|
通常是采用系统稳定运行情况下能够支持的最大并发用户数，或者日常运行用户数，持续执行一段时间业务，保证达到系统疲劳强度需求的业务量，通过综合分析交易执行指标和资源监控指标，来确定系统处理最大工作量强度性能的过程。一般情况下利用疲劳强度测试来模拟系统日常业务操作。
|
|
|
|
|
|
|
|
大数据量测试包括独立的数据量测试和综合数据量测试两类。
|
|
|
|
独立的数据量测试指针对某些系统存储、传输、统计、查询等业务进行的大数据量测试。
|
|
|
|
综合数据量测试指和压力性能测试、负载性能测试、疲劳性能测试相结合的综合测试。
|
|
|
|
|
|
这是一个很重要的问题，也是测试前首先要考虑的问题。
|
|
|
|
我们经常听到“很多人都在使用系统时，响应时间太慢了，到底问题在哪里”这样的用户抱怨。类似的问题还有“要花多少时间做完一笔交易；什么样的配置提供了最好的性能；系统能在无错情况下承担多大及多长时间的负载；这些升级对系统性能影响多大；服务器应该选择哪些硬件与软件；在没有较大性能衰减的前提下，系统能够承受多大负载；哪些因素降低交易响应时间”等等，这样直观的问题描述代表了测试需求，也由此决定了测试目的。
|
|
|
|
|
|
. 在真实环境下检测系统性能，评估系统性能以及服务等级的满足情况。
|
|
|
|
例如电信计费软件，众所周知，每月20日左右是市话交费的高峰期，全市几千个收费网点同时启动。收费过程一般分为两步，首先要根据用户提出的电话号码来查询出其当月产生费用，然后收取现金并将此用户修改为已交费状态。一个看起来简单的两个步骤，当成百上千的终端同时执行这样的操作时情况就大不一样了，如此众多的交易同时发生，对应用程序本身、操作系统、中心数据库服务器、中间件服务器、网络设备的承受力都是一个严峻的考验。决策者需要模拟系统负载压力，预见软件的并发承受力，这是在测试阶段就应该解决的重要问题。
|
|
|
|
一个企业自己组织力量或委托软件公司代为开发的应用系统，在生产环境中实际使用起来以后，往往会产生这样一个问题，即这套系统能不能承受大量的并发用户同时访问，这个问题是系统负载压力需求的体现。
|
|
|
|
这里强调在真实环境下检测系统性能，在实施过程中大家认为这样做会遇到很多阻力，比如系统上线运行之后，真实环境下不允许负载压力测试为系统带来大量的垃圾数据，测试数据与真实业务数据混在一起无法控制测试结果，负载压力测试如果使服务器宕机会给系统带来巨大损失等。那么在这种条件不允许的情况下，应该采用什么样的措施弥补呢？我们可以使用一种“模拟环境”来做测试，这种环境是指与实际真实应用环境基本等级保持一致的测试环境。
|
|
|
|
. 预见系统负载压力承受力，在应用实际部署之前，评估系统性能。
|
|
|
|
目前的大多数公司企业需要支持成百上千名用户，各类应用环境，以及由不同供应商的元件组装起来的复杂产品。难以预知的用户负载和越来越复杂的应用程序，使公司时时担忧会发生投放性能差，用户遭受反应慢，系统失灵等问题。其结果就是导致公司收益的损失。
|
|
|
|
检测系统性能强调对系统当前性能的评估，通过评估，可以在应用实际部署之前，预见系统负载压力承受力。这种测试的意义在于指导系统总体设计，既可以避免浪费不必要的人力、物力和财力，又避免硬件和软件的设计不匹配，使系统具有更长、更健壮的生命力。
|
|
|
|
如何确定系统的“负载压力承受力”是一个非常复杂且关键的问题，我们会在“负载压力测试需求分析”一节中详细论述。
|
|
|
|
对于系统性能检测，有时我们所从事的工作仅仅是被动监控一些性能指标，而预见系统负载压力承受力，则不可避免地会借助自动化的负载压力测试工具。
|
|
|
|
|
|
系统性能检测和预见为分析系统瓶颈和优化提供了原始数据，打好了基础。
|
|
|
|
瓶颈这个术语来源于玻璃瓶与瓶身相比收缩了的部分。收缩的瓶颈将引起流量的下降，从而限制了液体流出瓶外的速度。类似的，在负载压力测试中，“瓶颈”这个术语用来描述那些限制系统负载压力性能的因素。我们给系统瓶颈一个简单定义，即应用系统中导致系统性能大幅下降的原因。瓶颈大大降低了系统性能，测试工程师的职责之一，就是降低或者消除系统中的瓶颈。一般情况下，发现瓶颈并找出原因并不是件容易的事。很多时候，你可能无法准确定位系统瓶颈之所在。瓶颈可能定位在硬件中，也可能定位在软件中。对软件来讲，可能定位在开发的应用程序中，也可能定位在操作系统或者数据库内部，对于后者，我们是无能为力的。数据库和操作系统的开发者们都一直在测试其产品的新版本，以期能尽其所能地排除产品中存在的所有瓶颈。硬件中的瓶颈可能会非常容易排除，一般来讲，解决硬件瓶颈的方法只是简单地向系统中添加CPU、磁盘或者内存等，如果硬件瓶颈是由于系统缓冲区设计或内存总线造成的，那么通常情况下我们就无能为力了。硬件瓶颈与软件瓶颈相比，我们更建议先解决软件瓶颈，原因有三，其一是软件瓶颈往往导致系统性能衰减更快，反过来讲，消除软件瓶颈，系统性能提升更快；其二是人为因素更易导致软件瓶颈，要消除软件瓶颈，开发人员会更主动，并且可以节省资源；其三，盲目增加硬件则无形中增加维护费用，将来，软硬件不匹配的问题终究还会暴露出来。
|
|
|
|
优化调整系统是在发现瓶颈，故障定位之后要完成的事情，实现优化之后即可消除瓶颈，提高性能。我们建议将负载压力性能问题分为两类：一类是需要优化的性能问题，这类问题可能导致系统性能大幅度下降，或者给系统造成破坏，也可能性能不会下降许多；另一类是非系统优化所能解决的性能问题。我们这里讨论的是前者，导致系统性能下降的因素来自许多方面，例如I/O过载、内存不足、数据库资源匮乏、网络速度低、硬件资源不足、操作系统资源不足、应用程序架构存在缺陷，软硬件配置不恰当等等。优化调整即是对症下药，做到药到病除。我们来看一个例子，如果是磁盘I/O导致了系统瓶颈，那么消除它的方法可能是重新设计数据库或者提高系统能力。
|
|
|
|
在系统优化调整领域，有许多指导性文件，例如IBM针对其产品DB2、WebSphere、CM、Portal等都提供了专门的Tuning Guide，并且配合以培训。我们知道，各个组成部分的最优并不代表系统性能可以达到最优，每个组成单元都具备一些调优指标，每个指标的调整并非最大就好，或者最小就好，也很少存在在某个范围就最好这种情况。我们给测试工程师的建议是，调优的最终目的是各个指标的调整取得系统的平衡点，也即达到了系统性能的最佳点。讲到这里，我们会想到吴清源大师的“六合之棋”，他曾经提出围棋的目标不是局限于边角，而是应该很好地保持全体的平衡，站在一个很高的角度去看待。
|
|
|
|
由此可见，负载压力测试将为企业项目的实施提供信心，帮助用户正确地进行容量规划，实现软硬件投资合理化，最终交付高质量的系统，避免项目投产失败，保证用户的投资得到相应的回报。
|
|
|
|
|
|
负载压力测试可以采取利用手工进行测试和利用自动化负载压力测试工具进行测试两种测试策略。
|
|
|
|
大多数工程师掌握手工测试技巧，比如，可以手工模拟负载压力，方法是找若干台电脑和同样数目的操作人员，在同一时刻进行操作，然后用秒表记录下响应时间，这样的手工测试方法可以大致反映系统所能承受的负载压力情况。但是，这种方法需要大量的人员和机器设备，而且测试人员的同步问题无法解决，更无法捕捉程序内部的变化情况。利用自动化负载压力测试工具进行测试可以很好地解决这些问题。利用自动化负载压力测试工具可以在一台或几台PC机上，模拟成百或上千的虚拟用户同时执行业务的情景，通过可重复的、真实的测试能够彻底地度量应用的性能，确定问题所在。
|
|
|
|
可见，负载压力测试的发展趋势是，利用自动化的测试工具进行测试，当然在没有工具的情况下，我们也可以通过手工测试对系统承受负载压力情况做一个近似的评估。下面重点介绍一下利用自动化测试工具进行负载压力测试的策略，分别是利用商业化测试工具进行测试、利用开放资源测试工具进行测试和自主开发工具进行测试。
|
|
|
|
|
|
利用商业化的自动化测试工具是进行负载压力测试的主要手段，知名的商业化的测试工具，比如LoadRunner、QALoad等，适用范围非常广，一般都经过了长时间的市场检验，测试效果得到业界的普遍认可，测试结果具有一定的可比性，并且厂商一般都能提供很好的技术支持，其版本的升级也会得到保证。但是商业化的自动化测试工具一般价格较高，如果考虑价格因素，那么利用开放资源工具进行测试也是一个不错的策略。
|
|
|
|
|
|
开放资源被定义为用户不侵犯任何专利权和著作权，以及无需通过专利使用权转让，就可以获取、检测、更改的软件源代码，这意味着任何人都有权访问、修改、改进或重新分配源代码。开放资源的理念是，当人们在已存在的工具上共同开发时，最终产品会更加先进。简而言之，很多企业和个体都会从中获益。开放资源的最大优点是测试工具是免费的。
|
|
|
|
|
|
最流行的几个开放资源性能测试工具是：开放系统测试体系OpenSTA、TestMaker和JMeter。这些工具中的每一个都能提供完成负载压力测试所需的功能，现存的多种开放资源测试工具都是可获得的。下面列举几个例子。
|
|
|
|
①开放系统测试体系——OpenSTA（http://portal.opensta.org/）。
|
|
|
|
OpenSTA是Windows平台、分布式的软件测试体系，基于CORBA（Common Object Request Broker Architecture）。OpenSTA能产生数百或数千个虚拟用户，最初用于测试基于Web的应用软件。此工具还为用户响应时间和平台应用软件（包括应用服务器、数据库服务器、Web服务器）的资源占用信息监控提供了图形化标准。
|
|
|
|
OpenSTA具有一种简单的脚本语言，即脚本控制语言（SCL）。SCL与商业性能测试工具一样，使用户能够创建测试脚本。它能将输入数据参数化，从外部文件读入参数数据。如下图所示是OpenSTA的脚本模型界面。
|
|
|
|
|
|
|
|
②TestMaker（http://www.pushtotest.com/）。
|
|
|
|
它是一种基于Java的架构，能够创建测试代理，以用于衡量应用软件和Web服务器的性能。TestMaker可以在Windows、Linux和UNIX平台上运行，可以用它创建针对Web应用的测试案例，而不管这些应用是基于J2EE平台还是.NET平台。TestMaker支持各种不同的协议，例如HTTP/HTTPS、TCP/IP、SOAP以及XML。TestMaker的脚本语言是一种开放资源语言，叫做Jython。Jython其实是Python语言的Java实现形式。Jython除了给开发者提供所有的Java对象外，还提供Python的面向对象的环境。TestMaker包含一个代理日志，同商品化测试工具所提供的功能类似。
|
|
|
|
③Apache JMeter（http://jakarta.apache.org/jmeter/）。
|
|
|
|
Apache JMeter是一种纯粹的Java应用软件，用于测试功能和衡量性能。JMeter最初是基于Apache Tomcat设计的，用于测试Web应用软件的性能，但是目前，开放资源发展联盟将此产品的应用扩展得更广泛了，Apache JMeter同时用于功能测试和负载压力测试。应用这一软件可以测试Java对象、JDBC、数据库、Perl脚本、Web服务器和应用服务器等。
|
|
|
|
和商品化测试工具一样，Apache JMeter的代理记录可以记录浏览器和Web服务器之间的通信。并且，由于JMeter是100%Java的，所以它不受平台约束。
|
|
|
|
|
|
自主开发测试即开发自己的负载压力测试程序或者工具。
|
|
|
|
例如，一个简单的Web应用测试工具可以这样构建。首先编写一个对每一个模拟客户机运行一个线程的程序。每一个线程需要与服务器通信，可能使用Java、Net、URL类。这种方法能够达到基本的HTTP客户机模拟，它可以执行GET和PUT。每个线程需要做的就是发送HTTP请求，收集回复。这一组行动可以相当容易地抽象到一个单独的配置文件中。很快地，就得到一个基本的负载测试工具。同时可能需要增加一些配置选项以确定运行多少个线程（模拟的客户机），以及它们是同时开始，还是慢慢增加负载。当然，需要对与服务器的交互计时，因为这是要测试的核心内容，响应时间。
|
|
|
|
后面章节中，我们会详细论述开发负载压力测试程序或者工具的一些思路。
|
|
|
|
|
|
我们知道，在项目的不同阶段都需要进行负载压力性能测试，而测试是需要必要的资源的，所以应该为此制定相应的计划。这里提供了5点计划安排，它们能确保系统负载压力性能满足需求。
|
|
|
|
|
|
在需求分析阶段，主要的焦点是为系统中共享的和有限的资源进行需求分析。例如，一个网络联接既是共享的又是有限的资源；一个数据库表是一个共享的资源；线程是一个有限的资源。如果没有正确的设计，这些在以后的各阶段将引发严重问题。
|
|
|
|
为了突出负载压力性能需求分析，有时需要为负载压力性能分析分配大约10%的时间，不同的设计选择对于负载压力性能的影响是不同的。测试工程师需要掌握负载压力性能目标设计方法，同时应该具备与确定负载压力性能需求相关的体系结构资料，需求分析应该与体系结构分析结合进行。
|
|
|
|
|
|
设计者应当清楚地了解不同设计对负载压力性能的影响，在设计的各个方面应该充分考虑负载压力性能设计各方的意见，给出负载压力性能的预期指标。
|
|
|
|
如果设计中系统应用了第三方产品，例如，中间件或者数据库产品，则应要求第三方产品提供商能够对其产品进行性能验证和设计，识别与其产品有关的负载压力性能问题。
|
|
|
|
为了突出负载压力性能的重要性，在预算方面也应当留出专门的资金，如为负载压力性能方面分配10%的资金预算是一个安全的选择。
|
|
|
|
设计中还应该考虑应用规模和数据量的可升级性。应用分布的规模可能依赖于分布组件的需求级别、事务处理机制和模式等，数据量的升级将要求设计中包含专门处理大数据集处理的内容。
|
|
|
|
|
|
开发阶段开始时的负载压力性能任务是建立负载压力性能测试环境。需要进行以下工作：
|
|
|
|
|
|
. 为测试环境制定规则的负载压力性能测试时间表，如果测试环境是共享的，负载压力性能测试不能与其他活动同时发生；
|
|
|
|
|
|
|
|
测试要如实表现系统的主要应用，测试系统的可升级性，例如，可确定共享资源如何响应增长的负载，也可确定受限资源在哪个阶段开始用尽或者成为瓶颈。
|
|
|
|
验收测试结果可以统计负载压力性能、比较负载压力性能，以及报告异常，提供分析依据。
|
|
|
|
|
|
监控系统在正常运行状态下的负载压力性能，识别系统性能的倾向，确定何种条件下负载压力性能超过可接受范围等。
|
|
|
|
|
|
就像汽车的观后镜存在“盲点”一样，许多负载压力测试工具也存在“盲点”，会给使用工具的测试工程师一种盲目的安全感。这个盲点是什么呢？就是在负载压力测试中，不进行功能校验，当功能错误发生时，测试工具不能够记录产生的错误，这就忽略了负载压力情况下的功能不稳定问题。目前分布式应用部署结构、Web技术的发展等极大地扩大了这些“盲点”发生的可能，忽视这些“盲点”，必然会导致结果的不可信，甚至导致结果有害。
|
|
|
|
所以负载压力测试期间必须要进行必要的功能内容校验，换句话讲，没有正确的功能保证，负载压力性能测试就失去了意义。那么，如何做功能内容校验呢？我们认为只有在负载压力测试过程中记录所有虚拟用户的操作，及服务器的响应，才有助于判断功能错误，这就是当前负载压力测试技术发展的最大挑战。测试过程中的附加记录会导致资源消耗、操作行为增加以及产生大量日志等问题。
|
|
|
|
目前有些负载压力测试工具能够将负载压力测试与功能校验融为一体，尽量减少此“盲点”。如果使用的工具不具备此功能，那么就必须借助于一些辅助手段来克服“盲点”，视而不见肯定不是一个明智的选择。
|
|
|
