CS架構(gòu)性能測試

1、C/S測試通常，客戶 / 服務(wù)器軟件測試發(fā)生在三個(gè)不同的層次：1. 個(gè)體的客戶端應(yīng)用以 “ 分離的 ” 模式被測試 不考慮服務(wù)器和底層網(wǎng)絡(luò)的運(yùn)行；2. 客戶端軟件和關(guān)聯(lián)的服務(wù)器端應(yīng)用被一起測試，但網(wǎng)絡(luò)運(yùn)行不被明顯的考慮；3. 完整的 C/S 體系結(jié)構(gòu)，包括網(wǎng)絡(luò)運(yùn)行和性能，被測試。下面的測試方法是 C/S 應(yīng)用中經(jīng)常用到的： 應(yīng)用功能測試客戶端應(yīng)用被獨(dú)立地執(zhí)行，以揭示在其運(yùn)行中的錯(cuò)誤。服務(wù)器測試 測試服務(wù)器的協(xié)調(diào)和數(shù)據(jù)管理功能， 也考慮服務(wù)器性能 （整體反映時(shí)間和 數(shù)據(jù)吞吐量）。數(shù)據(jù)庫測試 測試服務(wù)器存儲的數(shù)據(jù)的精確性和完整性，檢查客戶端應(yīng)用提交的事務(wù)， 以保證數(shù)據(jù)被正確地存儲、更新和檢索。事務(wù)

2、測試 創(chuàng)建一系列的測試以保證每類事務(wù)被按照需求處理。 測試著重于處理的正確 性，也關(guān)注性能問題。網(wǎng)絡(luò)通信測試 這些測試驗(yàn)證網(wǎng)絡(luò)節(jié)點(diǎn)間的通信正常地發(fā)生， 并且消息傳遞、 事務(wù)和相 關(guān)的網(wǎng)絡(luò)交通無錯(cuò)的發(fā)生。C/S 結(jié)構(gòu)與 B/S 結(jié)構(gòu)的特點(diǎn)分析為了區(qū)別于傳統(tǒng)的 C/S模式，才特意將其稱為B/S模式。認(rèn)識到這些結(jié)構(gòu)的特征，對于系統(tǒng)的選型而言是很關(guān)鍵的。1、系統(tǒng)的性能在系統(tǒng)的性能方面， B/S 占有優(yōu)勢的是其異地瀏覽和信息采集的靈活性。任何時(shí)間、任何地 點(diǎn)、任何系統(tǒng)，只要可以使用瀏覽器上網(wǎng)，就可以使用 B/S 系統(tǒng)的終端。不過，采用 B/S 結(jié)構(gòu)，客戶端只能完成瀏覽、查詢、數(shù)據(jù)輸入等簡單功能，絕大部分

3、工作由 服務(wù)器承擔(dān)，這使得服務(wù)器的負(fù)擔(dān)很重。采用C/S結(jié)構(gòu)時(shí)，客戶端和服務(wù)器端都能夠處理任 務(wù)，這雖然對客戶機(jī)的要求較高，但因此可以減輕服務(wù)器的壓力。而且，由于客戶端使用瀏覽器，使得網(wǎng)上發(fā)布的信息必須是以 HTML 格式為主，其它格式文件多半是以附件的形式存 放。而HTML格式文件（也就是 Web頁面）不便于編輯修改，給文件管理帶來了許多不便。2、系統(tǒng)的開發(fā)C/S結(jié)構(gòu)是建立在中間件產(chǎn)品基礎(chǔ)之上的，要求應(yīng)用開發(fā)者自己去 處理事務(wù)管理、消息隊(duì)列、數(shù)據(jù)的復(fù)制和同步、通信安全等系統(tǒng)級 的問題。這對應(yīng)用開發(fā)者提出了較高的要求，而且 迫使應(yīng)用開發(fā)者投入很多精力來解決應(yīng)用程序以外的問題。 這使得應(yīng)用程序的維

4、護(hù)、 移植和 互操作變得復(fù)雜。如果客戶端是在不同的操作系統(tǒng)上，C/S結(jié)構(gòu)的軟件需要開發(fā)不同版本的客戶端軟件。但是，與 B/S 結(jié)構(gòu)相比， C/S 技術(shù)發(fā)展歷史更為“悠久”。從技術(shù)成熟度及軟 件設(shè)計(jì)、開發(fā)人員的掌握水平來看，C/S技術(shù)應(yīng)是更成熟、更可靠的。3、系統(tǒng)的升級維護(hù)C/S 系統(tǒng)的各部分模塊中有一部分改變， 就要關(guān)聯(lián)到其它模塊的變動(dòng)， 使系統(tǒng)升級成本比較 大。 B/S 與 C/S 處理模式相比，則大大簡化了客戶端，只要客戶端機(jī)器能上網(wǎng)就可以。對于 B/S 而言， 開發(fā)、 維護(hù)等幾乎所有工作也都集中在服務(wù)器端， 當(dāng)企業(yè)對網(wǎng)絡(luò)應(yīng)用進(jìn)行升級時(shí)， 只需更新服務(wù)器端的軟件就可以， 這減輕了異地用戶系

