1. CS/CSS系統(tǒng)架構(gòu)的基本概念

1.1系統(tǒng)架構(gòu)定義

雖然B/S結(jié)構(gòu)埃疫、J2EE架構(gòu)愈來愈成為流行模式军洼，但基于傳統(tǒng)的C/S結(jié)構(gòu)的應(yīng)用程序還廣泛地應(yīng)用于各種行業(yè)锤窑。尤其是金融行業(yè)中的商業(yè)銀行柜面－核心帳務(wù) 系統(tǒng)等。一方面由于傳統(tǒng)商業(yè)銀行一般都有大量的字符終端等需要復(fù)用的設(shè)備坦袍，一方面也是因為他們存在大量密集的對實時性要求很高的高柜業(yè)務(wù)十厢，使用傳統(tǒng)的基于 C/S結(jié)構(gòu)或者C/S/S結(jié)構(gòu)的應(yīng)用效率更有保證。

C/S結(jié)構(gòu)即CLIENT/SERVER結(jié)構(gòu)捂齐。傳統(tǒng)的C/S結(jié)構(gòu)一般分為兩層：客戶端和服務(wù)器端蛮放。該結(jié)構(gòu)的基本工作原理是，客戶程序向數(shù)據(jù)服務(wù)器發(fā)送 SQL請求奠宜，服務(wù)器返回數(shù)據(jù)和結(jié)果包颁。客戶端負責(zé)實現(xiàn)用戶接口功能压真，同時封裝了部分應(yīng)用邏輯娩嚼。服務(wù)器端的數(shù)據(jù)庫服務(wù)器主要提供數(shù)據(jù)存儲功能，也通過觸發(fā)器和 存儲過程提供部分應(yīng)用邏輯滴肿。

C/S/S結(jié)構(gòu)即客戶/應(yīng)用服務(wù)器/數(shù)據(jù)庫服務(wù)器三層結(jié)構(gòu)岳悟，中間增加了應(yīng)用服務(wù)器，通常實現(xiàn)應(yīng)用邏輯，是連接客戶與數(shù)據(jù)庫服務(wù)器的橋梁贵少。它響應(yīng)用戶發(fā)來的 請求執(zhí)行某種業(yè)務(wù)任務(wù)呵俏，并與數(shù)據(jù)庫服務(wù)器打交道，技術(shù)實現(xiàn)上通常選用中間件產(chǎn)品滔灶，如BEA公司的TUXEDO和IBM公司的CICS等普碎。（事實上J2EE 架構(gòu)的應(yīng)用也屬于這種三層或多層結(jié)構(gòu)，這里不包括宽气。）

三層或多層C/S結(jié)構(gòu)與兩層C/S結(jié)構(gòu)相比随常，它的優(yōu)勢主要表現(xiàn)在：安全性加強潜沦、效率提高萄涯、易于維護、可伸縮性唆鸡、可共享性涝影、開放性好等。

1.2系統(tǒng)架構(gòu)

1.3CS/CSS系統(tǒng)架構(gòu)中性能測試的特點

1.3.1CS/CSS系統(tǒng)架構(gòu)的性能影響因素

由于CS/CSS系統(tǒng)的以下特性争占，測試工程師對一個CS/CSS系統(tǒng)實施性能測試具有很大的難度：

*整個系統(tǒng)的各個部分使用多種操作系統(tǒng)燃逻，性能上有差別；

*整個系統(tǒng)架構(gòu)的各個環(huán)節(jié)上使用多種數(shù)據(jù)庫臂痕，同樣在性能上有差別伯襟；

*應(yīng)用是多個，分屬多個種類握童，分布在不同設(shè)備上姆怪，包括自行開發(fā)的應(yīng)用、第三方的應(yīng)用澡绩；

*系統(tǒng)中的設(shè)備稽揭、組件通過不同協(xié)議進行連接、通訊肥卡；

*系統(tǒng)的內(nèi)部接口多溪掀，性能瓶頸多；而系統(tǒng)的整體性能往往取決于最差的部分步鉴；需要分別測試和聯(lián)合測試

