昨天看了測試大俠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、如何對指令碼進行角色劃分、如何分配使用者執行對應的交易等等諸多細節。
通過這種方法建立的測試指令碼和測試場景，最符合實際負載的運**況，從而可以得出有用的結論，否則你就是在浪費時間，浪費金錢。
借用2023年看過的sunshinelius版主的一篇文章《讓loadrunner走下神壇》中的一句話：
「我們無論在loadrunner前面加多少個「強大」、「智慧型」的形容詞，別忘了其最終修飾的只是乙個名詞－「工具」。《大話西遊》中相當精闢的論斷：官兵？最多也只是個長了痔瘡的官兵！」
如果你沒有把它用好，那它就是長了痔瘡的官兵。哈哈！！
如何做效能測試？
一提到效能測試，大家首先想到的就是測試工具，很多人認為效能測試就是使用測試工具，會使用測試工具就是會效能測試，我認為這種思想是不對的。什麼叫效能測試呢？效能測試是通過自動化的測試工具模擬多種正常 峰值以及異常負載條件來對系統的各項效能指標進行測試。測試工具只是用於模擬某些特定的情況的，模擬出某些情況...
如何做效能測試？
一 什麼是效能測試 是不斷的通過不同場景的系統表現去 系統設計與資源消耗之間的平衡。我們可以認為效能測試是 通過在測試環境下對系統或構件的效能進行探測，用以驗證在生產環境下系統效能是否達到預估的效能 需求，發現系統可能存在的效能瓶頸，進而改善優化並系統的效能，提高系統的可擴充套件性 穩定性。從上面的...
如何做效能測試怎麼做的
做效能需求分析，挑選了使用者使用最頻繁的功能來做效能測試，比如 登陸，開啟系統首頁，搜尋，提交訂單，確定效能指標，比如 事務通過率為100 90 的事務響應時間不超過3秒，cpu和記憶體的使用率為70 以下。搭建效能測試環境，準備好效能測試資料。使用jmeter開發優化指令碼，包括 引數化，斷言，關...