5、統(tǒng)維護(hù)與升級的成本。如果客戶端的軟件系統(tǒng)升級比較頻繁， 那么 B/S 架構(gòu)的產(chǎn)品優(yōu)勢明顯所有的升級操作只需要針對服務(wù) 器進(jìn)行，這對那些點(diǎn)多面廣的應(yīng)用是很有價(jià)值的，例如一些招聘網(wǎng)站就需要采用B/S 模式，客戶端分散，且應(yīng)用簡單，只需要進(jìn)行簡單的瀏覽和少量信息的錄入。4、C/S 模式的優(yōu)點(diǎn)和缺點(diǎn) C/S 模式的優(yōu)點(diǎn) 由于客戶端實(shí)現(xiàn)與服務(wù)器的直接相連，沒有中間環(huán)節(jié)，因此 響應(yīng)速度快 。 操作界面漂亮、形式多樣，可以充分滿足客戶自身的個(gè)性化要求。 C/S 結(jié)構(gòu)的管理信息系統(tǒng)具有較強(qiáng)的 事務(wù)處理能力 ，能實(shí)現(xiàn)復(fù)雜的業(yè)務(wù)流程。 C/S 模式的缺點(diǎn) 需要專門的客戶端安裝程序， 分布功能弱， 針對點(diǎn)多面廣且不

6、具備網(wǎng)絡(luò)條件的用戶群體， 不能夠?qū)崿F(xiàn)快速部署安裝和配置。 兼容性差，對于不同的開發(fā)工具，具有較大的局限性。若采用不同工具，需要重新改寫 程序。 開發(fā)成本較高，需要具有一定專業(yè)水準(zhǔn)的技術(shù)人員才能完成。5、B/S 模式的優(yōu)點(diǎn)和缺點(diǎn) B/S 模式的優(yōu)點(diǎn) 具有 分布性特點(diǎn) ，可以隨時(shí)隨地進(jìn)行查詢、瀏覽等業(yè)務(wù)處理。 業(yè)務(wù)擴(kuò)展簡單方便，通過增加網(wǎng)頁即可增加服務(wù)器功能。 維護(hù)簡單方便，只需要改變網(wǎng)頁，即可實(shí)現(xiàn)所有用戶的同步更新。 開發(fā)簡單，共享性強(qiáng)。 B/S 模式的缺點(diǎn) 個(gè)性化特點(diǎn)明顯降低，無法實(shí)現(xiàn)具有個(gè)性化的功能要求。 操作是以鼠標(biāo)為最基本的操作方式，無法滿足快速操作的要求。 頁面動(dòng)態(tài)刷新，響應(yīng)速度明顯降

7、低。 無法實(shí)現(xiàn)分頁顯示 ，給數(shù)據(jù)庫訪問造成較大的壓力。 功能弱化，難以實(shí)現(xiàn)傳統(tǒng)模式下的特殊功能要求。近年來，隨著軟硬件技術(shù)發(fā)展和人們意識的提高，Web應(yīng)用得到廣泛的普及，一方面在互聯(lián)網(wǎng)浪潮的推動(dòng)下，基于互聯(lián)網(wǎng)的信息共享和電子商務(wù)不斷發(fā)展，像新浪、搜狐、8848 等大型網(wǎng)站不斷涌現(xiàn)出來，另一方面隨著Java、CGI等網(wǎng)絡(luò)技術(shù)的成熟， 基于B/S結(jié)構(gòu)的大型軟件逐漸顯示出巨大的優(yōu)勢。 同時(shí)，也就產(chǎn)生了一個(gè)焦點(diǎn)問題， 什么樣的服務(wù)器能夠滿足不同 用戶的需求，怎么能夠保證 Web服務(wù)器能夠長期穩(wěn)定地運(yùn)行，為了滿足這樣的需求 Web測試也就同樣變得十分重要。當(dāng)前Web測試主要通過Web測試工具加上良好的測

8、試案例完成的，我們認(rèn)為主要有以下兩種測試類型：基準(zhǔn)測試、非基準(zhǔn)測試基準(zhǔn)測試：主要指測試工具已經(jīng)提供了標(biāo)準(zhǔn)的測試案例庫，包括靜態(tài)測試案例（HTM、JPG、動(dòng)態(tài)測試案例（CGI）和SSL測試案例等。這類測試工具分為測試案例庫、控制臺程 序、客戶端程序三個(gè)部分。它的原理是，Web服務(wù)器開啟特定的 Web服務(wù)程序，并且運(yùn)行上述測試案例，由控制臺程序控制各個(gè)客戶端按照一定的腳本訪問順序遍歷Web服務(wù)器的各個(gè)測試案例，每個(gè)請求完成后，各個(gè)客戶端向控制臺報(bào)告訪問的結(jié)構(gòu)， 當(dāng)一個(gè)測試集完成后由 控制臺將所有的信息綜合統(tǒng)計(jì)，測試過程中控制臺還需要采用SNMP協(xié)議對服務(wù)器進(jìn)行實(shí)時(shí)監(jiān)控，綜合兩個(gè)方面的因素可以反映出

9、Web服務(wù)器在不同壓力情況下的綜合性能。在測試過程中，主要影響測試結(jié)果的因素有網(wǎng)絡(luò)環(huán)境、客戶端性能。目前無論IA 架構(gòu)服務(wù)器還是SUN HP IBM的UNIX服務(wù)器性能都越來越優(yōu)越，有可能出現(xiàn)在100MB網(wǎng)絡(luò)下不能夠提供足夠的網(wǎng)絡(luò)壓力，有可能網(wǎng)絡(luò)首先出現(xiàn)瓶頸，這樣就需要擴(kuò)展到1000MB網(wǎng)絡(luò)環(huán)境或使用多個(gè)網(wǎng)段對服務(wù)器提供足夠的壓力，而穩(wěn)定的客戶端對于測試來說也是十分重要的， 因?yàn)榭蛻舳巳绻霈F(xiàn)性能下降， 就會造成系統(tǒng)崩潰或者不能提供穩(wěn)定的測試壓力從而導(dǎo)致測 試結(jié)果出現(xiàn)偏差；一臺客戶端到底能夠穩(wěn)定運(yùn)行多少數(shù)量的連接是根據(jù)不同的硬件配置和操 作系統(tǒng)決定的，因此對客戶端的硬件資源進(jìn)行監(jiān)控是保證客戶端

