昨天看了测试大侠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/