*系統(tǒng)的性能指標不光同應(yīng)用系統(tǒng)架構(gòu)有關(guān)揪胃，還和具體行業(yè)應(yīng)用的業(yè)務(wù)模式有關(guān)；

*采用此架構(gòu)的行業(yè)應(yīng)用往往是一個7×24小時系統(tǒng)氛琢；

*采用此架構(gòu)的行業(yè)應(yīng)用可能高柜業(yè)務(wù)多喊递，這樣會影響對性能度量項的選取和轉(zhuǎn)換；

*各個環(huán)節(jié)基本上以交換數(shù)據(jù)報文的方式通信艺沼，其格式經(jīng)常會比較復(fù)雜册舞。

因此這樣的系統(tǒng)對于對測試工程師的知識的深度和廣度都是一個考驗。對于這樣的系統(tǒng)障般，到底如何使用什么樣的測試策略调鲸、如何分析測試需求盛杰、如何選取性能度量項 的轉(zhuǎn)換計算模型、如何確定測試內(nèi)容和輪次藐石、如何設(shè)計性能測試案例等等以及規(guī)劃和實施性能測試中的其它諸多問題即供，都需要遵循一個系統(tǒng)的方法來解決。

1.3.2CS/CSS系統(tǒng)架構(gòu)中性能測試的基本策略

1. 確定好測試工作范圍

首先可以分析壓力測試中最容易出現(xiàn)瓶頸的地方于微，從而有目的地調(diào)整測試策略或測試環(huán)境逗嫡，使壓力測試結(jié)果真實地反映出軟件的性能。例如株依，服務(wù)器的硬件限制驱证、數(shù) 據(jù)庫的訪問性能設(shè)置等常常會成為制約軟件性能的重要因素，但這些因素顯然不是用戶最關(guān)心的恋腕，我們在測試之前就要通過一些設(shè)置把這些因素的影響調(diào)至最低抹锄。

另外，用戶更關(guān)心整個系統(tǒng)中哪個環(huán)節(jié)的性能情況也會影響工作范圍荠藤。如有的環(huán)節(jié)是全新系統(tǒng)伙单，而有的環(huán)節(jié)已經(jīng)是成熟系統(tǒng)只是稍有改動，這樣可能全新系統(tǒng)的局部性能測試就需要系統(tǒng)和全面一些哈肖。

2. 分析好客戶的性能測試需求

客戶是已經(jīng)明確提出了性能指標吻育，還是只提供了用戶使用方式和歷史交易流量數(shù)據(jù)，需要我們自己進行性能基準的計算淤井？性能測試的目的是驗證系統(tǒng)性能還是想確定 目標系統(tǒng)的理想配置布疼？是否還要使用測試結(jié)果預(yù)測在不同機型的處理能力？是否要求在性能測試各個輪次中安排性能調(diào)優(yōu)過程等等問題都需要有針對性的解答庄吼。

3. 要作好性能測試的計劃和方案

測試計劃和方案中要注意測試需求分析階段提出的問題的解決缎除。

4. 確定的測試通過準則、性能測試的計劃总寻、結(jié)果要獲得客戶的認可

要和客戶確認器罐，系統(tǒng)的性能指標達標的標準是什么；對于性能測試中各個部分和步驟的計劃和結(jié)果渐行，甚至是性能測試過程轰坊，都要根據(jù)其重要程度，決定是否需要客戶進行確認和簽字祟印。獲得客戶的認可是最重要的肴沫。

1.3.3CS/CSS系統(tǒng)中性能測量與性能探測

性能測量

1. 在性能測試開始前必須認真規(guī)劃性能測量：

軟件性能測量技術(shù)范圍很廣≡桃洌可以包括日志颤芬、事件計數(shù)、事件持續(xù)時間、采樣等性能測量技術(shù)站蝠。

*確定性能測量的策略：我們要測試什么汰具？

*規(guī)劃性能測試中使用什么樣的測量工具。

2. 測量的代表性