10、可以穩(wěn)定運(yùn)行的必要手段。由于這類測試工具使用的是工具開發(fā)商提供的測試案例集，雖然也具有一定的權(quán)威性， 但是目前再完美的測試案例集也不能涵蓋所有的Web應(yīng)用情況，所以也不能夠完全體現(xiàn)出Web服務(wù)器完整的性能，因此該類測試工具更加適合IT媒體對Web類服務(wù)器軟硬件的橫向?qū)Ρ葴y試，在測試對象和環(huán)境大體統(tǒng)一的情況下，可以比較出各個(gè)測試對象的性能差異。而對于有實(shí)際應(yīng)用背景的 Web服務(wù)器進(jìn)行測試，使用這樣的測試工具就不適合了，我們在以后的測試漫談中會繼續(xù)介紹。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)用程序還廣

11、泛地應(yīng)用于各種行業(yè)。尤其是金融行業(yè)中的商業(yè)銀行柜面核心帳 務(wù)系統(tǒng)等。一方面由于傳統(tǒng)商業(yè)銀行一般都有大量的字符終端等需要復(fù)用的設(shè) 備，一方面也是因?yàn)樗麄兇嬖诖罅棵芗膶?shí)時(shí)性要求很高的高柜業(yè)務(wù)， 使用傳 統(tǒng)的基于C/S結(jié)構(gòu)或者C/S/S結(jié)構(gòu)的應(yīng)用效率更有保證。C/S結(jié)構(gòu)即CLIENT/SERVE結(jié)構(gòu)。傳統(tǒng)的C/S結(jié)構(gòu)一般分為兩層：客戶端和 服務(wù)器端。該結(jié)構(gòu)的基本工作原理是，客戶程序向數(shù)據(jù)服務(wù)器發(fā)送SQL請求，服 務(wù)器返回?cái)?shù)據(jù)和結(jié)果。 客戶端負(fù)責(zé)實(shí)現(xiàn)用戶接口功能， 同時(shí)封裝了部分應(yīng)用邏輯。 服務(wù)器端的數(shù)據(jù)庫服務(wù)器主要提供數(shù)據(jù)存儲功能， 也通過觸發(fā)器和存儲過程提供 部分應(yīng)用邏輯。C/S/S 結(jié)構(gòu)即客

12、戶 /應(yīng)用服務(wù)器 / 數(shù)據(jù)庫服務(wù)器三層結(jié)構(gòu)，中間增加了應(yīng)用 服務(wù)器，通常實(shí)現(xiàn)應(yīng)用邏輯， 是連接客戶與數(shù)據(jù)庫服務(wù)器的橋梁。 它響應(yīng)用戶發(fā) 來的請求執(zhí)行某種業(yè)務(wù)任務(wù)， 并與數(shù)據(jù)庫服務(wù)器打交道， 技術(shù)實(shí)現(xiàn)上通常選用中 間件產(chǎn)品，女口 BEA公司的TUXED和IBM公司的CICS等。（事實(shí)上J2EE架構(gòu)的 應(yīng)用也屬于這種三層或多層結(jié)構(gòu)，這里不包括。）三層或多層 C/S 結(jié)構(gòu)與兩層 C/S 結(jié)構(gòu)相比， 它的優(yōu)勢主要表現(xiàn)在： 安全性加 強(qiáng)、效率提高、易于維護(hù)、可伸縮性、可共享性、開放性好等。1.2 系統(tǒng)架構(gòu)示意圖1.3 CS/CSS 系統(tǒng)架構(gòu)中性能測試的特點(diǎn)1.3.1 CS/CSS 系統(tǒng)架構(gòu)的性能影響因素

13、由于CS/CSS系統(tǒng)的以下特性，測試工程師對一個(gè)CS/CSS系統(tǒng)實(shí)施性能測試 具有很大的難度：l 整個(gè)系統(tǒng)的各個(gè)部分使用多種操作系統(tǒng)，性能上有差別；l 整個(gè)系統(tǒng)架構(gòu)的各個(gè)環(huán)節(jié)上使用多種數(shù)據(jù)庫，同樣在性能上有差別；l 應(yīng)用是多個(gè)，分屬多個(gè)種類，分布在不同設(shè)備上，包括自行開發(fā)的應(yīng)用、 第三方的應(yīng)用；l 系統(tǒng)中的設(shè)備、組件通過不同協(xié)議進(jìn)行連接、通訊；l 系統(tǒng)的內(nèi)部接口多， 性能瓶頸多；而系統(tǒng)的整體性能往往取決于最差的部 分；需要分別測試和聯(lián)合測試l 系統(tǒng)的性能指標(biāo)不光同應(yīng)用系統(tǒng)架構(gòu)有關(guān)， 還和具體行業(yè)應(yīng)用的業(yè)務(wù)模式 有關(guān)；I采用此架構(gòu)的行業(yè)應(yīng)用往往是一個(gè) 7X 24小時(shí)系統(tǒng)；l 采用此架構(gòu)的行業(yè)應(yīng)用

