qileilove

blog已经转移至github,大家请访问 http://qaseven.github.io/

捉虫记--大容量Web应用性能测试与LoadRunner实战(连载五)

5.1.10  并发测试(Concurrency Testing)简介

  并发测试(Concurrency Testing)方法通过模拟很多用户在同一时刻访问系统或对系统的一个功能进行操作,来测试系统的性能,从中发现问题。网站就是一个很典型的需要并发测试的应用场景:当网站运行的时候,在世界各地同一时刻都可能有很多用户在进行同一个操作,如图5-6所示。除此之外,类似的还有银行的某些系统、航空的某些系统等,它们都需要大量用户同时访问和操作。

图5-6  用户对Web应用的并发访问

  类似小白在本章开始对公司测试网站的访问是无法发现可能存在的并发问题的。即使是公司所有的同事一声令下,也无法做到比较精确的同时访问,数量也很不够。因此,并发测试是无法用人工的方式来完成的,必须依赖一些工具软件来模拟实现,比如HP公司的LoadRunner等,这个软件我们将在后面的章节专门介绍使用方法。

  并发测试所要考察的是系统在并发处理方面是否存在缺陷。实现并发的编码与原理是比较复杂的,需要很高级的开发技巧,因此不在本书介绍的范围之内。在实际工作中,我们只需要了解如下3个要点:

  并发测试需要用工具模拟多用户的访问。

  要熟悉第一点提到的工具测试并发的操作。本书介绍的是LoadRunner。

  要了解并发测试所关注的性能问题是什么。

  至于并发中深入的线程、进程、内存泄露等知识,则需要在工作中遇到问题时来学习了。

  5.1.11  并发测试所关注的性能问题

  并发测试关注哪些性能上的问题?为了理解方便,我们用一个通俗的例子来说明。

  还是利用传统的类比--饭馆,毕竟民以食为天。在某一时刻的饭馆中,有很多客人都在吃饭,这可以说是一个并发场景。于是,可能出现的问题有如下几个(当然不限于以下的这些):

  餐桌是有限的,客人很多,超出桌子数目,只能排队叫号了。类似这样抢空闲桌子的情况在程序代码中也会出现,叫做资源(内存等也被称为资源,程序运行需要在内存中,而可用的内存又是有限的)的争用(Race)。

  如果饭馆还有一个空桌子,但被别人电话预定了,而此时饭馆等位的人又很多,服务员该如何处理呢?一般是等待15分钟、联系预定人的电话等方法。类似这样有关保留预定与放弃预定的情况在程序代码或者数据库中也会出现,根据条件不同(比较复杂,涉及类似多个客户订同一张桌子等细节),分别叫做活锁(livelock)和死锁(deadlock)等。

  如果饭馆的服务员应付众多的客人已经忙不过来;或者就是服务员忘记了,经常会出现这样的情况:有一桌客人在吃完饭后已经结账走人,但服务员并没有及时的清理桌布,收盘子、擦桌子等,导致后面的客人无法使用这张桌子进餐,无形中使得饭馆的接待能力下降。由于代码的问题使得类似上面这样的情况在程序运行中也出现,就叫做内存泄露(Memory leak)。

  以上几个类比可能不很确切,但是引申出了一个结论:并发测试所关注的性能问题就是:系统中的内存泄露、线程控制(锁的问题)和资源争用。

 5.1.12  并发测试的特点与工具

  并发测试具备如下的几个特点:

  (1)并发测试可以是黑盒测试,也可以是白盒测试。测试工程师可以不了解代码实现的细节,通过工具软件实施并发测试找出Web应用的并发问题。开发工程师也可以通过并发测试对自己编写的代码做单元测试。

  (2)并发测试可以在项目进行的大部分时候进行。在项目的早期,它可以通过结果大致验证系统总体设计和结构是否合理;在项目编码阶段,它可以发现代码的并发问题;在项目的测试阶段,它可以发现整个系统的并发问题。

  【并发测试工具】

  除了前文提到,本书后面章节要介绍的综合性能测试软件LoadRunner之外,还有很多专用的并发测试工具,比如在Java平台下有JProfile、JProbe等;在.NET平台下有CHESS、Zing等。

  由于并发测试这部分内容程度比较深,完全展开需要更多的是开发知识,而不是测试知识本身,感兴趣的读者可阅读相关的书籍。

  5.1.13  配置测试(Configuration Testing)

  所谓配置测试(Configuration Testing)方法,是通过对被测系统所处的软、硬件环境进行设置上的调整,来了解其对于系统性能影响的程度,并根据结果发现环境的最优配置组合。这个测试方法主要用于性能的优化,一般用于Web应用正式投入使用前夕和运行当中。

  1.配置测试的实例

  实际上,在使用电脑的过程中,我们每个人都可能做过这样的测试。比如,使用Windows XP一段时间后,电脑运行速度可能有所减慢。那么我们可能就会上网查询具体变慢的原因,更改一些系统默认的设置,并从实际的效果来验证这些设置的更改是否有效。无效的配置很可能被恢复成默认值。这可以说就是一种配置测试。

  2.配置测试的目的

  配置测试的目的就在于发现当前修改的这种配置是否能够有效提高Web应用的性能。

  还记得有一种比较流行的工具软件:Windows优化大师吗?它实际上就是通过调整不同的系统软、硬件参数,使得我们的Windows运行起来感觉更快。Windows优化大师的软件界面如图5-7所示,可以发现它是由多个配置修改页面组成的。

