軟體測試入門隨筆——軟體測試基礎知識（六）

標籤：cpu   處理常式   實用   負載   觀察   事先   預先處理   多少   思考   

初步接觸效能測試啦！！學習書籍《loadrunner 效能測試巧匠訓練營》

• 針對不同系統，效能測試有不同的關注點

     C/S架構的產品更關注系統資源使用方式、資料庫效能以及啟動並執行配置要求等等。如：記憶體、使用者串連數、資料庫死結、資料庫cache命中率、啟動並執行最低配置等等。

　  B/S架構的產品關注web伺服器的相關指標。如：每秒點擊率、輸送量、嘗試串連數、事務成功率等等。B/S架構的較為複雜。

• 效能測試的目的（know how fast & how much）

　　1、評估當前系統

　　2、尋找瓶頸，最佳化系統（分析→定位→調優）

　　3、預測未來效能（要考慮使用者數和業務量增加時系統如何及時應對和調整等等）

• 效能測試的術語和指標

　　1、並發數

　　　　首先明確3個概念：系統使用者數、線上使用者數和並發使用者數。

　　　　系統使用者數是指該系統的註冊使用者；線上使用者數是指登入了系統的使用者；並發使用者是指線上並對伺服器產生壓力的使用者。

　　　　並發數可以通過分析伺服器日誌確定。常用日誌分析工具有AWStats、Webalizer、Analog、Deep Log Analyzer等。

　　　　並發的兩種理解：①所有使用者在同一時刻做同樣的操作②多個使用者發起多個請求，請求可能不同。

　　2、回應時間

　　　　回應時間=網路傳輸（請求）時間+伺服器處理（一層或多層）時間+網路傳輸（響應）時間+頁面前端解析渲染時間

　　　　一般用戶端發起請求後，會先預先處理判斷是否有緩衝。如果有，直接讀取cache，再進行資料處理和渲染；如果沒有，要先解析DNS網域名稱獲得伺服器IP，串連伺服器發送請求，

　　待伺服器響應後返回資料，再進行資料處理和渲染。

　　3、每秒通過事務數

　　　　TPS是指每秒通過事務數，是直接反映系統效能的指標。

　　　　把它與平均事務回應時間進行對比，可以分析事務數量對回應時間的影響。

　　　　當壓力加大時，TPS曲線如果變化緩慢，很有可能是伺服器開始出現瓶頸了。如果環境沒有發生大的變化，對於同一系統會存在一個最大處理事務能力，它並不隨並發使用者的多少而改變。

　　4、每秒點擊數

　　　　代表使用者每秒向web伺服器提交的HTTP請求數。需要注意，對使用者來說是一個請求，對後端來說是多個請求。比如，點擊一個網頁連結，返回頁面上的每張圖片每個模組都需要一個HTTP請求。

　　　　每秒點擊數從側面反映了用戶端的狀況，每秒點擊數不正常，一般可能是網路問題或指令碼問題所致，需要進一步具體分析。

　　5、輸送量

　　　　輸送量是指單位時間內系統處理的請求數量，能直接反映伺服器承受的壓力，是需要重點關注的指標。

　　　　要與吞吐率區別開來，吞吐率是指使用者在給定的一秒內從伺服器獲得的資料量，就是伺服器返回的資料量資料量啊喂。

　　6、考慮時間

　　　　兩種理解：①使用者進行操作時，每個請求或者操作之間的間隔時間②滿足業務的特定需求，限制使用者的某一請求在一定的時間間隔內不能發送第二次。

　　7、資源使用率

　　　　這部分的內容太雜，主要先瞭解幾個重點指標。

　　　　①CPU

　　　　能反映出系統的繁忙程度，分為系統CPU和使用者CPU，其中系統CPU是處理系統本身所佔用的資源，而使用者CPU則是處理常式所佔用的資源，對象不同。

　　　　②Load Average

　　　　指一段時間內CPU正在處理和等待CPU處理的任務，也就是CPU使用隊列的程度的統計資訊。

　　　　③Memory

　　　　將各種資訊收集起來存放。因為資料從記憶體中讀取比從磁碟上讀取快，所以記憶體經常會泄露或溢出，需要重點留意。