14、可能高柜業(yè)務(wù)多， 這樣會影響對性能度量項(xiàng)的選取 和轉(zhuǎn)換；I 各個(gè)環(huán)節(jié)基本上以交換數(shù)據(jù)報(bào)文的方式通信，其格式經(jīng)常會比較復(fù)雜。因此這樣的系統(tǒng)對于對測試工程師的知識的深度和廣度都是一個(gè)考驗(yàn)。 對于 這樣的系統(tǒng)， 到底如何使用什么樣的測試策略、 如何分析測試需求、 如何選取性 能度量項(xiàng)的轉(zhuǎn)換計(jì)算模型、 如何確定測試內(nèi)容和輪次、 如何設(shè)計(jì)性能測試案例等 等以及規(guī)劃和實(shí)施性能測試中的其它諸多問題， 都需要遵循一個(gè)系統(tǒng)的方法來解 決。1.3.2 CS/CSS 系統(tǒng)架構(gòu)中性能測試的基本策略1. 確定好測試工作范圍首先可以分析壓力測試中最容易出現(xiàn)瓶頸的地方， 從而有目的地調(diào)整測試策 略或測試環(huán)境， 使壓力測試結(jié)

15、果真實(shí)地反映出軟件的性能。 例如， 服務(wù)器的硬件 限制、數(shù)據(jù)庫的訪問性能設(shè)置等常常會成為制約軟件性能的重要因素， 但這些因 素顯然不是用戶最關(guān)心的， 我們在測試之前就要通過一些設(shè)置把這些因素的影響 調(diào)至最低。另外，用戶更關(guān)心整個(gè)系統(tǒng)中哪個(gè)環(huán)節(jié)的性能情況也會影響工作范圍。 如有 的環(huán)節(jié)是全新系統(tǒng)， 而有的環(huán)節(jié)已經(jīng)是成熟系統(tǒng)只是稍有改動(dòng)， 這樣可能全新系 統(tǒng)的局部性能測試就需要系統(tǒng)和全面一些。2. 分析好客戶的性能測試需求客戶是已經(jīng)明確提出了性能指標(biāo)， 還是只提供了用戶使用方式和歷史交易流 量數(shù)據(jù)，需要我們自己進(jìn)行性能基準(zhǔn)的計(jì)算？性能測試的目的是驗(yàn)證系統(tǒng)性能還 是想確定目標(biāo)系統(tǒng)的理想配置？是否還要

16、使用測試結(jié)果預(yù)測在不同機(jī)型的處理 能力？是否要求在性能測試各個(gè)輪次中安排性能調(diào)優(yōu)過程等等問題都需要有針 對性的解答。3. 要作好性能測試的計(jì)劃和方案 測試計(jì)劃和方案中要注意測試需求分析階段提出的問題的解決。4. 確定的測試通過準(zhǔn)則、性能測試的計(jì)劃、結(jié)果要獲得客戶的認(rèn)可 要和客戶確認(rèn)， 系統(tǒng)的性能指標(biāo)達(dá)標(biāo)的標(biāo)準(zhǔn)是什么； 對于性能測試中各個(gè)部 分和步驟的計(jì)劃和結(jié)果， 甚至是性能測試過程， 都要根據(jù)其重要程度， 決定是否 需要客戶進(jìn)行確認(rèn)和簽字。獲得客戶的認(rèn)可是最重要的。1.3.3 CS/CSS 系統(tǒng)中性能測量與性能探測u 性能測量1. 在性能測試開始前必須認(rèn)真規(guī)劃性能測量： 軟件性能測量技術(shù)范圍很

17、廣。可以包括日志、事件計(jì)數(shù)、事件持續(xù)時(shí)間、采 樣等性能測量技術(shù)。l 確定性能測量的策略：我們要測試什么？l 規(guī)劃性能測試中使用什么樣的測量工具。2. 測量的代表性l 測量結(jié)果要能夠反映出影響性能的重要因素： 工作量負(fù)載、 軟件和計(jì)算機(jī) 系統(tǒng)環(huán)境。3. 測量的可重復(fù)性l 能夠控制工作量負(fù)載、軟件和計(jì)算機(jī)系統(tǒng)環(huán)境，從而能夠重復(fù)測試過程。u 性能探測技術(shù) 在進(jìn)行性能測量時(shí)， 可以使用標(biāo)準(zhǔn)的商用工具進(jìn)行， 但是往往標(biāo)準(zhǔn)工具提供 的數(shù)據(jù)不能滿足要求。 性能探測就是在程序的關(guān)鍵點(diǎn)插入代碼探針來測量軟件的 執(zhí)行特性。從而達(dá)到以下的目標(biāo)：-性能數(shù)據(jù)獲取更方便-數(shù)據(jù)的詳細(xì)程度提高-數(shù)據(jù)收集方式更加可控依據(jù)SPE

18、（軟件性能工程）的建議，軟件探測需求應(yīng)該作為軟件體系結(jié)構(gòu)的 組成部分。在設(shè)計(jì)軟件時(shí)設(shè)計(jì)軟件探針。所以在規(guī)劃項(xiàng)目中的性能測試過程中， 要建議進(jìn)行軟件設(shè)計(jì)時(shí)考慮島性能探 測需求，為性能測試中更好的進(jìn)行性能測量做好準(zhǔn)備。1.3.4 CS/CSS 系統(tǒng)下性能測試的類型 廣義的性能測試包括許多類型。如：? Scalability/load testing （規(guī)模化/ 壓力測試 ）通過在被測系統(tǒng)上不斷增加壓力， 直到性能指標(biāo)例如響應(yīng)時(shí)間超過預(yù)定指標(biāo) 或者某種資源已經(jīng)達(dá)到飽和狀態(tài)。 這種測試可以找到系統(tǒng)的處理極限， 為系統(tǒng)調(diào) 優(yōu)提供數(shù)據(jù)。? Performance testing （ 性能測試 ）通過模擬生

