來源：http://www.51testing.com/html/60/n-82560.html
1. CS/CSS系統架構的基本概念
1.1系統架構定義
雖然B/S結構、J2EE架構愈來愈成爲流行模式，但基於傳統的C/S結構的應用程序還廣泛地應用於各種行業。尤其是金融行業中的商業銀行櫃面－核心帳務系統等。一方面由於傳統商業銀行一般都有大量的字符終端等需要複用的設備，一方面也是因爲他們存在大量密集的對實時性要求很高的高櫃業務，使用傳統的基於C/S結構或者C/S/S結構的應用效率更有保證。
C/S結構即CLIENT/SERVER結構。傳統的C/S結構一般分爲兩層：客戶端和服務器端。該結構的基本工作原理是，客戶程序向數據服務器發送SQL請求，服務器返回數據和結果。客戶端負責實現用戶接口功能，同時封裝了部分應用邏輯。服務器端的數據庫服務器主要提供數據存儲功能，也通過觸發器和存儲過程提供部分應用邏輯。
C/S/S結構即客戶/應用服務器/數據庫服務器三層結構，中間增加了應用服務器，通常實現應用邏輯，是連接客戶與數據庫服務器的橋樑。它響應用戶發來的請求執行某種業務任務，並與數據庫服務器打交道，技術實現上通常選用中間件產品，如BEA公司的TUXEDO和IBM公司的CICS等。（事實上J2EE架構的應用也屬於這種三層或多層結構，這裏不包括。）
三層或多層C/S結構與兩層C/S結構相比，它的優勢主要表現在：安全性加強、效率提高、易於維護、可伸縮性、可共享性、開放性好等。
1.2系統架構示意圖
1.3CS/CSS系統架構中性能測試的特點
1.3.1CS/CSS系統架構的性能影響因素
由於CS/CSS系統的以下特性，測試工程師對一個CS/CSS系統實施性能測試具有很大的難度：
*整個系統的各個部分使用多種操作系統，性能上有差別；
*整個系統架構的各個環節上使用多種數據庫，同樣在性能上有差別；
*應用是多個，分屬多個種類，分佈在不同設備上，包括自行開發的應用、第三方的應用；
*系統中的設備、組件通過不同協議進行連接、通訊；
*系統的內部接口多，性能瓶頸多；而系統的整體性能往往取決於最差的部分；需要分別測試和聯合測試
*系統的性能指標不光同應用系統架構有關，還和具體行業應用的業務模式有關；
*採用此架構的行業應用往往是一個7×24小時系統；
*採用此架構的行業應用可能高櫃業務多，這樣會影響對性能度量項的選取和轉換；
*各個環節基本上以交換數據報文的方式通信，其格式經常會比較複雜。
因此這樣的系統對於對測試工程師的知識的深度和廣度都是一個考驗。對於這樣的系統，到底如何使用什麼樣的測試策略、如何分析測試需求、如何選取性能度量項的轉換計算模型、如何確定測試內容和輪次、如何設計性能測試案例等等以及規劃和實施性能測試中的其它諸多問題，都需要遵循一個系統的方法來解決。
1.3.2CS/CSS系統架構中性能測試的基本策略
1. 確定好測試工作範圍
首先可以分析壓力測試中最容易出現瓶頸的地方，從而有目的地調整測試策略或測試環境，使壓力測試結果真實地反映出軟件的性能。例如，服務器的硬件限制、數據庫的訪問性能設置等常常會成爲制約軟件性能的重要因素，但這些因素顯然不是用戶最關心的，我們在測試之前就要通過一些設置把這些因素的影響調至最低。
另外，用戶更關心整個系統中哪個環節的性能情況也會影響工作範圍。如有的環節是全新系統，而有的環節已經是成熟系統只是稍有改動，這樣可能全新系統的局部性能測試就需要系統和全面一些。
2. 分析好客戶的性能測試需求
客戶是已經明確提出了性能指標，還是隻提供了用戶使用方式和歷史交易流量數據，需要我們自己進行性能基準的計算？性能測試的目的是驗證系統性能還是想確定目標系統的理想配置？是否還要使用測試結果預測在不同機型的處理能力？是否要求在性能測試各個輪次中安排性能調優過程等等問題都需要有針對性的解答。
3. 要作好性能測試的計劃和方案
測試計劃和方案中要注意測試需求分析階段提出的問題的解決。
4. 確定的測試通過準則、性能測試的計劃、結果要獲得客戶的認可
要和客戶確認，系統的性能指標達標的標準是什麼；對於性能測試中各個部分和步驟的計劃和結果，甚至是性能測試過程，都要根據其重要程度，決定是否需要客戶進行確認和簽字。獲得客戶的認可是最重要的。
1.3.3CS/CSS系統中性能測量與性能探測
性能測量
1. 在性能測試開始前必須認真規劃性能測量：
軟件性能測量技術範圍很廣。可以包括日誌、事件計數、事件持續時間、採樣等性能測量技術。
*確定性能測量的策略：我們要測試什麼？
*規劃性能測試中使用什麼樣的測量工具。
2. 測量的代表性
*測量結果要能夠反映出影響性能的重要因素：工作量負載、軟件和計算機系統環境。
3. 測量的可重複性
*能夠控制工作量負載、軟件和計算機系統環境，從而能夠重複測試過程。
性能探測技術
在進行性能測量時，可以使用標準的商用工具進行，但是往往標準工具提供的數據不能滿足要求。性能探測就是在程序的關鍵點插入代碼探針來測量軟件的執行特性。從而達到以下的目標：
– 性能數據獲取更方便
– 數據的詳細程度提高
– 數據收集方式更加可控
依據SPE（軟件性能工程）的建議，軟件探測需求應該作爲軟件體系結構的組成部分。在設計軟件時設計軟件探針。
所以在規劃項目中的性能測試過程中，要建議進行軟件設計時考慮島性能探測需求，爲性能測試中更好的進行性能測量做好準備。
1.3.4CS/CSS系統下性能測試的類型
廣義的性能測試包括許多類型。如：
*Scalability/load testing (規模化/壓力測試) ：通過在被測系統上不斷增加壓力，直到性能指標例如響應時間超過預定指標或者某種資源已經達到飽和狀態。這種測試可以找到系統的處理極限，爲系統調優提供數據。
*Performance testing (性能測試)：通過模擬生產運行的業務壓力量和使用場景組合測試系統的性能是否滿足生產性能要求。如以實際投產結構測試，求出最大的吞吐量與最佳迴應時間以保證上線的平穩，安全等。
*Configuration testing(配置測試)：通過測試找到系統各項資源的最優分配原則。
*Concurrency testing（併發測試）：測試多個用戶同時訪問同一個應用、同一個模塊或者數據記錄時是否存在死鎖或者其他性能問題。
*Stress testing （極限測試）：測試系統在一定飽和狀態下，例如CPU、內存在飽和使用飽和情況下，系統能夠處理的會話能力，以及系統是否會出現錯誤。
*Volume testing （容量測試）：測試系統能夠處理的最大會話能力。
*Reliability testing （可靠性測試）：通過給系統加載一定的業務壓力（例如資源在70-90%的使用率）的情況下，運行一段時間。
*Failover testing （失敗測試）：對於有冗餘備份和負載均衡的系統，通過這樣的測試來檢驗如果系統局部發生故障用戶是否能夠繼續使用系統，用戶將受到多大的影響。
在CS/CSS系統下實際的性能測試中，需要根據具體情況進行性能測試類型的選取和組合。
1.3.5CS/CSS系統下性能測試的組成部分
通常在一個CS/CSS系統中，分爲用戶界面層、服務邏輯層和數據服務層等幾個層次，分別對應着客戶、應用服務器、數據庫服務器。如在金融行業應用中，客戶端承載着櫃面業務，部署在網點（包括字符櫃員或圖形櫃員），還包括部署在自助設備上面的自助業務等；應用服務器上面主要是起到路由功能、業務處理功能、和渠道整合的作用；而核心業務處理系統包括交易平臺、業務邏輯、核心處理、數據處理等。
由於業務邏輯分佈在不同的環節，導致系統的內部接口多，性能瓶頸多，而系統的整體性能往往取決於最差的部分。所以對於整個系統的整體性能的測試可能需要針對各個環節分別做好各自的內部性能測試。
如下面的一個CS/CSS系統金融行業應用的例子：
在本次進行的內部壓力測試中，爲了排除系統其它部分的影響，均需要隔離各自的部分，驅動和樁都使用軟件測試工具或自行編制程序來代替。在每個部分的內部壓力測試中，又均可以根據具體情況使用上一節說明的各種性能測試類型進行性能測量。
2. CS/CSS系統架構中的性能測試的度量項計算模型
2.1 定義度量標準項
進行性能測試的模型分析時，首先要確定關鍵性能目標。它應該是通過與客戶溝通獲得的，這些目標應該是解決客戶關注的性能問題，也就是說，客戶的性能測試需求體現爲關鍵性能目標。性能目標應該是明確的、可度量的。例如：支持2000個併發用戶；連續運行30天不停機等。
在明確了關鍵性能目標和性能測試的通過/失敗準則後，需要定義如何度量關鍵性能目標和性能測試的通過/失敗準則。度量的標準項會影響測試方法和測試工具的選擇。舉例來說，如果要度量100個用戶併發的響應時間，就必須明確要度量以下哪一個標準項：
*每個併發用戶的響應時間
*在有99個用戶已經接入的情況下，第100個用戶的響應時間
*兩個指標都要度量
2.2 性能基準及測試強度估算
實際上，關鍵性能目標並不總是很容易明確的。客戶往往只有一些歷史數據和業務增長的一些預期比例等等。但是這些數據對於我們也是很有用的，它們可以作爲我們設計和測試使用的性能基準。
對於性能測試，在設計時就要首先提出設計的性能基準。所謂性能基準，就是要思考：多少人使用這個系統？使用時最大的用戶數是多少？用戶高峯期使用時間間隔多少，在多大數量級別上系統響應時間分別是什麼？數據增長量有多大？數據增長到什麼數量級和時間長短對硬件而言難於承受？網絡實現條件是什麼？在處理時CPU和內存增長如何控制？種種這些，然後設計時根據性能基準有條件的在編碼實現和硬件配置方面進行優化，測試只不過驗證系統是否達到預期設計目標。
但是現在的情況卻往往是：設計出來後要求性能測試，測試什麼然後是什麼，好比考試沒有標準答案卻要求大家及格一樣。或者是，客戶雖然已經明確的提出了關鍵性能指標，但是設計的時候沒有考慮，依賴於性能測試給出實際性能數據，然後再對比優化。性能測試在基於性能基準上，特別是基於經過計算和轉換得到的關鍵性能目標，才能得出預期結果。這一點，需要測試工程師向設計人員反覆灌輸這種觀念，否則，性能測試研究包括工具研究總是停留在討論階段。不要在編碼完成以後才考慮優化問題，如果等項目實施了，優化還沒有完成，就很難保證客戶滿意。
沒有目標的設計，如同城市間的交通問題一樣，我們抱怨建設者們缺乏遠見，而軟件設計人員同樣缺乏想象力。對於性能基準向關鍵性能目標的轉化，用以下例子來說明。
有200個用戶使用客戶端軟件進行業務處理（併發度至少要達到200併發），每年通過軟件進行處理的總業務量爲：2000萬筆業務/年。
測試強度估算時採用如下假設前提：
*全年的業務量集中在10個月完成，每個月20個工作日，每個工作日8個小時；
*採用80—20原理，每個工作日中80%的業務在20%的時間內完成，即每天80%的業務在1.6小時內完成；
測試壓力的估算結果：
去年全年處理業務約2000萬筆，其中15%的業務處理每筆業務需對應用服務器提交3次請求；70%的業務處理每筆業務需對應用服務器提交2次請求；其餘15%的業務每筆業務嚮應用服務器提交1次請求。根據以往統計結果，每年的業務增量爲15%，考慮到今後三年業務發展的需要，測試需按現有業務量的2倍進行。
每年總的請求數量爲：（2000*15%*3+2000*70%*2+2000*15%*1）*2="8000萬次/年。
每天的請求數量爲：8000/200="40萬次/天。
每秒的請求數量爲：（400000*80%）/（8*20%*3600）=55.6次/秒。
正常情況下，應用服務器處理請求的能力至少應達到：56次/秒。
或者，忽略提交的請求數，以業務交易數爲準，定義每秒鐘的交易數，及“吞吐量”。
如果再考慮未來幾年的交易量的增加（每年增長15％），則可以歸納爲：
? 吞吐量：(T4*80%) /(1.6*3600)
–T4 = T0 * (1 + 15%) ^ 4
–T0：當前日均交易量2000萬
–T4：未來4年日均交易量
另外，有時關鍵性能指標的確定和具體應用相關。如金融行業應用中的核心業務系統中會有日結、月結等批處理，往往使用一次批處理小於多少小時來表徵性能指標。
2.3 度量標準項和可採集的測量數據項轉換
只有使用明確的可採集到的數據才能真正反映系統的性能狀況。例如：
*每秒鐘運行成功的交易數量
*單一客戶端的響應時間(使用時間戳的差值，發出請求的時間和收到迴應的時間)
*CPU的佔用率
*網絡流量佔用率
*內存的佔用率
*硬盤使用率
2.4 壓力的分解
對於一個由很多環節組成的複雜系統來說，如果想要模擬實際環境進行整體的聯合性能測試的話，就需要針對整體壓力進行各個層次的分解。
如：下圖是一個實際系統進行的聯合性能測試。後臺主機系統最多的吞吐量是480筆/秒。。由於通信網關和主機在此環境中是1對1的關係，所以通信網關的壓力要達到480筆/秒。而一個通信網關對應着三個前置機，所以每個前置機要達到160筆/秒送達主機的吞吐量，纔可能使整個系統滿負荷運轉。考慮到其它層次類推。由於主機以外還存在其它服務系統，所以在前置機的壓力上面加了一個“X”代表其它服務系統要求的壓力。當某個層次的設備短缺，無法實際上達到其分解下來的壓力時，往往需要使用軟件手段，在上一層次上直接加壓力解決。
3. CS/CSS系統架構中的性能測試的規劃與實施要點
3.1 測試計劃中的人力資源計劃
由於性能測試時軟件測試領域比較複雜的類型，所以性能測試計劃中人力資源的計劃也比較重要。要充分考慮到測試組織、測試程序的編寫、測試設計、實現和執行、測試報告等等各種工作任務的人力資源需求情況。
一般情況下，一個工程類項目的性能測試工作由如下角色和職責：
*測試分析師：負責分析測試策略、編寫測試計劃、制訂測試方案、組織測試；
*測試工程師：測試例設計、實現；環境協調；對測試結果進行分析，編寫測試總結報告。
*測試員（通常也可測試工程師兼任）：測試執行；對測試過程進行記錄，收集、整理測試記錄數據。
*軟件工程師（有時由測試工程師兼任）：負責編寫、調試客戶端測試軟件和模擬軟件；數據庫管理系統的安裝、ofs配置及系統的預埋數據準備。
*系統工程師（有時由測試工程師兼任）：負責測試用的硬件維護及操作系統安裝、配置。
*上級測試負責人：負責對測試計劃及測試總結報告進行批准。
*客戶：必要時可參加測試，並提出具體的測試要求；可要求暫停測試；重要測試結論要簽字認可。
3.2 爲項目選擇適合的測試工具
在性能測試過程中，一定要有適合的測試工具支持。
性能測試所使用的測試工具包括：
負載模擬類工具
性能測量類工具
系統級測量工具：CPU、內存使用率統計
統計類：響應時間、吞吐
剖析類：代碼級測量工具，例如統計函數調用次數
對於測試工具，每個具體項目的需求是有差異的，不存在通用解決方案。而且，工具的引入需要時間、資金和人力的投入。
測試工具的選擇需要考慮性能測試中被測系統的需要，以及測試工具需要完成的功能。一般情況下的選擇方案包括：
*真實生產系統
*商用壓力測試工具
*定製壓力測試工具
第一種選擇限於資源以及準確性等因素在壓力測試中一般不採用，這裏不再討論。對於後兩種選擇的取捨主要考慮的因素包括：
*是否能夠滿足壓力測試中作爲模擬程序、負載模擬的需要
*是否能夠提供詳細，準確的性能測量數據
*測試工具在成本的限制因素，包括時間和金錢
*測試組對測試工具的掌握程度
有很多很好的自動化的性能測試工具。如：MI的Loadrunner、MI的Astra LoadTest、Empirix的E-load、Rational TeamTest等等。其中又以MI的Loadrunner最爲著名和常用。
有時在性能測試過程中也會採用自編的或定製的壓力測試工具的方案，主要基於如下的原因：
首先、由於被測系統本身的特點，滿足模擬程序需要的商用測試工具難以尋覓，即便是有靠近這方面需求的測試工具，考慮到費用以及培訓時間的因素，也會增加測試過程的風險。
其次，有時由於相關技術的成熟，選擇定製壓力測試工具的方案無論在設計，實現，還是在測試工具的掌握上都不存在不可控的風險；並且在測試過程中隨時滿足測試需要的及時性方面，定製的測試工具也有無可比擬的優勢。
最後、考慮到將來前置系統的產品化，對該系統進一步測試的需要會持續很久，定製的測試工具可以更好，更完善地滿足這種需求。同時，對於與對象系統採用同樣系統架構的項目都可以借鑑此定製測試工具的思想，快速地建立新的測試工具。
3.3 測試準備工作
性能測試的準備工作，可以包括測試數據的準備、測試工具準備、測試環境準備、試執行等部分。
3.3.1測試數據的準備
對於行業應用，尤其是金融行業應用，測試數據的準備中最重要的就是交易的選取。交易的選取有如下原則：
內部壓力測試：儘量選取幾個最消耗系統資源的交易，並覆蓋所有的交易形態（如會話式、批量式、異步式之類），這樣纔有可能最大限度的檢查出該部分的性能瓶頸；
整體聯合壓力測試：由於一般整體聯合壓力測試需要完全模擬實際生產情況，所以交易的抽樣選取相對比較複雜。通常需要進行當前交易量的收集和預測性能測試交易量，更重要的是確定交易發送比例的分佈。
如一個實際金融項目的交易發送比例的分佈：
先選取實際原始發送比例中前50位的交易。然後將其所有比例數相加（一定小於1），做爲新的基數，分別於各個交易的原始比例相除，即可得到使用工具模擬發送的比例。
此外，主要實際交易數據的獲得通常要從數據庫中使用腳本提取出來；還有可能需要自己利用某些規則自造一些數據。
3.3.2測試工具的準備
通常，要爲測試工具的編制和學習使用預留充足的時間。對於商用的測試工具，通常需要進行腳本的錄製和修改，場景的設定工作；對於自編工具，要有設計、編碼過程。而且，它還通常有其自己的配置文件和使用的數據文件，需要進行配置或數據格式轉換。
3.3.3測試環境準備
這裏需要注意的問題是，可能在後臺（充當樁的）數據庫中需要生成預埋測試數據，要保證其足夠且可重複生成或容易清理。另外測試環境準備好了以後，每次執行前的檢查環境過程也是非常重要的，可以避免大量的無用功。
4. 性能測試報告
4.1 測試結構數據的整理和分析
測試報告文檔的撰寫
1． 測試中應該生成的測試文件
測試記錄（測試負責人和參與測試的人員簽字）；
測試總結報告。
2． 測試總結報告中一般必須包含的內容
被測試軟件名稱、測試項、測試環境；
被測試軟件的壓力測試結論：響應時間、最大/最小併發數、失敗的次數、正常連續運行的最長/最短時間，併發數與失敗的關係等
總之必須包含預先定義的關鍵性能指標的數據、變化曲線分析和結論。
5. CS/CSS系統架構下性能測試中需要注意的問題
5.1 注意中間件的license、數據庫的用戶數等影響因素
有時候測試結果沒有達到預期並不一定是被測對象的問題，可能是中間件的license不足或者是使用的數據庫系統的併發用戶數的限制導致，有時還因爲配置項有問題等，需要綜合分析。
5.2 數據聚集問題
性能測試中選用的數據應該在差異上進行分散，與實際生產數據的隨即差異分佈相似，充分測試系統在不同數據下的狀態。如果使用較單一的數據進行測試，一方面可能使系統的局部功能沒有被使用，導致性能測試數據不可靠；另外，如果系統對於同樣的數據處理有優化處理功能，也導致性能測試數據不可靠。