性能測試方案設計

性能測試方案設計

　　通過(guò)自動(dòng)化的測試工具模擬多種正常、峰值以及異常負載條件來(lái)對系統的各項性能指標進(jìn)行測試，這就是性能測試。下面是性能測試方案設計，為大家提供參考。

　　一、需求分析

　　1.   測試目的

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

　　1）新項目上線(xiàn)

　　2）老項目?jì)?yōu)化

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

　　2.   測試對象

　　要測啥？

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

　　有沒(méi)有必要測？

　　需求來(lái)源哪里？，有沒(méi)有數據支撐測試這個(gè)需求的必要性？

　　通常，可以從以下幾個(gè)方面考慮：

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

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

　　3）可能占用系統較多資源的功能

　　4）使用人數多還是少

　　5）在線(xiàn)人數多還是少

　　3.   拆分對象

　　先從業(yè)務(wù)上來(lái)分，實(shí)現這個(gè)完整的功能包含哪些流程、環(huán)節

　　舉例：購買(mǎi)商品

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

　　4.   指標分析

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

　　有必要測試這個(gè)需求，考慮需求指標是否合理？有沒(méi)有數據支撐？

　　通常，支撐數據可以從以下方面考慮：

　　1）采樣時(shí)間段內系統使用人數

　　2）采樣時(shí)間段內系統在線(xiàn)人數

　　3）采樣時(shí)間段內系統(頁(yè)面)訪(fǎng)問(wèn)量

　　4）采樣時(shí)間段內請求數

　　....

　　常用分析思路：

　　1）2/8法則

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

　　2）正態(tài)分布

　　3）按比例倍增

　　4）響應時(shí)間2-5-8原則

　　就是說(shuō)，一般情況下，當用戶(hù)能夠在2秒以?xún)鹊玫巾憫獣r(shí)，會(huì )感覺(jué)系統的響應很快；當用戶(hù)在2-5秒之間得到響應時(shí)，會(huì )趕緊系統的響應速度還可以；當用戶(hù)在5-8秒以?xún)鹊玫巾憫獣r(shí)，會(huì )趕緊系統的速度很慢，但是還可以接受；而當用戶(hù)在超過(guò)8秒后仍然無(wú)法得到響應時(shí)，會(huì )感覺(jué)系統糟糕透了，或者認為系統已經(jīng)失去響應。

　　注意：這個(gè)要根據實(shí)際情況，有些情況下時(shí)間長(cháng)點(diǎn)也是可以接受的，好比12306

　　舉例：

　　某公司后臺監控，根據一段時(shí)間的采樣數據，分析得出日高峰時(shí)段(11:00-14:00)用戶(hù)下單請求數平均為1000，峰值為1500，根據這個(gè)計算并發(fā)請求數

　　時(shí)段：3個(gè)小時(shí) -> 3 x 60 x 60 = 1080s

　　業(yè)務(wù)量：1500

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

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

　　注意:

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

　　2、如果要求更高系統性能，根據實(shí)際情況，也可以考慮1/9原則或其它更嚴格的算法

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

　　舉例：

　　想了下，暫時(shí)沒(méi)想到啥好的例子，大致就說(shuō)一些涉及到數據量的性能測試，比如報表統計，或者是大數據挖掘，查詢(xún)等，怎么去估算數據量？

　　數據生命周期：

　　一般來(lái)說(shuō)，數據都是有一定的生命周期的，時(shí)間的選取需要結合數據周期考慮。這里假設3年后系統性能仍然需要滿(mǎn)足業(yè)務(wù)需求。

　　數據增長(cháng)率：

　　如果是老項目，可以考慮對應功能主表歷史數據存放情況

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

　　預估3年后，數據增長(cháng)率為 3，需要測試數據量為 （1+3）x 10000 = 40000

　　注意：

　　1、實(shí)際數據一般是沒(méi)上面舉例那么規律的，只能大致估算數據增長(cháng)率。

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

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

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

　　二、系統分析

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

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

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

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

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

　　5）關(guān)注應用是否采用多進(jìn)程、多線(xiàn)程架構-> 多線(xiàn)程容易造成線(xiàn)程死鎖、數據庫死鎖，數據不一致等

　　6）是否使用集群/是否使用負載均衡

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

　　通常建議測試時(shí)先不考慮集群，采用單機測試，測試通過(guò)后再考慮使用集群，這樣有個(gè)比較，比較能說(shuō)明問(wèn)題

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

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

　　目的在于

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

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

　　四、用例設計

　　1）用例設計

　　通常是基于場(chǎng)景的測試用例設計

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

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

