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ù)測試 創(chuàng)建一系列的

2、測試以保證每類事務(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ù)輸入等簡單功能，絕大部分工作由服務(wù)器承擔(dān)，這使得服務(wù)器的負(fù)擔(dān)很重。采用C/

3、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)用程序的維護(hù)、移植和互操作變得復(fù)雜。如果客戶端是在不同的操作系統(tǒng)上，C/S結(jié)構(gòu)

4、的軟件需要開發(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)到其它模塊的變動，使系統(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ù)器端的軟件就可以，這減輕了異地用戶系統(tǒng)維護(hù)與升級的成本。如果客戶端的軟件系統(tǒng)升級比較頻繁，那么B/S架構(gòu)的產(chǎn)品優(yōu)勢明顯所有的升級操作只需要針對服務(wù)器

5、進(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)多面廣且不具備網(wǎng)絡(luò)條件的用戶群體，不能夠?qū)崿F(xiàn)快速部署安裝和配置。 兼容性差，對于不同的開發(fā)工具，具有較大的局限性。若采用不同工具，需要重新改寫程序

6、。 開發(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)為最基本的操作方式，無法滿足快速操作的要求。 頁面動態(tài)刷新，響應(yīng)速度明顯降低。 無法實(shí)現(xiàn)分頁顯示，給數(shù)據(jù)庫訪問造成較大的壓力。 功能弱化，難以實(shí)現(xiàn)傳統(tǒng)模式下的特殊功能要求。近年來，隨著軟硬件技術(shù)發(fā)展和人們意識的提高，We

7、b應(yīng)用得到廣泛的普及，一方面在互聯(lián)網(wǎ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測試工具加上良好的測試案例完成的，我們認(rèn)為主要有以下兩種測試類型：基準(zhǔn)測試、非基準(zhǔn)測試基準(zhǔn)測試：主要指測試工具已經(jīng)提供了標(biāo)準(zhǔn)的測試案例庫，包括靜態(tài)測試案例（HTM、JPG）、動態(tài)測試

8、案例（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è)方面的因素可以反映出Web服務(wù)器在不同壓力情況下的綜合性能。在測試過程中，主要影響測試結(jié)果的因素有網(wǎng)絡(luò)環(huán)境、客戶端性能。目前無論IA架構(gòu)服務(wù)器還是SUN、HP、IBM的UNIX服務(wù)器性能都

9、越來越優(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)控是保證客戶端可以穩(wěn)定運(yùn)行的必要手段。由于這類測試工具使用的是工具開發(fā)商提供的測試案例集，雖然也具有一定的權(quán)威性，但是目前再完美的測試案例集也不能涵蓋所有的Web應(yīng)用情況，所以也不能夠完全體現(xiàn)

10、出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)用程序還廣泛地應(yīng)用于各種行業(yè)。尤其是金融行業(yè)中的商業(yè)銀行柜面核心帳務(wù)系統(tǒng)等。一方面由于傳統(tǒng)商業(yè)銀行一般都有大量的字符終端等需要復(fù)用的設(shè)備，一方面也是因?yàn)樗麄兇嬖诖罅棵芗膶?shí)時(shí)性要求很高的高柜業(yè)務(wù)

11、，使用傳統(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ù)器返回?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)即客戶/應(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)品，如B

12、EA公司的TUXEDO和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)的性能影響因素由于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è)種類，分布在不

13、同設(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)；l 采用此架構(gòu)的行業(yè)應(yīng)用往往是一個(gè)7×24小時(shí)系統(tǒng)；l 采用此架構(gòu)的行業(yè)應(yīng)用可能高柜業(yè)務(wù)多，這樣會影響對性能度量項(xiàng)的選取和轉(zhuǎn)換；l 各個(gè)環(huán)節(jié)基本上以交換數(shù)據(jù)報(bào)文的方式通信，其格式經(jīng)常會比較復(fù)雜。因此這樣的系統(tǒng)對于對測試工程師的知識的深度和廣度都是一個(gè)考驗(yàn)。對于這樣的系統(tǒng)，到底如何使用什么樣的測試策略、如何分析測試需求、如何選取