图5-7  Windows优化大师的界面

  3.配置测试实施的时机

  那么,什么时候进行配置测试呢?还是与我们平时使用电脑的情况做类比。当我们尚未把所有需要的软件都安装完毕之前,一般是不会做配置测试的,这是因为这段时间即使修改了软、硬件配置、进行了优化,这种配置也可能被新安装的软件在之后覆盖掉,导致优化失效。同样的道理,在Web应用的程序代码没有开发完毕、测试没有基本完成、有关性能的Bug还远远没有被修改的时候,就进行配置测试、性能优化是不合适的。也就是说,配置测试测试的是Web应用所依赖的软、硬件配置对于性能的影响,对于Web应用的代码本身,已经假设它达到了最好的性能。

  配置测试所涉及的系统设置要依照Web应用所依赖的环境而定,一般分为软件和硬件两部分:

  软件部分:数据库各参数的设置;操作系统各参数的设置;网络带宽的设置等。

  硬件部分:硬盘缓存、硬盘运行模式、磁盘阵列的设置等。

 5.1.14  耐久度测试(Endurance Testing)

  耐久度测试又叫做浸泡测试(Soak Testing),具体方法是令被测试的软件系统、Web应用在大负荷条件下长时间运行,从中发现问题。从这个定义来看,被测软件系统或者Web应用长时间处于测试状态下,用"浸泡"来描述是很恰当的。

  耐久度测试所能发现的问题都和被测系统运行时间变长后,一些资源无法释放,导致系统响应时间慢慢变长有关。详细而言,有以下几类:

  严重的内存泄露(请见并发测试小节)导致系统内存慢慢不够使用。

  数据库连接、数据库游标、应用服务器资源等没有适时释放,导致系统变慢。

  被测系统代码中的数据结构不甚健壮或合理,在长时间运行后,对其的增加、删除、修改、查询等速度出现问题。

  耐久度测试需要至少关注以下一些指标:CPU使用率、可用内存、内存使用百分比等。通过隔一段时间记录以上的指标,最终形成数据表和相应的图,从中可以找到规律,如图5-8所示,它是在进行一次耐久度测试时,每小时在线用户数量的结果绘图。

