昨天看了测试大侠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前面加多少个“强大”、“智能”的形容词，别忘了其最终修饰的只是一个名词－“工具”。《大话西游》中相当精辟的论断：官兵？最多也只是个长了痔疮的官兵！”
如果你没有把它用好，那它就是长了痔疮的官兵。哈哈！！