1、性能測(cè)試方法及分析方法一、 性能測(cè)試簡(jiǎn)介1.1 什么是軟件性能一般來(lái)說(shuō)，性能是一種指標(biāo)，表明軟件系統(tǒng)或構(gòu)件對(duì)于其及時(shí)性要求的符合程度；其次，性能是軟件產(chǎn)品的一種特性，可以用時(shí)間來(lái)進(jìn)行度量。性能的及時(shí)性用響應(yīng)時(shí)間或者吞吐量來(lái)衡量。響應(yīng)時(shí)間是對(duì)請(qǐng)求作出響應(yīng)所需要的時(shí)間。對(duì)于單個(gè)事務(wù)，響應(yīng)時(shí)間就是完成事務(wù)所需的時(shí)間；對(duì)于用戶任務(wù)，響應(yīng)時(shí)間體現(xiàn)為端到端的時(shí)間。比如，“用戶單擊OK按鈕后2秒內(nèi)收到結(jié)果”就是一個(gè)對(duì)用戶任務(wù)響應(yīng)時(shí)間的描述，具體到這個(gè)用戶任務(wù)中，可能有多個(gè)具體的事務(wù)需要完成，每個(gè)事務(wù)都有其單獨(dú)的響應(yīng)時(shí)間。對(duì)交互式的應(yīng)用（例如典型的Web應(yīng)用）來(lái)說(shuō)，我們一般以用戶感受到的響應(yīng)時(shí)間來(lái)描述系統(tǒng)的性

2、能，而對(duì)非交互式應(yīng)用（嵌入式系統(tǒng)或是銀行等的業(yè)務(wù)處理系統(tǒng)）而言，響應(yīng)時(shí)間是指系統(tǒng)對(duì)事件產(chǎn)生響應(yīng)所需要的時(shí)間。通常，對(duì)軟件性能的關(guān)注是多個(gè)層面的：用戶關(guān)注軟件性能，管理員關(guān)注軟件性能，產(chǎn)品的開(kāi)發(fā)人員也關(guān)注軟件性能，下面將從3個(gè)不同層面來(lái)對(duì)軟件性能進(jìn)行闡述。1.1.1 用戶視角的軟件性能從用戶的角度來(lái)說(shuō)，軟件性能就是軟件對(duì)用戶操作的響應(yīng)時(shí)間。說(shuō)得更明確一點(diǎn)，對(duì)用戶來(lái)說(shuō)，當(dāng)用戶單擊一個(gè)按鈕、發(fā)出一條指令或是在Web頁(yè)面上單擊一個(gè)鏈接，從用戶單擊開(kāi)始到應(yīng)用系統(tǒng)把本次操作的結(jié)果以用戶能察覺(jué)的方式展示出來(lái)，這個(gè)過(guò)程所消耗的時(shí)間就是用戶對(duì)軟件性能的直觀印象。圖1.1以一個(gè)Web系統(tǒng)為例，說(shuō)明了用戶的這種印象

3、。圖1.1 Web系統(tǒng)的響應(yīng)必須要說(shuō)明的是，用戶所體會(huì)到的“響應(yīng)時(shí)間”既有客觀的成分，也有主觀的成分。例如，用戶執(zhí)行了某個(gè)操作，該操作返回大量數(shù)據(jù)，從客觀的角度來(lái)說(shuō)，事務(wù)的結(jié)束應(yīng)該是系統(tǒng)返回所有的數(shù)據(jù)，響應(yīng)時(shí)間應(yīng)該是從用戶操作開(kāi)始到所有數(shù)據(jù)返回完成的整個(gè)耗時(shí)；但從用戶的主觀感知來(lái)說(shuō)，如果采用一種優(yōu)化的數(shù)據(jù)呈現(xiàn)策略，當(dāng)少部分?jǐn)?shù)據(jù)返回之后就立刻將數(shù)據(jù)呈現(xiàn)在用戶面前，則用戶感受到的響應(yīng)時(shí)間就會(huì)遠(yuǎn)遠(yuǎn)小于實(shí)際的事務(wù)響應(yīng)時(shí)間（順便說(shuō)一下，這種技巧是在C/S結(jié)構(gòu)的管理系統(tǒng)中開(kāi)發(fā)人員常用的一種技巧）。關(guān)于響應(yīng)時(shí)間的進(jìn)一步討論請(qǐng)見(jiàn)1.2.1節(jié)對(duì)“響應(yīng)時(shí)間”的解釋。1.1.2 管理員視角的軟件性能從管理員的角度來(lái)

4、看，軟件系統(tǒng)的性能首先表現(xiàn)在系統(tǒng)的響應(yīng)時(shí)間上，這一點(diǎn)和用戶視角是一樣的。但管理員是一種特殊的用戶，和一般用戶相比，除了會(huì)關(guān)注一般用戶的體驗(yàn)之外，他還會(huì)關(guān)心和系統(tǒng)狀態(tài)相關(guān)的信息。例如，管理員已經(jīng)知道，在并發(fā)用戶數(shù)為100時(shí)，A業(yè)務(wù)的響應(yīng)時(shí)間為8秒，那么此時(shí)的系統(tǒng)狀態(tài)如何呢？服務(wù)器的CPU使用是不是已經(jīng)達(dá)到了最大值？是否還有可用的內(nèi)存？應(yīng)用服務(wù)器的狀態(tài)如何？我們?cè)O(shè)置的JVM可用內(nèi)存是否足夠？數(shù)據(jù)庫(kù)的狀況如何？是否還需要進(jìn)行一些調(diào)整？這些問(wèn)題普通的用戶并不關(guān)心，因?yàn)檫@不在他們的體驗(yàn)范圍之內(nèi)；但對(duì)管理員來(lái)說(shuō)，要保證系統(tǒng)的穩(wěn)定運(yùn)行和持續(xù)的良好性能，就必須關(guān)心這些問(wèn)題。另一方面，管理員還會(huì)想要知道系統(tǒng)具有

5、多大的可擴(kuò)展性，處理并發(fā)的能力如何；而且，管理員還會(huì)希望知道系統(tǒng)可能的最大容量是什么，系統(tǒng)可能的性能瓶頸在哪里，通過(guò)更換哪些設(shè)備或是進(jìn)行哪些擴(kuò)展能夠提高系統(tǒng)性能，了解這些情況，管理員才能根據(jù)系統(tǒng)的用戶狀況制定管理措施，在系統(tǒng)出現(xiàn)計(jì)劃之外的用戶增長(zhǎng)等緊急情況的時(shí)候能夠立即制定相應(yīng)措施，進(jìn)行迅速的處理；此外，管理員可能還會(huì)關(guān)心系統(tǒng)在長(zhǎng)時(shí)間的運(yùn)行中是否足夠穩(wěn)定，是否能夠不間斷地提供業(yè)務(wù)服務(wù)等。因此，從管理員的視角來(lái)看，軟件性能絕對(duì)不僅僅是應(yīng)用的響應(yīng)時(shí)間這么一個(gè)簡(jiǎn)單的問(wèn)題。表1-1給出了管理員關(guān)注的部分性能相關(guān)問(wèn)題的列表。表1-1 管理員關(guān)注的部分性能相關(guān)問(wèn)題管理員關(guān)心的問(wèn)題軟件性能描述服務(wù)器的資源使

6、用狀況合理嗎資源利用率應(yīng)用服務(wù)器和數(shù)據(jù)庫(kù)的資源使用狀況合理嗎資源利用率系統(tǒng)是否能夠?qū)崿F(xiàn)擴(kuò)展系統(tǒng)可擴(kuò)展性系統(tǒng)最多能支持多少用戶的訪問(wèn)？系統(tǒng)最大的業(yè)務(wù)處理量是多少系統(tǒng)容量系統(tǒng)性能可能的瓶頸在哪里系統(tǒng)可擴(kuò)展性更換哪些設(shè)備能夠提高系統(tǒng)性能系統(tǒng)可擴(kuò)展性系統(tǒng)能否支持724小時(shí)的業(yè)務(wù)訪問(wèn)系統(tǒng)穩(wěn)定性1.1.3開(kāi)發(fā)視角的軟件性能從開(kāi)發(fā)人員的角度來(lái)說(shuō)，對(duì)軟件性能的關(guān)注就更加深入了。開(kāi)發(fā)人員會(huì)關(guān)心主要的用戶感受響應(yīng)時(shí)間，因?yàn)檫@畢竟是用戶的直接體驗(yàn)；另外，開(kāi)發(fā)人員也會(huì)關(guān)心系統(tǒng)的擴(kuò)展性等管理員關(guān)心的內(nèi)容，因?yàn)檫@些也是產(chǎn)品需要面向的用戶（特殊的用戶）。但對(duì)開(kāi)發(fā)人員來(lái)說(shuō)，其最想知道的是“如何通過(guò)調(diào)整設(shè)計(jì)和代碼實(shí)現(xiàn)，或是如何

7、通過(guò)調(diào)整系統(tǒng)設(shè)置等方法提高軟件的性能表現(xiàn)”，和“如何發(fā)現(xiàn)并解決軟件設(shè)計(jì)和開(kāi)發(fā)過(guò)程中產(chǎn)生的由于多用戶訪問(wèn)引起的缺陷”，因此，其最關(guān)注的是使性能表現(xiàn)不佳的因素和由于大量用戶訪問(wèn)引發(fā)的軟件故障，也就是我們通常所說(shuō)的“性能瓶頸”和系統(tǒng)中存在的在大量用戶訪問(wèn)時(shí)表現(xiàn)出來(lái)的缺陷。舉例來(lái)說(shuō)，對(duì)于一個(gè)沒(méi)有達(dá)到預(yù)期性能規(guī)劃的應(yīng)用，開(kāi)發(fā)人員最想知道的是，這個(gè)糟糕的性能表現(xiàn)究竟是由于系統(tǒng)架構(gòu)選擇的不合理還是由于代碼實(shí)現(xiàn)的問(wèn)題引起？由于數(shù)據(jù)庫(kù)設(shè)計(jì)的問(wèn)題引起？抑或是由于系統(tǒng)的運(yùn)行環(huán)境引發(fā)？或者，對(duì)于一個(gè)即將發(fā)布到現(xiàn)場(chǎng)給用戶使用的應(yīng)用，開(kāi)發(fā)人員可能會(huì)想要知道當(dāng)大量用戶訪問(wèn)這個(gè)系統(tǒng)時(shí)，系統(tǒng)會(huì)不會(huì)出現(xiàn)某些故障，例如，是否存在由