*測量結(jié)果要能夠反映出影響性能的重要因素：工作量負載菱魔、軟件和計算機系統(tǒng)環(huán)境留荔。

3. 測量的可重復(fù)性

*能夠控制工作量負載、軟件和計算機系統(tǒng)環(huán)境澜倦，從而能夠重復(fù)測試過程聚蝶。

性能探測技術(shù)

在進行性能測量時，可以使用標準的商用工具進行藻治，但是往往標準工具提供的數(shù)據(jù)不能滿足要求碘勉。性能探測就是在程序的關(guān)鍵點插入代碼探針來測量軟件的執(zhí)行特性。從而達到以下的目標：

– 性能數(shù)據(jù)獲取更方便

– 數(shù)據(jù)的詳細程度提高

– 數(shù)據(jù)收集方式更加可控

依據(jù)SPE（軟件性能工程）的建議栋艳，軟件探測需求應(yīng)該作為軟件體系結(jié)構(gòu)的組成部分恰聘。在設(shè)計軟件時設(shè)計軟件探針句各。

所以在規(guī)劃項目中的性能測試過程中吸占，要建議進行軟件設(shè)計時考慮島性能探測需求，為性能測試中更好的進行性能測量做好準備凿宾。

1.3.4CS/CSS系統(tǒng)下性能測試的類型

廣義的性能測試包括許多類型矾屯。如：

*Scalability/load testing (規(guī)模化/壓力測試) ：通過在被測系統(tǒng)上不斷增加壓力初厚，直到性能指標例如響應(yīng)時間超過預(yù)定指標或者某種資源已經(jīng)達到飽和狀態(tài)件蚕。這種測試可以找到系統(tǒng)的處理極限，為系統(tǒng)調(diào)優(yōu)提供數(shù)據(jù)产禾。

*Performance testing (性能測試)：通過模擬生產(chǎn)運行的業(yè)務(wù)壓力量和使用場景組合測試系統(tǒng)的性能是否滿足生產(chǎn)性能要求排作。如以實際投產(chǎn)結(jié)構(gòu)測試，求出最大的吞吐量與最佳回應(yīng)時間以保證上線的平穩(wěn)亚情，安全等妄痪。

*Configuration testing(配置測試)：通過測試找到系統(tǒng)各項資源的最優(yōu)分配原則。

*Concurrency testing（并發(fā)測試）：測試多個用戶同時訪問同一個應(yīng)用楞件、同一個模塊或者數(shù)據(jù)記錄時是否存在死鎖或者其他性能問題衫生。

*Stress testing （極限測試）：測試系統(tǒng)在一定飽和狀態(tài)下，例如CPU土浸、內(nèi)存在飽和使用飽和情況下罪针，系統(tǒng)能夠處理的會話能力，以及系統(tǒng)是否會出現(xiàn)錯誤黄伊。

*Volume testing （容量測試）：測試系統(tǒng)能夠處理的最大會話能力泪酱。

*Reliability testing （可靠性測試）：通過給系統(tǒng)加載一定的業(yè)務(wù)壓力（例如資源在70-90%的使用率）的情況下，運行一段時間。

*Failover testing （失敗測試）：對于有冗余備份和負載均衡的系統(tǒng)墓阀，通過這樣的測試來檢驗如果系統(tǒng)局部發(fā)生故障用戶是否能夠繼續(xù)使用系統(tǒng)愈腾，用戶將受到多大的影響。

在CS/CSS系統(tǒng)下實際的性能測試中岂津，需要根據(jù)具體情況進行性能測試類型的選取和組合虱黄。

1.3.5CS/CSS系統(tǒng)下性能測試的組成部分

