939      阿裏雲  技術社區[雲棲]

性能測試技術指南__性能測試技術體係_性能測試體係_性能測試-阿裏雲

訪問性能測試控製台

1 編寫目的

製定性能測試實施指南，從技術角度製定性能測試實施過程中關鍵技術規範，更好的對係統進行性能測試，幫助客戶更好地從技術上來規避係統上線後的風險。

2 適用範圍

適用於性能測試所有需要性能測試的項目。對性能測試實施過程中非常重要、非常關鍵的相關技術進行分析；主要包括：係統環境、測試指標、業務模型、數據量、測試模型、測試類型、腳本、場景、監控、瓶頸分析、調優、性能測試分布式壓測工具。

3 係統環境

3.1 分析

係統環境分為生產環境、測試環境等，做性能測試之前，肯定需要一套測試環境的，那麼如何搭建、配置測試環境，在性能測試前需重點考慮。性能測試結果是要為生產係統服務的，那麼理想中的性能測試關鍵最好就是生產環境，但是由於某種因素，不可能將生產環境完整的再搭建一套，有時必須進行”裁剪”。

3.2 風險

測試環境的風險主要體現在跟生產差異太大，測試結果根本沒有參考價值。對測試環境係統平台、中間件、數據庫等不熟悉和了解，也會導致瓶頸不易分析、不易調優等。

3.3 規範

3.3.1 測試環境搭建

測試環境搭建需滿足如下規範：

• 測試環境架構與生產環境架構完全相同
• 測試環境機型與生產環境機型盡量相同
• 測試環境軟件版本與生產環境軟件版本完全相同，版本主要包括：操作係統、中間件、數據庫、應用等
• 測試環境參數配置與生產環境完全相同，參數主要包括：操作係統參數、中間件參數、數據庫參數、應用參數
• 測試環境基礎數據量與生產環境基礎數據量需在同一個數量級上。
• 隻能減少測試環境機器台數，並且需要同比例縮小，而不能隻減少某一層的機器台數。
• 理想的測試環境配置是生產環境的1/2，1/4。

3.3.2 測試環境調研

測試環境調研，需要調研如下內容：

• 係統架構：係統如何組成的，每一層功能是做什麼的，與生產環境有多大差異，主要為後麵進行瓶頸分析服務和生產環境性能評估。
• 操作係統平台：操作係統是哪種平台，進行工具監控。
• 中間件：哪種中間件，進行工具監控和瓶頸定位。
• 數據庫：哪種數據庫，進行工具監控和瓶頸定位。
• 應用：啟動多少個實例，啟動參數是多少，進行問題查找和瓶頸定位。

4 測試指標

4.1 分析

測試指標一般分為業務指標、資源指標、應用指標、前端指標：業務指標：從業務人員的角度得出來的，例如：並發用戶數、TPS、成功率、響應時間。資源指標：從運維人員的角度得出來的，例如：CPU資源利用率、內存利用率、I/O、內核參數(信號量、打開文件數)等。應用指標：從開發人員的角度得出來的，例如：空閑線程數、數據庫連接數、GC/FULL GC次數、函數耗時等。前端指標：從測試人員和開發人員角度得出來的，例如：頁麵加載時間，網絡時間（DNS，連接時間、傳輸時間等）。

4.2 風險

不同用戶對係統的指標類型和期望值是不一樣的，需要提前針對不同角色的人員進行指標調研，設定閾值，測試出係統在閾值下的性能，瓶頸定位及調優。未提前關注測試指標，將會導致測試結果不是相關人員需要的，結果是無效的。

4.3 規範

4.3.1 業務指標

