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

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