　　或者

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

　　注：這里用例沒(méi)說(shuō)到多少用戶(hù)去跑，跑多久等，這里只是把他當作相同場(chǎng)景用例下的的一組組測試數據了。

　　2）事務(wù)定義

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

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

　　3）場(chǎng)景監控對象

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

　　五、測試策略

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

　　2）負載測試 -> 壓力測試-> 穩定性測試-> 強度測試

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

　　3）逐步加壓

　　比如開(kāi)始前5分鐘，20個(gè)用戶(hù)，然后每隔5分鐘，增加20個(gè)用戶(hù)。

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

　　4）單點(diǎn)并發(fā)

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

　　常識：

　　a) 負載測試

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

　　b) 壓力測試

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

　　c) 穩定性測試

　　測試系統的長(cháng)期穩定運行的能力。同疲勞強度測試的區別是，穩定性測試的壓力強度較小，一般趨向于客戶(hù)現場(chǎng)日常狀態(tài)下的壓力強度，當然在通過(guò)時(shí)間不能保證穩定性的狀態(tài)下，需要加大壓力強度來(lái)測試，此時(shí)的壓力強度則會(huì )高于正常值。

　　d) 強度測試

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

　　注：疲勞強度測試是一類(lèi)特殊的強度測試，主要測試系統長(cháng)時(shí)間運行后的性能表現，例如7x24小時(shí)的壓力測試。

　　六、工具選取

　　1）協(xié)議分析

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

　　2）工具選取

　　1）類(lèi)型

　　開(kāi)源工具、收費工具、自研工具

　　2）分析工具

　　<1>理解工具實(shí)現原理

　　常識：

　　1．同步請求：發(fā)出一個(gè)調用請求，在沒(méi)有得到結果之前，該調用就不返回。

　　2.異步請求：發(fā)出一個(gè)調用請求，在沒(méi)有得到請求結果之前，該調用可立即返回。該調用請求的處理者在處理完成后通過(guò)狀態(tài)、通知和回調等來(lái)通知調用者。

　　<3>使用長(cháng)連接還是短連接

　　<2>Web服務(wù)器參數配置

　　八、網(wǎng)絡(luò )分析

　　1）網(wǎng)絡(luò )路由

　　通常為了排除網(wǎng)絡(luò )型瓶頸，通常建議在局域網(wǎng)下進(jìn)行測試。

　　通常，這里我的分析思路是這樣的：

　　<1>檢查hosts文件的配置

　　不同DNS，其速度和準確率是不一樣的，比如114.114.114.114速度遠比8.8.8.8快，如果有用到DNS（特別是壓測機），需要考慮下是否適當

　　<3>確保路由正確設置

　　2）網(wǎng)絡(luò )帶寬

　　如果沒(méi)條件在局域網(wǎng)下測試，可能需要估算所需大致帶寬。

　　如果測試時(shí)是基于UI層操作的操作，那么得估算頁(yè)面平均大小，這個(gè)可以通過(guò)瀏覽器自帶工具查看打開(kāi)單個(gè)頁(yè)面服務(wù)器返回的請求數據大小。如果是測試時(shí)是基于接口層的請求測試，可以通過(guò)工具查看服務(wù)器響應數據大小。

　　然后根據采集的頁(yè)面PV峰值、請求數峰值進(jìn)行計算。

　　假設在 PV峰值、請求數峰值 = 1000，峰值時(shí)段：8:00 - 12:00，平均頁(yè)面、請求大小 200k

　　帶寬 = 1000 x 80% / (20% x 4 x 3600s) x 200KB x /1024 x 8bit ,單位MBps

　　注意： 這里涉及到瀏覽器緩存等因素，估值可能不準，大致估算。

　　九、硬件配置

　　1) CPU

　　型號，頻率，核數

　　2) 內存

　　3) 磁盤(pán)

　　不同磁盤(pán)類(lèi)型，讀寫(xiě)速率不一樣

　　4) 網(wǎng)卡

　　不同網(wǎng)卡，其傳輸速率也不一樣

　　注意：硬件配置最好和生產(chǎn)環(huán)境的配置保持一致。

【性能測試方案設計】相關(guān)文章：

車(chē)輛動(dòng)態(tài)性能測試系統招標07-10

紡織纖維靜電性能測試探討論文07-03

諾基亞107性能評測07-12

諾基亞515性能評測07-12

諾基亞2060性能評測07-12

華為 Ascend Mate性能評測07-11

汽車(chē)的分類(lèi)與使用性能07-02

軟件測試07-11

股權轉讓的方案設計07-20

技術(shù)方案設計原則04-25