做“准确”的性能测试-阿里云开发者社区

开发者社区> 开发与运维> 正文

做“准确”的性能测试

简介:

昨天看了测试大侠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前面加多少个“强大”、“智能”的形容词,别忘了其最终修饰的只是一个名词-“工具”。《大话西游》中相当精辟的论断:官兵?最多也只是个长了痔疮的官兵!”

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

本文出自seven的测试人生公众号最新内容请见作者的GitHub页:http://qaseven.github.io/

版权声明:本文内容由阿里云实名注册用户自发贡献,版权归原作者所有,阿里云开发者社区不拥有其著作权,亦不承担相应法律责任。具体规则请查看《阿里云开发者社区用户服务协议》和《阿里云开发者社区知识产权保护指引》。如果您发现本社区中有涉嫌抄袭的内容,填写侵权投诉表单进行举报,一经查实,本社区将立刻删除涉嫌侵权内容。

分享:
开发与运维
使用钉钉扫一扫加入圈子
+ 订阅

集结各类场景实战经验,助你开发运维畅行无忧

其他文章