軟體效能測試過程詳解與案例分析（段念 編著） 學習筆記二
1.響應時間
對請求做出響應所需用的時間；
①應用系統從發出請求開始到客戶端接收到響應所消耗的時間；
②應用系統從請求發出開始到客戶端接收到最後乙個位元組資料所消耗的時間；（一般使用此種方式描述響應時間）
③頁面響應時間=網路傳輸時間+應用延遲時間
④對乙個電子商務**來說，在美國和歐洲，乙個普遍被接受的響應時間標準為2/5/10秒，也就是說，在2秒之內給客戶響應被認為是「非常有吸引力的」，在5秒之內響應客戶被認為是「比較不錯的」，而10秒時客戶能接受的響應的上限；
⑤在進行測試時，「合理的響應時間」取決於實際的使用者需求，而不能依據測試人員自己的設想來決定；如，稅務報賬系統，該系統的使用者每月使用一次該系統，一次花費2小時以上進行資料的錄入，當使用者單擊「提交」按鈕後，即使系統在20分鐘後才給出「處理成功」的訊息，使用者仍然不會認為該系統的響應時間不能接受；
2.併發使用者數
①業務併發使用者數
對服務端來說，每個使用者和伺服器端的互動都是離散的。如果僅考慮乙個單獨的使用者對系統的使用，過程大致如下：使用者每隔一段時間向伺服器傳送乙個請求或是命令，服務端按照使用者的請求執行某些操作，然後將結果返回給使用者。
從使用者的角度來說，在乙個相當長的時間段內（例如1天），都會有基本固定數量的使用者使用該系統，雖然每個使用者的行為不同，但從業務的角度來說，如果所有這些使用者的操作都沒有遇到效能障礙，則可以說該系統能夠承受該數量的併發使用者訪問。
②如果考慮整個系統執行過程中伺服器所承受的壓力：在該系統的執行過程中，把整個執行過程劃分為離散的時間點，在每個點上，都有乙個「同時向服務端傳送請求的客戶數」，這個就是所稱的服務端承受的最大併發訪問數。如果能找到執行過程中可能出現的最大可能的服務端承受的最大併發訪問數，則在該使用者數下，伺服器承受的壓力最大，資源承受的壓力也最大，在這種狀態下， 可以考慮通過併發測試（concurrency testing）發現系統中存在的併發引用的資源爭用等問題。
根據我們對業務併發使用者數的定義，這500就是整個系統使用時最大的業務併發使用者數。當然，500這個數值只是表明在最高峰時刻有500個使用者登入了系統，並不表示實際伺服器承受的壓力。因為伺服器承受的壓力還與具體的使用者訪問模式有關。例如，在這500個「同時使用系統」的使用者中，考察某乙個時間點，在這個時間點上，假設其中40%的使用者在饒有興致的看系統公告，20%的使用者在填寫複雜的**，20%的使用者在發呆，剩下的20%使用者在不停地從乙個頁面跳轉到另乙個頁面—在這種場景下，可以說，只有20%的使用者真正對伺服器構成了壓力。因此，從上面的例子可以看出，伺服器實際承受的壓力不只取決於業務併發使用者數，還取決於使用者的業務場景。
④如何確定乙個系統的併發使用者數？
a.以更細的時間粒度進行考察：例如，可以設計1個小時為考察時間的粒度，對乙個典型的oa系統，將一天的上班時間劃分為8個區間，這樣可以解決業務操作存在的時間集中性的問題；
b.考慮典型的業務模式：不同的應用有不同的業務模式，例如，乙個內部系統一般在上班開始後的30分鐘至1個小時集中出現使用者的登入；乙個賬務系統在每月的結賬日前幾天會比較繁忙；乙個門戶**在重大訊息發布的前後會有訪問高峰；乙個旅遊的**在節假日前夕會有大量使用者的訪問。。。因此，在考慮計算併發使用者數時，可以結合應用的業務模式，多考慮一些可能發生的場景，基於這些場景進行估算；
⑤c=n/10，c^=rxc
用每天訪問系統使用者數的10%作為平均的併發使用者數，併發使用者數的最大值由併發使用者數乘上乙個調整因子r得到，r的取值一般為2-3。
⑥日誌分析
「日誌分析」方法是指通過對應用伺服器的日誌進行分析，從而了解系統使用者的使用狀態，從日誌中計算出「伺服器承受的最大併發使用者訪問數」資料，這種方式得到的資料準確度和可信度都比較高，對於internet應用等無法估計使用者數量和使用者行為模式的應用，這種方式最為可信；
「日誌分析」的方法需要日誌分析工具的支援，如awstats開源工具。
3.吞吐量
①單位時間內系統處理的客戶請求的數量，直接體現軟體系統的效能承載能力。吞吐量用請求數/秒或是頁面數/秒來衡量，從網路的角度來說，也可以用位元組數/秒來考察網路流量。
②吞吐量指標可以在兩個方面發揮作用：
a.可以協助設計效能測試場景，以及衡量效能測試場景是否達到了預期的設計目標；在設計效能測試場景時，吞吐量可被用於協助設計效能測試場景，根據估算的吞吐量資料，可以對應到測試場景的事務發生頻率、事務發生次數等；另外，在測試完成後，根據實際的吞吐量可以衡量測試是否達到了預期的目標。
b.用於協助分析效能瓶頸：吞吐量的限制是效能瓶頸的一種重要表現形式；例如，rbi（rapid bottleneck identify）方法就主要通過吞吐量測試發現效能瓶頸。
③以不同方式表達的吞吐量可以說明不同層次的問題。例如，以位元組數/秒方式表示的吞吐量主要受網路基礎設施、伺服器架構、應用伺服器制約；以單擊數/秒表示的吞吐量主要受應用伺服器和應用**的制約。
④吞吐量和併發使用者數之間的關係：
在沒有遇到效能瓶頸的時候，吞吐量的公式 f=nvu x r/t
f表示吞吐量，nuv表示vu（虛擬使用者）的個數，r表示每個vu發出的請求數量，t表示效能測試所用的時間；
4.效能計數器
①是描述伺服器或作業系統效能的一些資料指標；
②計數器在效能測試中發揮著「監控和分析」的關鍵作用，尤其是在分析系統的可擴充套件性、進行效能瓶頸的定位時，對計數器取值的分析非常關鍵；
③資源利用率：系統各種資源的使用狀況，一般用「資源的實際使用/總的資源可用量」形成資源利用率的資料，用以進行各種資源使用的比較；
5.思考時間
思考時間（think time），也被稱為「休眠時間」，從業務的角度來說，這個時間指的是使用者在進行操作時，每個請求之間的間隔時間；
軟體效能中幾個主要的術語
一 響應時間 響應時間是 對請求做出響應所需要的時間 之前說過，它既有客觀的成分，也有主觀的成分，一般將使用者所感受到的軟體效能 響應時間 分為呈現時間和伺服器端響應時間兩個部分。對於乙個web應用，呈現時間就是瀏覽器接受到響應資料後呈現和執行頁面上指令碼所消耗的時間 而伺服器端響應時間指應用系統從...
軟體效能測試的幾個主要術語
二 軟體效能測試的幾個主要術語 響應時間 n1 n2 n3 n4 a1 a3 a2 2 併發使用者數的計算公式 系統使用者數 系統額定的使用者數量，如乙個oa系統，可能使用該系統的使用者總數是5000個，那麼這個數量，就是系統使用者數。平均併發使用者數的計算 c nl t 其中c是平均的併發使用者數...
效能測試用到的主要術語
l 響應時間 對請求作出響應所需的時間。它是作為使用者視角的軟體效能的主要體現。響應時間分為2部分 呈現時間 系統響應時間。呈現時間取決於資料在被客戶端收到響應資料後呈現頁面所消耗的時間 系統響應時間指應用系統從請求發出開始到客戶端接收到資料所消耗的時間。一般主要關心 系統響應時間 圖略 註明 n1...