本文主要針對WEB系統的性能測試。不涉及具體的執行操做，只是本人對性能測試的一點理解和認識。數據庫
性能測試的目的，簡單說其實就是爲了獲取待測系統的響應時間、吞吐量、穩定性、容量等信息。而發現一些具體的性能相關的缺陷（如內存溢出、併發處理等問題），我認爲只是一種附加結果。從更高的層次來講，性能測試最想發現的，是瓶頸。如何能獲得所須要的信息，就須要從多方面進行測試。緩存
性能測試的內容網絡
性能測試種類的劃分與定義這裏就不說了，各有各的說法，好比性能測試、負載測試、壓力測試這三個詞，在網上能找到N個版本的定義，大致理解就好了，不必在文字層面上較這個真。如下的內容也只是我我的的理解，一些名詞的定義可能和其餘資料有所不一樣，但在個人工做中，這樣是比較形象和容易理解的。架構
在實際工做，通常的應用系統會從這麼幾個方面進行性能測試。 併發
1.基準測試
Benchmark或者Baseline測試。通常爲單用戶測試，或者是零數據量環境下的測試。目的在於創建一個可度量的參考標準，爲其餘測試場景或者調優過程提供對比參考。也可認爲是最基礎的性能測試，若是基準測試的結果都不能達到預期要求，那麼後續場景也就不必測試了。高併發
2.平常壓力測試
在基準測試經過後，應該先進行較小壓力下的測試，首先對系統在平常壓力下的表現進行測試。此壓力須要根據系統使用相關數據得出，如系統平均天天訪問量、平均在線人數、每日完成事務數等。經過此測試，發現一些較表面的性能問題並進行處理。工具
3.峯值壓力測試
在平常壓力測試經過後，須要進行更大壓力的測試。此處壓力一樣須要相關數據的支持，通常爲將來幾年後的預期壓力。可根據歷史日均壓力、日最高壓力等信息，估算出將來幾年的日均以及日最高壓力。再經過一些通用估算方法、如二八原則（80%的工做在20%時間內完成，至關於2小時完成一天8小時的工做量），將日壓力轉換成峯值壓力。
峯值壓力爲可預期到的最大負載壓力，經過了此測試，則認爲系統有能力知足將來增加的壓力。post
4.容量測試
驗證了系統是否可知足預期的壓力後，還須要知道系統可以承受的最大壓力，也就是容量。通常經過「拐點法」進行測試，逐步增大系統的壓力，直到性能指標不可接受或者出現了明顯的拐點。以下圖，拐點在哪？性能
5.穩定性測試
驗證系統是否可長期穩定的運行，是否存在一些短期內可能沒法發現的缺陷（如內存溢出、數據庫鏈接不釋放等）。爲了縮短測試工期，通常可將預期一天的壓力集中在2小時內完成（二八原則），這樣持續加壓10小時，便至關於系統運行5天。注意監控各類性能指標是否平穩，有無降低。
以上幾種類型的測試，是性能測試過程當中最多用到的。固然也也其餘一些比較經常使用的類型，如絕對併發測試，測試多用戶對某一功能的瞬時請求，主要用於驗證系統是否存在併發邏輯上的處理問題。此測試也可劃分到不一樣的壓力測試場景中去，根據不一樣的用戶壓力，測試相應的絕對併發，通常取在線用戶數的10%進行測試；突發壓力測試，對一些不在預期內的忽然壓力進行測試（其實既然想到了，就應該是在預期內了）。以銀行門戶網站爲例，可能會因爲發佈了一條重要消息（政策調整）而致使訪問量激增，這種壓力是否會致使系統宕機或者暫時沒法提供服務，就是突發壓力測試須要考慮的了。也有人將此壓力定義爲峯值壓力，這就無所謂了，只要考慮到會有這麼一個問題就夠了。
性能測試的階段
上面主要說的是測試內容的劃分，也就是說作性能測試時要考慮到的幾個方面。從實際執行層面來看，測試的過程通常分爲這麼幾個階段：
1.測試確認
理解被測系統、尋找測試點、確認測試範圍、測試環境等。一些重要信息須要同PM、需求人員、設計人員討論確認，如用戶最經常使用哪些功能、最關注哪的性能，程序上哪多是壓力點，哪些數據須要模擬到真實的量級，大致上須要使用哪一種測試方法。
2.肯定經過標準
性能是好是壞、測試是否經過，必須有明確的標準。這個標準，主要從客戶的指望和業務上的需求兩方面來考慮，客戶的指望通常指頁面上的響應時間，業務需求則是系統的處理能力，通常爲吞吐量或TPS（每秒完成事務數）。標準制定的不合理，測試結果可能沒法反映系統真實的性能表現，或者會讓客戶沒法接受咱們認爲經過的軟件。
至於具體如何去設定，是須要同業務負責人（通常爲PM）和技術負責人（通常爲設計人員）共同確認的，業務負責人瞭解用戶的實際需求和指望，技術負責人瞭解具體的實現，能夠判斷哪些是不可達到的要求。
一旦達成了共識，那麼測試就要嚴格的按照標準去執行。
3.測試設計
主要從上面提到的幾個方面進行分析，針對系統的特色設計出合理的測試場景。爲了讓測試結果更加準確，這裏須要很細緻的工做。如創建用戶模型，只有知道真實的用戶是如何對系統產生壓力，才能夠設計出有表明性的壓力測試場景。這就涉及到不少信息，如用戶羣的分佈、各種型用戶用到的功能、用戶的使用習慣、工做時間段、系統各模塊壓力分佈等等。只有從多方面不斷的積累這種數據，纔會讓壓力場景更有意義。最後將設計場景轉換成具體的用例。
測試數據的設計也是一個重點且容易出問題的地方。生成測試數據量達到將來預期數量只是最基礎的一步，更須要考慮的是數據的分佈是否合理，須要仔細的確認程序中使用到的各類查詢條件，這些重點列的數值要儘量的模擬真實的數據分佈（數據統計信息、執行計劃相關的內容，此處就不細說了），不然測試的結果多是無效的。
此外，性能測試執行過程當中，須要監控收集的各類指標數據，也須要明確下來。
4.測試環境準備
部署測試環境，生成測試數據，環境預調優等等。預調優指根據系統的特色和本身的經驗，提早對系統的各個方面作一些優化調整，避免測試執行過程當中的無謂返工。好比一個高併發的系統，10000人在線，鏈接池和線程池的配置還用默認的，顯然是會測出問題的。
5.測試執行、監控
準備測試腳本，執行以前設計好的各個用例，監控並收集須要的數據。出現問題時，切記要全面的保留事故現場、或者是能進行分析的數據。好比TOMCAT再也不響應，不能只把這個現象記錄下來，這對問題的排查定位是沒有意義的，要保留全部相關的日誌，導出線程轉儲和堆轉儲。
6.問題分析定位、調優
發現問題或者性能指標達不到預期，及時的分析定位，處理後重複測試過程。
性能問題一般是相互關聯相互影響的，表面上看到的現象極可能不是根本問題，而是另外一處出現問題後引發的反應。這就要求監控收集數據時要全面，從多方面多個角度去判判定位。
調優的過程其實也是一種平衡的過程，在系統的多個方面達到一個平衡便可。
7.性能報告
將測試過程當中記錄的各類數據彙總成報告，將各方面須要的結果清楚的展示出來。
上面全部內容中，若是排除技術上的問題，性能測試中最難作好的，就是用戶模型（或者叫系統使用模型）的分析。它直接決定了壓力測試場景是否可以有效的模擬真實世界壓力，而正是這種對真實壓力的模擬，才使性能測試有了更大的意義。能夠說，性能測試作到必定程度，差距就體如今了模型創建上。
至於性能問題的分析、定位或者調優，很大程度是一種技術問題，須要多方面的專業知識。數據庫、操做系統、網絡、開發都是一個合格的性能測試人員須要擁有的技能，只有這樣，才能從多角度全方位的去考慮分析問題。
固然，對於測試人員來講，技術能力只能排在第二號，測試思想纔是最根本的。敏銳的嗅覺、嚴謹的邏輯、合理的推測、大膽的實踐是一個合格測試工程師的必備要素。
模擬演練
寫了一大堆，新手仍是不知道如何去作。其實寫本文的目的也不是講具體操做，而是思想，思想。新手學性能測試，建議找一本從LOADRUNNER開講的書比較好。如51TESTING上有連載的《性能測試從零開始》。
不過仍是儘可能說點具體些的內容吧。
普通BS架構的系統，通常都採用測試工具（如LR）直接錄製手工操做的方式進行測試。這種方式簡單有效，對測試人員要求不高。但在一些狀況下，這種基於錄製的方法可能沒法完成，好比頁面上有特殊控件、系統是CS架構、或者通信的協議沒法捕獲等。這時就須要更復雜的測試方法，如手動編寫模擬客戶端的JAVA代碼，而把測試工具看成一個調度控制檯，去調度大量的虛擬用戶線程執行編寫好的代碼。
如今假設有一個簡易版的12306網站，JAVA實現，中間件爲TOMCAT，數據庫爲SYBASE，沒有集羣處理（一切從簡，只有查詢和訂票功能）。如何對它進行性能測試呢？
按照上面的幾個步驟來想想吧，這裏只簡單寫幾點。
第一步，測試確認。海量併發，數據也應該是海量的，但基本都是簡單查詢，沒有複雜的統計，因此主要困難仍是在海量併發事務的處理上。中間件、數據庫上都會承受巨大壓力。此類高併發系統還須要對一些功能特別注意，好比一個車次有10張票，5我的同時購票，如何處理？若是是12我的同時點購票，又是如何處理？
第二步，經過標準。無非是系統可以知足多少人同時在線，一分鐘內能處理多少訂單，用戶最大等待時間是幾分鐘。注意這個標準必定要是通過各方面確認過實際可行的啊，定一個訂單響應時間不超過5秒有意義麼？確認了之後，就要按着這個目標來設計測試和執行。
另外一個須要注意的問題，按照預期的壓力測試經過了之後，是否是就高枕無憂了？答案是否認的，由於極可能這個預期或者標準是不合理的，這個是很是可能的，只有長期的數據積累，纔會一點點走向精確。想一想奧運訂票系統，開通後短短五分鐘，網站就癱瘓了，大家覺得這種系統沒有通過專業的性能測試麼？據我所知，奧運訂票系統性能測試時制定的標準是每分鐘處理四百萬訪問（具體數據記不住了，就假設是這個數吧），出過後的檢查發現，每分鐘的訪問量超過了八百萬。這種事故責任在誰呢？測試機構敢拍胸脯保證，每分鐘處理四百萬就是沒問題的。而奧組委本身設定的每分鐘四百萬目標，和實際出現誤差也是正常的，畢竟這種系統是第一次上線。最後的處理方法就是，壓力達到了預期最大值之後，再後來的訪問就被排隊了。好好體會這個案例吧，會有收穫的。
第三步，測試設計。設計用戶模型，設計測試場景，設計測試用例。一個典型的用戶是如何使用系統的？登陸、查詢車次餘票、訂票、付款，這是理想化的狀況。實際更多是這樣的，登陸（一次登不進去，重複屢次）、查詢A車次（未到放票時間、不斷重試，時間到無票）、查詢B車次（無票）、查詢C車次（有票）、訂票、付款、查詢訂單。兩種交互方式對系統產生的壓力，差異是很大的。
將多個用戶行動整合到一塊兒，也就是用戶模型，或者叫系統使用模型，是壓力場景設計的依據。假設系統一天的訪問量是一萬個用戶，這一萬訪問量是在24小時內平均分佈的，仍是分佈在8小時內，仍是在某一時間點上集中訪問？這些具體到用例中也就是虛擬用戶的加載策略，直接決定了壓力的大小。
除了這個壓力場景，針對此係統還須要進行絕對併發測試，參考第一步的分析。
第4、五步就不細說了，準備環境、數據，針對大量用戶的併發進行一些預調優。按照第三步設計好的各個測試用例準備腳本、執行測試。
第六步，發現問題了怎麼辦？好比1000人的壓力下，系統響應就比較慢了，查詢車次須要1分鐘，下訂單須要2分鐘，接下來要作什麼？能把這些做爲一個性能缺陷提起麼？顯然是不能夠的，這只是經過你的壓力測試場景產生的一個現象，多是測試腳本有問題、也多是測試環境有問題。做爲一個性能測試人員，須要儘可能深刻的定位到問題產生的緣由。就像這個響應慢，只是一個表面現象，慢在哪？是中間件仍是數據庫？一些簡單的測試方法就能夠進行判斷，如在頁面上進行一些數據庫無關的操做，若是依然比較慢，說明在中間件上壓力就已經比較大了。還能夠部署另外一套中間件測試環境，鏈接以前相同的數據庫，在壓力測試出現問題的同時，手動訪問新部署的應用（只有一個用戶），若是一樣很慢，那說明慢在了數據庫端的處理上。還能夠經過日誌的方式更準確的進行判斷，如應用日誌和數據庫SQL執行日誌。總之方法是多種多樣的，但目的只有一個，就是不斷的排除無關部分、縮小問題範圍。
定位到了中間件和數據庫之一，而後又該怎麼辦？此時恐怕就須要一些相關方面的專業知識了，但其實最多見的仍是那些。中間件相關的通常是線程池、JVM、數據庫鏈接池等，數據庫相關的有鎖、緩存、IO（通常就是SQL語句的問題）等。要進行全面的監控和分析，再作一些合理的調優並重複測試。
問題定位到什麼程度才行？我認爲是要讓人看了知道改哪就能夠了。好比提一個「這個SQL語句進行了大量的物理IO，性能很差」，這就不是個好問題，物理IO是什麼？怎麼改？若是這麼說就好多了「這個SQL語句沒有使用索引，致使了全表掃描，進行了大量的物理IO，性能很差。若是要避免全表掃描，須要調整SQL語句或者添加XX索引」，這纔是定位問題。
固然了，上面只是一個很是簡陋的舉例，真實的性能測試要比這複雜的多。
總的來講，我認爲，性能測試的難度主要不在技術手段上，互聯網時代技術都是共享的，要善於去搜索利用他人的成果。即便本身搞不定，團隊內必定還有專業的開發工程師、數據庫管理員、系統管理員能夠幫你搞定。真正的難點在於，你要想出來如何去測是有效的、有保障的，這纔是測試工程師最重要的能力。
仍是那個觀點，思想纔是根本。