web效能測試流程

　　1.1基本概念

　　併發使用者：使用者併發一般發生在使用比較頻繁的模組中，而且遇到異常通常都是程式的問題。

　　使用者併發數量：線上使用者數量是計算併發使用者數量的主要依據之一。=使用系統的使用者數量*(5%~20%)

　　併發主要針對WEB伺服器而言，是否併發的關鍵是看使用者的操作是否對伺服器產生了影響。

　　吞吐量：一次過程中網路上傳輸的資料量的總和。

　　吞吐率:吞吐量/傳輸時間，單位時間內網路上傳輸的資料量，也可以指單位時間內處理的客戶端請求數量。吞吐率用“請求數/秒”或者“頁面數/秒”來衡量。

　　點選率：每秒鐘使用者向web伺服器提交的HTTP請求數。點選率越大，對伺服器的壓力也越大。重要的是分析點選時產生的影響。

　　點選不是指滑鼠的一次“單擊”操作，因為在一次“單擊”操作中，客戶端可能向伺服器發出多個HTTP請求。

　　1.2WEB種類

　：確定一個系統的瓶頸或者不能接收使用者請求的效能點，來獲得系統能提供的最大服務級別的測試。

　　：在被測系統上不斷增加壓力　，直到效能指標達到極限，響應時間超過預定指標或者某種資源已經達到飽和狀態。這種測試可以找到系統的處理極限，為系統調優提供依據。

　　大資料量測試：針對某些系統儲存、傳輸、統計查詢等業務進行大資料量的測試。

　　配置測試：透過測試找到系統各資源的最優分配原則。

　　可靠性測試：可以施加cpu資源保持70%-90%使用率的壓力，連續對系統加壓執行8小時，然後根據結果分析系統是否穩定。即載入一定壓力的情況下，使系統執行一段時間。

　　併發測試：多以發現一些演算法設計上的問題。

　　以使用者併發測試為主的測試。

　　主要是為了發現軟體問題和硬體瓶頸。

　　對於效能方面給系統留有30%左右的擴充套件空間即可。

　　1.3Web全面模型

　　1.3.1預期指標的效能測試

　　主要指需求分析和設計階段提出的一些效能指標。

　　針對每個指標都要編寫一個或者多個測試用例來驗證系統是否達到要求。

　　預期指標的用例通常以單使用者為主，如果涉及併發使用者內容，則歸併到併發使用者測試用例中進行設計。

　　1.3.2併發

　　選擇具有代表性、關鍵的業務來設計用例，並且使用者的設計應該面向“模組”

　　使用者併發分為：獨立核心模組併發，組合模組併發

　　獨立核心模組併發：完全一樣功能的併發測試；完全一樣操作的併發測試；相同/不同的子功能併發。

　　針對獨立核心模組使用者併發效能的測試用例設計，可發現一些核心演算法或者功能方面的問題，如一些多執行緒、同步併發演算法在單使用者模式下測試是很難發現問題的，透過模擬多使用者的併發操作，更容易驗證其是否正確和穩定。

　　核心模組測試一般屬於基本的，它較多地關注模擬的“功能”，一般不會對伺服器進行測試。

　　組合模組併發：具有耦合關係的核心模組進行組合併發測試；彼此獨立的、內部具有耦合關係的核心模組組的併發測試；基於使用者場景的併發測試。

　　組合模組測試一般發現介面方面的功能問題，並儘早發現綜合效能問題。

　　在實際中，各種型別的使用者都會對應一組模組，相當於不同的業務組在併發訪問系統，要充分考慮實際場景，如話費管理系統中的每月10日左右的收費高峰等場景。

　　在編寫組合模組使用者併發效能測試用例時，不但要考慮使用者使用場景，還要注意併發點的運用，併發點是指一定數量的使用者開始執行同一功能或者操作的時間點，一組測試場景通常包含多個併發點，從而實現了核心模組同一功能或者操作的真正併發。

　　1.3.3獨立業務效能測試

　　獨立業務實際是指一些核心業務模組對應的業務。這些模組通常具有功能比較複雜，使用比較頻繁，屬於核心業務等特點。主要測試這類模組和效能相關的一些演算法、還要測試這類模組對併發使用者的響應情況。

　　使用者併發測試是核心業務模組的重點測試內容。

　　1.3.4組合業務效能測試

　　是最接近使用者實際使用情況的測試，也是的核心內容。

　　組合併發的突出特點是根據使用者使用系統的情況分成不同的使用者組進行併發，每組的使用者比例要根據實際情況來進行匹配。