• 業務響應時間(Response Time):這個指標所有相關人員都明白其含義，業務部門更需要此指標的具體值，一般情況下，不同係統的業務響應時間期望值是不同的，１秒以內最佳；像淘寶係統業務ＲＴ基本在幾十毫秒以內。
• 業務處理能力（Transaction Per Second）:這個指標是衡量係統的處理能力的一個非常重要的指標，TPS可以參照同行業係統和結合具體業務，中小企業TPS值為50~1000筆/秒，銀行TPS值為1000~10000筆/秒，淘寶TPS值為30000~100000筆/秒。
• 成功率:這個指標是衡量係統處於壓力下，業務的成功率，一般業界成功率要大於99.6%。

4.3.2 資源指標

一般情況下，係統資源指標也不能超過瓶頸值，例如CPU資源利用率<=75%,內存無SWAP,　磁盤和網絡I/O不能自身處理能力。理想的情況下，當係統壓力上不去的時候，資源成為瓶頸（正常情況下，非其他瓶頸情況下導致），這樣的話加資源，係統處理能力還會上升的，但是遺憾的是，很多係統性能測試資源都沒達到瓶頸的時候，壓力就上不去了。

5 業務模型

5.1 分析

係統有很多業務，每筆業務邏輯和業務量是不一樣的，消耗係統的資源也是不一樣的，因此業務種類、業務占比決定了係統的處理能力，業務模型在性能測試中起著關鍵性的作用。

5.2 風險

業務模型中業務和占比選取不對，跟生產差異非常大，直接導致測試結果沒有任何參考價值，並且容易誤導對係統處理能力的判斷。有些業務的業務量雖然占比很低，但一旦突變，對係統也是致命的，這些業務在性能測試中也需要關注。

5.3 規範

係統中的典型業務如何選取一般情況下遵循的規則是選取業務量高的、經常使用的、有風險的、未來有增長趨勢的業務作為係統的典型業務。已經上線的係統可以通過高峰時段曆史業務量和生產問題性能來評估，對於即將上線的係統可以通過調研和單交易資源消耗的結果來評估。

5.3.1 已上線係統

• 搜集生產上不同高峰時間段的業務種類和業務量，每個時間段的業務種類和業務量是否有很大的差異，如有的話，必須有多個業務模型；差異不大的，可以隻用一個業務模型。
• 搜集生產上高峰時間段資源消耗和資源異常的時間點，從中捕獲資源消耗高和異常的原因，可能是由於某種”不起眼”的業務導致。
• 搜集生產問題，進行分析，如果是由於某種業務導致而且以前性能測試的時候忽略此筆業務，那麼這筆業務的風險是非常大的，需要後續性能測試將此業務加入到業務模型中。

5.3.2 未上線係統

• 通過調研，確定業務種類和業務占比
• 通過調研，確定是否在業務促銷等活動中，某些業務有突變的可能。
• 通過測試結果，確定每筆業務的資源消耗，如果某些業務雖然占比低，但資源消耗非常大，那麼需要適當的調整此業務占比。

6 數據量

6.1 分析

數據量主要包括基礎數據量（或者叫曆史數據量、墊底數據量、數據庫中已有的數據量）和參數化數據量，數據量在性能測試中起到非常重要的作用。對於在數據庫中隻有幾條記錄和有幾億條記錄裏麵查詢信息，那麼結果肯定相差非常大的，隨著業務量的增長，記錄也越來越多，因此在性能測試過程中，需要保持跟生產上相同級別的數據量。生產係統中業務中使用不同的數據、那麼我們在測試的時候需要考慮參數數據量的大小和數據分布的問題。

6.2 風險　

如果基礎數據量跟生產環境的基礎數據量不在同一個數量級上，將會導致相關指標例如響應時間比生產上快很多，不真實，甚至導致測試結果沒有參考意義。如果參數化數據量過少、未考慮數據分布的情況，將會導致測試結果不真實，甚至測試結果沒有參考意義。

6.3 規範

6.3.1 基礎數據量

測試環境基礎數據量需要跟生產環境基礎數據量保持在同一個數據量級上，一般情況下需要考慮未來三年數據量增長趨勢，如果增長過快需要在測試環境造非常多的數據。

6.3.2 參數化數據量

