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系統金融行業應用的例子：

為了測試整個系統的效能，需要預先針對各個組成部分進行內部效能測試，如後臺主機的壓力測試、SNA gateway的壓力測試、大前置系統的壓力測試、前端系統的壓力測試、外系統接入的壓力測試等等。

在本次進行的內部壓力測試中，為了排除系統其它部分的影響，均需要隔離各自的部分，驅動和樁都使用軟體測試工具或自行編制程式來代替。在每個部分的內部壓力測試中，又均可以根據具體情況使用上一節說明的各種效能測試型別進行效能測量。

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 資料聚集問題

性 能測試中選用的資料應該在差異上進行分散，與實際生產資料的隨即差異分佈相似，充分測試系統在不同資料下的狀態。如果使用較單一的資料進行測試，一方面可 能使系統的區域性功能沒有被使用，導致效能測試資料不可靠；另外，如果系統對於同樣的資料處理有優化處理功能，也導致效能測試資料不可靠。

作者：西邊人，西說測試

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

頭條號、公眾號請搜尋(軟體測試資源站)。

關注後，私信回覆【資源包】獲取如下內容，

測試資料、測試工具、Python、效率軟體、自動化測試報告、梯子 等