8、于資源競(jìng)爭(zhēng)引起的掛起？是否存在由于內(nèi)存處理等問(wèn)題引起的系統(tǒng)故障？因此，對(duì)開(kāi)發(fā)人員來(lái)說(shuō)，單純獲知系統(tǒng)性能“好”或者“不好”的評(píng)價(jià)并沒(méi)有太大的意義，他們更想知道的是“哪些地方是引起不好的性能表現(xiàn)的根源”或是“哪里可能存在故障發(fā)生的可能”。表1-2給出了開(kāi)發(fā)視角的軟件性能關(guān)注內(nèi)容。表1-2 開(kāi)發(fā)人員關(guān)注的性能問(wèn)題開(kāi)發(fā)人員關(guān)心的問(wèn)題問(wèn)題所屬層次架構(gòu)設(shè)計(jì)是否合理系統(tǒng)架構(gòu)數(shù)據(jù)庫(kù)設(shè)計(jì)是否存在問(wèn)題數(shù)據(jù)庫(kù)設(shè)計(jì)代碼是否存在性能方面的問(wèn)題代碼系統(tǒng)中是否有不合理的內(nèi)存使用方式代碼系統(tǒng)中是否存在不合理的線程同步方式設(shè)計(jì)與代碼系統(tǒng)中是否存在不合理的資源競(jìng)爭(zhēng)設(shè)計(jì)與代碼1.1.4總結(jié)以上我們描述了3個(gè)不同層面上的軟件性能關(guān)注

9、點(diǎn)，由此可見(jiàn)，不同的對(duì)象對(duì)軟件系統(tǒng)性能的關(guān)注是有著顯著的差異的。從項(xiàng)目管理的角度，以我們的系統(tǒng)干系人來(lái)分析，大部分用戶對(duì)性能的理解屬于“用戶視角”，項(xiàng)目的維護(hù)人員或是用戶方的項(xiàng)目經(jīng)理一般會(huì)從“管理員視角”來(lái)看待軟件性能的問(wèn)題，而項(xiàng)目的創(chuàng)建者開(kāi)發(fā)人員（包括設(shè)計(jì)人員）自然就是從“開(kāi)發(fā)視角”來(lái)關(guān)注軟件性能了。因此，對(duì)軟件性能測(cè)試來(lái)說(shuō)，在不同的層面上要求我們關(guān)注不同的內(nèi)容：從直接體驗(yàn)的用戶的角度來(lái)說(shuō)，表現(xiàn)為軟件系統(tǒng)對(duì)用戶操作的響應(yīng)時(shí)間；在系統(tǒng)或是管理員的關(guān)注層面，我們還需要從軟件的性能表現(xiàn)分析系統(tǒng)的可擴(kuò)展性、并發(fā)能力等指標(biāo)；最后，從最貼近軟件的創(chuàng)建者開(kāi)發(fā)人員的角度來(lái)說(shuō)，還需要為軟件性能問(wèn)題進(jìn)行定位，了

10、解性能的制約因素和引起性能問(wèn)題的關(guān)鍵原因。1.2 軟件性能的幾個(gè)術(shù)語(yǔ)接觸過(guò)軟件性能測(cè)試的人，會(huì)經(jīng)常聽(tīng)到這樣一些詞匯：響應(yīng)時(shí)間、并發(fā)用戶數(shù)、吞吐量、性能計(jì)數(shù)器，在使用性能測(cè)試工具進(jìn)行測(cè)試時(shí)，還會(huì)接觸到“思考時(shí)間（Think Time）”的概念，那么，這些術(shù)語(yǔ)的確切含義究竟是什么呢？本節(jié)重點(diǎn)介紹以上的各個(gè)術(shù)語(yǔ)。1.2.1 響應(yīng)時(shí)間在1.1節(jié)和1.1.1節(jié)中都提到了“響應(yīng)時(shí)間”的概念，響應(yīng)時(shí)間是“對(duì)請(qǐng)求作出響應(yīng)所需要的時(shí)間”，而且，我們把響應(yīng)時(shí)間作為用戶視角的軟件性能的主要體現(xiàn)。圖1.1將用戶所感受到的軟件性能（響應(yīng)時(shí)間）劃分為“呈現(xiàn)時(shí)間”和“系統(tǒng)響應(yīng)時(shí)間”兩個(gè)部分，其中“呈現(xiàn)時(shí)間”取決于數(shù)據(jù)在被客

11、戶端收到響應(yīng)數(shù)據(jù)后呈現(xiàn)頁(yè)面所消耗的時(shí)間，例如，對(duì)一個(gè)Web應(yīng)用，呈現(xiàn)時(shí)間就是瀏覽器接收到數(shù)據(jù)后用戶把數(shù)據(jù)呈現(xiàn)出來(lái)的時(shí)間；而“系統(tǒng)響應(yīng)時(shí)間”指應(yīng)用系統(tǒng)從請(qǐng)求發(fā)出開(kāi)始到客戶端接收到數(shù)據(jù)所消耗的時(shí)間。在一般的性能測(cè)試中，我們并不關(guān)注“呈現(xiàn)時(shí)間”，這是因?yàn)槌尸F(xiàn)時(shí)間在很大程度上取決于客戶端的表現(xiàn)，例如，一臺(tái)內(nèi)存不足的客戶端機(jī)器在處理復(fù)雜頁(yè)面的時(shí)候，其呈現(xiàn)時(shí)間可能就很長(zhǎng)，而這并不能說(shuō)明整個(gè)系統(tǒng)的性能。在后續(xù)的軟件性能測(cè)試的討論中，我們不會(huì)區(qū)分“系統(tǒng)響應(yīng)時(shí)間”和“響應(yīng)時(shí)間”，直接把這里的“系統(tǒng)響應(yīng)時(shí)間”等同于“響應(yīng)時(shí)間”。響應(yīng)時(shí)間可以被進(jìn)一步分解。圖1.2描述了一個(gè)Web應(yīng)用的頁(yè)面響應(yīng)時(shí)間的構(gòu)成。從圖中可以

12、看到，頁(yè)面的響應(yīng)時(shí)間可被分解為“網(wǎng)絡(luò)傳輸時(shí)間”（N1+N2+N3+N4）和“應(yīng)用延遲時(shí)間”（A1+A2+A3），而“應(yīng)用延遲時(shí)間”又可以分解為“數(shù)據(jù)庫(kù)延遲時(shí)間”（A2）和“應(yīng)用服務(wù)器延遲時(shí)間”（A1+A3）。之所以要對(duì)響應(yīng)時(shí)間進(jìn)行這些分解，主要目的是為了能更好定位性能瓶頸的所在。在后續(xù)的實(shí)例討論中，讀者將會(huì)看到如何應(yīng)用這些響應(yīng)時(shí)間的分解進(jìn)行性能問(wèn)題的定位。圖1.2 Web應(yīng)用的頁(yè)面響應(yīng)時(shí)間分解關(guān)于響應(yīng)時(shí)間，要特別說(shuō)明的一點(diǎn)是，對(duì)客戶來(lái)說(shuō)，該值是否能夠被接受是帶有一定的用戶主觀色彩，也就是說(shuō)，響應(yīng)時(shí)間的“長(zhǎng)”和“短”沒(méi)有絕對(duì)的區(qū)別。例如，對(duì)一個(gè)電子商務(wù)網(wǎng)站來(lái)說(shuō)，在美國(guó)和歐洲，一個(gè)普遍被接受的響應(yīng)

13、時(shí)間標(biāo)準(zhǔn)為2/5/10秒，也就是說(shuō)，在2秒之內(nèi)給客戶響應(yīng)被用戶認(rèn)為是“非常有吸引力的”，在5秒之內(nèi)響應(yīng)客戶被認(rèn)為是“比較不錯(cuò)的”，而10秒是客戶能接受的響應(yīng)的上限。但考慮一個(gè)稅務(wù)報(bào)賬系統(tǒng)，該系統(tǒng)的用戶每月使用一次該系統(tǒng)，一次花費(fèi)2小時(shí)以上進(jìn)行數(shù)據(jù)的錄入，當(dāng)用戶單擊“提交”按鈕后，即使系統(tǒng)在20分鐘后才給出“處理成功”的消息，用戶仍然不會(huì)認(rèn)為該系統(tǒng)的響應(yīng)時(shí)間不能接受畢竟，相對(duì)于一個(gè)月才進(jìn)行一次的操作來(lái)說(shuō)，20分鐘確實(shí)是一個(gè)可以接受的等待時(shí)間。因此，在進(jìn)行性能測(cè)試時(shí)，“合理的響應(yīng)時(shí)間”取決于實(shí)際的用戶需求，而不能依據(jù)測(cè)試人員自己的設(shè)想來(lái)決定。1.2.2 并發(fā)用戶數(shù)在闡述這個(gè)術(shù)語(yǔ)之前，先來(lái)看看為什么

