品才網(wǎng)>輔助設(shè)計與工程計算>性能測試方案設(shè)計

性能測試方案設(shè)計

時間：2022-07-03 20:05:24 輔助設(shè)計與工程計算

性能測試方案設(shè)計

　　通過自動化的測試工具模擬多種正常、峰值以及異常負(fù)載條件來對系統(tǒng)的各項性能指標(biāo)進行測試，這就是性能測試。下面是性能測試方案設(shè)計，為大家提供參考。

性能測試方案設(shè)計

　　一、需求分析

　　1. 測試目的

　　為什么測？目的在于測試系統(tǒng)相關(guān)性能能否滿足業(yè)務(wù)需求。通常分以下兩種情況：

　　1）新項目上線

　　2）老項目優(yōu)化

　　如果是老項目優(yōu)化，可考慮是否存有歷史測試方案，如果有可以參考，或許可以省事很多。

　　2. 測試對象

　　要測啥？

　　測試對象可以歸結(jié)為“業(yè)務(wù)功能”。測試前，需要了解我們需要測試的業(yè)務(wù)功能（不深入細節(jié)）有哪些，比如“購買商品”、“寄送快遞”。

　　有沒有必要測？

　　需求來源哪里？，有沒有數(shù)據(jù)支撐測試這個需求的必要性？

　　通常，可以從以下幾個方面考慮：

　　1）是否核心功能，是否要求嚴(yán)格的質(zhì)量

　　2）是否常用、高頻使用的功能

　　3）可能占用系統(tǒng)較多資源的功能

　　4）使用人數(shù)多還是少

　　5）在線人數(shù)多還是少

　　3. 拆分對象

　　先從業(yè)務(wù)上來分，實現(xiàn)這個完整的功能包含哪些流程、環(huán)節(jié)

　　舉例：購買商品

　　登錄->搜索商品->提交訂單->支付訂單->退出

　　4. 指標(biāo)分析

　　分析性能需求指標(biāo)（如“支持300人并發(fā)登錄”）是否合理

　　有必要測試這個需求，考慮需求指標(biāo)是否合理？有沒有數(shù)據(jù)支撐？

　　通常，支撐數(shù)據(jù)可以從以下方面考慮：

　　1）采樣時間段內(nèi)系統(tǒng)使用人數(shù)

　　2）采樣時間段內(nèi)系統(tǒng)在線人數(shù)

　　3）采樣時間段內(nèi)系統(tǒng)(頁面)訪問量

　　4）采樣時間段內(nèi)請求數(shù)

　　....

　　常用分析思路：

　　1）2/8法則

　　2/8法則：80%的業(yè)務(wù)量在20%的時間里完成。這里，業(yè)務(wù)量泛指訪問量，請求數(shù)，數(shù)據(jù)量等

　　2）正態(tài)分布

　　3）按比例倍增

　　4）響應(yīng)時間2-5-8原則

　　就是說，一般情況下，當(dāng)用戶能夠在2秒以內(nèi)得到響應(yīng)時，會感覺系統(tǒng)的響應(yīng)很快；當(dāng)用戶在2-5秒之間得到響應(yīng)時，會趕緊系統(tǒng)的響應(yīng)速度還可以；當(dāng)用戶在5-8秒以內(nèi)得到響應(yīng)時，會趕緊系統(tǒng)的速度很慢，但是還可以接受；而當(dāng)用戶在超過8秒后仍然無法得到響應(yīng)時，會感覺系統(tǒng)糟糕透了，或者認(rèn)為系統(tǒng)已經(jīng)失去響應(yī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è)務(wù)量：1500

　　吞吐量：1500 * 80% / (1080 * 20%) = 5.56請求數(shù)/s

　　假設(shè)用戶下單遵循正態(tài)分布，那么并發(fā)請求數(shù)峰值會肯定大于上述估算的吞吐量

　　注意:

　　1、2/8原則計算的結(jié)果并非在線并發(fā)用戶數(shù)，是系統(tǒng)要達到的處理能力（吞吐量）

　　2、如果要求更高系統(tǒng)性能，根據(jù)實際情況，也可以考慮1/9原則或其它更嚴(yán)格的算法

　　3、以上估值只是大致的估算，不是精確值

　　舉例：

