- 相關推薦
性能測試方案設計
通過自動化的測試工具模擬多種正常、峰值以及異常負載條件來對系統(tǒng)的各項性能指標進行測試，這就是性能測試。下面是性能測試方案設計，為大家提供參考。
一、需求分析
1. 測試目的
為什么測？目的在于測試系統(tǒng)相關性能能否滿足業(yè)務需求。通常分以下兩種情況：
1）新項目上線
2）老項目優(yōu)化
如果是老項目優(yōu)化，可考慮是否存有歷史測試方案，如果有可以參考，或許可以省事很多。
2. 測試對象
要測啥？
測試對象可以歸結為“業(yè)務功能”。測試前，需要了解我們需要測試的業(yè)務功能（不深入細節(jié)）有哪些，比如“購買商品”、“寄送快遞”。
有沒有必要測？
需求來源哪里？，有沒有數(shù)據(jù)支撐測試這個需求的必要性？
通常，可以從以下幾個方面考慮：
1）是否核心功能，是否要求嚴格的質量
2）是否常用、高頻使用的功能
3）可能占用系統(tǒng)較多資源的功能
4）使用人數(shù)多還是少
5）在線人數(shù)多還是少
3. 拆分對象
先從業(yè)務上來分，實現(xiàn)這個完整的功能包含哪些流程、環(huán)節(jié)
舉例：購買商品
登錄->搜索商品->提交訂單->支付訂單->退出
4. 指標分析
分析性能需求指標（如“支持300人并發(fā)登錄”）是否合理
有必要測試這個需求，考慮需求指標是否合理？有沒有數(shù)據(jù)支撐？
通常，支撐數(shù)據(jù)可以從以下方面考慮：
1）采樣時間段內系統(tǒng)使用人數(shù)
2）采樣時間段內系統(tǒng)在線人數(shù)
3）采樣時間段內系統(tǒng)(頁面)訪問量
4）采樣時間段內請求數(shù)
....
常用分析思路：
1）2/8法則
2/8法則：80%的業(yè)務量在20%的時間里完成。這里，業(yè)務量泛指訪問量，請求數(shù)，數(shù)據(jù)量等
2）正態(tài)分布
3）按比例倍增
4）響應時間2-5-8原則
就是說，一般情況下，當用戶能夠在2秒以內得到響應時，會感覺系統(tǒng)的響應很快；當用戶在2-5秒之間得到響應時，會趕緊系統(tǒng)的響應速度還可以；當用戶在5-8秒以內得到響應時，會趕緊系統(tǒng)的速度很慢，但是還可以接受；而當用戶在超過8秒后仍然無法得到響應時，會感覺系統(tǒng)糟糕透了，或者認為系統(tǒng)已經(jīng)失去響應。
注意：這個要根據(jù)實際情況，有些情況下時間長點也是可以接受的，好比12306
舉例：
某公司后臺監(jiān)控，根據(jù)一段時間的采樣數(shù)據(jù)，分析得出日高峰時段(11:00-14:00)用戶下單請求數(shù)平均為1000，峰值為1500，根據(jù)這個計算并發(fā)請求數(shù)
時段：3個小時 -> 3 x 60 x 60 = 1080s
業(yè)務量：1500
吞吐量：1500 * 80% / (1080 * 20%) = 5.56請求數(shù)/s
假設用戶下單遵循正態(tài)分布，那么并發(fā)請求數(shù)峰值會肯定大于上述估算的吞吐量
注意:
1、2/8原則計算的結果并非在線并發(fā)用戶數(shù)，是系統(tǒng)要達到的處理能力（吞吐量）
2、如果要求更高系統(tǒng)性能，根據(jù)實際情況，也可以考慮1/9原則或其它更嚴格的算法
3、以上估值只是大致的估算，不是精確值
舉例：
想了下，暫時沒想到啥好的例子，大致就說一些涉及到數(shù)據(jù)量的性能測試，比如報表統(tǒng)計，或者是大數(shù)據(jù)挖掘，查詢等，怎么去估算數(shù)據(jù)量？
數(shù)據(jù)生命周期：
一般來說，數(shù)據(jù)都是有一定的生命周期的，時間的選取需要結合數(shù)據(jù)周期考慮。這里假設3年后系統(tǒng)性能仍然需要滿足業(yè)務需求。
數(shù)據(jù)增長率：
如果是老項目，可以考慮對應功能主表歷史數(shù)據(jù)存放情況
這里假設按年統(tǒng)計，比如第一年 10000，第二年 15000，第三年 20000，第四年25000，那么我們得出，以第一年為基準，數(shù)據(jù)增長率分別為 0.5，1，1.5，每年在上一年的基礎上，以5000的速度增長
預估3年后，數(shù)據(jù)增長率為 3，需要測試數(shù)據(jù)量為 （1+3）x 10000 = 40000
注意：
1、實際數(shù)據(jù)一般是沒上面舉例那么規(guī)律的，只能大致估算數(shù)據(jù)增長率。
2、一些大數(shù)據(jù)量的性能測試除了和數(shù)據(jù)量相關，還涉及到數(shù)據(jù)分布等，比如查詢，構造數(shù)據(jù)時需要結合實際，盡量貼近實際。
3、不同業(yè)務模塊，涉及表不一樣，數(shù)據(jù)量要求也是不一樣的，需要有區(qū)別的對待。
如果是新項目，那就比較不確定了，除非能收集相關數(shù)據(jù)。
二、系統(tǒng)分析
結合需求分析中第3點，分析系統(tǒng)架構。從功能實現(xiàn)上來看，怎么實現(xiàn)這個完整功能的。通常這些業(yè)務功能操作都對應著一個或多個請求(可能能是不同類型的請求，比如http, mysql等)，我們要做的是找出這些：
1）請求順序、請求之間相互調用關系
2）數(shù)據(jù)流向，數(shù)據(jù)是怎么走的，經(jīng)過哪些組件、服務器等
3）預測可能存在性能瓶頸的環(huán)節(jié)（組件、服務器等）
4）明確應用類型 IO型，還是CPU消耗性、內存消耗型-> 弄清楚重點監(jiān)控對象
5）關注應用是否采用多進程、多線程架構-> 多線程容易造成線程死鎖、數(shù)據(jù)庫死鎖，數(shù)據(jù)不一致等
6）是否使用集群/是否使用負載均衡
了解測試環(huán)境部署和生產(chǎn)環(huán)境部署差異，是否按1:1的比例部署
通常建議測試時先不考慮集群，采用單機測試，測試通過后再考慮使用集群，這樣有個比較，比較能說明問題
三、業(yè)務分析
1）明確要測試的功能業(yè)務中，功能業(yè)務占比，重要程度。
目的在于
<1>明確重點測試對象，安排測試優(yōu)先級
2）明確下“需求分析-指標分析”中相關業(yè)務功能所需基礎數(shù)據(jù)及數(shù)據(jù)量問題，因為那塊需求分析時可能只是大致估算下，評估指標是否合理，需要認真再分析下
四、用例設計
1）用例設計
通常是基于場景的測試用例設計
<1>單業(yè)務功能場景
運行測試期間，部分虛擬用戶執(zhí)行某種業(yè)務的某個環(huán)節(jié)操作，部分虛擬用戶執(zhí)行該業(yè)務功能的其它環(huán)節(jié)
或者
運行測試期間，部分虛擬用戶執(zhí)行某種業(yè)務功能，部分虛擬用戶執(zhí)行其它業(yè)務功能
注：這里用例沒說到多少用戶去跑，跑多久等，這里只是把他當作相同場景用例下的的一組組測試數(shù)據(jù)了。
2）事務定義
根據(jù)用例合理的定義事務，方便分析耗時（特別是混合業(yè)務功能場景測試），進而方便分析瓶頸。
比如，購買商品，我們可以把下訂單定義為一個事務，把支付也定義為一個事務。
3）場景監(jiān)控對象
針對每條用例，結合“系統(tǒng)分析”第4）點，明確可能的壓力點（比如數(shù)據(jù)庫、WEB服務器），需要監(jiān)控的對象，比如tps，耗時，CPU，內存，I/O等
五、測試策略
1）先進行混合業(yè)務功能場景的測試，在考慮進行測試單業(yè)務功能場景的測試
2）負載測試 -> 壓力測試-> 穩(wěn)定性測試-> 強度測試
注：如果測試穩(wěn)定性，時間建議至少8小時；
3）逐步加壓
比如開始前5分鐘，20個用戶，然后每隔5分鐘，增加20個用戶。
好處：不僅比較真實的模擬現(xiàn)實環(huán)境，而且在性能指標比較模糊，且不知道服務器處理能力的情況下，可以幫我們確定一個大致基準，因為通常情況下，隨著用戶數(shù)的不斷增加，服務器壓力也會隨著增加，如果服務器不夠強大，那么就會出現(xiàn)不能及時處理請求、處理請求失敗的情況下，對應的運行結果圖形中，運行曲線也會出現(xiàn)對應的形態(tài)，比如從原本程一條穩(wěn)定直線的情況，到突然極限下降、開始上下波動等，通過分析我們就能得出服務器大致處理能力，供后續(xù)測試參考。
4）單點并發(fā)
比如使用集合點，單獨針對某個環(huán)節(jié)的并發(fā)測試，通常是針對某個環(huán)節(jié)的性能調優(yōu)時使用。
常識：
a) 負載測試
保證系統(tǒng)能正常運行(通常是滿足某些系統(tǒng)性能指標)的前提下，讓被測對象承擔不同的工作量，以評估被測對象的最大處理能力及存在缺陷而進行的測試
b) 壓力測試
不保證系統(tǒng)能否正常運行的前提下，讓被測對象承擔不同工作量，以評估被測對象能提供的最大處理能力及存在缺陷而進行的測試
c) 穩(wěn)定性測試
測試系統(tǒng)的長期穩(wěn)定運行的能力。同疲勞強度測試的區(qū)別是，穩(wěn)定性測試的壓力強度較小，一般趨向于客戶現(xiàn)場日常狀態(tài)下的壓力強度，當然在通過時間不能保證穩(wěn)定性的狀態(tài)下，需要加大壓力強度來測試，此時的壓力強度則會高于正常值。
d) 強度測試
通常模擬系統(tǒng)在較差、異常資源配置下運行，如人為降低系統(tǒng)工作環(huán)境所需要的資源,如網(wǎng)絡帶寬,系統(tǒng)內存,數(shù)據(jù)鎖等等,以評估被測對象在資源不足的情況下的工作狀態(tài)
注：疲勞強度測試是一類特殊的強度測試，主要測試系統(tǒng)長時間運行后的性能表現(xiàn)，例如7x24小時的壓力測試。
六、工具選取
1）協(xié)議分析
一般性能測試工具都是基于協(xié)議開發(fā)的，所以先要明確應用使用的協(xié)議
2）工具選取
1）類型
開源工具、收費工具、自研工具
2）分析工具
<1>理解工具實現(xiàn)原理
常識：
1．同步請求：發(fā)出一個調用請求，在沒有得到結果之前，該調用就不返回。
2.異步請求：發(fā)出一個調用請求，在沒有得到請求結果之前，該調用可立即返回。該調用請求的處理者在處理完成后通過狀態(tài)、通知和回調等來通知調用者。
<3>使用長連接還是短連接
<2>Web服務器參數(shù)配置
八、網(wǎng)絡分析
1）網(wǎng)絡路由
通常為了排除網(wǎng)絡型瓶頸，通常建議在局域網(wǎng)下進行測試。
通常，這里我的分析思路是這樣的：
<1>檢查hosts文件的配置
不同DNS，其速度和準確率是不一樣的，比如114.114.114.114速度遠比8.8.8.8快，如果有用到DNS（特別是壓測機），需要考慮下是否適當
<3>確保路由正確設置
2）網(wǎng)絡帶寬
如果沒條件在局域網(wǎng)下測試，可能需要估算所需大致帶寬。
如果測試時是基于UI層操作的操作，那么得估算頁面平均大小，這個可以通過瀏覽器自帶工具查看打開單個頁面服務器返回的請求數(shù)據(jù)大小。如果是測試時是基于接口層的請求測試，可以通過工具查看服務器響應數(shù)據(jù)大小。
然后根據(jù)采集的頁面PV峰值、請求數(shù)峰值進行計算。
假設在 PV峰值、請求數(shù)峰值 = 1000，峰值時段：8:00 - 12:00，平均頁面、請求大小 200k
帶寬 = 1000 x 80% / (20% x 4 x 3600s) x 200KB x /1024 x 8bit ,單位MBps
注意： 這里涉及到瀏覽器緩存等因素，估值可能不準，大致估算。
九、硬件配置
1) CPU
型號，頻率，核數(shù)
2) 內存
3) 磁盤
不同磁盤類型，讀寫速率不一樣
4) 網(wǎng)卡
不同網(wǎng)卡，其傳輸速率也不一樣
注意：硬件配置最好和生產(chǎn)環(huán)境的配置保持一致。
【性能測試方案設計】相關文章：
紡織纖維靜電性能測試探討論文07-03
諾基亞107性能評測07-12
諾基亞515性能評測07-12
諾基亞2060性能評測07-12
華為 Ascend Mate性能評測07-11
汽車的分類與使用性能07-02
軟件測試07-11
股權轉讓的方案設計07-20
技術方案設計原則04-25