• 參數化數據量盡可能的多，必要的情況下，可以清除緩存或者用寫代碼的方式提供參數化。
• 參數化數據分布，如果業務有明顯的地域等分布的特征，需要考慮數據分布的情況。

7 測試模型

7.1 分析

測試模型是在業務模型的基礎上演變而來的，一般情況測試模型和業務模型是相同的，但是由於某種業務無法模擬或者安全原因，需要去掉此筆業務，重新計算占比得出。

7.2 風險

• 參照５業務模型風險
• 去掉的業務如果有風險，那麼需評估此筆業務的風險，風險大的情況下，需采取其他解決方案。

7.3 規範

參照５業務模型規範。

8 測試類型

8.1 分析

測試類型主要分為負載測試、壓力測試；其中單交易基準測試、負載測試、壓力測試；混合交易負載測試（容量測試）、壓力測試；業務突變測試；混合交易穩定性測試；混合交易可靠性測試；批量測試、批量測試對混合交易影響測試等是常見的測試類型。每種測試類型針對不同的目的，可以根據生產係統現實情況進行選擇。

8.2 風險

缺少某種測試類型，將會導致現實生產係統某種場景沒有測到，發生風險，例如：係統崩潰、響應時間慢等。

8.3 規範

如果時間充足，建議大部分測試類型都需要測試一下，也可以參考以下規範：

• 單交易基準測試：可選
• 單交易負載測試：可選，未上線係統建議做負載，看資源消耗
• 混合交易負載測試（容量測試）：必須
• 混合交易壓力測試：可選
• 業務突變測試：可選
• 混合交易穩定性測試：必須
• 混合交易可靠性測試：可選
• 批量測試：可選
• 批量測試對混合交易影響測試：可選

9 腳本

9.1 分析

腳本是用來模擬生產環境係統的業務操作，腳本模擬的正確與否直接影響著係統的性能，模擬業務操作的時候，需要參數化數據，參數化數據分布及數據量在６數據量章節已經分析過了。

9.2 風險

腳本“空轉”（業務沒有做成功）或業務邏輯與實際生產環境差距太大將會導致測試結果沒有參考價值，甚至係統上線後，係統“宕機”的生產事故。

9.3 規範

• 跟生產上業務規則一致編寫腳本。
• 在關鍵地方校驗服務器返回值。
• 數據盡量參數化、數據量盡可能的多。

10 場景

10.1 分析

場景是模擬現實生產環境中業務場景的，包括並發用戶數、加減壓策略、運行時間等。場景模擬需要跟生產上場景相一致，特別是在一段時間內，測試出來的各業務TPS占比跟生產上高峰時候業務占比一致。

10.2 風險

場景的風險主要體現在測試出來的業務TPS占比需跟生產上業務占比一致，在業務比例偏離嚴重的情況下，將會導致測試結果不真實或者無效，不能反映生產上的業務場景。

10.3 規範

測試結果中各業務TPS占比需跟生產上業務占比（業務模型）相一致，如何才能保證一致呢？需要設置步調時間（PacingTime）：例如：A和B兩筆業務，占比為1：4，響應時間分別為1ms,100ms,總的用戶數為50，那麼A和B按照業務比例並發用戶數分別為10和40，測試出來的TPS分別為10000(10個用戶/0.001秒)筆/秒和400筆/秒，那麼TPS比例為25:1,跟生產上差距非常大，嚴重偏離生產上業務模型，此時我們設置A和B的PacingTime都為200ms,那麼測試出來的TPS分別為50（10個用戶/0.2秒）筆/秒和200筆/秒，A和B業務TPS比例50:200=1:4,與生產上保持一致了，沒有偏離生產上業務模型。

11 監控

11.1 分析

監控的目的主要是為進行性能測試分析服務的，完善的對係統進行監控，針對瓶頸定位起到”事半功倍”的效果。一般來說，需要針對操作係統、中間件、數據庫、應用等進行監控，每種類型的監控盡量指標全麵。

11.2 風險

