软件测试论坛

 找回密码
 软件测试论坛注册页
查看: 813|回复: 4

面向运维的性能测试

[复制链接]
发表于 2011-12-22 16:21:50 | 显示全部楼层 |阅读模式
软件测试工程师就业班马上开班
每个公司都有自己的基因。做产品起家的,和网络公司不同。对于性能测试,很多的思维还停留在单机时代。于是很多QA就认为,无非就是测试CPU,memory,disk等参数而已。  但是随着后台的service程序逐渐增多,service的性能测试,和之前测试一个产品,已经有了很多的不同。这里,就谈谈这次性能测试的一些经验。
  其实之前QA已经做过了一些性能测试。但是有一天我们计划购入机器为产品上线做准备,manager问我如何购买机器。我一看module不少,首先就考虑如何分配这些moudule在不同的机器上,以获得最好的性能。于是我要搞清楚每个module的性能瓶颈,到底是cpu bound,还是IO bound,还是memory bound。
  我就建议QA做了这样的测试。测试结果出来了。从结果看来,扫描病毒的模块CPU还是一个瓶颈,毕竟,扫描病毒是一个很耗时的操作。而web service则需要较多的memory。
  我后面关心的就是那么多模块协同工作,谁是最慢的环节。因为我们之前的设计还是考虑的拓展性,所以,对于最慢的环节,通过增加进程数目和增加机器可以改善。
  结果出来了,QA很快就根据他们的性能,给出了一组最小的机器配置列表。哪些module可以放在一起,每个module至少要起几个进程才不至于出现特别慢的module block整个service的效率。这下就简单了。我们可以把它作为一个service组,以后增加机器,就按照这样的配置成倍的增加。
  其实这样的思路,就是现在所谓的SOA运维。别人问你需要多少机器,如何扩容,你给出的不是几台机器,而是以一个最小的service集群组为单位的系统配置。比如说你的service有3个模块,他们的配置可能是
  模块 数目 特征
  A 1 CPU bound
  B 2 IO bound
  C 1 memory bound
  意味这增加一个A和C,需要两个B配合。
  这样,最小的配置就是 1 cpu,2 disk,1 memory,有可能对于到服务器上面,就是
  8core cpu
  15000 PRM SAS disk *2
  32G memory
  有了这样的最小单位,下面才是真正的性能测试环节,我们要知道,这个最小的service单位,能够有多大的吞吐量。
  于是,尽可以多地喂数据,看看输出的效率。这时,我们关心的已经不是cpu、memory、io这些参数了,因为你的最小配置必须是这样的。你可能会浪费CPU,浪费内存,但是没有办法,因为瓶颈在那里,要增加机器提高整体吞吐量,IO是瓶颈。 我们关心的是,整个最小的service集合到底能有多大的吞吐量。如果我要更大的吞吐量,需要多少个这样的service单位。
  这样的性能测试结果,对产品,对运维才是真正有意义的。这就是从整体的角度去考虑一个service产品。而这也为RD后期的开发起了指导意义,哪个模块是重头戏,对整体而言起决定意义。需要重点调优,哪个模块虽然效率很低,但是调优的优先级可以放低。因为他不是关键。
  这里的关键,就在于强调整体测试。而且这个整体是建立在之前模块测试后的模块配比的基础上的。强调最小service集合的测试。


ISTQB
发表于 2011-12-22 16:24:10 | 显示全部楼层
软件测试工程师就业班马上开班
先mark一下,有空再仔细看
ISTQB
发表于 2011-12-23 11:21:51 | 显示全部楼层
软件测试工程师就业班马上开班
晕  不信啊  
发表于 2011-12-23 11:21:51 | 显示全部楼层
软件测试工程师就业班马上开班
…没我说话的余地…飘走  
发表于 2011-12-23 21:36:50 | 显示全部楼层
软件测试工程师就业班马上开班
这么看来,性能测试的确对运维节省资源和高校利用硬件资源有着很大的帮助!

本版积分规则

Archiver|手机版|小黑屋|领测软件测试网 ( 京ICP备10010545号-5 )

GMT+8, 2021-10-16 20:50 , Processed in 0.178189 second(s), 11 queries , Xcache On.

Powered by Discuz! X3

© 2001-2013 Comsenz Inc.

快速回复 返回顶部 返回列表