目 錄

引 言

1 性能測驗的基本概念

2 性能測驗的分類

2.1 負載測驗

2.2 壓力測驗

2.3 基準測驗

2.4 配單測驗

2.5 容量測驗

2.6 穩定性測驗

2.7 擴展性測驗

2.8 負載測驗VS壓力測驗

3 業務場景與設計要點

3.1 業務場景的劃分

3.2 業務設計要點

3.2.1 測驗目的

3.2.2 業務組成

3.2.3 資料規格

3.2.4 指標監測

引 言

“性能”一詞對大部分來說并不陌生，在日常生活或作業中我們經常會聽到關于性能的描述：

“這臺電腦的性能也太差了吧，打開個軟體都能卡半天！”

“新發布的小米11pro性能好強大啊！”

“這款處理器的性能真強勁，完全吊打……”

“打開個網頁也要加載半天，這個網站的服務器性能也太差了吧……”

“看看我的新車，百米加速xxx秒，性能強的一批！”

雖說如此，但是你真的了解“性能”嗎？你知道性能背后深層的意思嗎？以軟體測驗中的服務器性能場景為例：

A：這個網站的服務器性能太差啦！

B：差在哪里？

A：加載網頁的速度太慢了！

B：確定是服務器性能差？而不是你的網路不行？不是你的電腦不行？不是你打開的方式不對？？？

打破砂鍋問到底，用量化的資料指標來代替直觀的感受是我們性能測驗需要做的事情，下面我們就來詳細學習一下性能測驗的基本知識吧！

1 性能測驗的基本概念

性能測驗在軟體的質量保證程序中起著舉足輕重的作用，特別是對于一些并發量大的大型網站來說，做好性能測驗，找到性能瓶頸，并根據性能測驗結果做出針對性的優化至關重要，比如各大電商平臺在雙11背后肯定做足了性能測驗，否則一旦網站崩潰，帶來的損失就不是億點點了……

中國軟體評測中心將性能測驗概括為三個方面：應用在客戶端性能的測驗、應用在網路上性能的測驗和應用在服務器端性能的測驗，通常情況下，三方面有效、合理的結合，可以達到對系統性能全面的分析和瓶頸的預測，

2 性能測驗的分類

根據測驗的目的和手段來劃分，性能測驗可以劃分為負載測驗、壓力測驗、基準測驗、配單測驗、容量測驗、穩定性測驗和擴展性測驗，如下圖所示：

2.1 負載測驗

系統在不同負載下的性能表現，通過負載測驗能夠測驗出系統在各種負載下的性能變化曲線，發現系統的性能拐點，從而找出系統的最佳性能，舉例：用戶并發測驗（遞增并發用戶數，查看系統性能指標變化），

2.2 壓力測驗

系統在高強度負載下的性能表現，通過壓力測驗可以測驗出系統能夠承受的最大負載，壓測是一種尋求系統介于正常和不正常之間臨界值的一種負載測驗，壓測不僅關注高負載下系統是否正常運行，同時關注負載減小后，系統是否能夠恢復，

2.3 基準測驗

基準測驗（benchmarking）是一種測量和評估軟體性能指標的活動，在特定時期（系統穩定時）通過基準測驗建立一個已知的性能水平（稱為基準線），當系統的軟硬體環境發生變化之后再進行一次基準測驗以確定那些變化對性能的影響，基準測驗可以比較系統在版本迭代程序中，各個性能指標的變化，為系統的版本迭代優化提供參考，

2.4 配單測驗

也叫配置項測驗，對被測系統的軟硬體引數進行配置的測驗，通過配單測驗可以找出系統各項資源指標的最佳分配比，

2.5 容量測驗

通過容量測驗預先分析出反映軟體系統應用特征的某項指標的極限值（如最大并發用戶數、資料庫記錄數等），系統在其極限狀態下沒有出現任何軟體故障或還能保持主要功能正常運行，軟硬體固定的情況下，對系統進行一定規模的資料量操作，觀察系統各項性能指標是否正常，舉例：電子商務網站所能承受的、同時進行交易或結算的在線用戶數，

2.6 穩定性測驗

通過對軟體穩定性的測驗可以觀察在一個運行周期內、一定的壓力條件下，軟體的出錯機率、性能劣化趨勢等，進而大大減少軟體上線后的崩潰卡死等現象，為軟體的逐步優化提供方向及驗證，在特定的負載下（正常或略高于正常的負載），在一段運行周期內，對被測系統進行一系列的正常操作，觀察各個系統性能指標變化以及系統是否能夠長期穩定運行，

2.7 擴展性測驗