　　使用者併發測試是組合業務的核心內容。“組合”併發的突出特點是根據使用者使用系統的情況分成不同的使用者組進行併發，每組的使用者比例要根據實際情況來進行匹配。

　　1.3.5網路

　　為準確展未頻寬、延遲、負載和埠的變化是如何影響使用者的響應時間的。主要是測試應用系統的使用者數目與網路頻寬的關係。

　　調整效能最好的辦法就是軟硬相結合。

　　1.3.6大資料量測試

　　主要是針對對資料庫有特殊要求的系統進行的測試，主要分為三種：

　　1．實時大資料量：模擬使用者工作時的實時大資料量，主要目的是測試使用者較多或者某些業務產生較大資料量時，系統能否穩定地執行。

　　2．極限狀態下的測試：主要是測試系統使用一段時間即系統累積一定量的資料時，能否正常地執行業務

　　3．前面兩種的結合：測試系統已經累積較大資料量時，一些實時產生較大資料量的模組能否穩定地工作。

　　大資料量測試用例的設計:1，歷史資料引起的大資料量測試和2執行時大資料量測試

　　首先確定系統資料的最長遷移週期和選擇一些前面的核心模組或者組合模組的併發使用者測試用例作為其主要內容即可.

　　1.3.7伺服器

　　的主要目的是在軟體功能良好的前提下，發現系統瓶頸並解決，而軟體和伺服器是產生瓶頸的兩大來源，因此在進行使用者併發，疲勞強度與大資料量時，完成對伺服器效能的監控，並對伺服器效能進行評估。

　　伺服器用例設計就是確定要採集的效能計數器，並將其與前面的測試關聯起來。

　　1.3.8設計用例注意的原則：

　　可以滿足預期效能指標測試用例要求的，就沒有必要設計更多的內容，因為用例越多，執行的成本也越高。

　　一定要服從整體策略，千萬不能僅從技術角度來考慮設計“全面”的測試用例，“全面”應該以是否滿足自己的測試要求作為標準。

　　適當裁剪原則

　　只有根據實際專案的特點制定合理的策略、編寫適當的用例，並在測試實施中靈活地變通才可以做好工作。

　　測試計劃：主要包含測試範圍、測試環境、測試方案簡介、風險分析等，測試計劃要進行評審後方可生效。

　　測試報告：主要包含測試過程記錄、測試分析結果、系統調整建議等。

　　測試經驗總結：不斷總結工作經驗是建立學習型團隊的基礎，實踐－總結－再實踐
　　2.1人員之間的配合關係

　　客戶代表：可瞭解一些專案的背景知識，例如客戶在軟體效能方面的需求，是否關注等，這些都是制定策略的依據。

　　需求分析員：確定哪些業務是核心業務，為後面編寫核心業務模組相關的測試用例打下良好的基礎，並且他們對使用者群體構成以及系統的擴充套件目標較清楚，這些都是設計的資料來源。

　　架構師：瞭解系統的結構，使設計出的用例在“恰當”的地方施壓。

　　2.2的範圍確定

　　對測試項或測試需求進行打分，根據綜合評分確定工作包含的測試內容，評分要素主要包含客戶關注度、效能風險、測試的成本等，效能風險主要指如果不進行該項需求，投產系統可能潛在的風險。

　　客戶關注程度或者效能風險較高的均應劃分到測試範圍內。

　　編號 測試需求 效能風險(10分) 使用者關注度(10分) 成本投入(10分)    總分

　  1系統運轉一年的資料量測試 7 10   6    23  2       ……           ……  

　　2.3 目標系統的業務分析

　　確定系統的核心模組：業務比較複雜或使用者使用較頻繁

　　確定模組件的耦合關係：清晰瞭解核心模組間資料傳輸方式，透過確定模組間如何介面，可以真實地模擬多使用者併發時的情況，尤其可以確定使用者併發時一些演算法是否正確。

　　分析系統壓力點：多是使用者使用較頻繁或資料流量較大的地方。

　　2.4使用者及場景分析

一，基於使用者實際使用情況的場景測試，

二，為了特殊測試目的(擴充套件性、穩定性)而設計的場景測試。

　　確定系統有多少類典型的使用者，每類使用者的大概數量以及在不同時間段各類使用者大概按照何種比例來使用系統。較常見的使用者場景有如下三種：

　　一天內不同時間段的使用場景

　　系統執行不同時期的場景

不同業務模式下的使用者

本文轉載：