14、在性能測(cè)試中需要關(guān)注這個(gè)“并發(fā)用戶數(shù)”。首先，如果性能測(cè)試的目標(biāo)是驗(yàn)證當(dāng)前系統(tǒng)能否支持現(xiàn)有用戶的訪問(wèn)，最好的辦法就是弄清楚會(huì)有多少用戶會(huì)在同一個(gè)時(shí)間段內(nèi)訪問(wèn)被測(cè)試的系統(tǒng)，如果使用性能測(cè)試工具模擬出與系統(tǒng)的訪問(wèn)用戶數(shù)相同的用戶，并模擬用戶的行為，那得到的測(cè)試結(jié)果就能夠真實(shí)反映實(shí)際用戶訪問(wèn)時(shí)的系統(tǒng)性能表現(xiàn)，這樣一來(lái)，也就能夠通過(guò)性能測(cè)試了解到當(dāng)系統(tǒng)處于實(shí)際用戶訪問(wèn)時(shí)，會(huì)具有怎樣的性能表現(xiàn)。這里提到的在同一個(gè)時(shí)間段內(nèi)訪問(wèn)系統(tǒng)的用戶數(shù)量，也就是我們說(shuō)的并發(fā)用戶數(shù)的一個(gè)概念，這種并發(fā)的概念通常在性能測(cè)試（Performance Testing）方法中使用，用于從業(yè)務(wù)的角度模擬真實(shí)的用戶訪問(wèn)，體現(xiàn)的是業(yè)務(wù)

15、并發(fā)用戶數(shù)。如果拋開(kāi)業(yè)務(wù)的層面，僅從服務(wù)器端承受的壓力來(lái)考慮，那么，對(duì)C/S或是B/S結(jié)構(gòu)的應(yīng)用來(lái)說(shuō)，系統(tǒng)的性能表現(xiàn)毫無(wú)疑問(wèn)地主要由“服務(wù)端”決定。在什么時(shí)候“服務(wù)端”會(huì)承受最大的壓力，或者說(shuō)，在什么時(shí)候“服務(wù)端”表現(xiàn)為最差的性能呢？毫無(wú)疑問(wèn)，肯定是在大量用戶同時(shí)對(duì)這個(gè)系統(tǒng)進(jìn)行訪問(wèn)的時(shí)候。為了說(shuō)明這個(gè)“同時(shí)”，參見(jiàn)圖1.3。圖1.3 用排球擊打墻面圖1.3用“排球擊打墻面”說(shuō)明這種“同時(shí)”，毫無(wú)疑問(wèn)，越多的球同時(shí)擊打到墻面，墻面承受的壓力也就越大。如果把擊打排球的人看成是系統(tǒng)的使用者，墻壁代表了我們可憐的服務(wù)端，顯然，當(dāng)越多的用戶同時(shí)使用系統(tǒng)，系統(tǒng)承受的壓力越大，系統(tǒng)的性能表現(xiàn)也就越差，而且，

16、此時(shí)很可能出現(xiàn)由于用戶的同時(shí)訪問(wèn)導(dǎo)致的資源爭(zhēng)用等問(wèn)題。我們?cè)谶@里提到了“并發(fā)用戶數(shù)”的另一個(gè)概念，該概念不從業(yè)務(wù)角度出發(fā)，而是從服務(wù)端承受的壓力出發(fā)，描述的是同時(shí)向客戶端發(fā)出請(qǐng)求的客戶，該概念一般結(jié)合并發(fā)測(cè)試（Concurrency Testing）使用，體現(xiàn)的是服務(wù)端承受的最大并發(fā)訪問(wèn)數(shù)。下面我們用一個(gè)更接近實(shí)際的例子來(lái)說(shuō)明這兩個(gè)并發(fā)概念之間的不同。圖1.4所示是實(shí)際應(yīng)用系統(tǒng)的演示。圖1.4 實(shí)際應(yīng)用系統(tǒng)對(duì)服務(wù)端來(lái)說(shuō)，每個(gè)用戶和服務(wù)端的交互都是離散的。如果僅考慮一個(gè)單獨(dú)的用戶對(duì)系統(tǒng)的使用，過(guò)程大致如下：用戶每隔一段時(shí)間向服務(wù)端發(fā)送一個(gè)請(qǐng)求或是命令，服務(wù)端按照用戶的請(qǐng)求執(zhí)行某些操作，然后將結(jié)果

17、返回給用戶。從用戶的角度來(lái)看，在一個(gè)相當(dāng)長(zhǎng)的時(shí)間段內(nèi)（例如1天），都會(huì)有基本固定數(shù)量的使用者使用該系統(tǒng)，雖然每個(gè)使用者的行為不同，但從業(yè)務(wù)的角度來(lái)說(shuō)，如果所有這些用戶的操作都沒(méi)有遇到性能障礙，則可以說(shuō)該系統(tǒng)能夠承受該數(shù)量的并發(fā)用戶訪問(wèn)，這里的并發(fā)概念就是前面討論的業(yè)務(wù)并發(fā)用戶數(shù)。然而，如果考慮整個(gè)系統(tǒng)運(yùn)行過(guò)程中服務(wù)器所承受的壓力，情況就會(huì)不同了：在該系統(tǒng)的運(yùn)行過(guò)程中，把整個(gè)運(yùn)行過(guò)程劃分為離散的時(shí)間點(diǎn)，在每個(gè)點(diǎn)上，都有一個(gè)“同時(shí)向服務(wù)端發(fā)送請(qǐng)求的客戶數(shù)”，這個(gè)就是所稱的服務(wù)端承受的最大并發(fā)訪問(wèn)數(shù)。如果能找到運(yùn)行過(guò)程中可能出現(xiàn)的最大可能的服務(wù)端承受的最大并發(fā)訪問(wèn)數(shù)，則在該用戶數(shù)下，服務(wù)器承受的壓力

18、最大，資源承受的壓力也最大，在這種狀態(tài)下，可以考慮通過(guò)并發(fā)測(cè)試（Concurrency Testing）發(fā)現(xiàn)系統(tǒng)中存在的并發(fā)引起的資源爭(zhēng)用等問(wèn)題。在實(shí)際的性能測(cè)試中，經(jīng)常接觸到的與并發(fā)用戶數(shù)相關(guān)的概念還包括“并發(fā)用戶數(shù)”、“系統(tǒng)用戶數(shù)”和“同時(shí)在線用戶人數(shù)”，下面用一個(gè)實(shí)際的例子來(lái)說(shuō)明它們之間的差別。假設(shè)有一個(gè)OA系統(tǒng)，該系統(tǒng)有2000個(gè)使用用戶這就是說(shuō)，可能使用該OA系統(tǒng)的用戶總數(shù)是2000名，這個(gè)概念就是“系統(tǒng)用戶數(shù)”，該系統(tǒng)有一個(gè)“在線統(tǒng)計(jì)”功能（系統(tǒng)用一個(gè)全局變量計(jì)數(shù)所有已登錄的用戶），從在線統(tǒng)計(jì)功能中可以得到，最高峰時(shí)有500人在線（這個(gè)500就是一般所說(shuō)的“同時(shí)在線人數(shù)”），那么，

19、系統(tǒng)的并發(fā)用戶數(shù)是多少呢？根據(jù)我們對(duì)業(yè)務(wù)并發(fā)用戶數(shù)的定義，這500就是整個(gè)系統(tǒng)使用時(shí)最大的業(yè)務(wù)并發(fā)用戶數(shù)。當(dāng)然，500這個(gè)數(shù)值只是表明在最高峰時(shí)刻有500個(gè)用戶登錄了系統(tǒng)，并不表示實(shí)際服務(wù)器承受的壓力。因?yàn)榉?wù)器承受的壓力還與具體的用戶訪問(wèn)模式相關(guān)。例如，在這500個(gè)“同時(shí)使用系統(tǒng)”的用戶中，考察某一個(gè)時(shí)間點(diǎn)，在這個(gè)時(shí)間上，假設(shè)其中40%的用戶在饒有興致地看系統(tǒng)公告（注意：“看”這個(gè)動(dòng)作是不會(huì)對(duì)服務(wù)端產(chǎn)生任何負(fù)擔(dān)的），20%的用戶在填寫復(fù)雜的表格（對(duì)用戶填寫的表格來(lái)說(shuō)，只有在“提交”的時(shí)刻才會(huì)向服務(wù)端發(fā)送請(qǐng)求，填寫過(guò)程是不對(duì)服務(wù)端構(gòu)成壓力的），20%部分用戶在發(fā)呆（也就是什么也沒(méi)有做），剩下的

20、20%用戶在不停地從一個(gè)頁(yè)面跳轉(zhuǎn)到另一個(gè)頁(yè)面在這種場(chǎng)景下，可以說(shuō)，只有20%的用戶真正對(duì)服務(wù)器構(gòu)成了壓力。因此，從上面的例子中可以看出，服務(wù)器實(shí)際承受的壓力不只取決于業(yè)務(wù)并發(fā)用戶數(shù)，還取決于用戶的業(yè)務(wù)場(chǎng)景。那么，該系統(tǒng)的服務(wù)端承受的最大并發(fā)訪問(wèn)數(shù)是多少呢？這個(gè)取決于業(yè)務(wù)并發(fā)用戶數(shù)和業(yè)務(wù)場(chǎng)景，一般可以通過(guò)對(duì)服務(wù)器日志的分析得到。在實(shí)際的性能測(cè)試工作中，測(cè)試人員一般比較關(guān)心的是業(yè)務(wù)并發(fā)用戶數(shù)，也就是從業(yè)務(wù)角度關(guān)注究竟應(yīng)該設(shè)置多少個(gè)并發(fā)數(shù)比較合理，因此，在后面的討論中，也是主要針對(duì)業(yè)務(wù)并發(fā)用戶數(shù)進(jìn)行討論，而且，為了方便，直接將業(yè)務(wù)并發(fā)用戶數(shù)稱為并發(fā)用戶數(shù)。那么，究竟應(yīng)該如何獲得測(cè)試人員關(guān)心的并發(fā)用戶