19、產(chǎn)運(yùn)行的業(yè)務(wù)壓力量和使用場景組合測試系統(tǒng)的性能是否滿足 生產(chǎn)性能要求。 如以實(shí)際投產(chǎn)結(jié)構(gòu)測試， 求出最大的吞吐量與最佳回應(yīng)時(shí)間以保 證上線的平穩(wěn)，安全等? Configuration testing（ 配置測試 ） 通過測試找到系統(tǒng)各項(xiàng)資源的最優(yōu)分配原則。? Concurrency testing （并發(fā)測試）測試多個(gè)用戶同時(shí)訪問同一個(gè)應(yīng)用、 同一個(gè)模塊或者數(shù)據(jù)記錄時(shí)是否存在死 鎖或者其他性能問題。? Stress testing （極限測試）測試系統(tǒng)在一定飽和狀態(tài)下，例如 CPU內(nèi)存在飽和使用飽和情況下，系統(tǒng) 能夠處理的會話能力，以及系統(tǒng)是否會出現(xiàn)錯(cuò)誤。? Volume testing （容

20、量測試）測試系統(tǒng)能夠處理的最大會話能力。? Reliability testing （可靠性測試） 通過給系統(tǒng)加載一定的業(yè)務(wù)壓力（例如資源在 70-90%的使用率）的情況下， 運(yùn)行一段時(shí)間。? Failover testing （失敗測試）對于有冗余備份和負(fù)載均衡的系統(tǒng)， 通過這樣的測試來檢驗(yàn)如果系統(tǒng)局部發(fā) 生故障用戶是否能夠繼續(xù)使用系統(tǒng)，用戶將受到多大的影響。在CS/CSS系統(tǒng)下實(shí)際的性能測試中，需要根據(jù)具體情況進(jìn)行性能測試類型 的選取和組合。1.3.5 CS/CSS 系統(tǒng)下性能測試的組成部分通常在一個(gè)CS/CSS系統(tǒng)中，分為用戶界面層、服務(wù)邏輯層和數(shù)據(jù)服務(wù)層等 幾個(gè)層次， 分別對應(yīng)著客戶、

21、 應(yīng)用服務(wù)器、數(shù)據(jù)庫服務(wù)器。 如在金融行業(yè)應(yīng)用中， 客戶端承載著柜面業(yè)務(wù)，部署在網(wǎng)點(diǎn)（包括字符柜員或圖形柜員），還包括部署 在自助設(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)的整體性能往往取決于最差的部分。 所以對于整個(gè)系統(tǒng)的整體性能的測試可 能需要針對各個(gè)環(huán)節(jié)分別做好各自的內(nèi)部性能測試。如下面的一個(gè)CS/CSS系統(tǒng)金融行業(yè)應(yīng)用的例子：圖 1-3 cs/css 金融行業(yè)應(yīng)用 為了測試整個(gè)系統(tǒng)的性能，需要

22、預(yù)先針對各個(gè)組成部分進(jìn)行內(nèi)部性能測試， 如后臺主機(jī)的壓力測試、 sna gateway 的壓力測試、大前置系統(tǒng)的壓力測試、前 端系統(tǒng)的壓力測試、外系統(tǒng)接入的壓力測試等等。在本別進(jìn)行的內(nèi)部壓力測試中， 為了排除系統(tǒng)其它部分的影響， 均需要隔離 各自的部分， 驅(qū)動(dòng)和樁都使用軟件測試工具或自行編制程序來代替。 在每個(gè)部分 的內(nèi)部壓力測試中， 又均可以根據(jù)具體情況使用上一節(jié)說明的各種性能測試類型 進(jìn)行性能測量。2. CS/CSS系統(tǒng)架構(gòu)中的性能測試的度量項(xiàng)計(jì)算模型2.1 定義度量標(biāo)準(zhǔn)項(xiàng)進(jìn)行性能測試的模型分析時(shí)， 首先要確定關(guān)鍵性能目標(biāo)。 它應(yīng)該是通過與客 戶溝通獲得的， 這些目標(biāo)應(yīng)該是解決客戶關(guān)注的性

23、能問題， 也就是說， 客戶的性 能測試需求體現(xiàn)為關(guān)鍵性能目標(biāo)。性能目標(biāo)應(yīng)該是明確的、可度量的。例如：支 持 2000 個(gè)并發(fā)用戶；連續(xù)運(yùn)行 30 天不停機(jī)等。在明確了關(guān)鍵性能目標(biāo)和性能測試的通過 / 失敗準(zhǔn)則后，需要定義如何度量 關(guān)鍵性能目標(biāo)和性能測試的通過 / 失敗準(zhǔn)則。度量的標(biāo)準(zhǔn)項(xiàng)會影響測試方法和測 試工具的選擇。 舉例來說， 如果要度量 100個(gè)用戶并發(fā)的響應(yīng)時(shí)間， 就必須明確 要度量以下哪一個(gè)標(biāo)準(zhǔn)項(xiàng)：l 每個(gè)并發(fā)用戶的響應(yīng)時(shí)間l 在有 99 個(gè)用戶已經(jīng)接入的情況下，第 100 個(gè)用戶的響應(yīng)時(shí)間l 兩個(gè)指標(biāo)都要度量2.2 性能基準(zhǔn)及測試強(qiáng)度估算實(shí)際上，關(guān)鍵性能目標(biāo)并不總是很容易明確的。