　　想了下，暫時沒想到啥好的例子，大致就說一些涉及到數(shù)據(jù)量的性能測試，比如報表統(tǒng)計，或者是大數(shù)據(jù)挖掘，查詢等，怎么去估算數(shù)據(jù)量？

　　數(shù)據(jù)生命周期：

　　一般來說，數(shù)據(jù)都是有一定的生命周期的，時間的選取需要結(jié)合數(shù)據(jù)周期考慮。這里假設(shè)3年后系統(tǒng)性能仍然需要滿足業(yè)務(wù)需求。

　　數(shù)據(jù)增長率：

　　如果是老項目，可以考慮對應(yīng)功能主表歷史數(shù)據(jù)存放情況

　　這里假設(shè)按年統(tǒng)計，比如第一年 10000，第二年 15000，第三年 20000，第四年25000，那么我們得出，以第一年為基準(zhǔn)，數(shù)據(jù)增長率分別為 0.5，1，1.5，每年在上一年的基礎(chǔ)上，以5000的速度增長

　　預(yù)估3年后，數(shù)據(jù)增長率為 3，需要測試數(shù)據(jù)量為（1+3）x 10000 = 40000

　　注意：

　　1、實際數(shù)據(jù)一般是沒上面舉例那么規(guī)律的，只能大致估算數(shù)據(jù)增長率。

　　2、一些大數(shù)據(jù)量的性能測試除了和數(shù)據(jù)量相關(guān)，還涉及到數(shù)據(jù)分布等，比如查詢，構(gòu)造數(shù)據(jù)時需要結(jié)合實際，盡量貼近實際。

　　3、不同業(yè)務(wù)模塊，涉及表不一樣，數(shù)據(jù)量要求也是不一樣的，需要有區(qū)別的對待。

　　如果是新項目，那就比較不確定了，除非能收集相關(guān)數(shù)據(jù)。

　　二、系統(tǒng)分析

　　結(jié)合需求分析中第3點，分析系統(tǒng)架構(gòu)。從功能實現(xiàn)上來看，怎么實現(xiàn)這個完整功能的。通常這些業(yè)務(wù)功能操作都對應(yīng)著一個或多個請求(可能能是不同類型的請求，比如http, mysql等)，我們要做的是找出這些：

　　1）請求順序、請求之間相互調(diào)用關(guān)系

　　2）數(shù)據(jù)流向，數(shù)據(jù)是怎么走的，經(jīng)過哪些組件、服務(wù)器等

　　3）預(yù)測可能存在性能瓶頸的環(huán)節(jié)（組件、服務(wù)器等）

　　4）明確應(yīng)用類型 IO型，還是CPU消耗性、內(nèi)存消耗型-> 弄清楚重點監(jiān)控對象

　　5）關(guān)注應(yīng)用是否采用多進程、多線程架構(gòu)-> 多線程容易造成線程死鎖、數(shù)據(jù)庫死鎖，數(shù)據(jù)不一致等

　　6）是否使用集群/是否使用負(fù)載均衡

　　了解測試環(huán)境部署和生產(chǎn)環(huán)境部署差異，是否按1:1的比例部署

　　通常建議測試時先不考慮集群，采用單機測試，測試通過后再考慮使用集群，這樣有個比較，比較能說明問題

　　三、業(yè)務(wù)分析

　　1）明確要測試的功能業(yè)務(wù)中，功能業(yè)務(wù)占比，重要程度。

　　目的在于

　　<1>明確重點測試對象，安排測試優(yōu)先級

　　2）明確下“需求分析-指標(biāo)分析”中相關(guān)業(yè)務(wù)功能所需基礎(chǔ)數(shù)據(jù)及數(shù)據(jù)量問題，因為那塊需求分析時可能只是大致估算下，評估指標(biāo)是否合理，需要認(rèn)真再分析下

　　四、用例設(shè)計

　　1）用例設(shè)計

　　通常是基于場景的測試用例設(shè)計

　　<1>單業(yè)務(wù)功能場景

　　運行測試期間，部分虛擬用戶執(zhí)行某種業(yè)務(wù)的某個環(huán)節(jié)操作，部分虛擬用戶執(zhí)行該業(yè)務(wù)功能的其它環(huán)節(jié)

　　或者

