首先從最核心的指標開始介紹：

1.吞吐量（平均吞吐量）

之前在

一文裡也提過了。吞吐量表示待測應用對業務的支援量，以TPS或QPS為單位，表示每秒鐘能處理的請求數。

有一個很模糊的概念“併發數”，似乎和吞吐量有關：

比如經理說，這個系統要支援2000併發，那麼這個要怎麼理解，併發數和吞吐量是同一個東西嗎。

不一定。

併發數可能是：

2.（總）併發使用者數

同一時間在系統上的使用者數量，這些使用者可能分佈在不同的功能模組或頁面上。

也可能是：

3.（總）併發請求數

同一時間在系統上的使用者同時向伺服器做出的請求數量，這些請求也可能分佈在不同的功能呢模組或頁面上。

所以這個時候就問清楚經理，是 2000併發使用者數，還是2000併發請求數。後續可以根據不同的回答來設計不同的測試場景。

再說一下為什麼這裡提到了測試場景。

因為在測試一個系統的效能或者說吞吐量時，離不開具體業務場景。在解釋為什麼之前，先看這個：

4。

平均響應時間

一些請求從發起到收到服務端響應所需的時間的平均數。

說下為什麼離不開具體業務場景，請看公式1：

一段時間內的平均吞吐量=這段時間內的總併發請求數/這段時間的平均響應時間

比如獲取一個靜態圖片，響應時間就短，那麼根據公式1，單位時間內的請求的平均響應時間越小，其平均吞吐量就越高。而如果是請求一個需要服務端做一定計算的資源，那麼響應時間就長。自然按照公式1，就會發現吞吐量降低了。

也就是說響應時間和吞吐量成反比，因此討論系統的效能時離不開響應時間，也就離不開具體的業務場景。

在實際測試工作中，我們會採用逐步加壓的方式，一步一步提高虛擬的總併發使用者數，並觀察其響應時間變化，因為響應時間和吞吐量成反比，那麼我們觀察響應時間的時候其實也就是在觀察吞吐量的變化。

壓力較低時，吞吐量和虛擬的總併發使用者數可能成正比。當用戶數逐步增加上來之後，可能吞吐量的增加速度會逐漸下降。這是因為壓力上升後，系統處理請求能力下降，平均響應時間加長。直至某一個點開始，吞吐量不再上升，反而下降。這就是系統處理能力的瓶頸了。

而在這個吞吐量上升的過程中，我們會觀察到還有一個數字有可能上升，那就是：

5.錯誤率

一段時間內出錯的請求在總請求數中的佔比。

對於錯誤率的容忍程度，取決於不同的系統需求。那麼一般錯誤又分情況：

5。1有返回值的錯誤，這裡又要分是HTTP請求之類的錯誤，還是業務上的錯誤。這些可能出現錯誤的值需要在測試腳本里做校驗，或者說斷言。

5。2 沒有返回值的錯誤，或者說就是超時。

有些請求會超時，那麼不但會導致錯誤率的出現還會影響平均響應時間。

因為：平均響應時間=所有請求所需總時間/所有請求總數量

而個別超時的請求會嚴重增加請求所需總時間。因此，對於平均響應時間就會有更多細分，比如

6.90%平均響應時間

從計算平均響應時間的那些請求裡去掉最慢的10%之後重新計算平均響應時間。

顯然，使用90%平均響應時間，因為去掉了出錯超時的那些請求，使得得到的資料更加接近真實值。

最後再介紹一個指標

7.平均傳輸頻寬

這個指標用於計算服務端的資料傳輸量。單位是KIB/S，1k位元組也就是1024位元組。KIB/S就是每秒鐘傳輸多少k位元組。這個指標和我們上網的頻寬是同一個指標。

瞭解了這些指標，那麼就能大致上看懂一份效能測試報告了，應該也更能理解效能測試的設計方法了。當然還有一些服務端的資源使用指標等這次沒講。

首發於公眾號：測試進階（test_up）