性能測試的目的是檢查軟件的平均響應時間或者吞吐量是否符合指定的標準。
例如,當測試前已經獲知在線人數為10000,可以設定性能測試的目的是檢測軟件典型交易的平均響應時間是否符合小于5秒的指標值。
例如,當測試前不知道在線人數是多少,但是已經獲知該軟件在一定的時間周期內(t)必須處理N筆交易,可以設定性能測試的目的是檢測軟件典型交易的吞吐量是否符合大于25筆交易/秒的指標值。
但是,在第二種情況出現時,還應該考慮若軟件的吞吐量符合指定的指標值時,軟件典型交易的平均響應時間是否符合小于5秒的指標值。
為什么呢?
我們可以利用“門”的概念來理解這里面的偏差!
首先,我們假設如下的情況:
共有5個人;有1扇門;一個人通過這扇門需要花費1秒的時間;此時,這扇門的吞吐量為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秒。
而,如果測試前,規定了在線人數為10000,平均響應時間為小于5秒,在測試后,僅憑實際平均響應時間等于4秒就可以判斷該軟件的性能符合要求。
文章來源于領測軟件測試網 http://www.kjueaiud.com/