21、數(shù)的具體數(shù)值呢？下面給出了一些用于估算并發(fā)用戶數(shù)的公式。 （1） （2）在公式（1）中，C是平均的并發(fā)用戶數(shù)；n是login session的數(shù)量；L是login session的平均長(zhǎng)度；T指考察的時(shí)間段長(zhǎng)度。例如，對(duì)一個(gè)典型的OA應(yīng)用，考察的時(shí)間段長(zhǎng)度應(yīng)該為8小時(shí)的工作時(shí)間。公式（2）則給出了并發(fā)用戶數(shù)峰值的計(jì)算方式，其中，指并發(fā)用戶數(shù)的峰值，C就是公式（1）中得到的平均的并發(fā)用戶數(shù)。該公式的得出是假設(shè)用戶的login session產(chǎn)生符合泊松分布而估算得到的。下面根據(jù)上述給出的方法進(jìn)行實(shí)例計(jì)算。實(shí)例：假設(shè)有一個(gè)OA系統(tǒng)，該系統(tǒng)有3000個(gè)用戶，平均每天大約有400個(gè)用戶要訪問(wèn)該系統(tǒng)，對(duì)

22、一個(gè)典型用戶來(lái)說(shuō)，一天之內(nèi)用戶從登錄到退出該系統(tǒng)的平均時(shí)間為4小時(shí)，在一天的時(shí)間內(nèi)，用戶只在8小時(shí)內(nèi)使用該系統(tǒng)。則根據(jù)公式（1）和公式（2），可以得到：C=4004/8=200200+3=242當(dāng)然，這是種可行的方法，但仔細(xì)考究起來(lái)，其并不是惟一，甚至說(shuō)不上是最精確的方法，因?yàn)樵诠街腥匀恍枰浪恪捌骄脩魯?shù)”和“l(fā)ogin session的長(zhǎng)度”，而要精確估算這兩個(gè)值并不容易。另外，考慮到用戶的業(yè)務(wù)操作存在一定的時(shí)間集中性（也就是說(shuō)，用戶對(duì)系統(tǒng)業(yè)務(wù)的訪問(wèn)往往不是平均分布在整個(gè)考察時(shí)間段內(nèi)，而是相對(duì)集中地分布在某幾個(gè)時(shí)間段內(nèi)），采用公式（1）和公式（2）進(jìn)行計(jì)算仍然存在一定的偏差。我們給出對(duì)該

23、公式使用的一些建議，遵循這些建議，可以更精確地計(jì)算得到并發(fā)用戶數(shù)：（1）以更細(xì)的時(shí)間粒度進(jìn)行考察：例如，可以設(shè)定1個(gè)小時(shí)為考察時(shí)間的粒度，對(duì)一個(gè)典型的OA系統(tǒng)，將一天的上班時(shí)間劃分為8個(gè)區(qū)間，這樣可以解決前面提到的業(yè)務(wù)操作存在的時(shí)間集中性的問(wèn)題。（2）考慮典型的業(yè)務(wù)模式：不同的應(yīng)用有不同的業(yè)務(wù)模式，例如，一個(gè)內(nèi)部系統(tǒng)一般在上班開(kāi)始后的30分鐘至1個(gè)小時(shí)集中出現(xiàn)用戶的登錄；一個(gè)賬務(wù)系統(tǒng)在每月的結(jié)賬日前幾天會(huì)比較繁忙；一個(gè)門戶網(wǎng)站在重大消息發(fā)布的前后會(huì)有訪問(wèn)高峰；一個(gè)旅游的網(wǎng)站在節(jié)假日前夕會(huì)有大量用戶的訪問(wèn)因此，在考慮計(jì)算并發(fā)用戶數(shù)時(shí)，可以結(jié)合應(yīng)用的業(yè)務(wù)模式，多考慮一些可能發(fā)生的場(chǎng)景，基于這些場(chǎng)景

24、進(jìn)行估算。除了這種介紹的方法之外，對(duì)于企業(yè)內(nèi)部使用的Web系統(tǒng)來(lái)說(shuō)，一個(gè)更一般的（當(dāng)然精度更差）經(jīng)驗(yàn)公式是： （3） （4）也就是說(shuō)，用每天訪問(wèn)系統(tǒng)用戶數(shù)的10%作為平均的并發(fā)用戶數(shù)，并發(fā)用戶數(shù)的最大值由并發(fā)用戶數(shù)乘上一個(gè)調(diào)整因子r得到，r的取值一般為23。公式（3）和公式（4）可以在要求不太嚴(yán)格的性能測(cè)試，或是只有很少數(shù)據(jù)支持分析的性能測(cè)試中使用。在本節(jié)的前面部分提到了“日志分析”方法。所謂“日志分析”方法是指通過(guò)對(duì)應(yīng)用服務(wù)器的日志進(jìn)行分析，從而了解系統(tǒng)用戶的使用狀態(tài)，從日志中計(jì)算出“服務(wù)器承受的最大并發(fā)用戶訪問(wèn)數(shù)”數(shù)據(jù)。這種方式得到的數(shù)據(jù)準(zhǔn)確度和可信度都比較高，對(duì)于Internet應(yīng)用等無(wú)

25、法估計(jì)用戶數(shù)量和用戶行為模式的應(yīng)用，這種方式最為可信。1.2.3 吞吐量吞吐量是指“單位時(shí)間內(nèi)系統(tǒng)處理的客戶請(qǐng)求的數(shù)量”，直接體現(xiàn)軟件系統(tǒng)的性能承載能力。一般來(lái)說(shuō)，吞吐量用請(qǐng)求數(shù)/秒或是頁(yè)面數(shù)/秒來(lái)衡量，從業(yè)務(wù)的角度，吞吐量也可以用訪問(wèn)人數(shù)/天或是處理的業(yè)務(wù)數(shù)/小時(shí)等單位來(lái)衡量。當(dāng)然，從網(wǎng)絡(luò)的角度來(lái)說(shuō)，也可以用字節(jié)數(shù)/天來(lái)考察網(wǎng)絡(luò)流量。例如，對(duì)一個(gè)Web應(yīng)用系統(tǒng)來(lái)說(shuō)，從系統(tǒng)的處理能力考慮，可以以頁(yè)面數(shù)/秒作為吞吐量的標(biāo)準(zhǔn)；對(duì)一個(gè)銀行的業(yè)務(wù)前臺(tái)系統(tǒng)來(lái)說(shuō)，可以以其處理的業(yè)務(wù)數(shù)/小時(shí)作為吞吐量的標(biāo)準(zhǔn)。在本章的開(kāi)始部分，已經(jīng)討論過(guò)，對(duì)于交互式應(yīng)用，用戶直接的體驗(yàn)是“響應(yīng)時(shí)間”，通過(guò)“并發(fā)用戶數(shù)”和“響

26、應(yīng)時(shí)間”可以確定系統(tǒng)的性能規(guī)劃；但對(duì)于非交互式應(yīng)用，用“吞吐量”來(lái)描述我們對(duì)系統(tǒng)性能的期望可能更加合理。對(duì)于交互式應(yīng)用來(lái)說(shuō)，吞吐量指標(biāo)反映的是服務(wù)器承受的壓力。在容量規(guī)劃的測(cè)試中，吞吐量是一個(gè)重點(diǎn)關(guān)注的指標(biāo)，因?yàn)樗軌蛘f(shuō)明系統(tǒng)級(jí)別的負(fù)載能力；另外，在性能調(diào)優(yōu)的過(guò)程中，吞吐量指標(biāo)也有重要的價(jià)值，例如，Empirix公司在報(bào)告中聲稱，在他們所發(fā)現(xiàn)的性能問(wèn)題中，有80%是因?yàn)橥掏铝康南拗茖?dǎo)致的。在對(duì)Web系統(tǒng)的性能測(cè)試過(guò)程中，吞吐量主要以請(qǐng)求數(shù)（單擊數(shù)）/秒、頁(yè)面數(shù)/秒或是字節(jié)數(shù)/秒來(lái)體現(xiàn)，吞吐量指標(biāo)可以在兩個(gè)方面發(fā)揮作用：（1）用于協(xié)助設(shè)計(jì)性能測(cè)試場(chǎng)景，以及衡量性能測(cè)試場(chǎng)景是否達(dá)到了預(yù)期的設(shè)計(jì)目標(biāo)

27、：在設(shè)計(jì)性能測(cè)試場(chǎng)景時(shí)，吞吐量可被用于協(xié)助設(shè)計(jì)性能測(cè)試場(chǎng)景，根據(jù)估算的吞吐量數(shù)據(jù)，可以對(duì)應(yīng)到測(cè)試場(chǎng)景的事務(wù)發(fā)生頻率、事務(wù)發(fā)生次數(shù)等；另外，在測(cè)試完成后，根據(jù)實(shí)際的吞吐量可以衡量測(cè)試是否達(dá)到了預(yù)期的目標(biāo)。（2）用于協(xié)助分析性能瓶頸：吞吐量的限制是性能瓶頸的一種重要表現(xiàn)形式，因此，有針對(duì)性地對(duì)吞吐量設(shè)計(jì)測(cè)試，可以協(xié)助盡快定位到性能瓶頸所在位置。例如，RBI（Rapid Bottleneck Identify）方法就主要通過(guò)吞吐量測(cè)試發(fā)現(xiàn)性能瓶頸。以不同方式表達(dá)的吞吐量可以說(shuō)明不同層次的問(wèn)題。例如，以字節(jié)數(shù)/秒方式表示的吞吐量主要受網(wǎng)絡(luò)基礎(chǔ)設(shè)施、服務(wù)器架構(gòu)、應(yīng)用服務(wù)器制約；以單擊數(shù)/秒方式表示的吞吐