通常在一個CS/CSS系統(tǒng)中，分為用戶界面層吮成、服務(wù)邏輯層和數(shù)據(jù)服務(wù)層等幾個層次橱乱，分別對應(yīng)著客戶、應(yīng)用服務(wù)器粱甫、數(shù)據(jù)庫服務(wù)器泳叠。如在金融行業(yè)應(yīng)用中，客 戶端承載著柜面業(yè)務(wù)茶宵，部署在網(wǎng)點（包括字符柜員或圖形柜員）危纫，還包括部署在自助設(shè)備上面的自助業(yè)務(wù)等；應(yīng)用服務(wù)器上面主要是起到路由功能乌庶、業(yè)務(wù)處理功能种蝶、 和渠道整合的作用；而核心業(yè)務(wù)處理系統(tǒng)包括交易平臺瞒大、業(yè)務(wù)邏輯螃征、核心處理、數(shù)據(jù)處理等透敌。

由于業(yè)務(wù)邏輯分布在不同的環(huán)節(jié)盯滚，導(dǎo)致系統(tǒng)的內(nèi)部接口多，性能瓶頸多酗电，而系統(tǒng)的整體性能往往取決于最差的部分魄藕。所以對于整個系統(tǒng)的整體性能的測試可能需要針對各個環(huán)節(jié)分別做好各自的內(nèi)部性能測試。

如下面的一個CS/CSS系統(tǒng)金融行業(yè)應(yīng)用的例子：

為了測試整個系統(tǒng)的性能撵术，需要預(yù)先針對各個組成部分進行內(nèi)部性能測試背率，如后臺主機的壓力測試、SNA gateway的壓力測試荷荤、大前置系統(tǒng)的壓力測試退渗、前端系統(tǒng)的壓力測試、外系統(tǒng)接入的壓力測試等等蕴纳。

在本次進行的內(nèi)部壓力測試中会油，為了排除系統(tǒng)其它部分的影響，均需要隔離各自的部分古毛，驅(qū)動和樁都使用軟件測試工具或自行編制程序來代替翻翩。在每個部分的內(nèi)部壓力測試中都许，又均可以根據(jù)具體情況使用上一節(jié)說明的各種性能測試類型進行性能測量。

2. CS/CSS系統(tǒng)架構(gòu)中的性能測試的度量項計算模型

2.1?定義度量標準項

進行性能測試的模型分析時嫂冻，首先要確定關(guān)鍵性能目標胶征。它應(yīng)該是通過與客戶溝通獲得的，這些目標應(yīng)該是解決客戶關(guān)注的性能問題桨仿，也就是說睛低，客戶的性能測試需求體現(xiàn)為關(guān)鍵性能目標。性能目標應(yīng)該是明確的服傍、可度量的钱雷。例如：支持2000個并發(fā)用戶；連續(xù)運行30天不停機等吹零。

在明確了關(guān)鍵性能目標和性能測試的通過/失敗準則后罩抗，需要定義如何度量關(guān)鍵性能目標和性能測試的通過/失敗準則。度量的標準項會影響測試方法和測試工具的選擇灿椅。舉例來說套蒂，如果要度量100個用戶并發(fā)的響應(yīng)時間，就必須明確要度量以下哪一個標準項：

*每個并發(fā)用戶的響應(yīng)時間

*在有99個用戶已經(jīng)接入的情況下茫蛹，第100個用戶的響應(yīng)時間

*兩個指標都要度量

2.2?性能基準及測試強度估算

實際上操刀，關(guān)鍵性能目標并不總是很容易明確的÷榛蹋客戶往往只有一些歷史數(shù)據(jù)和業(yè)務(wù)增長的一些預(yù)期比例等等馍刮。但是這些數(shù)據(jù)對于我們也是很有用的，它們可以作為我們設(shè)計和測試使用的性能基準窃蹋。

對于性能測試，在設(shè)計時就要首先提出設(shè)計的性能基準静稻。所謂性能基準警没，就是要思考：多少人使用這個系統(tǒng)？使用時最大的用戶數(shù)是多少振湾？用戶高峰期使用時間間隔 多少杀迹，在多大數(shù)量級別上系統(tǒng)響應(yīng)時間分別是什么？數(shù)據(jù)增長量有多大押搪？數(shù)據(jù)增長到什么數(shù)量級和時間長短對硬件而言難于承受树酪？網(wǎng)絡(luò)實現(xiàn)條件是什么？在處理時 CPU和內(nèi)存增長如何控制大州？種種這些续语，然后設(shè)計時根據(jù)性能基準有條件的在編碼實現(xiàn)和硬件配置方面進行優(yōu)化，測試只不過驗證系統(tǒng)是否達到預(yù)期設(shè)計目標厦画。

