七種性能測試方法

根據在實際項目中的實踐經驗，我把經常使用的性能測試方法分爲七大類：後端性能測試（Back-end Performance Test）、前端性能測試（Front-end Performance Test ）、代碼級性能測試（Code-level Performance Test）、壓力測試（Load/Stress Test）、配置測試（Confguration Test）、併發測試 （Concurrence Test），以及可靠性測試（Reliability Test）。接下來，我將詳細爲你介紹每一種測試 方法。

第一，後端性能測試
其實，你平時聽到的性能測試，大多數狀況下指的是後端性能測試，也就是服務器端性能測試。
後端性能測試，是經過性能測試工具模擬大量的併發用戶請求，而後獲取系統性能的各項指標，而且驗 證各項指標是否符合預期的性能需求的測試手段。
這裏的性能指標，除了包括併發用戶數、響應時間和系統吞吐量外，還應該包括各種資源的使用率，比 如系統級別的CPU佔用率、內存使用率、磁盤I/O和網絡I/O等，再好比應用級別以及JVM級別的各種資 源使用率指標等。
因爲須要模擬的併發用戶數，一般在「幾百」到「幾百萬」的數量級，因此你選擇的性能測試工具，必定不 是基於GUI的，而是要採用基於協議的模擬方式，也就是去模擬用戶在GUI操做的過程當中實際向後端服 務發起的請求。
只有這樣才能模擬很高的併發用戶數，儘量地模擬出真實的使用場景，這也是如今全部後端性能測試 工具所採用的方法。
根據應用領域的不一樣，後端性能測試的場景設計主要包括如下兩種方式：
基於性能需求目標的測試驗證； 探索系統的容量，並驗證系統容量的可擴展性
隨着系統併發用戶數的增加，系統處理能力達到過飽和狀態。此時，若是繼續增長併發用 戶數，最終全部用戶的響應時間會變得無限長。相應地，系統的總體吞吐量會降爲零，系 統處於被壓垮的狀態。咱們每每把這個階段稱爲「過飽和區間」。

第二，前端性能測試
前端性能測試並無一個嚴格的定義和標準。
一般來說，前端性能關注的是瀏覽器端的頁面渲染時間、資源加載順序、請求數量、前端緩存使用情 況、資源壓縮等內容，但願藉此找到頁面加載過程當中比較耗時的操做和資源，而後進行有針對性的優 化，最終達到優化終端用戶在瀏覽器端使用體驗的目的。
目前，業界廣泛採用的前端測試方法，是雅虎（Yahoo）前端團隊總結的7大類35條前端優化規則，你 能夠經過雅虎網站查看這些規則，以及對各規則的詳細解讀。
我在這裏列出了其中幾個最典型也是最重要的規則，來幫助你理解前端性能測試優化的關注範圍。
減小http請求次數：http請求數量越多，執行過程耗時就越長，因此能夠採用合併多個圖片到一個 圖片文件的方法來減小http請求次數，也能夠採用將多個腳本文件合併成單一文件的方式減小http請 求次數； 減小DNS查詢次數：DNS的做用是將URL轉化爲實際服務器主機IP地址，實現原理是分級查找，查 找過程須要花費20~100ms的時間，因此一方面咱們要加快單次查找的時間，另外一方面也要減小一個 頁面中資源使用了多個不一樣域的狀況； 避免頁面跳轉：頁面跳轉至關於又打開一個新的頁面，耗費的時間就會比較長，因此要儘可能避免使 用頁面跳轉； 使用內容分發網絡（CDN）：使用CDN至關於對靜態內容作了緩存，並把緩存內容放在網絡供應商 （ISP）的機房，用戶根據就近原則到ISP機房獲取這些被緩存了的靜態資源，所以能夠大幅提升性 能； Gzip壓縮傳輸文件：壓縮能夠幫助減少傳輸文件的大小，進而能夠從網絡傳輸時間的層面來減小響 應時間；