28、量主要受應(yīng)用服務(wù)器和應(yīng)用代碼的制約。作為性能測(cè)試時(shí)的主要關(guān)注指標(biāo)，吞吐量和并發(fā)用戶數(shù)之間存在一定的聯(lián)系。在沒(méi)有遇到性能瓶頸的時(shí)候，吞吐量可以采用如下公式計(jì)算： （5）其中，F(xiàn)表示吞吐量；Nvu表示VU（Virtuae User，虛擬用戶）的個(gè)數(shù)；R表示每個(gè)VU發(fā)出的請(qǐng)求（單擊）數(shù)量；T表示性能測(cè)試所用的時(shí)間。但如果遇到了性能瓶頸，此時(shí)吞吐量和VU數(shù)量之間就不再符合公式（5）給出的關(guān)系。常用于分析吞吐量的圖形是“吞吐量VU數(shù)量”的關(guān)聯(lián)圖。圖1.5給出了兩個(gè)“吞吐量VU數(shù)量”關(guān)聯(lián)圖的示例。從圖中可以看到，吞吐量在VU數(shù)量增長(zhǎng)到一定程度的時(shí)候產(chǎn)生了性能 瓶頸。最后，必須要說(shuō)明的是，雖然吞吐量指標(biāo)可被

29、看作是系統(tǒng)承受壓力的體現(xiàn)，但在不同并發(fā)用戶數(shù)量的情況下，對(duì)同一個(gè)系統(tǒng)施加相同的吞吐量壓力，很可能會(huì)得到不同的測(cè)試結(jié)果。本文給出了一個(gè)示例。圖1.5 “吞吐量VU數(shù)量”關(guān)聯(lián)圖示例對(duì)同一個(gè)應(yīng)用進(jìn)行兩次不同的性能測(cè)試，測(cè)試A采用100個(gè)并發(fā)，每個(gè)VU間隔1秒發(fā)出一個(gè)請(qǐng)求；測(cè)試B采用1000個(gè)并發(fā)，每個(gè)VU間隔10秒發(fā)出一個(gè)請(qǐng)求；對(duì)測(cè)試A，測(cè)試時(shí)的吞吐量（頁(yè)/秒）為1001/1=100；對(duì)測(cè)試B來(lái)說(shuō)，吞吐量（頁(yè)/秒）為10001/10=100，仍然是100。但從測(cè)試結(jié)果來(lái)看，執(zhí)行測(cè)試A時(shí)，應(yīng)用在50頁(yè)/秒出現(xiàn)性能瓶頸，而測(cè)試B在25頁(yè)/秒出現(xiàn)性能瓶頸。1.2.4 性能計(jì)數(shù)器性能計(jì)數(shù)器（Counter）

30、是描述服務(wù)器或操作系統(tǒng)性能的一些數(shù)據(jù)指標(biāo)。例如，對(duì)Windows系統(tǒng)來(lái)說(shuō)，使用內(nèi)存數(shù)（Memory In Usage），進(jìn)程時(shí)間（Total Process Time）等都是常見(jiàn)的計(jì)數(shù)器。計(jì)數(shù)器在性能測(cè)試中發(fā)揮著“監(jiān)控和分析”的關(guān)鍵作用，尤其是在分析系統(tǒng)的可擴(kuò)展性、進(jìn)行性能瓶頸的定位時(shí)，對(duì)計(jì)數(shù)器取值的分析非常關(guān)鍵。但必須說(shuō)明的是，單一的性能計(jì)數(shù)器只能體現(xiàn)系統(tǒng)性能的某一個(gè)方面，對(duì)性能測(cè)試結(jié)果的分析必須基于多個(gè)不同的計(jì)數(shù)器。與性能計(jì)數(shù)器相關(guān)的另一個(gè)術(shù)語(yǔ)是“資源利用率”。該術(shù)語(yǔ)指的是系統(tǒng)各種資源的使用狀況。為了方便比較，一般用“資源的實(shí)際使用/總的資源可用量”形成資源利用率的數(shù)據(jù)，用以進(jìn)行各種資源使

31、用的比較。例如，我們會(huì)說(shuō)到，“某某系統(tǒng)在承受10000用戶的并發(fā)訪問(wèn)時(shí)，Web服務(wù)器的CPU占用率為68%，平均的內(nèi)存占用率為55%”，這其中，68%和55%就是典型的資源利用率的數(shù)值。在性能測(cè)試中常用資源利用率進(jìn)行橫向的對(duì)比，例如，在進(jìn)行測(cè)試時(shí)會(huì)發(fā)現(xiàn)，資源A的使用率達(dá)到了接近100%的數(shù)值，而其他的資源利用率都處于比較低的水平，則可以很清楚地知道，資源A就很有可能是系統(tǒng)的一個(gè)性能瓶頸。當(dāng)然，資源利用率在通常的情況下需要結(jié)合響應(yīng)時(shí)間變化曲線、系統(tǒng)負(fù)載曲線等各種指標(biāo)進(jìn)行分析。性能計(jì)數(shù)器是性能測(cè)試分析的主要參考值，本書的第3章對(duì)其進(jìn)行了詳細(xì)的解釋說(shuō)明，并說(shuō)明了如何利用這些計(jì)數(shù)器分析系統(tǒng)性能瓶頸。1

32、.2.5 思考時(shí)間思考時(shí)間（Think Time），也被稱為“休眠時(shí)間”，從業(yè)務(wù)的角度來(lái)說(shuō)，這個(gè)時(shí)間指的是用戶在進(jìn)行操作時(shí)，每個(gè)請(qǐng)求之間的間隔時(shí)間。前面已經(jīng)討論過(guò)，對(duì)交互式應(yīng)用來(lái)說(shuō)，用戶在使用系統(tǒng)時(shí)，不大可能持續(xù)不斷地發(fā)出請(qǐng)求，更一般的模式應(yīng)該是用戶在發(fā)出一個(gè)請(qǐng)求后，等待一段時(shí)間，再發(fā)出下一個(gè)請(qǐng)求。因此，從自動(dòng)化測(cè)試實(shí)現(xiàn)的角度來(lái)說(shuō)，要真實(shí)地模擬用戶操作，就必須在測(cè)試腳本中讓各個(gè)操作之間等待一段時(shí)間，體現(xiàn)在腳本中，具體而言，就是在操作之間放置一個(gè)Think的函數(shù)，使得腳本在執(zhí)行兩個(gè)操作之間等待一段時(shí)間。在測(cè)試腳本中，思考時(shí)間體現(xiàn)為腳本中兩個(gè)請(qǐng)求語(yǔ)句之間的間隔時(shí)間。不同的測(cè)試工具提供了不同的函數(shù)或

33、者方法來(lái)實(shí)現(xiàn)思考時(shí)間，本書附錄A中對(duì)思考時(shí)間進(jìn)行了的詳細(xì)描述，另外，本書實(shí)踐篇也有一些使用思考時(shí)間的實(shí)際 例子。在實(shí)際的測(cè)試中，設(shè)置多長(zhǎng)的思考時(shí)間最為合理是許多性能測(cè)試工程師關(guān)心的問(wèn)題。其實(shí)，思考時(shí)間與迭代次數(shù)、并發(fā)用戶數(shù)和吞吐量之間存在一定的關(guān)系。公式（5）說(shuō)明吞吐量是VU數(shù)量Nvu、每個(gè)用戶發(fā)出請(qǐng)求數(shù)R和時(shí)間T的函數(shù)，而其中的R又可以用時(shí)間T和用戶的思考時(shí)間Ts來(lái)計(jì)算： （6）用公式（5）和公式（6）進(jìn)行化簡(jiǎn)運(yùn)算可得，吞吐量與Nvu成正比，而與Ts成反比。不少性能測(cè)試工程師在實(shí)際的應(yīng)用中都對(duì)如何給定合適的思考時(shí)間存在疑問(wèn)，那么，在具體的測(cè)試實(shí)踐中，究竟該怎樣選擇合適的思考時(shí)間呢？下面給出一

34、個(gè)計(jì)算思考時(shí)間的一般步驟：1首先計(jì)算出系統(tǒng)的并發(fā)用戶數(shù)；2統(tǒng)計(jì)出系統(tǒng)平均的吞吐量；3統(tǒng)計(jì)出平均每個(gè)用戶發(fā)出的請(qǐng)求數(shù)量；4根據(jù)公式（6）計(jì)算出思考時(shí)間。當(dāng)然，為了讓性能測(cè)試場(chǎng)景更加符合實(shí)際情況，可以考慮以步驟4計(jì)算得出的思考時(shí)間為基準(zhǔn)，讓實(shí)際的思考時(shí)間在一定幅度內(nèi)隨機(jī)變動(dòng)。LoadRunner和Segue Silk Performer等工具都支持以這種方式設(shè)置思考時(shí)間。最后要說(shuō)明的是“0思考時(shí)間”。有些文章建議在測(cè)試中使用“0”作為思考時(shí)間，以給系統(tǒng)更大的壓力。在本人的實(shí)際性能測(cè)試過(guò)程中，對(duì)于交互式的應(yīng)用系統(tǒng)，很少遇到這樣的要求。因?yàn)閺臉I(yè)務(wù)的角度考慮，思考時(shí)間用于更真實(shí)地模擬用戶操作，設(shè)置思考時(shí)