24、客戶往往只有一些歷史數(shù)據(jù) 和業(yè)務(wù)增長的一些預(yù)期比例等等。 但是這些數(shù)據(jù)對于我們也是很有用的， 它們可 以作為我們設(shè)計(jì)和測試使用的性能基準(zhǔn)。對于性能測試， 在設(shè)計(jì)時(shí)就要首先提出設(shè)計(jì)的性能基準(zhǔn)。 所謂性能基準(zhǔn)， 就 是要思考：多少人使用這個(gè)系統(tǒng)？使用時(shí)最大的用戶數(shù)是多少？用戶高峰期使用 時(shí)間間隔多少，在多大數(shù)量級別上系統(tǒng)響應(yīng)時(shí)間分別是什么？數(shù)據(jù)增長量有多 大？數(shù)據(jù)增長到什么數(shù)量級和時(shí)間長短對硬件而言難于承受？網(wǎng)絡(luò)實(shí)現(xiàn)條件是 什么？在處理時(shí)CPU和內(nèi)存增長如何控制？種種這些，然后設(shè)計(jì)時(shí)根據(jù)性能基 準(zhǔn)有條件的在編碼實(shí)現(xiàn)和硬件配置方面進(jìn)行優(yōu)化， 測試只不過驗(yàn)證系統(tǒng)是否達(dá)到 預(yù)期設(shè)計(jì)目標(biāo)。但是現(xiàn)在的情況卻

25、往往是： 設(shè)計(jì)出來后要求性能測試， 測試什么然后是什么， 好比考試沒有標(biāo)準(zhǔn)答案卻要求大家及格一樣。 或者是，客戶雖然已經(jīng)明確的提出 了關(guān)鍵性能指標(biāo)，但是設(shè)計(jì)的時(shí)候沒有考慮， 依賴于性能測試給出實(shí)際性能數(shù)據(jù)， 然后再對比優(yōu)化。 性能測試在基于性能基準(zhǔn)上， 特別是基于經(jīng)過計(jì)算和轉(zhuǎn)換得到 的關(guān)鍵性能目標(biāo)， 才能得出預(yù)期結(jié)果。 這一點(diǎn)， 需要測試工程師向設(shè)計(jì)人員反復(fù) 灌輸這種觀念， 否則， 性能測試研究包括工具研究總是停留在討論階段。 不要在 編碼完成以后才考慮優(yōu)化問題， 如果等項(xiàng)目實(shí)施了， 優(yōu)化還沒有完成， 就很難保 證客戶滿意。沒有目標(biāo)的設(shè)計(jì)，如同城市間的交通問題一樣， 我們抱怨建設(shè)者們?nèi)狈h(yuǎn)見，

26、 而軟件設(shè)計(jì)人員同樣缺乏想象力。對于性能基準(zhǔn)向關(guān)鍵性能目標(biāo)的轉(zhuǎn)化，用以下例子來說明。有 200 個(gè)用戶使用客戶端軟件進(jìn)行業(yè)務(wù)處理 （并發(fā)度至少要達(dá)到 200 并發(fā)）， 每年通過軟件進(jìn)行處理的總業(yè)務(wù)量為： 2000萬筆業(yè)務(wù) /年。測試強(qiáng)度估算時(shí)采用如下假設(shè)前提：全年的業(yè)務(wù)量集中在10個(gè)月完成，每個(gè)月20個(gè)工作日，每個(gè)工作日8 個(gè)小時(shí)；采用 8020原理，每個(gè)工作日中 80%的業(yè)務(wù)在 20%的時(shí)間內(nèi)完成， 即每天 80%的業(yè)務(wù)在 1.6 小時(shí)內(nèi)完成；測試壓力的估算結(jié)果：去年全年處理業(yè)務(wù)約 2000 萬筆，其中 15%的業(yè)務(wù)處理每筆業(yè)務(wù)需對應(yīng)用服 務(wù)器提交 3次請求；70%的業(yè)務(wù)處理每筆業(yè)務(wù)需對應(yīng)用

27、服務(wù)器提交 2次請求；其 余 15%的業(yè)務(wù)每筆業(yè)務(wù)向應(yīng)用服務(wù)器提交 1 次請求。根據(jù)以往統(tǒng)計(jì)結(jié)果，每年的 業(yè)務(wù)增量為 15%，考慮到今后三年業(yè)務(wù)發(fā)展的需要，測試需按現(xiàn)有業(yè)務(wù)量的 2 倍 進(jìn)行。每年總的請求數(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)達(dá)到： 56 次/ 秒。 或者，忽略提交的請求數(shù)， 以業(yè)務(wù)交易數(shù)為準(zhǔn)， 定義每秒鐘的交易數(shù)，

28、 及“吞 吐量”。如果再考慮未來幾年的交易量的增加(每年增長 15)，則可以歸納為： ? 吞吐量： (T4*80%) /(1.6*3600)-T4 = TO * (1 + 15%) A 4-TO :當(dāng)前日均交易量2000萬-T4:未來4年日均交易量另外，有時(shí)關(guān)鍵性能指標(biāo)的確定和具體應(yīng)用相關(guān)。 如金融行業(yè)應(yīng)用中的核心 業(yè)務(wù)系統(tǒng)中會有日結(jié)、 月結(jié)等批處理， 往往使用一次批處理小于多少小時(shí)來表征 性能指標(biāo)。2.3 度量標(biāo)準(zhǔn)項(xiàng)和可采集的測量數(shù)據(jù)項(xiàng)轉(zhuǎn)換 只有使用明確的可采集到的數(shù)據(jù)才能真正反映系統(tǒng)的性能狀況。例如: l 每秒鐘運(yùn)行成功的交易數(shù)量l 單一客戶端的響應(yīng)時(shí)間 ( 使用時(shí)間戳的差值，發(fā)出請求的時(shí)

29、間和收到回應(yīng) 的時(shí)間)l CPU 的占用率l 網(wǎng)絡(luò)流量占用率l 內(nèi)存的占用率l 硬盤使用率2.4 壓力的分解對于一個(gè)由很多環(huán)節(jié)組成的復(fù)雜系統(tǒng)來說， 如果想要模擬實(shí)際環(huán)境進(jìn)行整體 的聯(lián)合性能測試的話，就需要針對整體壓力進(jìn)行各個(gè)層次的分解。如:下圖是一個(gè)實(shí)際系統(tǒng)進(jìn)行的聯(lián)合性能測試。 后臺主機(jī)系統(tǒng)最多的吞吐量 是 480筆/秒。由于通信網(wǎng)關(guān)和主機(jī)在此環(huán)境中是 1 對 1 的關(guān)系，所以通信網(wǎng) 關(guān)的壓力要達(dá)到 480筆/秒。而一個(gè)通信網(wǎng)關(guān)對應(yīng)著三個(gè)前置機(jī)，所以每個(gè)前置 機(jī)要達(dá)到 1 60筆/秒送達(dá)主機(jī)的吞吐量，才可能使整個(gè)系統(tǒng)滿負(fù)荷運(yùn)轉(zhuǎn)?？紤]到 其它層次類推。 由于主機(jī)以外還存在其它服務(wù)系統(tǒng)， 所以在前

