微信号:grzlwx

介绍:光荣之路官方资讯

性能测试浅谈(模拟演练)

2015-07-04 23:13 光荣之路



当然,对于测试人员来说,技术能力只能排在第二号,测试思想才是最根本的。敏锐的嗅觉、严谨的逻辑、合理的推测、大胆的实践是一个合格测试工程师的必备要素。

模拟演练

  写了一大堆,新手还是不知道如何去做。其实写本文的目的也不是讲具体操作,而是思想,思想。新手学性能测试,建议找一本从LOADRUNNER开讲的书比较好。如51TESTING上有连载的《性能测试从零开始》。

  不过还是尽量说点具体些的内容吧。

  普通BS架构的系统,一般都采用测试工具(如LR)直接录制手工操作的方式进行测试。这种方式简单有效,对测试人员要求不高。但在一些情况下,这种基于录制的方法可能无法完成,比如页面上有特殊控件、系统是CS架构、或者通讯的协议无法捕获等。这时就需要更复杂的测试方法,如手动编写模拟客户端的JAVA代码,而把测试工具当作一个调度控制台,去调度大量的虚拟用户线程执行编写好的代码。

  现在假设有一个简易版的12306网站,JAVA实现,中间件为TOMCAT,数据库为SYBASE,没有集群处理(一切从简,只有查询和订票功能)。如何对它进行性能测试呢?

  按照上面的几个步骤来想一想吧,这里只简单写几点。

  第一步,测试确认。海量并发,数据也应该是海量的,但基本都是简单查询,没有复杂的统计,所以主要困难还是在海量并发事务的处理上。中间件、数据库上都会承受巨大压力。此类高并发系统还需要对一些功能特别注意,比如一个车次有10张票,5个人同时购票,如何处理?如果是12个人同时点购票,又是如何处理?

  第二步,通过标准。无非是系统能够满足多少人同时在线,一分钟内能处理多少订单,用户最大等待时间是几分钟。注意这个标准一定要是经过各方面确认过实际可行的啊,定一个订单响应时间不超过5秒有意义么?确认了以后,就要按着这个目标来设计测试和执行。

  另一个需要注意的问题,按照预期的压力测试通过了以后,是不是就高枕无忧了?答案是否定的,因为很可能这个预期或者标准是不合理的,这个是非常可能的,只有长期的数据积累,才会一点点走向精确。想想奥运订票系统,开通后短短五分钟,网站就瘫痪了,你们以为这种系统没有经过专业的性能测试么?据我所知,奥运订票系统性能测试时制定的标准是每分钟处理四百万访问(具体数据记不住了,就假设是这个数吧),出事后的检查发现,每分钟的访问量超过了八百万。这种事故责任在谁呢?测试机构敢拍胸脯保证,每分钟处理四百万就是没问题的。而奥组委自己设定的每分钟四百万目标,和实际出现偏差也是正常的,毕竟这种系统是第一次上线。最后的处理方法就是,压力达到了预期最大值以后,再后来的访问就被排队了。好好体会这个案例吧,会有收获的。

  第三步,测试设计。设计用户模型,设计测试场景,设计测试用例。一个典型的用户是如何使用系统的?登录、查询车次余票、订票、付款,这是理想化的情况。实际更可能是这样的,登录(一次登不进去,重复多次)、查询A车次(未到放票时间、不断重试,时间到无票)、查询B车次(无票)、查询C车次(有票)、订票、付款、查询订单。两种交互方式对系统产生的压力,差别是很大的。

  将多个用户行动整合到一起,也就是用户模型,或者叫系统使用模型,是压力场景设计的依据。假设系统一天的访问量是一万个用户,这一万访问量是在24小时内平均分布的,还是分布在8小时内,还是在某一时间点上集中访问?这些具体到用例中也就是虚拟用户的加载策略,直接决定了压力的大小。

  除了这个压力场景,针对此系统还需要进行绝对并发测试,参考第一步的分析。

  第四、五步就不细说了,准备环境、数据,针对大量用户的并发进行一些预调优。按照第三步设计好的各个测试用例准备脚本、执行测试。

  第六步,发现问题了怎么办?比如1000人的压力下,系统响应就比较慢了,查询车次需要1分钟,下订单需要2分钟,接下来要做什么?能把这些作为一个性能缺陷提起么?显然是不可以的,这只是通过你的压力测试场景产生的一个现象,可能是测试脚本有问题、也可能是测试环境有问题。作为一个性能测试人员,需要尽量深入的定位到问题产生的原因。就像这个响应慢,只是一个表面现象,慢在哪?是中间件还是数据库?一些简单的测试方法就可以进行判断,如在页面上进行一些数据库无关的操作,如果依然比较慢,说明在中间件上压力就已经比较大了。还可以部署另一套中间件测试环境,连接之前相同的数据库,在压力测试出现问题的同时,手动访问新部署的应用(只有一个用户),如果同样很慢,那说明慢在了数据库端的处理上。还可以通过日志的方式更准确的进行判断,如应用日志和数据库SQL执行日志。总之方法是多种多样的,但目的只有一个,就是不断的排除无关部分、缩小问题范围。

  定位到了中间件和数据库之一,然后又该怎么办?此时恐怕就需要一些相关方面的专业知识了,但其实最常见的还是那些。中间件相关的一般是线程池、JVM、数据库连接池等,数据库相关的有锁、缓存、IO(一般就是SQL语句的问题)等。要进行全面的监控和分析,再做一些合理的调优并重复测试。

  问题定位到什么程度才行?我认为是要让人看了知道改哪就可以了。比如提一个“这个SQL语句进行了大量的物理IO,性能不好”,这就不是个好问题,物理IO是什么?怎么改?如果这么说就好多了“这个SQL语句没有使用索引,导致了全表扫描,进行了大量的物理IO,性能不好。如果要避免全表扫描,需要调整SQL语句或者添加XX索引”,这才是定位问题。

  当然了,上面只是一个非常简陋的举例,真实的性能测试要比这复杂的多。

  总的来说,我认为,性能测试的难度主要不在技术手段上,互联网时代技术都是共享的,要善于去搜索利用他人的成果。即使自己搞不定,团队内一定还有专业的开发工程师、数据库管理员、系统管理员可以帮你搞定。真正的难点在于,你要想出来如何去测是有效的、有保障的,这才是测试工程师最重要的能力。

  还是那个观点,思想才是根本。


(作者:薛定谔的破猫 来源:http://www.cnblogs.com/twocats/archive/2012/02/14/2351748.html)

一字一句当思来之不易,感谢作者,也让更多的人看到母们吧!

光荣之路软件测试培训

官网:http://www.gloryroad.cn/

微信公众号:gloryroadtrain

性能测试QQ群:415987441
软件测试招聘QQ群: 203715128
自动化3群QQ: 371211499



 
光荣之路 更多文章 今天晚上的 linux 公开课- Awk 编程 7月28日(今天)晚上的 linux 公开课- shell编程 8月4日(今天)晚上的 linux 公开课- shell编程 9月1日(本周一)晚8点半,光荣之路Web自动化系列基础课—javascript第二讲 推荐本好书《与机器赛跑》
猜您喜欢 一位女程序员的奋斗路程 圆桌论坛实录 | 从容器生态圈解析容器之热现象 阿里面试经历及总结(数据研发、Java研发方向) 24个有用的PHP类库 【C语言探索之旅】 第四课:变量的世界之内存那档事