35、間為0，基本上不具有實(shí)際的業(yè)務(wù)含義。但在非交互式應(yīng)用的性能測(cè)試過(guò)程中，有時(shí)候確實(shí)會(huì)將思考時(shí)間設(shè)置為0，這時(shí)候是模擬一種盡可能大的壓力，研究系統(tǒng)在巨大壓力下的表現(xiàn)。可以說(shuō)，如果測(cè)試的目的是為了“驗(yàn)證應(yīng)用系統(tǒng)具有預(yù)期的能力”（也就是所說(shuō)的“能力驗(yàn)證”的應(yīng)用領(lǐng)域），就應(yīng)該盡量模擬用戶在使用業(yè)務(wù)時(shí)的真實(shí)思考時(shí)間；如果目的是進(jìn)行更一般的研究，例如“了解系統(tǒng)在壓力下的性能水平”或是“了解系統(tǒng)承受壓力的能力”（也就是所說(shuō)的“規(guī)劃能力”的應(yīng)用領(lǐng)域），則可以采用0思考時(shí)間。二、 性能測(cè)試方法論與方法“沒(méi)有規(guī)矩，不成方圓”。對(duì)性能測(cè)試來(lái)說(shuō)，如果沒(méi)有合適的方法論指導(dǎo)，性能測(cè)試很容易成為一種隨意的測(cè)試行為，而隨意進(jìn)行

36、的性能測(cè)試很難取得實(shí)際的作用和預(yù)期的效果，因此本章將簡(jiǎn)單介紹幾種常見(jiàn)的性能測(cè)試過(guò)程和方法，并著重介紹常用的性能測(cè)試方法。2.1 性能測(cè)試方法論2.1.1 SEI負(fù)載測(cè)試計(jì)劃過(guò)程SEI負(fù)載測(cè)試計(jì)劃過(guò)程（SEI Load Testing Planning Process）是一個(gè)關(guān)注于負(fù)載測(cè)試計(jì)劃的方法，其目標(biāo)是產(chǎn)生“清晰、易理解、可驗(yàn)證的負(fù)載測(cè)試計(jì)劃”。SEI負(fù)載測(cè)試計(jì)劃過(guò)程包括6個(gè)關(guān)注的區(qū)域（Area）：目標(biāo)、用戶、用例、生產(chǎn)環(huán)境、測(cè)試環(huán)境和測(cè)試場(chǎng)景。SEI負(fù)載測(cè)試計(jì)劃過(guò)程將以上述6個(gè)區(qū)域作為負(fù)載測(cè)試計(jì)劃需要重點(diǎn)關(guān)注和考慮的內(nèi)容，其重點(diǎn)關(guān)注以下幾個(gè)方面的內(nèi)容：1生產(chǎn)環(huán)境與測(cè)試環(huán)境的不同：由于負(fù)載

37、測(cè)試環(huán)境與實(shí)際的生產(chǎn)環(huán)境存在一定的差異，因此，在測(cè)試環(huán)境上對(duì)應(yīng)用系統(tǒng)進(jìn)行的負(fù)載測(cè)試結(jié)果很可能不能準(zhǔn)確反映該應(yīng)用系統(tǒng)在生產(chǎn)環(huán)境上的實(shí)際性能表現(xiàn)，為了規(guī)避這個(gè)風(fēng)險(xiǎn)，必須仔細(xì)設(shè)計(jì)測(cè)試環(huán)境。2用戶分析：用戶是對(duì)被測(cè)應(yīng)用系統(tǒng)性能表現(xiàn)最關(guān)注和受影響最大的對(duì)象，因此，必須通過(guò)對(duì)用戶行為進(jìn)行分析，依據(jù)用戶行為模型建立用例和場(chǎng)景。3用例：用例是用戶使用某種順序和操作方式對(duì)業(yè)務(wù)過(guò)程進(jìn)行實(shí)現(xiàn)的過(guò)程，對(duì)負(fù)載測(cè)試來(lái)說(shuō)，用例的作用主要在于分析和分解出關(guān)鍵的業(yè)務(wù)，判斷每個(gè)業(yè)務(wù)發(fā)生的頻度、業(yè)務(wù)出現(xiàn)性能問(wèn)題的風(fēng)險(xiǎn)等。從SEI負(fù)載測(cè)試計(jì)劃過(guò)程的描述中可以看到，SEI負(fù)載測(cè)試計(jì)劃過(guò)程給出了負(fù)載測(cè)試需要關(guān)注的重點(diǎn)區(qū)域，但嚴(yán)格來(lái)說(shuō)，其

38、并不能被稱為具體的方法論，因?yàn)槠鋬H僅給出了對(duì)測(cè)試計(jì)劃過(guò)程的一些關(guān)注內(nèi)容，而沒(méi)有能夠形成實(shí)際的可操作的過(guò)程。同功能測(cè)試一樣，性能測(cè)試也必須經(jīng)歷測(cè)試需求、測(cè)試設(shè)計(jì)、測(cè)試執(zhí)行、測(cè)試分析等階段，但由于性能測(cè)試自身的特殊性（例如，需要引入工具，分析階段相對(duì)重要），性能測(cè)試過(guò)程又不能完全套用功能測(cè)試過(guò)程。SEI負(fù)載測(cè)試計(jì)劃過(guò)程在負(fù)載測(cè)試需要關(guān)注的具體內(nèi)容上提供了參考，但其并不是一個(gè)完整的測(cè)試過(guò)程。2.1.2 RBI方法RBI（Rapid Bottleneck Identify）方法是Empirix公司提出的一種用于快速識(shí)別系統(tǒng)性能瓶頸的方法。該方法基于以下一些事實(shí)：1. 發(fā)現(xiàn)的80%系統(tǒng)的性能瓶頸都由吞吐

39、量制約；2. 并發(fā)用戶數(shù)和吞吐量瓶頸之間存在一定的關(guān)聯(lián)；3. 采用吞吐量測(cè)試可以更快速定位問(wèn)題。RBI方法首先訪問(wèn)服務(wù)器上的“小頁(yè)面”和“簡(jiǎn)單應(yīng)用”，從應(yīng)用服務(wù)器、網(wǎng)絡(luò)等基礎(chǔ)的層次上了解系統(tǒng)吞吐量表現(xiàn)；其次選擇不同的場(chǎng)景，設(shè)定不同的并發(fā)用戶數(shù)，使其吞吐量保持基本一致的增長(zhǎng)趨勢(shì)，通過(guò)不斷增加并發(fā)用戶數(shù)和吞吐量，觀察系統(tǒng)的性能表現(xiàn)。在確定具體的性能瓶頸時(shí)，RBI將性能瓶頸的定位按照一種“自上而下”的分析方式進(jìn)行分析，首先確定是由并發(fā)還是由吞吐量引發(fā)的性能表現(xiàn)限制，然后從網(wǎng)絡(luò)、數(shù)據(jù)庫(kù)、應(yīng)用服務(wù)器和代碼本身4個(gè)環(huán)節(jié)確定系統(tǒng)性能具體的瓶頸。RBI方法在性能瓶頸的定位過(guò)程中能發(fā)揮良好的作用，其對(duì)性能分析和

40、瓶頸定位的方法值得借鑒，但其也不是完整的性能測(cè)試過(guò)程。2.1.3 性能下降曲線分析法性能下降曲線實(shí)際上描述的是性能隨用戶數(shù)增長(zhǎng)而出現(xiàn)下降趨勢(shì)的曲線。而這里所說(shuō)的“性能”可以是響應(yīng)時(shí)間，也可以是吞吐量或是單擊數(shù)/秒的數(shù)據(jù)。當(dāng)然，一般來(lái)說(shuō)，“性能”主要是指響應(yīng)時(shí)間。圖1.6給出了一個(gè)“響應(yīng)時(shí)間下降曲線”的示例。圖1.6 一條典型的響應(yīng)時(shí)間性能下降曲線示例從圖1.6可以看到，一條曲線可以分為以下幾個(gè)部分：（1）單用戶區(qū)域?qū)ο到y(tǒng)的一個(gè)單用戶的響應(yīng)時(shí)間。這對(duì)建立性能的參考值很有作用。（2）性能平坦區(qū)在不進(jìn)行更多性能調(diào)優(yōu)情況下所能期望達(dá)到的最佳性能。這個(gè)區(qū)域可被用作基線或是benchmark。（3）壓力區(qū)

41、域應(yīng)用“輕微下降”的地方。典型的、最大的建議用戶負(fù)載是壓力區(qū)域的開(kāi)始。（4）性能拐點(diǎn)性能開(kāi)始“急劇下降”的點(diǎn)。這幾個(gè)區(qū)域?qū)嶋H上明確標(biāo)識(shí)了系統(tǒng)性能最優(yōu)秀的區(qū)間，系統(tǒng)性能開(kāi)始變壞的區(qū)間，以及系統(tǒng)性能出現(xiàn)急劇下降的點(diǎn)。對(duì)性能測(cè)試來(lái)說(shuō)，找到這些區(qū)間和拐點(diǎn)，也就可以找到性能瓶頸產(chǎn)生的地方。因此，對(duì)性能下降曲線分析法來(lái)說(shuō)，主要關(guān)注的是性能下降曲線上的各個(gè)區(qū)間和相應(yīng)的拐點(diǎn)，通過(guò)識(shí)別不同的區(qū)間和拐點(diǎn)，從而為性能瓶頸識(shí)別和性能調(diào)優(yōu)提供依據(jù)。2.1.4 LoadRunner的性能測(cè)試過(guò)程圖1.7給出了LoadRunner的性能測(cè)試過(guò)程。LoadRunner將性能測(cè)試過(guò)程分為計(jì)劃測(cè)試、測(cè)試設(shè)計(jì)、創(chuàng)建VU腳本、創(chuàng)建測(cè)