沒有完善的係統監控，將會導致性能分析無從下手，定位不出係統瓶頸，根本不知道從哪進行調優。

11.3 規範

• 操作係統：CPU(User,Sys,Wait,Idle)利用率，內存利用率(包括Swap),磁盤I/O,網絡I/O，內核參數等
• 中間件：線程池、JDBC連接池、JVM（GC/FULL GC/堆大小）
• 數據庫: 效率低下SQL、鎖、緩存、會話、進程數等
• 應用：方法耗時、同步與異步、緩衝、緩存

12 瓶頸分析

12.1 分析

瓶頸定位的目的是對係統中存在的瓶頸點進行分析，為調優做準備，係統的性能瓶頸點主要分布在操作係統係統資源、中間件參數配置、數據庫問題以及應用算法上，對於有針對性的進行調優，有利於係統性能的提升。

12.2 風險

當係統的瓶頸點不能被分析出來以後，係統上線就存在風險，這種風險有可能導致業務高峰的時候，係統性能體驗差，甚至“崩潰”。

12.3 規範

分析係統的瓶頸點遵循的規則如下：

• 操作係統資源消耗：CPU、Memory、Disk I/O、Network I/O
• 中間件指標：線程池(Thread Pool)、數據庫連接池(JDBC)、JVM(GC/FULL GC/堆大小)
• 數據庫指標：效率低下SQL、鎖等待/死鎖、緩存命中率、會話、進程等
• 應用：方法耗時、算法、同步和異步、緩存、緩衝
• 壓力機：壓力機資源消耗，一般情況下，壓力機成為瓶頸的可能性非常低。

13 調優

13.1 分析

調優的目的是提升係統的性能，針對係統的“瓶頸點”對症“下藥”,通過測試驗證係統的性能有多大的提升。

13.2 風險

未進行調優的係統，係統上線後，可能會出現客戶體驗差的效果，甚至導致係統“崩潰”的風險。

13.3 規範

係統調優遵循的規則如下：

• 中間件調優：線程池、數據庫連接池、JVM。
• 數據庫調優：效率低下SQL、死鎖和鎖等待、緩存命中率，進程和會話參數。
• 應用調優：方法耗時、算法、同步和異步、緩存、緩衝。
• 係統資源：一般情況下，係統資源(CPU大部分是由應用和參數設置不合理導致的，並非係統資源真的不夠”用”。

14 性能測試分布式壓測工具

14.1 簡介

性能測試（Performance Testing）是集測試機管理、測試腳本管理、測試場景管理、測試任務管理、測試結果管理為一體的性能雲測試平台，可以幫助您全方位的評估雲上係統性能。

14.2 功能

• 測試機管理：被測係統機器管理，將當前阿裏雲ID名下的機器添加到環境當中。
• 測試腳本管理：模擬現實環境中業務操作，設置事務、自定義Cookie、Header、Body以及參數化。
• 測試場景管理：設置並發用戶數、加減壓方式、步調時間。
• 測試任務管理：設置測試場景、運行時間以及需要監控的機器。
• 測試結果管理：查看運行的結果。

14.3 優勢

14.3.1 易用

性能測試分布式壓測工具易學、易用、易操作，無論初學者還是有一定經驗的客戶都能很快利用此工具進行性能測試。

14.3.2 無維護成本

性能測試分布式壓測工具部署在雲上的平台，客戶無需進行壓測環境的維護。

14.3.3 分布式

性能測試分布式壓測壓力無上限,無論中小企業客戶還是大型企業客戶，都能滿足要求。

14.3.4 曆史數據對比分析

性能測試可以將測試過的場景相關指標進行對比，有利於調優前後的性能分析。

訪問性能測試控製台

最後更新：2016-06-08 11:18:21

  上一篇： 測試總結階段__性能測試流程體係_性能測試體係_性能測試-阿裏雲

  下一篇： 測試指標__性能測試技術體係_性能測試體係_性能測試-阿裏雲