|
|
知识路径： > 测试技术的分类 > 应用负载压力测试 > 负载压力测试概述 >
|
被考次数：2次
被考频率：低频率
总体答错率：39%
知识难度系数： 
|
由 软考在线 用户真实做题大数据统计生成
|
|
相关知识点：19个
|
|
|
|
|
这是一个很重要的问题，也是测试前首先要考虑的问题。
|
|
|
|
我们经常听到“很多人都在使用系统时，响应时间太慢了，到底问题在哪里”这样的用户抱怨。类似的问题还有“要花多少时间做完一笔交易；什么样的配置提供了最好的性能；系统能在无错情况下承担多大及多长时间的负载；这些升级对系统性能影响多大；服务器应该选择哪些硬件与软件；在没有较大性能衰减的前提下，系统能够承受多大负载；哪些因素降低交易响应时间”等等，这样直观的问题描述代表了测试需求，也由此决定了测试目的。
|
|
|
|
|
|
. 在真实环境下检测系统性能，评估系统性能以及服务等级的满足情况。
|
|
|
|
例如电信计费软件，众所周知，每月20日左右是市话交费的高峰期，全市几千个收费网点同时启动。收费过程一般分为两步，首先要根据用户提出的电话号码来查询出其当月产生费用，然后收取现金并将此用户修改为已交费状态。一个看起来简单的两个步骤，当成百上千的终端同时执行这样的操作时情况就大不一样了，如此众多的交易同时发生，对应用程序本身、操作系统、中心数据库服务器、中间件服务器、网络设备的承受力都是一个严峻的考验。决策者需要模拟系统负载压力，预见软件的并发承受力，这是在测试阶段就应该解决的重要问题。
|
|
|
|
一个企业自己组织力量或委托软件公司代为开发的应用系统，在生产环境中实际使用起来以后，往往会产生这样一个问题，即这套系统能不能承受大量的并发用户同时访问，这个问题是系统负载压力需求的体现。
|
|
|
|
这里强调在真实环境下检测系统性能，在实施过程中大家认为这样做会遇到很多阻力，比如系统上线运行之后，真实环境下不允许负载压力测试为系统带来大量的垃圾数据，测试数据与真实业务数据混在一起无法控制测试结果，负载压力测试如果使服务器宕机会给系统带来巨大损失等。那么在这种条件不允许的情况下，应该采用什么样的措施弥补呢？我们可以使用一种“模拟环境”来做测试，这种环境是指与实际真实应用环境基本等级保持一致的测试环境。
|
|
|
|
. 预见系统负载压力承受力，在应用实际部署之前，评估系统性能。
|
|
|
|
目前的大多数公司企业需要支持成百上千名用户，各类应用环境，以及由不同供应商的元件组装起来的复杂产品。难以预知的用户负载和越来越复杂的应用程序，使公司时时担忧会发生投放性能差，用户遭受反应慢，系统失灵等问题。其结果就是导致公司收益的损失。
|
|
|
|
检测系统性能强调对系统当前性能的评估，通过评估，可以在应用实际部署之前，预见系统负载压力承受力。这种测试的意义在于指导系统总体设计，既可以避免浪费不必要的人力、物力和财力，又避免硬件和软件的设计不匹配，使系统具有更长、更健壮的生命力。
|
|
|
|
如何确定系统的“负载压力承受力”是一个非常复杂且关键的问题，我们会在“负载压力测试需求分析”一节中详细论述。
|
|
|
|
对于系统性能检测，有时我们所从事的工作仅仅是被动监控一些性能指标，而预见系统负载压力承受力，则不可避免地会借助自动化的负载压力测试工具。
|
|
|
|
|
|
系统性能检测和预见为分析系统瓶颈和优化提供了原始数据，打好了基础。
|
|
|
|
瓶颈这个术语来源于玻璃瓶与瓶身相比收缩了的部分。收缩的瓶颈将引起流量的下降，从而限制了液体流出瓶外的速度。类似的，在负载压力测试中，“瓶颈”这个术语用来描述那些限制系统负载压力性能的因素。我们给系统瓶颈一个简单定义，即应用系统中导致系统性能大幅下降的原因。瓶颈大大降低了系统性能，测试工程师的职责之一，就是降低或者消除系统中的瓶颈。一般情况下，发现瓶颈并找出原因并不是件容易的事。很多时候，你可能无法准确定位系统瓶颈之所在。瓶颈可能定位在硬件中，也可能定位在软件中。对软件来讲，可能定位在开发的应用程序中，也可能定位在操作系统或者数据库内部，对于后者，我们是无能为力的。数据库和操作系统的开发者们都一直在测试其产品的新版本，以期能尽其所能地排除产品中存在的所有瓶颈。硬件中的瓶颈可能会非常容易排除，一般来讲，解决硬件瓶颈的方法只是简单地向系统中添加CPU、磁盘或者内存等，如果硬件瓶颈是由于系统缓冲区设计或内存总线造成的，那么通常情况下我们就无能为力了。硬件瓶颈与软件瓶颈相比，我们更建议先解决软件瓶颈，原因有三，其一是软件瓶颈往往导致系统性能衰减更快，反过来讲，消除软件瓶颈，系统性能提升更快；其二是人为因素更易导致软件瓶颈，要消除软件瓶颈，开发人员会更主动，并且可以节省资源；其三，盲目增加硬件则无形中增加维护费用，将来，软硬件不匹配的问题终究还会暴露出来。
|
|
|
|
优化调整系统是在发现瓶颈，故障定位之后要完成的事情，实现优化之后即可消除瓶颈，提高性能。我们建议将负载压力性能问题分为两类：一类是需要优化的性能问题，这类问题可能导致系统性能大幅度下降，或者给系统造成破坏，也可能性能不会下降许多；另一类是非系统优化所能解决的性能问题。我们这里讨论的是前者，导致系统性能下降的因素来自许多方面，例如I/O过载、内存不足、数据库资源匮乏、网络速度低、硬件资源不足、操作系统资源不足、应用程序架构存在缺陷，软硬件配置不恰当等等。优化调整即是对症下药，做到药到病除。我们来看一个例子，如果是磁盘I/O导致了系统瓶颈，那么消除它的方法可能是重新设计数据库或者提高系统能力。
|
|
|
|
在系统优化调整领域，有许多指导性文件，例如IBM针对其产品DB2、WebSphere、CM、Portal等都提供了专门的Tuning Guide，并且配合以培训。我们知道，各个组成部分的最优并不代表系统性能可以达到最优，每个组成单元都具备一些调优指标，每个指标的调整并非最大就好，或者最小就好，也很少存在在某个范围就最好这种情况。我们给测试工程师的建议是，调优的最终目的是各个指标的调整取得系统的平衡点，也即达到了系统性能的最佳点。讲到这里，我们会想到吴清源大师的“六合之棋”，他曾经提出围棋的目标不是局限于边角，而是应该很好地保持全体的平衡，站在一个很高的角度去看待。
|
|
|
|
由此可见，负载压力测试将为企业项目的实施提供信心，帮助用户正确地进行容量规划，实现软硬件投资合理化，最终交付高质量的系统，避免项目投产失败，保证用户的投资得到相应的回报。
|
|
|