14、性能度量項(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é)果真實(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)

15、節(jié)已經(jīng)是成熟系統(tǒ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)的理想配置？是否還要使用測試結(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)是什么；對于性能

16、測試中各個(gè)部分和步驟的計(jì)劃和結(jié)果，甚至是性能測試過程，都要根據(jù)其重要程度，決定是否需要客戶進(jìn)行確認(rèn)和簽字。獲得客戶的認(rèn)可是最重要的。1.3.3 CS/CSS系統(tǒng)中性能測量與性能探測u 性能測量1. 在性能測試開始前必須認(rèn)真規(guī)劃性能測量：軟件性能測量技術(shù)范圍很廣?？梢园ㄈ罩尽⑹录?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ù)

17、在進(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（軟件性能工程）的建議，軟件探測需求應(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ī)模化/壓力測試)通過在

18、被測系統(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 (性能測試)通過模擬生產(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

19、testing （極限測試）測試系統(tǒng)在一定飽和狀態(tài)下，例如CPU、內(nèi)存在飽和使用飽和情況下，系統(tǒng)能夠處理的會話能力，以及系統(tǒng)是否會出現(xiàn)錯(cuò)誤。 Volume testing （容量測試）測試系統(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)行性能測試類型的選

20、取和組合。1.3.5 CS/CSS系統(tǒng)下性能測試的組成部分通常在一個(gè)CS/CSS系統(tǒng)中，分為用戶界面層、服務(wù)邏輯層和數(shù)據(jù)服務(wù)層等幾個(gè)層次，分別對應(yīng)著客戶、應(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)部

21、性能測試。如下面的一個(gè)CS/CSS系統(tǒng)金融行業(yè)應(yīng)用的例子：圖1-3 cs/css金融行業(yè)應(yīng)用為了測試整個(gè)系統(tǒng)的性能，需要預(yù)先針對各個(gè)組成部分進(jìn)行內(nèi)部性能測試，如后臺主機(jī)的壓力測試、sna gateway的壓力測試、大前置系統(tǒng)的壓力測試、前端系統(tǒng)的壓力測試、外系統(tǒng)接入的壓力測試等等。在本別進(jìn)行的內(nèi)部壓力測試中，為了排除系統(tǒng)其它部分的影響，均需要隔離各自的部分，驅(qū)動和樁都使用軟件測試工具或自行編制程序來代替。在每個(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í)

22、，首先要確定關(guān)鍵性能目標(biāo)。它應(yīng)該是通過與客戶溝通獲得的，這些目標(biāo)應(yīng)該是解決客戶關(guān)注的性能問題，也就是說，客戶的性能測試需求體現(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í)際

23、上，關(guān)鍵性能目標(biāo)并不總是很容易明確的?？蛻敉挥幸恍v史數(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)。但是

24、現(xiàn)在的情況卻往往是：設(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)見，而軟件設(shè)計(jì)人員同樣缺乏想象力。對于

25、性能基準(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)用服務(wù)器提交2次請求；其余15%的業(yè)務(wù)每筆業(yè)務(wù)向應(yīng)用服務(wù)器提交1次請求。根據(jù)以往

26、統(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ù)，及“吞吐量”。 如果再考慮未來幾年的交易量的增加（每年增長15），則可以歸納為： 吞吐量：(T4*80%) /(1.6*3600) T4

27、 = T0 * (1 + 15%) 4 T0：當(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í)間和收到回應(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)行整體

28、的聯(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á)到160筆/秒送達(dá)主機(jī)的吞吐量，才可能使整個(gè)系統(tǒng)滿負(fù)荷運(yùn)轉(zhuǎn)?？紤]到其它層次類推。由于主機(jī)以外還存在其它服務(wù)系統(tǒng)，所以在前置機(jī)的壓力上面加了一個(gè)“X”代表其它服務(wù)系統(tǒng)要求的壓力。當(dāng)某個(gè)層次的設(shè)備短缺，無法實(shí)際上達(dá)到其分解下來的壓力時(shí)，往往需要使用軟件手段，在上一層次上直接加壓力解決。圖1-3 聯(lián)合性能測試實(shí)例3.CS/CSS系統(tǒng)

29、架構(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ì)劃、制訂測試方案、組織測試；測試工程師：測試?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)試客戶