但是現(xiàn)在的情況卻往往是：設(shè)計出來后要求性能測試疮茄，測試什么然后是什么滥朱，好比考試沒有標準答案卻要求大家及格一樣×κ裕或者是徙邻，客戶雖然已經(jīng)明確的提出了關(guān)鍵 性能指標，但是設(shè)計的時候沒有考慮畸裳，依賴于性能測試給出實際性能數(shù)據(jù)缰犁，然后再對比優(yōu)化。性能測試在基于性能基準上怖糊，特別是基于經(jīng)過計算和轉(zhuǎn)換得到的關(guān)鍵性 能目標民鼓，才能得出預(yù)期結(jié)果。這一點蓬抄，需要測試工程師向設(shè)計人員反復(fù)灌輸這種觀念丰嘉，否則，性能測試研究包括工具研究總是停留在討論階段嚷缭。不要在編碼完成以后 才考慮優(yōu)化問題饮亏，如果等項目實施了，優(yōu)化還沒有完成阅爽，就很難保證客戶滿意路幸。

沒有目標的設(shè)計，如同城市間的交通問題一樣付翁，我們抱怨建設(shè)者們?nèi)狈h見简肴，而軟件設(shè)計人員同樣缺乏想象力。對于性能基準向關(guān)鍵性能目標的轉(zhuǎn)化百侧，用以下例子來說明砰识。

有200個用戶使用客戶端軟件進行業(yè)務(wù)處理（并發(fā)度至少要達到200并發(fā)），每年通過軟件進行處理的總業(yè)務(wù)量為：2000萬筆業(yè)務(wù)/年佣渴。

測試強度估算時采用如下假設(shè)前提：

*全年的業(yè)務(wù)量集中在10個月完成辫狼，每個月20個工作日，每個工作日8個小時辛润；

*采用80—20原理膨处，每個工作日中80%的業(yè)務(wù)在20%的時間內(nèi)完成，即每天80%的業(yè)務(wù)在1.6小時內(nèi)完成砂竖；

測試壓力的估算結(jié)果：

去年全年處理業(yè)務(wù)約2000萬筆真椿，其中15%的業(yè)務(wù)處理每筆業(yè)務(wù)需對應(yīng)用服務(wù)器提交3次請求；70%的業(yè)務(wù)處理每筆業(yè)務(wù)需對應(yīng)用服務(wù)器提交2次請求乎澄；其余 15%的業(yè)務(wù)每筆業(yè)務(wù)向應(yīng)用服務(wù)器提交1次請求突硝。根據(jù)以往統(tǒng)計結(jié)果，每年的業(yè)務(wù)增量為15%三圆，考慮到今后三年業(yè)務(wù)發(fā)展的需要狞换，測試需按現(xiàn)有業(yè)務(wù)量的2倍進 行避咆。

每年總的請求數(shù)量為：（2000*15%*3+2000*70%*2+2000*15%*1）*2="8000萬次/年。

每天的請求數(shù)量為：8000/200="40萬次/天修噪。

每秒的請求數(shù)量為：（400000*80%）/（8*20%*3600）=55.6次/秒查库。

正常情況下，應(yīng)用服務(wù)器處理請求的能力至少應(yīng)達到：56次/秒黄琼。

或者樊销，忽略提交的請求數(shù)，以業(yè)務(wù)交易數(shù)為準脏款，定義每秒鐘的交易數(shù)围苫，及“吞吐量”。

如果再考慮未來幾年的交易量的增加（每年增長15％）撤师，則可以歸納為：

吞吐量：(T4*80%) /(1.6*3600)

–T4 = T0 * (1 + 15%) ^ 4

–T0：當前日均交易量2000萬

–T4：未來4年日均交易量