第三，代碼級性能測試
代碼級性能測試，是指在單元測試階段就對代碼的時間性能和空間性能進行必要的測試和評估，以防止 底層代碼的效率問題在項目後期才被發現的尷尬。
若是你從事過性能測試相關的工做，必定遇到過這樣的場景：系統級別的性能測試發現一個操做的響應 時間很長，而後你要花費不少時間去逐級排查，最後卻發現罪魁禍首是代碼中某個實現低效的底層算 法。這種自上而下的逐級排查定位的方法，效率一般都很低，代價也很高。
因此，咱們就須要在項目早期，對一些關鍵算法進行代碼級別的性能測試，以防止此類在代碼層面就可 以被發現的性能問題，遺留到最後的系統性能測試階段才被發現。
可是，從實際執行的層面來說，代碼級性能測試並不存在嚴格意義上的測試工具，一般的作法是：改造 現有的單元測試框架。
最常使用的改造方法是：
1. 將本來只會執行一次的單元測試用例連續執行n次，這個n的取值範圍一般是2000~5000；
2. 統計執行n次的平均時間。若是這個平均時間比較長（也就是單次函數調用時間比較長）的話，比 如已經達到了秒級，那麼一般狀況下這個被測函數的實現邏輯必定須要優化。
這裏之因此採用執行n次的方式，是由於函數執行時間每每是毫秒級的，單次執行的偏差會比較大，所 以採用屢次執行取平均值的作法。

第四，壓力測試
壓力測試，一般指的是後端壓力測試，通常採用後端性能測試的方法，不斷對系統施加壓力，並驗證系 統化處於或長期處於臨界飽和階段的穩定性以及性能指標，並試圖找到系統處於臨界狀態時的主要瓶頸 點。因此，壓力測試每每被用於系統容量規劃的測試。
還有些狀況，在執行壓力測試時，咱們還會故意在臨界飽和狀態的基礎上繼續施加壓力，直至系統徹底 癱瘓，觀察這個期間系統的行爲；而後，逐漸減少壓力，觀察癱瘓的系統是否能夠自愈。

第五，配置測試
配置測試，主要用於觀察系統在不一樣配置下的性能表現，一般使用後端性能測試的方法：
1. 經過性能基準測試（Performance Benchmark）創建性能基線（Performance Baseline）；
2. 在此基礎上，調整配置；
3. 基於一樣的性能基準測試，觀察不一樣配置條件下系統性能的差別，根本目的是要找到特定壓力模式 下的最佳配置。
這裏須要注意的是，「配置」是一個廣義配置的概念，包含了如下多個層面的配置：
宿主操做系統的配置； 應用服務器的配置； 數據庫的配置； JVM的配置； 網絡環境的配置； …

第六，併發測試
併發測試，指的是在同一時間，同時調用後端服務，期間觀察被調用服務在併發狀況下的行爲表現，旨 在發現諸如資源競爭、資源死鎖之類的問題。
談到併發測試，我就不得不和你說說「集合點併發」的概念了，它源於HP的LoadRunner，目前已經被廣 泛使用了。那，到底什麼是「集合點併發」呢？
假設咱們但願後端調用的併發數是100，若是直接設定100個併發用戶是沒法達到這個目標的，由於 這100個併發用戶會各自執行各自的操做，你沒法控制某一個肯定的時間點上後端服務的併發數量。
爲了達到準確控制後端服務併發數的目的，咱們須要讓某些併發用戶到達該集合點時，先處於等待狀 態，直到參與該集合的所有併發用戶都到達時，再一塊兒向後端服務發起請求。簡單地說，就是先到的並 發用戶要等着，等全部併發用戶都到了之後，再集中向後端服務發起請求。
好比，當要求的集合點併發數是100時，那麼前99個到達的用戶都會等在那裏，直到第100個用戶到了， 才集中向後端服務發起請求。固然，實際達到服務器的併發請求數，還會由於網絡延遲等緣由小 於100。
因此，在實際項目中，我建議在要求的併發數上進行適當放大，好比要求的併發數是100，那咱們集合 點併發數能夠設置爲120。

第七，可靠性測試
可靠性測試，是驗證系統在常規負載模式下長期運行的穩定性。
雖然可靠性測試在不一樣公司的叫法不一樣，但其本質就是經過長時間模擬真實的系統負載來發現系統潛在 的內存泄漏、連接池回收等問題。
因爲真實環境下的實際負載，會有高峯和低谷的交替變化（好比，對於企業級應用，白天一般是高峯時 段，而晚上則是低峯時段），因此爲了儘量地模擬出真實的負載狀況，咱們會每12小時模擬一個高峯 負載，兩個高峯負載中間會模擬一個低峯負載，依次循環3-7天，造成一個相似於「波浪形」的系統測試 負載曲線。
而後，用這個「波浪形」的測試負載模擬真實的系統負載，完成可靠性測試。一樣地，可靠性測試也會持 續3-7天。