30、端測試軟件和模擬軟件；數(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)?？蛻簦罕匾獣r(shí)可參加測試，并提出具體的測試要求；可要求暫停測試；重要測試結(jié)論要簽字認(rèn)可。3.2 為項(xiàng)目選擇適合的測試工具在性能測試過程中，一定要有適合的測試工具支持。性能測試所使用的測試工具包括： 負(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)目的需求是有差異的，不存在通用解

31、決方案。而且，工具的引入需要時(shí)間、資金和人力的投入。測試工具的選擇需要考慮性能測試中被測系統(tǒng)的需要，以及測試工具需要完成的功能。一般情況下的選擇方案包括：u 真實(shí)生產(chǎn)系統(tǒng)u 商用壓力測試工具u 定制壓力測試工具第一種選擇限于資源以及準(zhǔn)確性等因素在壓力測試中一般不采用，這里不再討論。對于后兩種選擇的取舍主要考慮的因素包括：n 是否能夠滿足壓力測試中作為模擬程序、負(fù)載模擬的需要n 是否能夠提供詳細(xì)，準(zhǔn)確的性能測量數(shù)據(jù)n 測試工具在成本的限制因素，包括時(shí)間和金錢n 測試組對測試工具的掌握程度有很多很好的自動化的性能測試工具。如：MI的Loadrunner、MI的Astra LoadTest、Empi

32、rix的E-load、Rational TeamTest等等。其中又以MI的Loadrunner最為著名和常用。有時(shí)在性能測試過程中也會采用自編的或定制的壓力測試工具的方案，主要基于如下的原因：首先、由于被測系統(tǒng)本身的特點(diǎn)，滿足模擬程序需要的商用測試工具難以尋覓，即便是有靠近這方面需求的測試工具，考慮到費(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)一步測

33、試的需要會持續(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)備、試執(zhí)行等部分。3.3.1. 測試數(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)合壓力測試需要完全模擬

34、實(shí)際生產(chǎn)情況，所以交易的抽樣選取相對比較復(fù)雜。通常需要進(jìn)行當(dāng)前交易量的收集和預(yù)測性能測試交易量，更重要的是確定交易發(fā)送比例的分布。如一個(gè)實(shí)際金融項(xiàng)目的交易發(fā)送比例的分布： 表1-1 金融交易發(fā)關(guān)比例分布交易代碼原始比例發(fā)送比例交易代碼10.49%16.90%交易代碼20.05%1.72%交易代碼30.01%0.34%交易代碼41.00%34.48%交易代碼50.98%33.79%交易代碼60.37%12.76% 先選取實(shí)際原始發(fā)送比例中前50位的交易。然后將其所有比例數(shù)相加（一定小于1），做為新的基數(shù)，分別于各個(gè)交易的原始比例相除，即可得到使用工具模擬發(fā)送的比例。 此外，主要實(shí)際交易數(shù)據(jù)的獲得

35、通常要從數(shù)據(jù)庫中使用腳本提取出來；還有可能需要自己利用某些規(guī)則自造一些數(shù)據(jù)。3.3.2. 測試工具的準(zhǔn)備 通常，要為測試工具的編制和學(xué)習(xí)使用預(yù)留充足的時(shí)間。對于商用的測試工具，通常需要進(jìn)行腳本的錄制和修改，場景的設(shè)定工作；對于自編工具，要有設(shè)計(jì)、編碼過程。而且，它還通常有其自己的配置文件和使用的數(shù)據(jù)文件，需要進(jìn)行配置或數(shù)據(jù)格式轉(zhuǎn)換。3.3.3. 測試環(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ù)

36、的整理和分析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)行測試，一方面可能使系統(tǒng)的局部功能沒有被使用，導(dǎo)致性能測試數(shù)據(jù)不可靠；