　　　　短時間內可用記憶體越來越少，不代表一定有記憶體泄露或溢出。（可能是記憶體損壞、檢測軟體漏洞、病毒佔用程式等等）

　　　　④隊列

　　　　隊列長，說明處理能力可能達到了極限或者遇到了阻塞。

　　　　⑤IO

　　　　與磁碟的互動，重點關注交換頻率和磁碟隊列長度。

　　　　⑥網路

　　　　重點關注網路的流量，看是否存在網路頻寬的瓶頸。

• 效能測試分類

　　　分類比較多啊，理解特點和概念就可以了，不需要嚴格區分。

　　　1、基準測試

　　　  應用情境有如下幾個：①某系統從來沒進行過任何效能測試，需要對系統做一次效能評估，作為後續開發調優的參考。（常見）

　　　　　　　　　　　　   ②可以在制定的標準下通過基準測試建立一個效能基準，這樣以後當系統的環境、參數發生變化之後，在進行一次相同標準下的測試，即可看出變化對效能的影響。

　　　　　　　　　　　　　③進行基準測試可以在較早的階段發現效能問題，減少不必要的測試。

　　   2、並發測試

　　　  很多的使用者按照預定的情境並發請求某個業務或功能時是否出現並發問題，例如記憶體泄露、線程鎖、資源爭用等。進行並發測試是為了找出並發引起的問題。

　　　  確定需要的並發數的方法：①並發數=PV / PV Time * 頁面串連次數 * HTTP回應時間 * 因數 / Web伺服器數量

　　     　　　　　　　　　　　　PV（page view）:頁面瀏覽量。PV Time是PV的統計時間，換算成秒，一天是86400s。

　　　　　　　　　　　　　　　  頁面串連次數包括外部的JS、CSS、圖片等，一般為10。HTTP回應時間一般可為1s或更少。因數一般為5。

　　　　　　　　　　　　　　　  ②經典理論80-20原則（80%的業務量在20%的時間裡完成。）

　　　　　　　　　　　　　　　　輸送量=80%*業務量/(20%*時間)

　　　　　　　　　　　　　　　　注意：二八原則的計算結果是輸送量而不是並發數。

　　　　　　　　　　　　　　　  ③在段念老師的《軟體效能測試過程詳解與案例剖析》中提到的估算方法有如下3種：

　　　　　　　　　　　　　　　　1>.     C=nL/T                （1）

　　　　　　　　　　　　　　　　　　　 C’≈C+3√C            （2）

　　　　　　　　　　　　　　　　公式（1）中，C是平均的並發使用者數；n是log session的數量；L是log session的平均長度；T指考察的時間段長度。例如，對一個典型的OA應用，考察的時間段長度應該為8小時的工作時間。

　　　　　　　　　　　　　　　　公式（2）給出了並發使用者數峰值的計算方法，其中，C’值並發使用者數的峰值。該公式是假設使用者的logsession產生泊松分布而估算得到的。

　　　　　　　　　　　　　　　　eg：假設有一個OA（辦公自動化）系統，該系統有3000個使用者，平均每天大約有400個使用者要訪問該系統，對一個典型使用者來說，一天之內使用者從登入到退出該系統的平均時間為4小時，在一天的時間內，使用者只在8小時內登入該系統。根據公式（1）（2）可得：

　　　　　　　　　　　　　　　　C=400*4/8=200

　　　　　　　　　　　　　　　　C’≈200+3√200=242

　　　　　　　　　　　　　　　　如果能知道平均每個使用者發出的請求數（假設為u），則系統的總輸送量就可估算為u*C。

　　　　　　　　　　　　　　　　但是要估算C和L並不容易，並且考慮到業務操作存在一定的時間集中性，這個方法存在一定的偏差。建議改進兩點：

　　　　　　　　　　　　　　　　一是以更細的時間粒紋進行考察，如設定1小時為考察時間的粒度，就可以解決時間集中性的問題；

　　　　　　　　　　　　　　　　二是考慮典型的業務模式：不同業務有不同的業務模式，如一個內部系統一般在上班開始後的30分鐘至1小時集中出現使用者的登入等等，基於這些情境進行估算。