42、試場(chǎng)景、運(yùn)行測(cè)試場(chǎng)景和分析結(jié)果6個(gè)步驟。圖1.7 LoadRunner的性能測(cè)試過(guò)程計(jì)劃測(cè)試階段主要進(jìn)行測(cè)試需求的收集、典型場(chǎng)景的確定；測(cè)試設(shè)計(jì)階段主要進(jìn)行測(cè)試用例的設(shè)計(jì)；創(chuàng)建VU腳本階段主要根據(jù)設(shè)計(jì)的用例創(chuàng)建腳本；創(chuàng)建測(cè)試場(chǎng)景階段主要進(jìn)行測(cè)試場(chǎng)景的設(shè)計(jì)和設(shè)置，包括監(jiān)控指標(biāo)的設(shè)定；運(yùn)行測(cè)試場(chǎng)景階段對(duì)已創(chuàng)建的測(cè)試場(chǎng)景進(jìn)行執(zhí)行，收集相應(yīng)數(shù)據(jù)；分析結(jié)果階段主要進(jìn)行結(jié)果分析和報(bào)告工作。LoadRunner提供的這個(gè)性能測(cè)試過(guò)程已經(jīng)涵蓋了性能測(cè)試工作的大部分內(nèi)容，但由于該過(guò)程過(guò)于緊密地與LoadRunner工具集成，沒(méi)有兼顧使用其他工具，或是用戶自行設(shè)計(jì)工具的需求，也不能被稱為是一個(gè)普適性的測(cè)試過(guò)程。另

43、外，LoadRunner提供的該性能測(cè)試過(guò)程并未對(duì)計(jì)劃測(cè)試階段、測(cè)試設(shè)計(jì)階段的具體行為、方法和目的進(jìn)行詳細(xì)描述，因此該方法最多只能被稱為“使用LoadRunner進(jìn)行測(cè)試的過(guò)程”，而不是一個(gè)適應(yīng)性廣泛的性能測(cè)試過(guò)程。2.1.5 Segue提供的性能測(cè)試過(guò)程圖1.8給出了Segue公司Silk Performer提供的性能測(cè)試過(guò)程。該性能測(cè)試過(guò)程與Performance Testing Lifecycle描述的一致，是一個(gè)不斷try-check的過(guò)程。Silk Performer提供的性能測(cè)試過(guò)程從確定性能基線開(kāi)始，通過(guò)單用戶對(duì)應(yīng)用的訪問(wèn)獲取性能取值的基線，然后設(shè)定可接受的性能目標(biāo)（響應(yīng)時(shí)間），

44、用不同的并發(fā)用戶數(shù)等重復(fù)進(jìn)行測(cè)試。Segue提供的這種性能測(cè)試方法非常適合性能調(diào)優(yōu)和性能優(yōu)化，通過(guò)不斷重復(fù)的try-check過(guò)程，可以逐一找到可能導(dǎo)致性能瓶頸的地方并對(duì)其進(jìn)行 優(yōu)化。圖1.8 Segue Silk Performer提供的性能測(cè)試過(guò)程但Segue提供的這個(gè)性能測(cè)試過(guò)程模型存在與LoadRunner的性能測(cè)試過(guò)程同樣的問(wèn)題， 就是過(guò)于依賴工具自身，另外，該過(guò)程模型缺乏對(duì)計(jì)劃、設(shè)計(jì)的階段的明確劃分，也沒(méi)有給出具體的活動(dòng)和目標(biāo)。2.2 性能測(cè)試的方法性能測(cè)試的方法很多，常見(jiàn)的比如說(shuō)的“負(fù)載測(cè)試”和“壓力測(cè)試”就是其中一些類型，此外還存在其他的一些類型的性能測(cè)試方法。根據(jù)大范圍的性能

45、測(cè)試的概念的界定，性能測(cè)試可包括如下幾種方法： 性能測(cè)試（Performance Testing）； 負(fù)載測(cè)試（Load Testing）； 壓力測(cè)試（Stress Testing）； 配置測(cè)試（Configuration Testing）； 并發(fā)測(cè)試（Concurrency Testing）； 可靠性測(cè)試（Reliability Testing）； 失效恢復(fù)測(cè)試（Failover Testing）；2.2.1 性能測(cè)試（Performance Testing）性能測(cè)試（Performance Testing）方法是通過(guò)模擬生產(chǎn)運(yùn)行的業(yè)務(wù)壓力量和使用場(chǎng)景組合，測(cè)試系統(tǒng)的性能是否滿足生產(chǎn)性能要求

46、。Performance Testing是一種最常見(jiàn)的測(cè)試方法，通俗地說(shuō)，這種測(cè)試方法就是要在特定的運(yùn)行條件下驗(yàn)證系統(tǒng)的能力狀況。這種方法的特點(diǎn)有：（1） 這種方法的主要目的是驗(yàn)證系統(tǒng)是否有系統(tǒng)宣稱具有的能力。Performance Testing方法包括確定用戶場(chǎng)景、給出需要關(guān)注的性能指標(biāo)、測(cè)試執(zhí)行和測(cè)試分析這幾個(gè)步驟，這是一種完全確定了系統(tǒng)運(yùn)行環(huán)境和測(cè)試行為的測(cè)試方法，其目的只能是依據(jù)事先的性能規(guī)劃，驗(yàn)證系統(tǒng)有沒(méi)有達(dá)到其宣稱具有的能力。（2） 這種方法需要事先了解被測(cè)試系統(tǒng)典型場(chǎng)景，并具有確定的性能目標(biāo)。Performance Testing方法需要首先了解被測(cè)西歐他能夠的典型場(chǎng)景，所謂的

47、典型場(chǎng)景，就是指具有代表性的用戶業(yè)務(wù)操作，一個(gè)典型場(chǎng)景包括操作序列、并發(fā)用戶數(shù)量條件。其次，這種方法需要有確定的性能目標(biāo)，性能目標(biāo)的描述基本上是這樣的方式：“要求系統(tǒng)在100個(gè)并發(fā)用戶的條件下進(jìn)行某業(yè)務(wù)操作，響應(yīng)時(shí)間不超過(guò)5秒”。（3） 這種方法要求在已確定的環(huán)境下運(yùn)行。Performance Testing方法的運(yùn)行環(huán)境必須是確定的。軟件系統(tǒng)的性能表現(xiàn)與非常多的因素相關(guān)，無(wú)法根據(jù)系統(tǒng)在一個(gè)環(huán)境上的表現(xiàn)趨推斷其在另一個(gè)不同環(huán)境中的表現(xiàn)，因此對(duì)這種驗(yàn)證性的測(cè)試，必須要求測(cè)試時(shí)的環(huán)境（硬件設(shè)備、軟件環(huán)境、網(wǎng)絡(luò)條件、基礎(chǔ)數(shù)據(jù)等）都已經(jīng)確定。2.2.2 負(fù)載測(cè)試（Load Testing）負(fù)載測(cè)試（L

48、oad Testing）方法通過(guò)在被測(cè)系統(tǒng)上不斷增加壓力，直到性能指標(biāo)，例如“響應(yīng)時(shí)間”超過(guò)預(yù)定指標(biāo)或者某種資源使用已經(jīng)達(dá)到飽和狀態(tài)。這種測(cè)試放大可以找到系統(tǒng)的處理極限，為系統(tǒng)調(diào)優(yōu)提供數(shù)據(jù)。在某些情況下，這種方法有時(shí)也被稱為可量性測(cè)試（Scalability Testing）。該方法有這樣一些特點(diǎn)：（1） 這種性能測(cè)試方法的主要目的是找到系統(tǒng)處理能力的極限。Load Testing方法通過(guò)“檢測(cè)-加壓-直到性能指標(biāo)超過(guò)預(yù)期”的手段，其主要目的是找到系統(tǒng)處理能力的極限，這個(gè)極限一般會(huì)用“在給定條件下最多允許120個(gè)并發(fā)用戶訪問(wèn)”或是“在給定條件下最多能夠在1小時(shí)內(nèi)處理2100筆業(yè)務(wù)”這樣的描述來(lái)

49、體現(xiàn)。而“預(yù)期的性能指標(biāo)”一般會(huì)被定義為“響應(yīng)時(shí)間不超過(guò)10秒”、“服務(wù)器平均CPU利用率低于65%”等指標(biāo)。（2） 這種性能測(cè)試方法需要在給定的測(cè)試環(huán)境下進(jìn)行，通常也需要考慮被測(cè)系統(tǒng)的與唯物壓力量和典型場(chǎng)景，使得測(cè)試結(jié)果具有業(yè)務(wù)上的意義。Load Testing方法由于涉及到“預(yù)定的性能指標(biāo)”等需要進(jìn)行比較的數(shù)據(jù)，也必須在給定的測(cè)試環(huán)境下進(jìn)行。另外，Load Testing方法在“加壓”的時(shí)候，必須選擇典型場(chǎng)景，在增加壓力時(shí)保證這種壓力具有業(yè)務(wù)上的意義。（3） 這種性能測(cè)試方法是一般用來(lái)了解系統(tǒng)的性能容量，或是配合性能調(diào)優(yōu)來(lái)使用。Load Testing方法可以用來(lái)了解系統(tǒng)的性能容量（系統(tǒng)在

50、保證一定響應(yīng)時(shí)間的情況下能夠允許多少并發(fā)用戶的訪問(wèn)），或是用來(lái)配合性能調(diào)優(yōu)，用這種方法比較調(diào)優(yōu)前后的性能差異。2.2.3 壓力測(cè)試（Stress Testing）壓力測(cè)試（Stress Testing）方法測(cè)試系統(tǒng)在一定飽和狀態(tài)下，例如CPU、內(nèi)存等在飽和使用情況下，系統(tǒng)能夠處理的會(huì)話能力，以及系統(tǒng)是否會(huì)出現(xiàn)錯(cuò)誤。Stress Testing方法具有以下特點(diǎn)：（1） 這種性能測(cè)試方法的主要目的是檢查系統(tǒng)處于壓力情況下時(shí)，應(yīng)用的表現(xiàn)。Stress Testing方法通過(guò)增加訪問(wèn)壓力（例如，增加并發(fā)的用戶數(shù)量等），使應(yīng)用系統(tǒng)的資源使用保持在一定的水平，這種測(cè)試方法的主要目的是檢驗(yàn)此時(shí)的應(yīng)用表現(xiàn)，重