30、置機(jī)的壓力上面加 了一個(gè)“X”代表其它服務(wù)系統(tǒng)要求的壓力。當(dāng)某個(gè)層次的設(shè)備短缺，無法實(shí)際 上達(dá)到其分解下來的壓力時(shí)， 往往需要使用軟件手段， 在上一層次上直接加壓力 解決。圖 1-3 聯(lián)合性能測試實(shí)例3. CS/CSS系統(tǒng)架構(gòu)中的性能測試的規(guī)劃與實(shí)施要點(diǎn)3.1 測試計(jì)劃中的人力資源計(jì)劃由于性能測試時(shí)軟件測試領(lǐng)域比較復(fù)雜的類型， 所以性能測試計(jì)劃中人力資 源的計(jì)劃也比較重要。要充分考慮到測試組織、測試程序的編寫、測試設(shè)計(jì)、實(shí) 現(xiàn)和執(zhí)行、測試報(bào)告等等各種工作任務(wù)的人力資源需求情況。 一般情況下，一個(gè)工程類項(xiàng)目的性能測試工作由如下角色和職責(zé)： 測試分析師：負(fù)責(zé)分析測試策略、 編寫測試計(jì)劃、制訂測試方

31、案、組織測試； 測試工程師：測試?yán)O(shè)計(jì)、實(shí)現(xiàn)；環(huán)境協(xié)調(diào)；對測試結(jié)果進(jìn)行分析，編寫測 試總結(jié)報(bào)告。測試員（通常也可測試工程師兼任）：測試執(zhí)行；對測試過程進(jìn)行記錄，收 集、整理測試記錄數(shù)據(jù)。軟件工程師（有時(shí)由測試工程師兼任）：負(fù)責(zé)編寫、調(diào)試客戶端測試軟件和 模擬軟件；數(shù)據(jù)庫管理系統(tǒng)的安裝、 ofs 配置及系統(tǒng)的預(yù)埋數(shù)據(jù)準(zhǔn)備。系統(tǒng)工程師 （有時(shí)由測試工程師兼任） ：負(fù)責(zé)測試用的硬件維護(hù)及操作系統(tǒng) 安裝、配置。上級測試負(fù)責(zé)人：負(fù)責(zé)對測試計(jì)劃及測試總結(jié)報(bào)告進(jìn)行批準(zhǔn)。 客戶：必要時(shí)可參加測試，并提出具體的測試要求；可要求暫停測試；重要 測試結(jié)論要簽字認(rèn)可。3.2 為項(xiàng)目選擇適合的測試工具 在性能測試過程中

32、，一定要有適合的測試工具支持。 性能測試所使用的測試工具包括：? 負(fù)載模擬類工具? 性能測量類工具?系統(tǒng)級測量工具：CPU內(nèi)存使用率統(tǒng)計(jì)? 統(tǒng)計(jì)類：響應(yīng)時(shí)間、吞吐? 剖析類：代碼級測量工具，例如統(tǒng)計(jì)函數(shù)調(diào)用次數(shù) 對于測試工具， 每個(gè)具體項(xiàng)目的需求是有差異的， 不存在通用解決方案。 而 且，工具的引入需要時(shí)間、資金和人力的投入。測試工具的選擇需要考慮性能測試中被測系統(tǒng)的需要， 以及測試工具需要完 成的功能。一般情況下的選擇方案包括：u 真實(shí)生產(chǎn)系統(tǒng)u 商用壓力測試工具u 定制壓力測試工具 第一種選擇限于資源以及準(zhǔn)確性等因素在壓力測試中一般不采用， 這里不再 討論。對于后兩種選擇的取舍主要考慮的因

33、素包括：n 是否能夠滿足壓力測試中作為模擬程序、負(fù)載模擬的需要n 是否能夠提供詳細(xì)，準(zhǔn)確的性能測量數(shù)據(jù)n 測試工具在成本的限制因素，包括時(shí)間和金錢n 測試組對測試工具的掌握程度有很多很好的自動(dòng)化的性能測試工具。如：Ml的Loadrunner、Ml的AstraLoadTest 、Empirix 的 E-load 、Rational TeamTest 等等。其中又以 MI 的 Loadrunner 最為著名和常用。有時(shí)在性能測試過程中也會采用自編的或定制的壓力測試工具的方案， 主要 基于如下的原因：首先、由于被測系統(tǒng)本身的特點(diǎn)， 滿足模擬程序需要的商用測試工具難以尋 覓，即便是有靠近這方面需求的測