基礎設施不需要經常變更，應用之間較少依賴或耦合，可以對需求變更快速回應，架構設計會考慮到未來功能的可擴展性，所以當系統增加新功能時，不需要對現有系統的結構和代碼進行修改，系統集群的擴展性測驗，觀察系統在集群服務器增加時，整體性能是否穩步提升，集群中的每臺服務器性能是否有額外損耗等，

2.8 負載測驗VS壓力測驗

有些童鞋可能對負載測驗和壓力測驗傻傻分不清楚，這邊也查閱了一些資料，做了個總結，方便大家參考：

相同點：兩種測驗都是針對系統承受能力的測驗，都是一種量的測驗；

不同點：負載測驗是觀察系統在不同負載下的測驗，旨在找出系統的性能拐點或最佳性能；壓力測驗是觀察系統在高負載下的運行情況，旨在找出系統所能承受的最大負載以及系統在高壓下再減壓后系統恢復正常的能力，

3 業務場景與設計要點

業務場景顧名思義就是系統真實運行環境的場景，模擬性能測驗場景的宗旨是盡可能還原業務現場真實的軟硬體環境，在一些入圍專案中，就需要盡可能按照入圍測驗的軟硬體配置模擬性能測驗場景，

3.1 業務場景的劃分

性能測驗的業務場景可以按照業務的組成以及測驗目的和手段兩個維度進行劃分，

按照業務場景劃分可以劃分為單業務場景以及混合業務場景（也可以叫多業務場景），顧名思義，單業務場景的性能測驗就是針對單一業務的性能測驗場景，比如交換機的介面帶寬測驗、網站的用戶登陸測驗、安防系統的視頻取流測驗等，混合業務場景的性能測驗則是對多個業務進行綜合性能測驗，主要考察整個系統或者多個模塊在真實業務場景下是否能夠滿足性能要求，

按照測驗目的和手段劃分性能測驗場景，可以劃分為：負載測驗場景、壓力測驗場景、基準測驗場景、配單測驗場景、容量測驗場景、穩定性測驗場景和擴展性測驗場景，與第二節描述類似，不再贅述，

3.2 業務設計要點

3.2.1 測驗目的

目的是行動的依據，明確測驗目的能夠對整個性能測驗的執行提供方向，是性能測驗的第一步，只有明確了測驗目的才能夠選擇恰當的測驗方法進行性能測驗，偏離目的的測驗做的都是無用功，

明確測驗目的需要確定以下幾個要素：

• 被測目標：一個介面、一個功能點、一個功能集合、一個模塊或整個系統等都可以是被測目標；
• 資料/操作規模：交換機單個介面的滿流量、交換機的所有介面滿帶寬、網站的10w并發、服務器介面呼叫100w次等資料或操作的量級；
• 預期性能表現：網站穩定運行、服務器不崩潰、系統CPU 80%以內，系統回應時間不超過3s等衡量系統性能的指標，

3.2.2 業務組成

分析業務組成最關鍵的一點就是抽象出對測驗目標有影響的因素或者業務，無關或者沒有影響的業務不需要進行設計和疊加，分析業務組成的同時還需要理解業務流程之間的關系，比如測驗電商網站是否能夠承受1000w用戶的并發操作，需要了解整個購物流程包括登陸、瀏覽商品、加入購物車、下單、付款等環節，并根據業務流配置合理的并發操作量（比如500w登陸、200w瀏覽商品、100w加入購物車、100w下單、100w付款），這與每個環節都設計1000w并發量的測驗目的是不同的，

3.2.3 資料規格

從3.2.2的分析我們可以知道，資料規格和業務組成是緊密相連的，在性能測驗中，說到業務的同時，也會連著提到業務的資料量/資料規模，為了方便理解，此時的業務組成也可以抽象成是資料組成，因此資料規格可以描述為：

資料規格=資料組成+資料量/資料規模

結合上文，我們可以得出電商網站1000w的用戶并發資料規格如下：

1000w用戶并發=500w登陸+200w瀏覽商品+100w加入購物車+100w下單+100w付款

當然這個只是一個簡要的程序，具體以實際業務為準哦，

3.2.4 指標監測

指標監測是指我們對系統做了一系列操作后，監測/監控系統的表現情況，一般情況，需要對這些指標進行量化，比如系統反應時間3s以內，CPU占用70%以內，網路傳輸不出現丟包，不出現行程死鎖或系統掛死現象等等，切記不要用系統穩定運行這類抽象字眼一句話帶過，這也是很多測驗新人常犯的錯誤，

如果文章對你有幫助，記得點贊，收藏，加關注，會不定期分享一些干貨哦......~~~///(^v^)\\\~~~