效能測試的目的是檢查軟體的平均響應時間或者吞吐量是否符合指定的標準。

例如，當測試前已經獲知線上人數為10000，可以設定效能測試的目的是檢測軟體典型交易的平均響應時間是否符合小於5秒的指標值。

例如，當測試前不知道線上人數是多少，但是已經獲知該軟體在一定的時間週期內（t）必須處理N筆交易，可以設定效能測試的目的是檢測軟體典型交易的吞吐量是否符合大於25筆交易/秒的指標值。

但是，在第二種情況出現時，還應該考慮若軟體的吞吐量符合指定的指標值時，軟體典型交易的平均響應時間是否符合小於5秒的指標值。

為什麼呢？

我們可以利用“門”的概念來理解這裡面的偏差！

首先，我們假設如下的情況：

此時，這扇門的吞吐量為1人/秒。5個人通過這扇門的平均響應時間為（1+2+3+4+5）/5=3秒。

如何才能提高人的通過效率呢？即，如何才能提高門的吞吐量呢？

有兩種方法：

（1）減小通過門的時間；

（2）增加門的數量

例如，

（1）將一個人通過門的時間減小為0.5秒，門的吞吐量變成了2人/秒；

（2）增加一個門，門的吞吐量也變成了2人/秒

結果是：

（1）5個人通過改善通過時間的門的平均響應時間為（0.5+1+1.5+2+2.5）/5＝1.5秒；

（2）5個人通過兩扇門的平均響應時間為（1+1+2+2+3）/5＝1.8秒

此時，你可以發現，軟體開發員改進軟體處理併發交易請求的方法有兩個，第一種是提高單個請求的處理速率，第二種是增加處理請求的執行緒的數量；或者是兩種方法的組合。但是，不同方法的使用並不代表吞吐量得到了提高，而同時軟體典型交易的平均響應時間也獲得了相同值的改善。

因此，在效能測試以吞吐量為檢測指標的時候，不光要評估吞吐量是否符合了效能指標的要求，同時也必須考慮響應時間是否符合效能指標的要求。

假設，在測試前，規定了吞吐量為大於25筆交易/秒，平均響應時間為小於5秒，在測試後，若實際吞吐量等於27筆交易/秒，不能僅憑這個27筆交易/秒就確定該軟體的效能符合要求了，還要看平均響應時間是否符合要求。這時的平均響應時間可能大於5秒。