34、試工具， 考慮到費(fèi)用以及培訓(xùn)時(shí)間的因素， 也 會增加測試過程的風(fēng)險(xiǎn)。其次，有時(shí)由于相關(guān)技術(shù)的成熟， 選擇定制壓力測試工具的方案無論在設(shè)計(jì)， 實(shí)現(xiàn)，還是在測試工具的掌握上都不存在不可控的風(fēng)險(xiǎn)； 并且在測試過程中隨時(shí) 滿足測試需要的及時(shí)性方面，定制的測試工具也有無可比擬的優(yōu)勢。最后、考慮到將來前置系統(tǒng)的產(chǎn)品化， 對該系統(tǒng)進(jìn)一步測試的需要會持續(xù)很 久，定制的測試工具可以更好，更完善地滿足這種需求。同時(shí)，對于與對象系統(tǒng) 采用同樣系統(tǒng)架構(gòu)的項(xiàng)目都可以借鑒此定制測試工具的思想， 快速地建立新的測 試工具。3.3 測試準(zhǔn)備工作性能測試的準(zhǔn)備工作， 可以包括測試數(shù)據(jù)的準(zhǔn)備、 測試工具準(zhǔn)備、 測試環(huán)境 準(zhǔn)備、試

35、執(zhí)行等部分。測試數(shù)據(jù)的準(zhǔn)備 對于行業(yè)應(yīng)用，尤其是金融行業(yè)應(yīng)用，測試數(shù)據(jù)的準(zhǔn)備中最重要的就是交 易的選取。交易的選取有如下原則：內(nèi)部壓力測試：盡量選取幾個(gè)最消耗系統(tǒng)資源的交易，并覆蓋所有的交易 形態(tài)（如會話式、批量式、異步式之類），這樣才有可能最大限度的檢查出該部 分的性能瓶頸；整體聯(lián)合壓力測試：由于一般整體聯(lián)合壓力測試需要完全模擬實(shí)際生產(chǎn)情 況，所以交易的抽樣選取相對比較復(fù)雜。 通常需要進(jìn)行當(dāng)前交易量的收集和預(yù)測 性能測試交易量，更重要的是確定交易發(fā)送比例的分布。如一個(gè)實(shí)際金融項(xiàng)目的交易發(fā)送比例的分布：表 1-1 金融交易發(fā)關(guān)比例分布交易代碼 原始比例 發(fā)送比例 交易代碼 1 0.49% 16

36、.90% 交易代碼 2 0.05% 1.72% 交易代碼 3 0.01% 0.34% 交易代碼 4 1.00% 34.48% 交易代碼 5 0.98% 33.79% 交易代碼 6 0.37% 12.76%先選取實(shí)際原始發(fā)送比例中前 50 位的交易。然后將其所有比例數(shù)相加 （ 定小于1）,做為新的基數(shù)，分別于各個(gè)交易的原始比例相除，即可得到使用工 具模擬發(fā)送的比例。此外，主要實(shí)際交易數(shù)據(jù)的獲得通常要從數(shù)據(jù)庫中使用腳本提取出來；還 有可能需要自己利用某些規(guī)則自造一些數(shù)據(jù)。測試工具的準(zhǔn)備通常，要為測試工具的編制和學(xué)習(xí)使用預(yù)留充足的時(shí)間。對于商用的測試 工具，通常需要進(jìn)行腳本的錄制和修改，場景的設(shè)定工

37、作；對于自編工具，要有 設(shè)計(jì)、編碼過程。而且，它還通常有其自己的配置文件和使用的數(shù)據(jù)文件，需要 進(jìn)行配置或數(shù)據(jù)格式轉(zhuǎn)換。測試環(huán)境準(zhǔn)備這里需要注意的問題是，可能在后臺（充當(dāng)樁的）數(shù)據(jù)庫中需要生成預(yù)埋 測試數(shù)據(jù)，要保證其足夠且可重復(fù)生成或容易清理。另外測試環(huán)境準(zhǔn)備好了以后，每次執(zhí)行前的檢查環(huán)境過程也是非常重要的， 可以避免大量的無用功。4性能測試報(bào)告4.1測試結(jié)構(gòu)數(shù)據(jù)的整理和分析u測試報(bào)告文檔的撰寫1 測試中應(yīng)該生成的測試文件測試記錄（測試負(fù)責(zé)人和參與測試的人員簽字）；測試總結(jié)報(bào)告。2.測試總結(jié)報(bào)告中一般必須包含的內(nèi)容被測試軟件名稱、測試項(xiàng)、測試環(huán)境；被測試軟件的壓力測試結(jié)論：響應(yīng)時(shí)間、最大 /最小并發(fā)數(shù)、失敗的次數(shù)、 正常連續(xù)運(yùn)行的最長/最短時(shí)間，并發(fā)數(shù)與失敗的關(guān)系等總之必須包含預(yù)先定義的關(guān)鍵性能指標(biāo)的數(shù)據(jù)、變化曲線分析和結(jié)論。5. CS/CSS系統(tǒng)架構(gòu)下性能測試中需要注意的問題5.1注意中間件的license、數(shù)據(jù)庫的用戶數(shù)等影響因素有時(shí)候測試結(jié)果沒有達(dá)到預(yù)期并不一定是被測對象的問題， 可能是中間件的 license不足或者是使用的數(shù)據(jù)庫系統(tǒng)的并發(fā)用戶數(shù)的限制導(dǎo)致， 有時(shí)還因?yàn)榕?置項(xiàng)有問題等，需要綜合分析。5.2數(shù)據(jù)聚集問題性能測試中選用的數(shù)據(jù)應(yīng)該在差異上進(jìn)行分散，與實(shí)際生產(chǎn)數(shù)據(jù)的隨即差異分布相似，充分測試系統(tǒng)在不同數(shù)據(jù)下的狀態(tài)。如果使用較單一的數(shù)據(jù)進(jìn)行