51、點(diǎn)在于有無(wú)出錯(cuò)信息產(chǎn)生，系統(tǒng)對(duì)應(yīng)用的響應(yīng)時(shí)間等。（2） 這種性能測(cè)試一般通過(guò)模擬負(fù)載等方法，使得系統(tǒng)的資源使用達(dá)到較高的水平。一般情況下，會(huì)把壓力設(shè)定為“CPU使用率達(dá)到75%以上，內(nèi)存使用率達(dá)到70%以上”這樣的描述，在這種情況下測(cè)試系統(tǒng)響應(yīng)時(shí)間、系統(tǒng)有無(wú)產(chǎn)生錯(cuò)誤。除了CPU和內(nèi)存使用率的設(shè)定外，“JVM的可用內(nèi)存”、“數(shù)據(jù)庫(kù)的連接數(shù)”、“數(shù)據(jù)庫(kù)服務(wù)器CPU利用率”等都可以作為壓力的依據(jù)。（3） 這種性能測(cè)試方法一般用于測(cè)試系統(tǒng)的穩(wěn)定性。用壓力測(cè)試的方法考察系統(tǒng)的穩(wěn)定性是出于這樣的考慮：“如果一個(gè)系統(tǒng)能夠在壓力環(huán)境下穩(wěn)定運(yùn)行一段時(shí)間，那么這個(gè)系統(tǒng)在通常的運(yùn)行條件下應(yīng)該可以達(dá)到令人滿意的穩(wěn)定程

52、度”。在壓力測(cè)試中，會(huì)考察系統(tǒng)在壓力下是否會(huì)出現(xiàn)錯(cuò)誤，測(cè)試中是否有內(nèi)存等方面的問(wèn)題。2.2.4 配置測(cè)試（Configuration Testing）配置測(cè)試（Configuration Testing）方法通過(guò)對(duì)被測(cè)系統(tǒng)的軟/硬件環(huán)境的調(diào)整，了解各種不同環(huán)境對(duì)系統(tǒng)性能影響的程度，從而找到系統(tǒng)各項(xiàng)資源的最優(yōu)分配原則。這種方法具有以下的特定：（1） 這種性能測(cè)試方法的主要目的是了解各種不同因素對(duì)系統(tǒng)性能影響的程度，從而判斷出最值得進(jìn)行的調(diào)優(yōu)操作。此配置測(cè)試方法不同于與功能測(cè)試并列的那個(gè)“配置測(cè)試”方法。對(duì)整個(gè)系統(tǒng)來(lái)說(shuō)，配置測(cè)試是針對(duì)軟件而言，其主要目的是驗(yàn)證軟件能否在不同的軟硬件環(huán)境中正常運(yùn)行，

53、其主要是功能上的驗(yàn)證。而這里提到的配置測(cè)試方法，是在性能測(cè)試領(lǐng)域內(nèi)的配置測(cè)試方法，它的主要目的是了解各種因素對(duì)系統(tǒng)性能的影響程度，從而判斷出對(duì)性能影響最大的因素。（2） 這種性能測(cè)試方法一般在對(duì)系統(tǒng)性能狀況有初步了解后進(jìn)行。Configuration Testing方法需要在確定的環(huán)境和操作步驟、確定的壓力條件下進(jìn)行。該方法在每次執(zhí)行測(cè)試時(shí)更換、擴(kuò)充硬件設(shè)備，調(diào)整網(wǎng)絡(luò)環(huán)境，調(diào)整應(yīng)用服務(wù)器和數(shù)據(jù)庫(kù)服務(wù)器的參數(shù)設(shè)置，比較每次測(cè)試結(jié)果，從而確定各個(gè)因素對(duì)系統(tǒng)性能的影響，找出影響最大的因素。（3） 這種性能測(cè)試方法一般用于性能調(diào)優(yōu)和規(guī)劃能力。Configuration Testing方法主要用于“性能

54、調(diào)優(yōu)”領(lǐng)域，這種方法可以實(shí)現(xiàn)調(diào)優(yōu)的持續(xù)進(jìn)行。另外，在“規(guī)劃能力”領(lǐng)域內(nèi)，該方法也常被用來(lái)評(píng)估“該如何調(diào)整才能實(shí)現(xiàn)系統(tǒng)的擴(kuò)展性”。2.2.5并發(fā)測(cè)試（Concurrency Testing）并發(fā)測(cè)試（Concurrency Testing）方法通過(guò)模擬用戶的并發(fā)訪問(wèn)，測(cè)試多用戶并發(fā)訪問(wèn)同一個(gè)應(yīng)用、同一個(gè)模塊或者數(shù)據(jù)記錄時(shí)是否存在死鎖或者其他性能問(wèn)題。該方法具有以下特點(diǎn)：（1） 這種性能測(cè)試方法的主要目的是發(fā)現(xiàn)系統(tǒng)中可能隱藏的并發(fā)訪問(wèn)時(shí)的問(wèn)題。Concurrency Testing方法是通過(guò)并發(fā)的手段發(fā)現(xiàn)系統(tǒng)中存在問(wèn)題的最常用方法。正如本章開(kāi)頭列舉的問(wèn)題，我們的應(yīng)用在測(cè)試時(shí)一切正常，但一旦交付給用

55、戶，在用戶量增大以后，就經(jīng)常會(huì)出現(xiàn)各種莫名其妙的問(wèn)題。解決這類問(wèn)題的方法是進(jìn)行仔細(xì)的并發(fā)模擬測(cè)試。（2） 這種性能測(cè)試方法主要關(guān)注系統(tǒng)可能存在的并發(fā)問(wèn)題，例如系統(tǒng)中的內(nèi)存泄露、線程鎖和資源爭(zhēng)用方面的問(wèn)題。Concurrency Testing在測(cè)試過(guò)程中主要關(guān)注系統(tǒng)的內(nèi)存泄露、死鎖等問(wèn)題。表2-1列出了并發(fā)測(cè)試主要關(guān)注的問(wèn)題。表2-1 并發(fā)測(cè)試主要關(guān)注的問(wèn)題問(wèn)題類別問(wèn)題描述內(nèi)存問(wèn)題是否有內(nèi)存泄露（C/C+）是否有太多的臨時(shí)對(duì)象（java）是否有太多的超過(guò)設(shè)計(jì)生命周期的對(duì)象（java）數(shù)據(jù)庫(kù)問(wèn)題是否有數(shù)據(jù)庫(kù)死鎖（Dead Lock）是否經(jīng)常出現(xiàn)長(zhǎng)事務(wù)（Long Transaction）線程/進(jìn)程

56、問(wèn)題是否出現(xiàn)線程/進(jìn)程同步失敗其他問(wèn)題是否出現(xiàn)資源爭(zhēng)用導(dǎo)致的死鎖是否沒(méi)有正常處理異常（例如超時(shí)等）導(dǎo)致系統(tǒng)死鎖（3） 這種性能測(cè)試方法可以在開(kāi)發(fā)的各個(gè)階段使用，需要相關(guān)的測(cè)試工具的配合和支持。并發(fā)測(cè)試可以針對(duì)整個(gè)系統(tǒng)進(jìn)行，也可以僅僅為了驗(yàn)證某個(gè)架構(gòu)或是設(shè)計(jì)的合理性而進(jìn)行，因此其可以在開(kāi)發(fā)的各個(gè)階段使用。一般來(lái)說(shuō)，并發(fā)測(cè)試除了需要性能測(cè)試工具進(jìn)行并發(fā)負(fù)載的產(chǎn)生外，還需要一些其他工具進(jìn)行代碼級(jí)別的檢查和定位。Compuware公司的DevPartner工具、dj-technologie公司的JProfile工具、Quest公司的JProbe工具等可以在這方面發(fā)揮作用。2.2.6可靠性測(cè)試（Reli

57、ability Testing） 這里說(shuō)的“可靠性測(cè)試”并不等同于“獲得軟件的可靠性”，軟件的可靠性是一個(gè)很大的命題，這里指的可靠性測(cè)試是通過(guò)給系統(tǒng)加載一定的業(yè)務(wù)壓力（例如：資源在70%90%的使用率），讓應(yīng)用系統(tǒng)運(yùn)行一段時(shí)間、測(cè)試系統(tǒng)是否穩(wěn)定運(yùn)行。這里有三點(diǎn)需要注意：（1） 在使用該測(cè)試前需要目的系統(tǒng)的資源使用率已經(jīng)達(dá)到70%90%。即在這樣的苛刻環(huán)境下運(yùn)行該應(yīng)用系統(tǒng)。（2） 應(yīng)用系統(tǒng)運(yùn)行起來(lái)后，加載業(yè)務(wù)壓力使應(yīng)用系統(tǒng)資源達(dá)到90%。比如：該J2EE系統(tǒng)中設(shè)置的JDBC數(shù)據(jù)庫(kù)連接池定義為30，那么加載業(yè)務(wù)壓力使連接達(dá)到27。（3） 應(yīng)用系統(tǒng)運(yùn)行起來(lái)后結(jié)合業(yè)務(wù)情況來(lái)設(shè)定一個(gè)運(yùn)行時(shí)間。比如：電力資產(chǎn)系統(tǒng)要求MTBF（平均無(wú)故障時(shí)間）達(dá)到10000小時(shí)、那么我們可以認(rèn)定該系統(tǒng)的運(yùn)行時(shí)間至少需要達(dá)到三年重新啟動(dòng)一次。超過(guò)這個(gè)數(shù)字我們就可以認(rèn)為“不可靠”。一般情況下對(duì)于這個(gè)要求、我們讓J2EE系統(tǒng)在資源使用率90%100%狀態(tài)連續(xù)穩(wěn)定的運(yùn)行3天左右沒(méi)