　　運行測試期間，部分虛擬用戶執(zhí)行某種業(yè)務(wù)功能，部分虛擬用戶執(zhí)行其它業(yè)務(wù)功能

　　注：這里用例沒說到多少用戶去跑，跑多久等，這里只是把他當(dāng)作相同場景用例下的的一組組測試數(shù)據(jù)了。

　　2）事務(wù)定義

　　根據(jù)用例合理的定義事務(wù)，方便分析耗時（特別是混合業(yè)務(wù)功能場景測試），進而方便分析瓶頸。

　　比如，購買商品，我們可以把下訂單定義為一個事務(wù)，把支付也定義為一個事務(wù)。

　　3）場景監(jiān)控對象

　　針對每條用例，結(jié)合“系統(tǒng)分析”第4）點，明確可能的壓力點（比如數(shù)據(jù)庫、WEB服務(wù)器），需要監(jiān)控的對象，比如tps，耗時，CPU，內(nèi)存，I/O等

　　五、測試策略

　　1）先進行混合業(yè)務(wù)功能場景的測試，在考慮進行測試單業(yè)務(wù)功能場景的測試

　　2）負(fù)載測試 -> 壓力測試-> 穩(wěn)定性測試-> 強度測試

　　注：如果測試穩(wěn)定性，時間建議至少8小時；

　　3）逐步加壓

　　比如開始前5分鐘，20個用戶，然后每隔5分鐘，增加20個用戶。

　　好處：不僅比較真實的模擬現(xiàn)實環(huán)境，而且在性能指標(biāo)比較模糊，且不知道服務(wù)器處理能力的情況下，可以幫我們確定一個大致基準(zhǔn)，因為通常情況下，隨著用戶數(shù)的不斷增加，服務(wù)器壓力也會隨著增加，如果服務(wù)器不夠強大，那么就會出現(xiàn)不能及時處理請求、處理請求失敗的情況下，對應(yīng)的運行結(jié)果圖形中，運行曲線也會出現(xiàn)對應(yīng)的形態(tài)，比如從原本程一條穩(wěn)定直線的情況，到突然極限下降、開始上下波動等，通過分析我們就能得出服務(wù)器大致處理能力，供后續(xù)測試參考。

　　4）單點并發(fā)

　　比如使用集合點，單獨針對某個環(huán)節(jié)的并發(fā)測試，通常是針對某個環(huán)節(jié)的性能調(diào)優(yōu)時使用。

　　常識：

　　a) 負(fù)載測試

　　保證系統(tǒng)能正常運行(通常是滿足某些系統(tǒng)性能指標(biāo))的前提下，讓被測對象承擔(dān)不同的工作量，以評估被測對象的最大處理能力及存在缺陷而進行的測試

　　b) 壓力測試

　　不保證系統(tǒng)能否正常運行的前提下，讓被測對象承擔(dān)不同工作量，以評估被測對象能提供的最大處理能力及存在缺陷而進行的測試

　　c) 穩(wěn)定性測試

　　測試系統(tǒng)的長期穩(wěn)定運行的能力。同疲勞強度測試的區(qū)別是，穩(wěn)定性測試的壓力強度較小，一般趨向于客戶現(xiàn)場日常狀態(tài)下的壓力強度，當(dāng)然在通過時間不能保證穩(wěn)定性的狀態(tài)下，需要加大壓力強度來測試，此時的壓力強度則會高于正常值。

　　d) 強度測試

　　通常模擬系統(tǒng)在較差、異常資源配置下運行，如人為降低系統(tǒng)工作環(huán)境所需要的資源,如網(wǎng)絡(luò)帶寬,系統(tǒng)內(nèi)存,數(shù)據(jù)鎖等等,以評估被測對象在資源不足的情況下的工作狀態(tài)

　　注：疲勞強度測試是一類特殊的強度測試，主要測試系統(tǒng)長時間運行后的性能表現(xiàn)，例如7x24小時的壓力測試。

　　六、工具選取

　　1）協(xié)議分析

　　一般性能測試工具都是基于協(xié)議開發(fā)的，所以先要明確應(yīng)用使用的協(xié)議

　　2）工具選取

　　1）類型

　　開源工具、收費工具、自研工具

　　2）分析工具

　　<1>理解工具實現(xiàn)原理

　　常識：