模擬演練
寫了一大堆，新手還是不知道如何去做。其實寫本文的目的也不是講具體操作，而是思想，思想。新手學性能測試，建議找一本從LOADRUNNER開講的書比較好。如51TESTING上有連載的《性能測試從零開始》。
不過還是盡量說點具體些的內容吧。
普通BS架構的系統，一般都采用測試工具（如LR）直接錄制手工操作的方式進行測試。這種方式簡單有效，對測試人員要求不高。但在一些情況下，這種基于錄制的方法可能無法完成，比如頁面上有特殊控件、系統是CS架構、或者通訊的協議無法捕獲等。這時就需要更復雜的測試方法，如手動編寫模擬客戶端的JAVA代碼，而把測試工具當作一個調度控制臺，去調度大量的虛擬用戶線程執行編寫好的代碼。
現在假設有一個簡易版的12306網站，JAVA實現，中間件為TOMCAT，數據庫為SYBASE，沒有集群處理（一切從簡，只有查詢和訂票功能）。如何對它進行性能測試呢？
按照上面的幾個步驟來想一想吧，這里只簡單寫幾點。
第一步，測試確認。海量并發，數據也應該是海量的，但基本都是簡單查詢，沒有復雜的統計，所以主要困難還是在海量并發事務的處理上。中間件、數據庫上都會承受巨大壓力。此類高并發系統還需要對一些功能特別注意，比如一個車次有10張票，5個人同時購票，如何處理？如果是12個人同時點購票，又是如何處理？
第二步，通過標準。無非是系統能夠滿足多少人同時在線，一分鐘內能處理多少訂單，用戶最大等待時間是幾分鐘。注意這個標準一定要是經過各方面確認過實際可行的啊，定一個訂單響應時間不超過5秒有意義么？確認了以后，就要按著這個目標來設計測試和執行。
另一個需要注意的問題，按照預期的壓力測試通過了以后，是不是就高枕無憂了？答案是否定的，因為很可能這個預期或者標準是不合理的，這個是非常可能的，只有長期的數據積累，才會一點點走向精確。想想奧運訂票系統，開通后短短五分鐘，網站就癱瘓了，你們以為這種系統沒有經過專業的性能測試么？據我所知，奧運訂票系統性能測試時制定的標準是每分鐘處理四百萬訪問（具體數據記不住了，就假設是這個數吧），出事后的檢查發現，每分鐘的訪問量超過了八百萬。這種事故責任在誰呢？測試機構敢拍胸脯保證，每分鐘處理四百萬就是沒問題的。而奧組委自己設定的每分鐘四百萬目標，和實際出現偏差也是正常的，畢竟這種系統是第一次上線。最后的處理方法就是，壓力達到了預期最大值以后，再后來的訪問就被排隊了。好好體會這個案例吧，會有收獲的。
第三步，測試設計。設計用戶模型，設計測試場景，設計測試用例。一個典型的用戶是如何使用系統的？登錄、查詢車次余票、訂票、付款，這是理想化的情況。實際更可能是這樣的，登錄（一次登不進去，重復多次）、查詢A車次（未到放票時間、不斷重試，時間到無票）、查詢B車次（無票）、查詢C車次（有票）、訂票、付款、查詢訂單。兩種交互方式對系統產生的壓力，差別是很大的。
將多個用戶行動整合到一起，也就是用戶模型，或者叫系統使用模型，是壓力場景設計的依據。假設系統一天的訪問量是一萬個用戶，這一萬訪問量是在24小時內平均分布的，還是分布在8小時內，還是在某一時間點上集中訪問？這些具體到用例中也就是虛擬用戶的加載策略，直接決定了壓力的大小。
除了這個壓力場景，針對此系統還需要進行絕對并發測試，參考第一步的分析。
第四、五步就不細說了，準備環境、數據，針對大量用戶的并發進行一些預調優。按照第三步設計好的各個測試用例準備腳本、執行測試。
第六步，發現問題了怎么辦？比如1000人的壓力下，系統響應就比較慢了，查詢車次需要1分鐘，下訂單需要2分鐘，接下來要做什么？能把這些作為一個性能缺陷提起么？顯然是不可以的，這只是通過你的壓力測試場景產生的一個現象，可能是測試腳本有問題、也可能是測試環境有問題。作為一個性能測試人員，需要盡量深入的定位到問題產生的原因。就像這個響應慢，只是一個表面現象，慢在哪？是中間件還是數據庫？一些簡單的測試方法就可以進行判斷，如在頁面上進行一些數據庫無關的操作，如果依然比較慢，說明在中間件上壓力就已經比較大了。還可以部署另一套中間件測試環境，連接之前相同的數據庫，在壓力測試出現問題的同時，手動訪問新部署的應用（只有一個用戶），如果同樣很慢，那說明慢在了數據庫端的處理上。還可以通過日志的方式更準確的進行判斷，如應用日志和數據庫SQL執行日志。總之方法是多種多樣的，但目的只有一個，就是不斷的排除無關部分、縮小問題范圍。
定位到了中間件和數據庫之一，然后又該怎么辦？此時恐怕就需要一些相關方面的專業知識了，但其實最常見的還是那些。中間件相關的一般是線程池、JVM、數據庫連接池等，數據庫相關的有鎖、緩存、IO（一般就是SQL語句的問題）等。要進行全面的監控和分析，再做一些合理的調優并重復測試。
問題定位到什么程度才行？我認為是要讓人看了知道改哪就可以了。比如提一個“這個SQL語句進行了大量的物理IO，性能不好”，這就不是個好問題，物理IO是什么？怎么改？如果這么說就好多了“這個SQL語句沒有使用索引，導致了全表掃描，進行了大量的物理IO，性能不好。如果要避免全表掃描，需要調整SQL語句或者添加XX索引”，這才是定位問題。
當然了，上面只是一個非常簡陋的舉例，真實的性能測試要比這復雜的多。
總的來說，我認為，性能測試的難度主要不在技術手段上，互聯網時代技術都是共享的，要善于去搜索利用他人的成果。即使自己搞不定，團隊內一定還有專業的開發工程師、數據庫管理員、系統管理員可以幫你搞定。真正的難點在于，你要想出來如何去測是有效的、有保障的，這才是測試工程師最重要的能力。
還是那個觀點，思想才是根本。