图5-8  某网站最近6天每小时在线用户统计

  根据图5-8的变化规律,再结合耐久度测试中定时记录的CPU、内存等指标,如果二者规律不符合(比如当在线用户数少的时候,内存占用并没有下降很多),就可以分析出有关资源分配是否正常的结论。

  耐久度测试可以在代码开发阶段,也可以在网站版本接近完成、准备上线前,更可以在网站运行当中。因此,根据这几种情况,进行耐久度测试的时间长度有所不同,但总的原则都是测试时间要尽可能地长,这样才有"浸泡"的作用。

  代码开发阶段,主要看开发工作的时间安排与发现问题的早晚。如果运行早期就发现了内存泄露问题,可以中断进行代码的修改。

  网站版本接近完成的时候,主要看网站上线时间安排,和发现问题的大小。如果上线时间不变,则耐久度测试进行到上线为止。

  网站运行当中的耐久度测试,由于要定时记录各种指标,对于网站本身可能影响较大,需要择机进行,比如在长假、长周末等时间。

  【耐久度测试与其他测试的区别】

  耐久度测试主要考虑的是时间对于系统或者Web应用的影响,因此,它测试的时间要比其他方法,如性能、压力、负载等测试要长得多。另外,它关注的是系统在一个渐进的资源消耗过程中的表现,与压力测试关注一个固定指标下(可以看作一个时间点)系统的表现、负载测试关注最终的那个最大负载(也可以看作一个时间点)、并发测试关注并发操作发生时系统的表现(也可以看作一个时间点)都不同。

  5.1.15  可靠性测试(Reliability Testing)

  可靠性测试(Reliability Testing)方法实际上就是前一节所说的耐久度测试,只是这个词一般用于测试大型软件,特别是应用于工业、交通等的行业软件。这是因为IT领域的可靠性测试这个词是从制造业"引用"过来的,带有些许传统大工业机器制造的意味。

 5.1.16  尖峰冲击测试(Spike Testing)

  与可靠性测试类似,尖峰冲击测试这种方法也是从其他行业借鉴而来。在电力工业,有一种冲击测试,用来验证设备在刚刚接通电源时能否经受住涌流的破坏。所谓涌流,通俗地说,就是电源接通瞬间,电流突然变大的现象。涌流过后,电流逐渐恢复到正常的水平。

  软件行业的冲击测试,或者说本书称之的尖峰冲击测试,就是为了验证网站在用户突然极具增加的情况下能够正常工作。我们知道,在网站的运行过程中,会经常出现各种各样用户数量的突然增加:

  网站开幕时可能导致用户急剧增加,超过预期。

  网站公布与用户极为相关的信息,比如高考成绩、录取分数等。

  网站投放一些商业促销广告和促销活动,比如季节性降价,春节前大促销。

  网站举办酝酿已久的明星访谈、在线销售演出、比赛门票等吸引眼球的活动。

  以上这些情况产生的在线用户数量突然增加都会对网站性能产生巨大影响,读者一定记得通过网络购买奥运会门票时,由于用户非常踊跃,导致售票网站无法打开的案例。

  在前文我们介绍过负载测试,但实际情况所产生的负载不会老老实实地遵循最大负载的限制,很可能在短时间内就会超过,这时系统并不一定会出现问题。尖峰冲击测试就是为了验证此时网站的应付能力。

  如图5-9所示为网站在某一时刻,在线用户突然增大,形成一个尖峰的情况。这也正是尖峰冲击测试中Spike的由来,Spike在英文中是钉子的意思。

  【尖峰冲击测试的实施】

  尖峰冲击测试一般也是采用工具软件进行自动测试的。在Load Runner中,可以修改之前性能测试的脚本,令某一个时刻用户数突然增大,就可以达到测试的目的。

图5-9  网站某时刻在线用户数突然增大形成尖峰

  5.1.17  失败恢复测试(FailOver Testing)

  失败恢复测试(Failover Testing)方法对于大中型的Web应用是很重要的,它针对有冗余备份(Redundant Backup)、负载均衡(Load Balance)的系统。这种测试方法用于验证某部分Web应用发生故障时,整个网站是否能够继续让用户使用的能力。

  1.用户访问网站可能出现的问题

  我们知道,Web应用是存放在服务器的硬盘上供用户访问的,而服务器一般来说都位于IDC(互联网数据中心,Internet Data Center)机房的机架上。用户访问一个Web应用的过程如图5-10所示,为简单起见,这里只列出大的部分。

图5-10  用户访问网站过程的示意图

  从图5-10中可以看出,如果一个用户无法访问某个网站,那么可能是:

  用户电脑出现了问题。解决方法:维修用户电脑。

  网络线路出现了问题。解决办法:更换网线,修正交换机、路由器等设置。

  网站服务器出现了问题。解决办法需要在下文进一步讨论。

