qileilove

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

做“准确”的性能测试

 昨天看了测试大侠pent翻译的一篇文章基于用户体验的性能测试》,原文名称为《User Experience, Not Metrics》,直译为《用户体验,而不是度量》,大侠翻译的很准确,不愧为前辈。这篇文章的观点很好,最近我正好也想谈谈类似的话题。

  看坛子里多数网友都在谈压力测试,讨论LoadRunner的使用,气氛热烈而又和谐,但我今天可能要给很多人泼一盆冷水了,“你做的压力测试“准确”吗?”,这里我说的

  “准确”有两层含义:

  符合现实:你模拟的负载测试真的能反映实际运行的负载吗?

  精确:你模拟测试中采集的度量数据足够详细、粒度够小吗?

  当然,借助于专业的压力测试工具,只要添加足够多的monitor,“精确”应该不难,但“符合现实”吗?以我作为过来人的经验,大多数的压力测试并不准确。为什么这么说,请往下看这张图。

  上图是大多数人得到的一个典型的测试结果,看上去很美,但它不符合现实情况。你的计算机、测试脚本有足够的耐心等待,但实际用户没有。在这个讲究效率、信息爆炸、社会高速运转的现实世界是什么样呢?

  另外用户对网站的熟悉程度、网络速度,甚至用户的计算机水平,都会影响用户的操作速度,进而对实际的负载形成不同的影响。



  一个不准确的压力测试会得出不准确的测试结果,对于一个重要的网站来讲,这样是非常危险的,会对决策层形成误导。

  ×对网站容量评估过高:当实际的负载上来时,会出现问题(响应过慢甚至崩溃)

  ×对网站容量评估过低:会导致不必要的浪费,包括不必要的硬件开支和资源浪费。

  因此,不准确的压力测试“后果很严重”。

  由此可以得到,做准确的压力测试是非常重要的,但如何才能做准确的压力测试呢?

  本文开始即提出,“准确”有两层含义,目前主要的问题还是“符合现实”,所以问题的关键是如何让你的压力测试符合现实情况。

  解决这个问题,主要还是站在业务的角度,在压力测试计划阶段考虑,具体来说,就是要回答几个问题,完成几个图形,详细请看本站的另外一篇文章:《LoadRunner前传:压力测试前的分析准备工作》。

  当然这里的几个问题其实不是那么好回答,要做很多分析统计工作,这里只是简单描述一下。如果被测系统是以前系统的升级,最好的方法就是从旧系统的运行日志中捕获以前的运行信息,比如原来系统使用的Web Server是IIS的话,IIS日志记录了用户访问系统的所有信息。借助于专门的分析工具(WebTrends等工具),导出分析IIS日志,可以建立WUS(Web Site Usage Signature)

  × Page Distribution

  —Home page 26%、Search 12%、Product Info 32%、Order 4%

  × 平均和标准偏差统计情况

  —Page size、Hit per Page、Session Duration ......

  有了以上的分析,你才知道如何设置脚本中think time、如何对脚本进行角色划分、如何分配用户执行对应的交易等等诸多细节。

  通过这种方法建立的测试脚本和测试场景,最符合实际负载的运行情况,从而可以得出有用的结论,否则你就是在浪费时间,浪费金钱。

  借用2004年看过的sunshinelius版主的一篇文章《让LoadRunner走下神坛》中的一句话:

  “我们无论在loadrunner前面加多少个“强大”、“智能”的形容词,别忘了其最终修饰的只是一个名词-“工具”。《大话西游》中相当精辟的论断:官兵?最多也只是个长了痔疮的官兵!”

  如果你没有把它用好,那它就是长了痔疮的官兵。哈哈!!

posted on 2011-12-09 16:40 顺其自然EVO 阅读(137) 评论(0)  编辑  收藏


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


网站导航:
 
<2011年12月>
27282930123
45678910
11121314151617
18192021222324
25262728293031
1234567

导航

统计

常用链接

留言簿(54)

随笔分类

随笔档案

文章分类

文章档案

搜索

最新评论

阅读排行榜

评论排行榜