昨天看了測試大俠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前面加多少個“強大”、“智能”的形容詞，別忘了其最終修飾的只是一個名詞－“工具”。《大話西游》中相當精辟的論斷：官兵？最多也只是個長了痔瘡的官兵！”
如果你沒有把它用好，那它就是長了痔瘡的官兵。哈哈！！