那么,如何使得网站具有高可用性呢?

  【何为高可用性】

  所谓高可用性,就是指网站在绝大多数的时间都能够正常显示。网站的设计说明书中经常提到"保证网站99.99%的时间都可用"这样的承诺,这就需要一定的技术保障。但是Web应用比较复杂,软件代码可能有Bug;用户的持续访问和数量的增加也会造成网站较大的负荷,导致硬件可能失效。

  可以用以下几种方法来提高网站能正常运转的时间。

  主动防御:尽量修改软件代码中的Bug,提高Web应用本身的健壮性,减少网站出问题的机会。

  被动防御:在保持现有Web应用代码、服务器配置不变的情况下,通过适当增加服务器的数量、尽量平均分配网站负荷、采用备份的方法提高可用性。在这些措施中,就有冗余备份,负载均衡等方法,我们将在下面的内容中介绍。

  2.提高可用性:冗余备份

  冗余备份是用两台或者多台服务器构成一个小的服务器场(Server Farm)来承担网站失败恢复工作的。简单地说,一台服务器作为Web应用的主服务器,另一台作为它一模一样的镜像复制。一旦主服务器发生问题,网站无法正常使用,立刻切换到备用服务器,使得用户的访问能够继续。它的结构示意如图5-11所示。

图5-11  冗余备份的简单结构示意图

  由于网站所需要的服务器要比图5-10中多出一台到多台,这些服务器中的数据又是互为备份的,因此,我们把这种方式叫做冗余备份。当图5-10中的Web应用服务器发生故障时,系统检测到(有多种方法能检测服务器故障是否发生:比如"心跳",即HeartBeat,采用定时ping服务器以及其他指标),系统将把连接服务器与外界的线路自动转接到备份服务器上,从而导致用户端浏览网站时基本感觉不到这种变化,极大地减少了维修Web应用服务器所带来的网站停止时间。

  这种方法在生活中也经常采用。比如家里的手机、电视、汽车等出了故障,维修点一般会先给一个替代用品来满足维修期间的需要。不同的是,对于网站来说,主服务器和备份服务器的数据要求尽量完全一致。

  3.提高可用性:负载均衡

  冗余备份看似很完美地解决了服务器故障所带来的影响,但是它增加了设备,增加了成本,而且备份服务器上网站的备份实际上用户也是可以使用的,平时闲置的话有些可惜。因此,人们又采用了负载均衡的办法,在多台同样的服务器之前,加入一个"调度员",将用户的访问请求尽量平均分配给它们,导致每台服务器的负担下降,因而出问题的几率也就下降了。整个系统的简单示意如图5-12所示。

图5-12  网站服务器的负载均衡

  在实际工作中,还有其他一些方法,人们也往往综合使用这些方法来达到网站的7×24(7天,每天24小时,也就是全天候)可访问目标。

  【失败恢复测试的意义】

  失败恢复测试一般都是人工进行,有点类似奥运会开幕式的彩排。在模拟一台Web服务器出现故障的时候,验证另外的服务器能否接管用户的请求。当然,目前这些工作都已经可以由专用软件、硬件厂商来提供服务,只需要购买就可以了,实际的操作一般不会由测试工程师参与,技术经理和网络管理参与即可。但是,作为一个Web性能测试工程师,没有进行失败恢复测试的意识是不合适的。在以后的章节中,我们将和小白一起编写测试计划,在其中,应该给失败恢复测试留出一定的文字、安排一定的时间。

  (未完待续)

相关链接:

捉虫记--大容量Web应用性能测试与LoadRunner实战(连载一)

捉虫记--大容量Web应用性能测试与LoadRunner实战(连载二)

捉虫记--大容量Web应用性能测试与LoadRunner实战(连载三)

捉虫记--大容量Web应用性能测试与LoadRunner实战(连载四)

 

 

posted on 2013-05-29 10:29 顺其自然EVO 阅读(633) 评论(0)  编辑  收藏 所属分类: loadrunner性能测试


只有注册用户登录后才能发表评论。


网站导航:
 
<2013年5月>
2829301234
567891011
12131415161718
19202122232425
2627282930311
2345678

导航

统计

常用链接

留言簿(55)

随笔分类

随笔档案

文章分类

文章档案

搜索

最新评论

阅读排行榜

评论排行榜