另外剂府，有時關(guān)鍵性能指標的確定和具體應(yīng)用相關(guān)。如金融行業(yè)應(yīng)用中的核心業(yè)務(wù)系統(tǒng)中會有日結(jié)剃盾、月結(jié)等批處理腺占，往往使用一次批處理小于多少小時來表征性能指標。

2.3?度量標準項和可采集的測量數(shù)據(jù)項轉(zhuǎn)換

只有使用明確的可采集到的數(shù)據(jù)才能真正反映系統(tǒng)的性能狀況痒谴。例如：

*每秒鐘運行成功的交易數(shù)量

*單一客戶端的響應(yīng)時間(使用時間戳的差值衰伯，發(fā)出請求的時間和收到回應(yīng)的時間)

*CPU的占用率

*網(wǎng)絡(luò)流量占用率

*內(nèi)存的占用率

*硬盤使用率

2.4?壓力的分解

對于一個由很多環(huán)節(jié)組成的復(fù)雜系統(tǒng)來說，如果想要模擬實際環(huán)境進行整體的聯(lián)合性能測試的話积蔚，就需要針對整體壓力進行各個層次的分解意鲸。

如：下圖是一個實際系統(tǒng)進行的聯(lián)合性能測試。后臺主機系統(tǒng)最多的吞吐量是480筆/秒尽爆。怎顾。由于通信網(wǎng)關(guān)和主機在此環(huán)境中是1對1的關(guān)系，所以通信網(wǎng)關(guān)的壓 力要達到480筆/秒教翩。而一個通信網(wǎng)關(guān)對應(yīng)著三個前置機杆勇，所以每個前置機要達到160筆/秒送達主機的吞吐量，才可能使整個系統(tǒng)滿負荷運轉(zhuǎn)饱亿。考慮到其它層 次類推闰靴。由于主機以外還存在其它服務(wù)系統(tǒng)彪笼，所以在前置機的壓力上面加了一個“X”代表其它服務(wù)系統(tǒng)要求的壓力。當某個層次的設(shè)備短缺蚂且，無法實際上達到其分 解下來的壓力時配猫，往往需要使用軟件手段，在上一層次上直接加壓力解決杏死。

3. CS/CSS系統(tǒng)架構(gòu)中的性能測試的規(guī)劃與實施要點

3.1?測試計劃中的人力資源計劃

由于性能測試時軟件測試領(lǐng)域比較復(fù)雜的類型泵肄，所以性能測試計劃中人力資源的計劃也比較重要捆交。要充分考慮到測試組織、測試程序的編寫腐巢、測試設(shè)計品追、實現(xiàn)和執(zhí)行、測試報告等等各種工作任務(wù)的人力資源需求情況冯丙。

一般情況下肉瓦，一個工程類項目的性能測試工作由如下角色和職責(zé)：

*測試分析師：負責(zé)分析測試策略、編寫測試計劃胃惜、制訂測試方案泞莉、組織測試；

*測試工程師：測試例設(shè)計船殉、實現(xiàn)鲫趁；環(huán)境協(xié)調(diào)；對測試結(jié)果進行分析利虫，編寫測試總結(jié)報告挨厚。

*測試員（通常也可測試工程師兼任）：測試執(zhí)行；對測試過程進行記錄列吼，收集幽崩、整理測試記錄數(shù)據(jù)。

*軟件工程師（有時由測試工程師兼任）：負責(zé)編寫寞钥、調(diào)試客戶端測試軟件和模擬軟件慌申；數(shù)據(jù)庫管理系統(tǒng)的安裝、ofs配置及系統(tǒng)的預(yù)埋數(shù)據(jù)準備理郑。

*系統(tǒng)工程師（有時由測試工程師兼任）：負責(zé)測試用的硬件維護及操作系統(tǒng)安裝蹄溉、配置。

*上級測試負責(zé)人：負責(zé)對測試計劃及測試總結(jié)報告進行批準您炉。

*客戶：必要時可參加測試柒爵，并提出具體的測試要求；可要求暫停測試赚爵；重要測試結(jié)論要簽字認可棉胀。