　　　　　　　　　　　　　　　　2>.對於企業內部使用的web系統來說，一個更一般（精度更差）的經驗公式是：

　　　　　　　　　　　　　　　　　　　　　　C=n/10      （3）

　　　　　　　　　　　　　　　　　　　　　　C’≈ r*C      （4）

　　　　　　　　　　　　　　　　用每天訪問系統使用者數的10%作為平均的並發使用者數，並發使用者數的最大值有並發使用者數乘上一個調整因子r得到，r的取值一般為2~3。

　　　　　　　　　　　　　　　　這種方法可以在要求不太嚴格的效能測試，或是只有少數資料支援分析的效能測試中使用。

　　　　　　　　　　　　　　　　3>.“日誌分析”方法

　　　　　　　　　　　　　　　　“日誌分析”方法是指通過對應用伺服器的日誌進行分析，從而瞭解系統使用者的使用狀況，從日誌中計算出“伺服器承受的最大並發使用者訪問數”資料。

　　　　　　　　　　　　　　　　這種方法得到的資料準確度和可信度都比較高。對於Internet應用等無法估計使用者數量和使用者行為模式的應用，這種方式最為可信。

　　   3、負載測試

　　　　主要目的是驗證業務或系統在給定的負載條件下的處理效能，此外，還要關注回應時間、每秒通過事務數和其它相關指標。負載測試是為了發現效能問題，效能測試是為了擷取效能指標。在效能測試中，也可以不調整負載，而是在負載相同的情況下通過改變系統的結構、演算法、硬體設定等來得到效能指標。

　　　4、壓力測試

　　　　沒有預期的效能指標，不斷地加壓，看系統什麼時候崩潰，以此來確定系統的瓶頸或者不能接受的效能拐點，以獲得系統的最佳並發數、最大並發數。通過壓力測試，可以更快地發現記憶體泄露問題，還可以更快地發現影響系統穩定性的原因。

　　  5、穩定性測試

　　　　要想知道系統穩定的情況，就需要長時間運行，在這段時間內觀察系統的出錯幾率、效能變化趨勢等，進而大大減少系統上線後的崩潰等現象。一般都會進行所謂的7*24小時的穩定性測試。

　　　　注意：①一般穩定性測試需要在系統成型後進行，並且沒有嚴重的bug存在。

　　　　　　   ②情境的設計以類比真實使用者的實際操作為佳。

　　  6、失效恢複測試

　　　　失效恢複測試重在關注系統出現問題後能否根據預定製定的策略恢複，且恢複後能否正常運行。不過失效恢複測試一般是對具有負載平衡的系統進行的，主要是為了測試當系統局部發生故障時，是否會對全域產生大的影響，產生的影響是否在可以接受的範圍內，以及使用者能否繼續使用系統。

　　　　在實際應用過程中，可以類比一台或幾台負載平衡機器出現故障來進行失效恢複測試，但需要注意的是，不僅要關心失效後，使用者是否可以正常訪問或者恢複後系統是否可以正常工作，也要關註失效後，系統還能支援多少並發使用者，以及採用哪些備選方案來快速響應。

　　7、現網效能測試

　　　　就是在實際網路、實際環境中進行測試，完全和真實使用者一樣，有一定的風險，需要注意：

　　　　①時間段的選擇：現網效能測試可能會影響正常使用者，要盡量避開高峰期，選擇半夜或淩晨來進行。

　　　　②垃圾資料處理：如果現網效能測試涉及了寫資料的操作，這些資料後期一定要處理，為了方便處理，前期資料的設計要有規律可循。

　　　　③網路限制：現網測試如果突然間產生大的資料量，可能會被網路頻寬節流設定，甚至路由會認為是非法資料請求而產生攔截等。所以進行現網測試時，壓力機需要和被測伺服器部署在同一網段機房內，這樣可以避免網路限制，最後遠程收集資料即可。

           如果沒有特殊情況，盡量不要進行內網的效能測試，風險比較大，如果非要進行，一定要事先充分評估風險以及應對的解決方案，以便快速響應，把影響控制到最小。所以人還是偶爾要慫一點的，別逞強。

 

 

 

 　　　　　　　　　　　　　　　　

 

軟體測試入門隨筆——軟體測試基礎知識（六）