第一，後端效能測試
後端效能測試，是通過效能測試工具模擬大量的併發使用者請求，然後獲取系統效能的各項指
標，並且驗證各項指標是否符合預期的效能需求的測試手段。
這裡的效能指標，除了包括併發使用者數、響應時間和系統吞吐量外，還應該包括各類資源的
使用率，比如系統級別的 cpu 佔用率、記憶體使用率、磁碟 i/o 和網路 i/o 等，再比如應用
級別以及 jvm 級別的各類資源使用率指標等
第二，前端效能測試
通常來講，前端效能關注的是瀏覽器端的頁面渲染時間、資源載入順序、請求數量、前端緩
存使用情況、資源壓縮等內容，希望藉此找到頁面載入過程中比較耗時的操作和資源，然後
進行有針對性的優化，最終達到優化終端使用者在瀏覽器端使用體驗的目的。
第三，**級效能測試
**級效能測試，是指在單元測試階段就對**的時間效能和空間效能進行必要的測試和評
估，以防止底層**的效率問題在專案後期才被發現的尷尬。
操作的響應時間很長，然後你要花費很多時間去逐級排查，最後卻發現罪魁禍首是**中某
個實現低效的底層演算法。這種自上而下的逐級排查定位的方法，效率通常都很低，代價也很
高。 所以，我們就需要在專案早期，對一些關鍵演算法進行**級別的效能測試，以防止此類在代
碼層面就可以被發現的效能問題，遺留到最後的系統效能測試階段才被發現。
但是，從實際執行的層面來講，**級效能測試並不存在嚴格意義上的測試工具，通常的做
法是：改造現有的單元測試框架。
第四，壓力測試
壓力測試，通常指的是後端壓力測試
，一般採用後端效能測試的方法，不斷對系統施加壓
力，並驗證系統化處於或長期處於臨界飽和階段的穩定性以及效能指標，並試圖找到系統處
於臨界狀態時的主要瓶頸點。所以，壓力測試往往被用於系統容量規劃的測試。
還有些情況，在執行壓力測試時，我們還會故意在臨界飽和狀態的基礎上繼續施加壓力，直
至系統完全癱瘓，觀察這個期間系統的行為；然後，逐漸減小壓力，觀察癱瘓的系統是否可
以自癒第五，配置測試
配置測試，主要用於觀察系統在不同配置下的效能表現，通常使用後端效能測試的方法：
1. 通過效能基準測試（performance benchmark）建立效能基線（performance
baseline）；
2. 在此基礎上，調整配置；
3. 基於同樣的效能基準測試，觀察不同配置條件下系統效能的差異，根本目的是要找到特
定壓力模式下的最佳配置。
這裡需要注意的是，「配置」是乙個廣義配置的概念，包含了以下多個層面的配置：
宿主作業系統的配置；
應用伺服器的配置；
資料庫的配置；
jvm 的配置；
網路環境的配置；
併發測試，指的是在同一時間，同時呼叫後端服務，期間觀察被呼叫服務在併發情況下的行
為表現，旨在發現諸如資源競爭、資源死鎖之類的問題。
談到併發測試，我就不得不和你說說「集合點併發」的概念了，它源於 hp 的
loadrunner，目前已經被廣泛使用了。那，到底什麼是「集合點併發」呢？
假設我們希望後端呼叫的併發數是 100，如果直接設定 100 個併發使用者是無法達到這個目
標的，因為這 100 個併發使用者會各自執行各自的操作，你無法控制某乙個確定的時間點上
後端服務的併發數量。
為了達到準確控制後端服務併發數的目的，我們需要讓某些併發使用者到達該集合點時，先處
於等待狀態，直到參與該集合的全部併發使用者都到達時，再一起向後端服務發起請求。簡單
地說，就是先到的併發使用者要等著，等所有併發使用者都到了以後，再集中向後端服務發起請
求。 比如，當要求的集合點併發數是 100 時，那麼前 99 個到達的使用者都會等在那裡，直到第
100 個使用者到了，才集中向後端服務發起請求。當然，實際達到伺服器的併發請求數，還
會因為網路延遲等原因小於 100。
所以，在實際專案中，我建議在要求的併發數上進行適當放大，比如要求的併發數是
100，那我們集合點併發數可以設定為 120。
第七，可靠性測試
可靠性測試，是驗證系統在常規負載模式下長期執行的穩定性。
雖然可靠性測試在不同公司的叫法不同，但其本質就是通過長時間模擬真實的系統負載來發
現系統潛在的記憶體洩漏、鏈結池**等問題
。 由於真實環境下的實際負載，會有高峰和低谷的交替變化（比如，對於企業級應用，白天通
常是高峰時段，而晚上則是低峰時段），所以為了盡可能地模擬出真實的負載情況，我們會
每 12 小時模擬乙個高峰負載，兩個高峰負載中間會模擬乙個低峰負載，依次迴圈 3-7 天，
形成乙個類似於「波浪形」的系統測試負載曲線。
然後，用這個「波浪形」的測試負載模擬真實的系統負載，完成可靠性測試。同樣地，可靠
性測試也會持續 3-7 天。
聊完了常用效能測試方法的種類後，我們再來簡單看一下效能測試的四大應用領域，以及每
個應用領域都會使用哪些效能測試方法。
參考：極客時間中《軟體測試52講》
軟體測試學習筆記（六） 測試模型 測試分類
按是否檢視源 按是否執行 其他測試 是否自動化 單元測試 又稱為模組測試，針對軟體設計中的最小單位 程式模組進行測試工作。單元測試需要從程式的內部結構出發測試設計用例。比如乙個小的按鍵，乙個下拉框。整合測試 又叫組裝測試，在單元測試的基礎之上，將所有程式模組進行有序的 遞增的測試。終點測試不同模組的...
測試的分類
1.按開發階段分 2.按測試實施組織分 3.按測試執行方式分 4.按是否檢視 分 5.按是否手工執行 6.按測試物件劃分 7.按測試地域劃分單元測試 測 概念 單元測試是對軟體組成單元進行測試 目的 檢驗軟體基本組成單位的正確性 測試物件 最小模組 測試人員 白盒測試工程師或開發工程師 測試方法 白...
測試的分類
預期結果和實際結果做對比 軟體測試的分類 分為 方法 方向 階段 物件 狀態 其他 方法 黑盒測試 白盒測試 灰盒測試 方向 功能測試 效能測試 安全測試 功能測試 效能測試 軟體的響應時間 測試在不同的情況下，軟體的響應時間 情況分為 假設軟體最慢的響應時間是10s，需要多少人一起使用軟體才會造成...