3.2?為項目選擇適合的測試工具

在性能測試過程中俘枫，一定要有適合的測試工具支持慷垮。

性能測試所使用的測試工具包括：

負載模擬類工具

性能測量類工具

系統(tǒng)級測量工具：CPU、內(nèi)存使用率統(tǒng)計

統(tǒng)計類：響應(yīng)時間柬焕、吞吐

剖析類：代碼級測量工具窝剖，例如統(tǒng)計函數(shù)調(diào)用次數(shù)

對于測試工具麻掸，每個具體項目的需求是有差異的，不存在通用解決方案赐纱。而且脊奋，工具的引入需要時間熬北、資金和人力的投入。

測試工具的選擇需要考慮性能測試中被測系統(tǒng)的需要诚隙，以及測試工具需要完成的功能讶隐。一般情況下的選擇方案包括：

*真實生產(chǎn)系統(tǒng)

*商用壓力測試工具

*定制壓力測試工具

第一種選擇限于資源以及準確性等因素在壓力測試中一般不采用，這里不再討論最楷。對于后兩種選擇的取舍主要考慮的因素包括：

*是否能夠滿足壓力測試中作為模擬程序整份、負載模擬的需要

*是否能夠提供詳細，準確的性能測量數(shù)據(jù)

*測試工具在成本的限制因素籽孙，包括時間和金錢

*測試組對測試工具的掌握程度

有很多很好的自動化的性能測試工具烈评。如：MI的Loadrunner、MI的Astra LoadTest犯建、Empirix的E-load讲冠、Rational TeamTest等等。其中又以MI的Loadrunner最為著名和常用适瓦。

有時在性能測試過程中也會采用自編的或定制的壓力測試工具的方案竿开，主要基于如下的原因：

首先、由于被測系統(tǒng)本身的特點玻熙，滿足模擬程序需要的商用測試工具難以尋覓否彩，即便是有靠近這方面需求的測試工具，考慮到費用以及培訓(xùn)時間的因素嗦随，也會增加測試過程的風(fēng)險列荔。

其次，有時由于相關(guān)技術(shù)的成熟枚尼，選擇定制壓力測試工具的方案無論在設(shè)計贴浙，實現(xiàn)，還是在測試工具的掌握上都不存在不可控的風(fēng)險署恍；并且在測試過程中隨時滿足測試需要的及時性方面崎溃，定制的測試工具也有無可比擬的優(yōu)勢。

最后盯质、考慮到將來前置系統(tǒng)的產(chǎn)品化袁串，對該系統(tǒng)進一步測試的需要會持續(xù)很久，定制的測試工具可以更好呼巷，更完善地滿足這種需求般婆。同時，對于與對象系統(tǒng)采用同樣系統(tǒng)架構(gòu)的項目都可以借鑒此定制測試工具的思想朵逝，快速地建立新的測試工具。

3.3?測試準備工作

性能測試的準備工作乡范，可以包括測試數(shù)據(jù)的準備配名、測試工具準備啤咽、測試環(huán)境準備、試執(zhí)行等部分渠脉。

3.3.1測試數(shù)據(jù)的準備

對于行業(yè)應(yīng)用宇整，尤其是金融行業(yè)應(yīng)用，測試數(shù)據(jù)的準備中最重要的就是交易的選取芋膘。交易的選取有如下原則：

內(nèi)部壓力測試：盡量選取幾個最消耗系統(tǒng)資源的交易鳞青，并覆蓋所有的交易形態(tài)（如會話式、批量式为朋、異步式之類）臂拓，這樣才有可能最大限度的檢查出該部分的性能瓶頸；

整體聯(lián)合壓力測試：由于一般整體聯(lián)合壓力測試需要完全模擬實際生產(chǎn)情況习寸，所以交易的抽樣選取相對比較復(fù)雜胶惰。通常需要進行當前交易量的收集和預(yù)測性能測試交易量，更重要的是確定交易發(fā)送比例的分布霞溪。

