2011.11.1好日子,今天博客访问量超过1000了。 2012.01.29,访问量突破2000了. 2012.02.01,访问量突破3000了.继续进步

性能测试设计和LR原理的探讨(下)

上一篇 / 下一篇  2012-08-24 23:08:49 / 个人分类:自动化脚本

接上一篇

说到了最关键的操作系统,网络,硬件这块了.很多时候我们高科技的性能测试产物性能报告变成废铁的.就是这3个造成.linux我最高记录并发10800个线程(4cpu虚拟双倍),win7最高记录2100个线程(双核),这个仅仅是好看的记录,没了!因为我们IO口就这么大,磁盘读写能力最大限制,网络带宽也有限制,所以上面开到的线程当然可以增加压力,但是在没穷到只剩1~2测试服务器的情况下,最好不要用一个方法,毕竟10台吊丝台式强过1台高富帅服务器做客户端.同时虽然云计算其中一个概念是虚拟化计算,但是并不代表你每个测试机都把资源利用做虚拟机来做压力,因为最关键的线程,虚拟机本身的软件和操作系统也消耗了一些线程的地盘,所以利用虚拟化计算做测试,需要谨慎.还有一点就是性能命令top,ps,sar等等的数值,你要注意那些有用,哪些相对准确,虽然linux提供了很多性能命令,但是不代表他们之间是一模一样的.当然lr也是靠人工配合分析组网,测试机的性能.

 

最后说下你分析和出测试报告.lr的报告很华丽,很多专用性能测试名词都打上一堆,可爱的老大最喜欢看这个赚奖金的东西.但是实事求是的大牛没那么容易骗过,把公司网络,各个资源都用上来做性能测试肯定要看到有意义的东西.我脚本投入了很多excel图表(交互式调用偷懒),来帮我做出很多图.性能测试最重要是分析,我上面说的很多技术都为了准确获得数据分析而设计的.所以现在性能测试从单机到分布式到云都往精确这个关键点发展.很多次带着报告面对各部分的开发老大,作为一个小QC如何把上百兆的日志和数据理出来跟这些高手报告需要注意很多细节.为什么这个阶段曲线会不没规律?什么是瓶颈?有没问题?这些数据作为参考数据还是代表有问题?系统该不该优化?下一个迭代的任务和程序设计如何做?这些都必须自己理清楚.对比Lr,唯一的优势就是这些数据我都知道怎么抓来的,但是要比上这个权威的工具,还是需要继续努力缩小差距.

 

下一个阶段不再是怎么去查询瓶颈,怎么去发现bug为主,因为敏捷到了接近尾声的时候,我需要变成选型工程师的角色,优化程序框架和处理,分析操作系统是主要任务,来为我们的产品节约成本,是性能测试的其中一个因素之一.

(完)

TAG:

 

评分:0

我来说两句

acbennn

acbennn

站在云端看浮云,晕. CSDN的博客:http://blog.csdn.net/bullswu/article/details/6798437

日历

« 2024-04-30  
 123456
78910111213
14151617181920
21222324252627
282930    

数据统计

  • 访问量: 60229
  • 日志数: 44
  • 建立时间: 2011-09-18
  • 更新时间: 2013-09-22

RSS订阅

Open Toolbar