1.性能測試、壓力測試、負載測試的區別

性能測試

負載測試、容量測試、壓力測試（強度測試）都屬於性能測試，性能測試是指在給定條件基準的前提下能達到的運行程度，測試軟件在系統中的運行性能，度量系統與預定義目標的差距。 

負載測試（關注用戶數量how much和性能指標） 

負載測試是模擬在超負荷環境中運行，通過不斷加載（如逐漸增加模擬用戶的數量）或其它加載方式來觀察不同負載下系統的響應時間和數據吞吐量、系統佔用的資源（如CPU、內存）等，以檢驗系統的行爲和特性，以發現系統可能存在的性能瓶頸、內存泄漏、不能實時同步等問題。負載測試更多地體現了一種方法或一種技術。

 
壓力測試，又叫強度測試（高壓力，看系統如何崩潰，準備預案）

壓力測試（強度測試）：壓力測試是在強負載（大數據量、大量併發用戶等）下的測試，查看應用系統在峯值使用情況下操作行爲，從而有效地發現系統的某項功能隱患、系統是否具有良好的容錯能力和可恢復能力。壓力測試分爲高負載下的長時間（如24小時以上）的穩定性壓力測試和極限負載情況下導致系統崩潰的破壞性壓力測試。 

容量測試（最大支撐的數量how much）

容量測試目的是通過測試預先分析出反映軟件系統應用特徵的某項指標的極限值（如最大併發用戶數、數據庫記錄數等），系統在其極限值狀態下沒有出現任何軟件故障或還能保持主要功能正常運行。容量測試是面向數據的，並且它的目的是顯示系統可以處理目標內確定的數據容量。
　　例：

性能測試：一個祕書對一個老闆。祕書是否能有條不紊地安排好老闆的日常工作、行程。

負載測試：一個祕書對一個部門。除了老闆的工作行程，還要幫部門裏的其他同事幹很多雜活。沒有閒着的時候。

壓力測試：一個祕書對多個部門。幾個部門的老闆、同事的所有等辦事情都交給祕書來做，同時不斷的有新的部門的老闆和同事加入到這個行列。就看祕書到什麼程度崩潰......

容量測試：一個祕書對多個部門。在堅持5天不崩潰的情況下，祕書最多能對接多少個部門。

2.壓測完整過程介紹

完整的壓力測試步驟

http://www.noobyard.com/article/p-fhmjjjko-ms.html

 

 

3.壓力測試常用性能指標介紹

壓力測試常用性能指標介紹

通常情況下，性能測試監控指標主要分爲：硬件資源指標和系統指標。

 

3.1資源指標

CPU使用率：指用戶進程與系統進程消耗的CPU時間百分比，長時間情況下，一般可接受上限不超過85%。

內存利用率：內存利用率=（1-空閒內存/總內存大小）*100%，一般至少有10%可用內存，內存使用率可接受上限爲85%。

磁盤I/O：磁盤主要用於存取數據，因此當說到IO操作的時候，就會存在兩種相對應的操作，存數據的時候對應的是寫IO操作，取數據的時候對應的是是讀IO操作，一般使用% Disk Time（磁盤用於讀寫操作所佔用的時間百分比）度量磁盤讀寫性能。

 

3.2系統指標

併發用戶數：某一物理時刻同時向系統提交請求的用戶數。

在線用戶數：某段時間內訪問系統的用戶數，這些用戶並不一定同時向系統提交請求。

平均響應時間：系統處理事務的響應時間的平均值。事務的響應時間是從客戶端提交訪問請求到客戶端接收到服務器響應所消耗的時間。對於系統快速響應類頁面，一般響應時間爲3秒左右。

 最大響應時間（Max Response Time） 指用戶發出請求或者指令到系統做出反應（響應）的最大時間。

最少響應時間（Mininum ResponseTime） 指用戶發出請求或者指令到系統做出反應（響應）的最少時間。

90%響應時間（90% Response Time） 是指所有用戶的響應時間進行排序，第90%的響應時間。

超時錯誤率：主要指事務由於超時或系統內部其它錯誤導致失敗佔總事務的比率。

每秒查詢率（Queries Per Second，簡稱QPS）：是一臺服務器每秒能夠相應的查詢次數，是對一個特定的查詢服務器在規定時間內所處理流量多少的衡量標準。QPS =併發量/平均響應時間。

一個典型的上班簽到系統，早上8點上班。7點半到8點這30分鐘的時間裏用戶會登錄簽到系統進行簽到。公司員工爲1000人，平均每一個員上登錄簽到系統的時長爲5分鐘。能夠用以下的方法計算：

QPS = 1000/(30*60) 事務/秒

平均響應時間爲 = 5*60  秒

併發數= QPS*平均響應時間 = 1000/(30*60) *(5*60)=166.7

每秒處理事務數（TransactionsPerSecond，簡稱TPS）：是軟件測試結果的測量單位。一個事務是指一個客戶機向服務器發送請求然後服務器做出反應的過程。客戶機在發送請求時開始計時，收到服務器響應後結束計時，以此來計算使用的時間和完成的事務個數。例如，用戶每分鐘執行6個事務，TPS爲6 / 60s = 0.10 TPS。同時我們會知道事務的響應時間(或節拍)，以此例，60秒完成6個事務也同時代表每個事務的響應時間或節拍爲10秒。

TPS包括了從請求服務器->服務器處理->返回給用戶這三個過程，每秒能夠完成N個這三個過程，TPS也就是N。

QPS基本類似於TPS，但是不同的是，對於一個頁面的一次訪問，形成一個TPS；但一次頁面請求，可能產生多次對服務器的請求，服務器對這些請求，就可計入「QPS」之中。

例如：訪問一個頁面會請求服務器3次，一次訪問，產生一個「T」，產生3個「Q」 

但是，如今的項目基本上都是前後端分離的，性能也分爲前端性能和後端性能，通常默認是後端性能，即服務端性能，也就是對服務端接口做壓測

如果是對一個接口（單場景）壓測，且這個接口內部不會再去請求其它接口，那麼TPS=QPS，否則，TPS≠QPS

如果是對多個接口（混合場景）壓測，不加事務控制器，jmeter會統計每個接口的TPS，而混合場景是要測試這個場景的TPS，顯然這樣得不到混合場景的TPS，所以，要加了事物控制器，結果纔是整個場景的TPS。

以上指標可以在對應的監聽器裏獲取：

[email protected] - PerfMon Metrics Collector：CPU使用率、內存利用率、磁盤I/O；

聚合報告：平均響應時間、 最大響應時間 、最少響應時間 、90%響應時間、每秒處理事務數（TransactionsPerSecond，簡稱TPS）、超時錯誤率。