如一個實際金融項目的交易發(fā)送比例的分布：

先選取實際原始發(fā)送比例中前50位的交易孵滞。然后將其所有比例數(shù)相加（一定小于1），做為新的基數(shù)鸯匹，分別于各個交易的原始比例相除坊饶，即可得到使用工具模擬發(fā)送的比例。

此外殴蓬，主要實際交易數(shù)據(jù)的獲得通常要從數(shù)據(jù)庫中使用腳本提取出來匿级；還有可能需要自己利用某些規(guī)則自造一些數(shù)據(jù)。

3.3.2測試工具的準備

通常科雳，要為測試工具的編制和學(xué)習(xí)使用預(yù)留充足的時間根蟹。對于商用的測試工具，通常需要進行腳本的錄制和修改糟秘，場景的設(shè)定工作简逮；對于自編工具，要有設(shè)計尿赚、編碼過程散庶。而且，它還通常有其自己的配置文件和使用的數(shù)據(jù)文件凌净，需要進行配置或數(shù)據(jù)格式轉(zhuǎn)換悲龟。

3.3.3測試環(huán)境準備

這里需要注意的問題是，可能在后臺（充當樁的）數(shù)據(jù)庫中需要生成預(yù)埋測試數(shù)據(jù)冰寻，要保證其足夠且可重復(fù)生成或容易清理须教。另外測試環(huán)境準備好了以后，每次執(zhí)行前的檢查環(huán)境過程也是非常重要的，可以避免大量的無用功轻腺。

4.?性能測試報告

4.1?測試結(jié)構(gòu)數(shù)據(jù)的整理和分析

測試報告文檔的撰寫

1． 測試中應(yīng)該生成的測試文件

測試記錄（測試負責(zé)人和參與測試的人員簽字）乐疆；

測試總結(jié)報告。

2． 測試總結(jié)報告中一般必須包含的內(nèi)容

被測試軟件名稱贬养、測試項挤土、測試環(huán)境；

被測試軟件的壓力測試結(jié)論：響應(yīng)時間误算、最大/最小并發(fā)數(shù)仰美、失敗的次數(shù)、正常連續(xù)運行的最長/最短時間儿礼，并發(fā)數(shù)與失敗的關(guān)系等

總之必須包含預(yù)先定義的關(guān)鍵性能指標的數(shù)據(jù)咖杂、變化曲線分析和結(jié)論。

5. CS/CSS系統(tǒng)架構(gòu)下性能測試中需要注意的問題

5.1?注意中間件的license蜘犁、數(shù)據(jù)庫的用戶數(shù)等影響因素

有時候測試結(jié)果沒有達到預(yù)期并不一定是被測對象的問題翰苫，可能是中間件的license不足或者是使用的數(shù)據(jù)庫系統(tǒng)的并發(fā)用戶數(shù)的限制導(dǎo)致，有時還因為配置項有問題等这橙，需要綜合分析奏窑。

5.2?數(shù)據(jù)聚集問題

性 能測試中選用的數(shù)據(jù)應(yīng)該在差異上進行分散，與實際生產(chǎn)數(shù)據(jù)的隨即差異分布相似屈扎，充分測試系統(tǒng)在不同數(shù)據(jù)下的狀態(tài)埃唯。如果使用較單一的數(shù)據(jù)進行測試，一方面可 能使系統(tǒng)的局部功能沒有被使用鹰晨，導(dǎo)致性能測試數(shù)據(jù)不可靠墨叛；另外，如果系統(tǒng)對于同樣的數(shù)據(jù)處理有優(yōu)化處理功能模蜡，也導(dǎo)致性能測試數(shù)據(jù)不可靠漠趁。

作者：西邊人，西說測試

程序爬蟲抓取有用資源共享給大家

頭條號忍疾、公眾號請搜索(軟件測試資源站)闯传。

關(guān)注后，私信回復(fù)【資源包】獲取如下內(nèi)容卤妒，

測試資料甥绿、測試工具、Python则披、效率軟件共缕、自動化測試報告、梯子 等