性能測試方法及分析方法

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

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

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

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

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

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

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

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

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

10、原因。1.2軟件性能的幾個術(shù)語接觸過軟件性能測試的人，會經(jīng)常聽到這樣一些詞匯：響應(yīng)時間、并發(fā)用戶數(shù)、吞吐量、性能計數(shù)器，在使用性能測試工具進行測試時，還會接觸到“思考時間（Think Time）”的概念，那么，這些術(shù)語的確切含義究竟是什么呢？本節(jié)重點介紹以上的各個術(shù)語。響應(yīng)時間“響應(yīng)時間”的概念，響應(yīng)時間是“對請求作出響應(yīng)所需要的時間” ，而且，我們把響應(yīng)時間作為用戶視角的軟件性能的主要體現(xiàn)。圖 1.1 將用戶所感受到的軟件性能（響應(yīng)時間）劃分為“呈現(xiàn)時間”和“系統(tǒng)響應(yīng)時間”兩個部分，其中“呈現(xiàn)時間”取決于數(shù)據(jù)在被客戶端收到響應(yīng)數(shù)據(jù)后呈現(xiàn)頁面所消耗的時間，例如，對一個 Web應(yīng)用，呈現(xiàn)時間就是

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

12、4）和“應(yīng)用延遲時間”（A1+A2+A3），而“應(yīng)用延遲時間”又可以分解為“數(shù)據(jù)庫延遲時間”（ A2）和“應(yīng)用服務(wù)器延遲時間” （ A1+A3）。之所以要對響應(yīng)時間進行這些分解，主要目的是為了能更好定位性能瓶頸的所在。在后續(xù)的實例討論中，讀者將會看到如何應(yīng)用這些響應(yīng)時間的分解進行性能問題的定位。圖 1.2 Web 應(yīng)用的頁面響應(yīng)時間分解關(guān)于響應(yīng)時間，要特別說明的一點是，對客戶來說，該值是否能夠被接受是帶有一定的用戶主觀色彩，也就是說，響應(yīng)時間的“長”和“短”沒有絕對的區(qū)別。例如，對一個電子商務(wù)網(wǎng)站來說，在美國和歐洲，一個普遍被接受的響應(yīng)時間標(biāo)準(zhǔn)為2/5/10秒，也就是說， 在 2 秒之內(nèi)給客戶

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

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

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

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

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

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

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

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

21、得測試人員關(guān)心的并發(fā)用戶數(shù)的具體數(shù)值呢？下面給出了一些用于估算并發(fā)用戶數(shù)的公式。nLCT?CC3 C（ 1）（ 2）在公式（1）中，C是平均的并發(fā)用戶數(shù)； n 是 loginsession i 的數(shù)量；L 是 loginsession的平均長度； T 指考察的時間段長度。例如，對一個典型的OA應(yīng)用，考察的時間段長度應(yīng)該為 8 小時的工作時間。公式（ 2）則給出了并發(fā)用戶數(shù)峰值的計算方式，其中，?C 指并發(fā)用戶數(shù)的峰值， C 就是公式（ 1）中得到的平均的并發(fā)用戶數(shù)。該公式的得出是假設(shè)用戶的login session 產(chǎn)生符合泊松分布而估算得到的。下面根據(jù)上述給出的方法進行實例計算。實例：假設(shè)有

22、一個OA系統(tǒng)，該系統(tǒng)有3000 個用戶，平均每天大約有400 個用戶要訪問該系統(tǒng)，對一個典型用戶來說，一天之內(nèi)用戶從登錄到退出該系統(tǒng)的平均時間為4 小時，在一天的時間內(nèi)，用戶只在8 小時內(nèi)使用該系統(tǒng)。則根據(jù)公式（ 1）和公式（ 2），可以得到：C=400× 4/8=200?200+3×200 =242C當(dāng)然，這是種可行的方法，但仔細考究起來，其并不是惟一，甚至說不上是最精確的方法，因為在公式中仍然需要估算“平均用戶數(shù)”和“l(fā)ogin session的長度”，而要精確估算這兩個值并不容易。另外，考慮到用戶的業(yè)務(wù)操作存在一定的時間集中性（也就是說，用戶對系統(tǒng)業(yè)務(wù)的訪問往往不是平

23、均分布在整個考察時間段內(nèi)，而是相對集中地分布在某幾個時間段內(nèi)），采用公式（ 1）和公式（ 2）進行計算仍然存在一定的偏差。我們給出對該公式使用的一些建議，遵循這些建議，可以更精確地計算得到并發(fā)用戶數(shù)：（ 1）以更細的時間粒度進行考察：例如，可以設(shè)定1 個小時為考察時間的粒度，對一個典型的 OA系統(tǒng)，將一天的上班時間劃分為8 個區(qū)間，這樣可以解決前面提到的業(yè)務(wù)操作存在的時間集中性的問題。（ 2）考慮典型的業(yè)務(wù)模式：不同的應(yīng)用有不同的業(yè)務(wù)模式，例如，一個內(nèi)部系統(tǒng)一般在上班開始后的 30 分鐘至 1 個小時集中出現(xiàn)用戶的登錄； 一個賬務(wù)系統(tǒng)在每月的結(jié)賬日前幾天會比較繁忙；一個門戶網(wǎng)站在重大消息發(fā)布的

24、前后會有訪問高峰；一個旅游的網(wǎng)站在節(jié)假日前夕會有大量用戶的訪問因此，在考慮計算并發(fā)用戶數(shù)時，可以結(jié)合應(yīng)用的業(yè)務(wù)模式，多考慮一些可能發(fā)生的場景，基于這些場景進行估算。除了這種介紹的方法之外，對于企業(yè)內(nèi)部使用的 Web系統(tǒng)來說，一個更一般的（當(dāng)然精度更差）經(jīng)驗公式是：Cn 10?CrC（ 3）（4）也就是說， 用每天訪問系統(tǒng)用戶數(shù)的10%作為平均的并發(fā)用戶數(shù)，并發(fā)用戶數(shù)的最大值由并發(fā)用戶數(shù)乘上一個調(diào)整因子r 得到， r 的取值一般為2 3。公式（ 3）和公式（ 4）可以在要求不太嚴(yán)格的性能測試，或是只有很少數(shù)據(jù)支持分析的性能測試中使用。在本節(jié)的前面部分提到了“日志分析”方法。所謂“日志分析”方法是

25、指通過對應(yīng)用服務(wù)器的日志進行分析，從而了解系統(tǒng)用戶的使用狀態(tài)，從日志中計算出“服務(wù)器承受的最大并發(fā)用戶訪問數(shù)” 數(shù)據(jù)。這種方式得到的數(shù)據(jù)準(zhǔn)確度和可信度都比較高， 對于 Internet 應(yīng)用等無法估計用戶數(shù)量和用戶行為模式的應(yīng)用，這種方式最為可信。吞吐量吞吐量是指“單位時間內(nèi)系統(tǒng)處理的客戶請求的數(shù)量”，直接體現(xiàn)軟件系統(tǒng)的性能承載能力。一般來說，吞吐量用請求數(shù)/ 秒或是頁面數(shù) / 秒來衡量，從業(yè)務(wù)的角度，吞吐量也可以用訪問人數(shù) / 天或是處理的業(yè)務(wù)數(shù)/ 小時等單位來衡量。當(dāng)然，從網(wǎng)絡(luò)的角度來說，也可以用字節(jié)數(shù) / 天來考察網(wǎng)絡(luò)流量。例如，對一個Web應(yīng)用系統(tǒng)來說，從系統(tǒng)的處理能力考慮，可以以頁面

26、數(shù)/ 秒作為吞吐量的標(biāo)準(zhǔn)；對一個銀行的業(yè)務(wù)前臺系統(tǒng)來說，可以以其處理的業(yè)務(wù)數(shù)/ 小時作為吞吐量的標(biāo)準(zhǔn)。在本章的開始部分，已經(jīng)討論過，對于交互式應(yīng)用，用戶直接的體驗是“響應(yīng)時間”，通過“并發(fā)用戶數(shù)”和“響應(yīng)時間”可以確定系統(tǒng)的性能規(guī)劃；但對于非交互式應(yīng)用，用“吞吐量”來描述我們對系統(tǒng)性能的期望可能更加合理。對于交互式應(yīng)用來說，吞吐量指標(biāo)反映的是服務(wù)器承受的壓力。在容量規(guī)劃的測試中，吞吐量是一個重點關(guān)注的指標(biāo)，因為它能夠說明系統(tǒng)級別的負載能力；另外，在性能調(diào)優(yōu)的過程中，吞吐量指標(biāo)也有重要的價值，例如，Empirix公司在報告中聲稱， 在他們所發(fā)現(xiàn)的性能問題中，有80%是因為吞吐量的限制導(dǎo)致的。在對

27、 Web系統(tǒng)的性能測試過程中，吞吐量主要以請求數(shù)（單擊數(shù)）/ 秒、頁面數(shù) / 秒或是字節(jié)數(shù) / 秒來體現(xiàn)，吞吐量指標(biāo)可以在兩個方面發(fā)揮作用：（ 1）用于協(xié)助設(shè)計性能測試場景， 以及衡量性能測試場景是否達到了預(yù)期的設(shè)計目標(biāo)：在設(shè)計性能測試場景時，吞吐量可被用于協(xié)助設(shè)計性能測試場景， 根據(jù)估算的吞吐量數(shù)據(jù)，可以對應(yīng)到測試場景的事務(wù)發(fā)生頻率、事務(wù)發(fā)生次數(shù)等；另外，在測試完成后，根據(jù)實際的吞吐量可以衡量測試是否達到了預(yù)期的目標(biāo)。（ 2）用于協(xié)助分析性能瓶頸：吞吐量的限制是性能瓶頸的一種重要表現(xiàn)形式，因此，有針對性地對吞吐量設(shè)計測試， 可以協(xié)助盡快定位到性能瓶頸所在位置。 例如， RBI（RapidBo

28、ttleneck Identify ）方法就主要通過吞吐量測試發(fā)現(xiàn)性能瓶頸。以不同方式表達的吞吐量可以說明不同層次的問題。例如，以字節(jié)數(shù) / 秒方式表示的吞吐量主要受網(wǎng)絡(luò)基礎(chǔ)設(shè)施、服務(wù)器架構(gòu)、應(yīng)用服務(wù)器制約；以單擊數(shù)/ 秒方式表示的吞吐量主要受應(yīng)用服務(wù)器和應(yīng)用代碼的制約。作為性能測試時的主要關(guān)注指標(biāo)，吞吐量和并發(fā)用戶數(shù)之間存在一定的聯(lián)系。在沒有遇到性能瓶頸的時候，吞吐量可以采用如下公式計算：Nvu R（5）FT其中， F 表示吞吐量； Nvu 表示 VU（ Virtuae User，虛擬用戶）的個數(shù)；R表示每個 VU發(fā)出的請求（單擊）數(shù)量；T 表示性能測試所用的時間。但如果遇到了性能瓶頸，此時

29、吞吐量和 VU數(shù)量之間就不再符合公式（5）給出的關(guān)系。常用于分析吞吐量的圖形是“吞吐量 VU數(shù)量”的關(guān)聯(lián)圖。圖 1.5 給出了兩個“吞吐量 VU數(shù)量”關(guān)聯(lián)圖的示例。從圖中可以看到，吞吐量在 VU數(shù)量增長到一定程度的時候產(chǎn)生了性能 瓶頸。最后，必須要說明的是，雖然吞吐量指標(biāo)可被看作是系統(tǒng)承受壓力的體現(xiàn)，但在不同并發(fā)用戶數(shù)量的情況下，對同一個系統(tǒng)施加相同的吞吐量壓力，很可能會得到不同的測試結(jié)果。本文給出了一個示例。圖 1.5“吞吐量 VU數(shù)量”關(guān)聯(lián)圖示例對同一個應(yīng)用進行兩次不同的性能測試，測試A 采用 100 個并發(fā)， 每個 VU間隔 1 秒發(fā)出一個請求；測試 B 采用 1000 個并發(fā)，每個 V

30、U間隔 10 秒發(fā)出一個請求；對測試 A，測試時的吞吐量（頁 / 秒）為 100×1/1=100 ；對測試 B 來說，吞吐量（頁 / 秒）為 1000× 1/10=100 ，仍然是 100。但從測試結(jié)果來看，執(zhí)行測試A 時，應(yīng)用在 50 頁 / 秒出現(xiàn)性能瓶頸，而測試B在 25 頁/ 秒出現(xiàn)性能瓶頸。性能計數(shù)器性能計數(shù)器（ Counter ）是描述服務(wù)器或操作系統(tǒng)性能的一些數(shù)據(jù)指標(biāo)。例如，對 Windows系統(tǒng)來說，使用內(nèi)存數(shù)（Memory In Usage ），進程時間（ Total Process Time）等都是常見的計數(shù)器。計數(shù)器在性能測試中發(fā)揮著“監(jiān)控和分析”的關(guān)

31、鍵作用，尤其是在分析系統(tǒng)的可擴展性、進行性能瓶頸的定位時，對計數(shù)器取值的分析非常關(guān)鍵。但必須說明的是，單一的性能計數(shù)器只能體現(xiàn)系統(tǒng)性能的某一個方面，對性能測試結(jié)果的分析必須基于多個不同的計數(shù)器。與性能計數(shù)器相關(guān)的另一個術(shù)語是 “資源利用率” 。該術(shù)語指的是系統(tǒng)各種資源的使用狀況。為了方便比較， 一般用 “資源的實際使用 / 總的資源可用量” 形成資源利用率的數(shù)據(jù)，用以進行各種資源使用的比較。例如，我們會說到， “某某系統(tǒng)在承受10000 用戶的并發(fā)訪問時，Web服務(wù)器的 CPU占用率為 68%，平均的內(nèi)存占用率為55%”，這其中， 68%和 55%就是典型的資源利用率的數(shù)值。在性能測試中常用資

32、源利用率進行橫向的對比，例如，在進行測試時會發(fā)現(xiàn)，資源A的使用率達到了接近100%的數(shù)值，而其他的資源利用率都處于比較低的水平，則可以很清楚地知道，資源A 就很有可能是系統(tǒng)的一個性能瓶頸。當(dāng)然，資源利用率在通常的情況下需要結(jié)合響應(yīng)時間變化曲線、系統(tǒng)負載曲線等各種指標(biāo)進行分析。性能計數(shù)器是性能測試分析的主要參考值，本書的第 3 章對其進行了詳細的解釋說明，并說明了如何利用這些計數(shù)器分析系統(tǒng)性能瓶頸。思考時間思考時間（ Think Time ），也被稱為“休眠時間” ，從業(yè)務(wù)的角度來說，這個時間指的是用戶在進行操作時，每個請求之間的間隔時間。前面已經(jīng)討論過，對交互式應(yīng)用來說，用戶在使用系統(tǒng)時，不大

33、可能持續(xù)不斷地發(fā)出請求，更一般的模式應(yīng)該是用戶在發(fā)出一個請求后，等待一段時間，再發(fā)出下一個請求。因此，從自動化測試實現(xiàn)的角度來說，要真實地模擬用戶操作，就必須在測試腳本中讓各個操作之間等待一段時間，體現(xiàn)在腳本中， 具體而言， 就是在操作之間放置一個Think的函數(shù)，使得腳本在執(zhí)行兩個操作之間等待一段時間。在測試腳本中，思考時間體現(xiàn)為腳本中兩個請求語句之間的間隔時間。不同的測試工具提供了不同的函數(shù)或者方法來實現(xiàn)思考時間，本書附錄A 中對思考時間進行了的詳細描述，另外，本書實踐篇也有一些使用思考時間的實際例子。在實際的測試中，設(shè)置多長的思考時間最為合理是許多性能測試工程師關(guān)心的問題。其實，思考時間

34、與迭代次數(shù)、并發(fā)用戶數(shù)和吞吐量之間存在一定的關(guān)系。公式（ 5）說明吞吐量是 VU數(shù)量 N 、每個用戶發(fā)出請求數(shù) R和時間 T 的函數(shù)，而其中vu的R又可以用時間T和用戶的思考時間s 來計算：TT（ 6）RTs用公式（ 5）和公式（ 6）進行化簡運算可得，吞吐量與Nvu 成正比，而與 Ts 成反比。不少性能測試工程師在實際的應(yīng)用中都對如何給定合適的思考時間存在疑問，那么，在具體的測試實踐中，究竟該怎樣選擇合適的思考時間呢？下面給出一個計算思考時間的一般步驟：1首先計算出系統(tǒng)的并發(fā)用戶數(shù)；2統(tǒng)計出系統(tǒng)平均的吞吐量；3統(tǒng)計出平均每個用戶發(fā)出的請求數(shù)量；4根據(jù)公式（ 6）計算出思考時間。當(dāng)然，為了讓性

35、能測試場景更加符合實際情況，可以考慮以步驟4 計算得出的思考時間為基準(zhǔn)，讓實際的思考時間在一定幅度內(nèi)隨機變動。LoadRunner和Segue SilkPerformer等工具都支持以這種方式設(shè)置思考時間。最后要說明的是“0 思考時間”。有些文章建議在測試中使用“0”作為思考時間，以給系統(tǒng)更大的壓力。在本人的實際性能測試過程中，對于交互式的應(yīng)用系統(tǒng)，很少遇到這樣的要求。因為從業(yè)務(wù)的角度考慮， 思考時間用于更真實地模擬用戶操作，設(shè)置思考時間為0，基本上不具有實際的業(yè)務(wù)含義。但在非交互式應(yīng)用的性能測試過程中，有時候確實會將思考時間設(shè)置為0，這時候是模擬一種盡可能大的壓力，研究系統(tǒng)在巨大壓力下的表現(xiàn)

36、?？梢哉f，如果測試的目的是為了“驗證應(yīng)用系統(tǒng)具有預(yù)期的能力”（也就是所說的“能力驗證”的應(yīng)用領(lǐng)域） ，就應(yīng)該盡量模擬用戶在使用業(yè)務(wù)時的真實思考時間；如果目的是進行更一般的研究，例如“了解系統(tǒng)在壓力下的性能水平”或是“了解系統(tǒng)承受壓力的能力”（也就是所說的“規(guī)劃能力”的應(yīng)用領(lǐng)域），則可以采用0 思考時間。二、性能測試方法論與方法“沒有規(guī)矩，不成方圓” 。對性能測試來說，如果沒有合適的方法論指導(dǎo)，性能測試很容易成為一種隨意的測試行為，而隨意進行的性能測試很難取得實際的作用和預(yù)期的效果，因此本章將簡單介紹幾種常見的性能測試過程和方法，并著重介紹常用的性能測試方法。2.1性能測試方法論負載測試計劃過程

37、SEI 負載測試計劃過程（SEI Load Testing Planning Process）是一個關(guān)注于負載測試計劃的方法，其目標(biāo)是產(chǎn)生“清晰、易理解、可驗證的負載測試計劃”。 SEI 負載測試計劃過程包括6 個關(guān)注的區(qū)域（ Area）：目標(biāo)、用戶、用例、生產(chǎn)環(huán)境、 測試環(huán)境和測試場景。SEI 負載測試計劃過程將以上述6 個區(qū)域作為負載測試計劃需要重點關(guān)注和考慮的內(nèi)容，其重點關(guān)注以下幾個方面的內(nèi)容：1生產(chǎn)環(huán)境與測試環(huán)境的不同：由于負載測試環(huán)境與實際的生產(chǎn)環(huán)境存在一定的差異，因此，在測試環(huán)境上對應(yīng)用系統(tǒng)進行的負載測試結(jié)果很可能不能準(zhǔn)確反映該應(yīng)用系統(tǒng)在生產(chǎn)環(huán)境上的實際性能表現(xiàn)，為了規(guī)避這個風(fēng)險，

38、必須仔細設(shè)計測試環(huán)境。2用戶分析：用戶是對被測應(yīng)用系統(tǒng)性能表現(xiàn)最關(guān)注和受影響最大的對象，因此，必須通過對用戶行為進行分析，依據(jù)用戶行為模型建立用例和場景。3用例：用例是用戶使用某種順序和操作方式對業(yè)務(wù)過程進行實現(xiàn)的過程，對負載測試來說，用例的作用主要在于分析和分解出關(guān)鍵的業(yè)務(wù)，判斷每個業(yè)務(wù)發(fā)生的頻度、業(yè)務(wù)出現(xiàn)性能問題的風(fēng)險等。從 SEI 負載測試計劃過程的描述中可以看到， SEI 負載測試計劃過程給出了負載測試需要關(guān)注的重點區(qū)域，但嚴(yán)格來說，其并不能被稱為具體的方法論，因為其僅僅給出了對測試計劃過程的一些關(guān)注內(nèi)容，而沒有能夠形成實際的可操作的過程。同功能測試一樣，性能測試也必須經(jīng)歷測試需求、測

39、試設(shè)計、測試執(zhí)行、測試分析等階段，但由于性能測試自身的特殊性（例如，需要引入工具，分析階段相對重要） ，性能測試過程又不能完全套用功能測試過程。SEI 負載測試計劃過程在負載測試需要關(guān)注的具體內(nèi)容上提供了參考，但其并不是一個完整的測試過程。方法RBI（ Rapid Bottleneck Identify）方法是Empirix公司提出的一種用于快速識別系統(tǒng)性能瓶頸的方法。該方法基于以下一些事實：1. 發(fā)現(xiàn)的 80%系統(tǒng)的性能瓶頸都由吞吐量制約；2. 并發(fā)用戶數(shù)和吞吐量瓶頸之間存在一定的關(guān)聯(lián)；3. 采用吞吐量測試可以更快速定位問題。RBI 方法首先訪問服務(wù)器上的“小頁面”和“簡單應(yīng)用”，從應(yīng)用服務(wù)

40、器、網(wǎng)絡(luò)等基礎(chǔ)的層次上了解系統(tǒng)吞吐量表現(xiàn)；其次選擇不同的場景，設(shè)定不同的并發(fā)用戶數(shù)，使其吞吐量保持基本一致的增長趨勢，通過不斷增加并發(fā)用戶數(shù)和吞吐量，觀察系統(tǒng)的性能表現(xiàn)。在確定具體的性能瓶頸時，RBI 將性能瓶頸的定位按照一種“自上而下” 的分析方式進行分析，首先確定是由并發(fā)還是由吞吐量引發(fā)的性能表現(xiàn)限制，然后從網(wǎng)絡(luò)、數(shù)據(jù)庫、應(yīng)用服務(wù)器和代碼本身4 個環(huán)節(jié)確定系統(tǒng)性能具體的瓶頸。RBI 方法在性能瓶頸的定位過程中能發(fā)揮良好的作用，其對性能分析和瓶頸定位的方法值得借鑒，但其也不是完整的性能測試過程。性能下降曲線分析法性能下降曲線實際上描述的是性能隨用戶數(shù)增長而出現(xiàn)下降趨勢的曲線。而這里所說的“性

41、能”可以是響應(yīng)時間， 也可以是吞吐量或是單擊數(shù) / 秒的數(shù)據(jù)。 當(dāng)然，一般來說，“性能”主要是指響應(yīng)時間。圖 1.6 給出了一個“響應(yīng)時間下降曲線”的示例。圖 1.6 一條典型的響應(yīng)時間性能下降曲線示例從圖 1.6 可以看到，一條曲線可以分為以下幾個部分：（ 1）單用戶區(qū)域?qū)ο到y(tǒng)的一個單用戶的響應(yīng)時間。這對建立性能的參考值很有作用。（ 2）性能平坦區(qū)在不進行更多性能調(diào)優(yōu)情況下所能期望達到的最佳性能。這個區(qū)域可被用作基線或是 benchmark。（ 3）壓力區(qū)域應(yīng)用“輕微下降”的地方。典型的、最大的建議用戶負載是壓力區(qū)域的開始。（ 4）性能拐點性能開始“急劇下降”的點。這幾個區(qū)域?qū)嶋H上明確標(biāo)識了

42、系統(tǒng)性能最優(yōu)秀的區(qū)間，系統(tǒng)性能開始變壞的區(qū)間，以及系統(tǒng)性能出現(xiàn)急劇下降的點。對性能測試來說，找到這些區(qū)間和拐點，也就可以找到性能瓶頸產(chǎn)生的地方。因此，對性能下降曲線分析法來說，主要關(guān)注的是性能下降曲線上的各個區(qū)間和相應(yīng)的拐點，通過識別不同的區(qū)間和拐點，從而為性能瓶頸識別和性能調(diào)優(yōu)提供依據(jù)。的性能測試過程圖 1.7 給出了 LoadRunner 的性能測試過程。 LoadRunner 將性能測試過程分為計劃測試、測試設(shè)計、創(chuàng)建VU腳本、創(chuàng)建測試場景、運行測試場景和分析結(jié)果6 個步驟。圖 1.7 LoadRunner 的性能測試過程計劃測試階段主要進行測試需求的收集、典型場景的確定；測試設(shè)計階段主

43、要進行測試用例的設(shè)計；創(chuàng)建VU腳本階段主要根據(jù)設(shè)計的用例創(chuàng)建腳本；創(chuàng)建測試場景階段主要進行測試場景的設(shè)計和設(shè)置，包括監(jiān)控指標(biāo)的設(shè)定；運行測試場景階段對已創(chuàng)建的測試場景進行執(zhí)行，收集相應(yīng)數(shù)據(jù)；分析結(jié)果階段主要進行結(jié)果分析和報告工作。LoadRunner 提供的這個性能測試過程已經(jīng)涵蓋了性能測試工作的大部分內(nèi)容，但由于該過程過于緊密地與LoadRunner 工具集成， 沒有兼顧使用其他工具，或是用戶自行設(shè)計工具的需求，也不能被稱為是一個普適性的測試過程。另外， LoadRunner 提供的該性能測試過程并未對計劃測試階段、測試設(shè)計階段的具體行為、方法和目的進行詳細描述，因此該方法最多只能被稱為“使

44、用LoadRunner 進行測試的過程”，而不是一個適應(yīng)性廣泛的性能測試過程。提供的性能測試過程圖 1.8 給出了 Segue 公司 Silk Performer提供的性能測試過程。該性能測試過程與Performance Testing Lifecycle描述的一致，是一個不斷try-check的過程。Silk Performer提供的性能測試過程從確定性能基線開始，通過單用戶對應(yīng)用的訪問獲取性能取值的基線，然后設(shè)定可接受的性能目標(biāo)（響應(yīng)時間），用不同的并發(fā)用戶數(shù)等重復(fù)進行測試。Segue 提供的這種性能測試方法非常適合性能調(diào)優(yōu)和性能優(yōu)化，通過不斷重復(fù)的try-check過程，可以逐一找到可能

45、導(dǎo)致性能瓶頸的地方并對其進行優(yōu)化。圖 1.8 Segue Silk Performer提供的性能測試過程但 Segue 提供的這個性能測試過程模型存在與LoadRunner 的性能測試過程同樣的問題， 就是過于依賴工具自身，另外，該過程模型缺乏對計劃、設(shè)計的階段的明確劃分，也沒有給出具體的活動和目標(biāo)。2.2性能測試的方法性能測試的方法很多，常見的比如說的“負載測試”和“壓力測試”就是其中一些類型，此外還存在其他的一些類型的性能測試方法。根據(jù)大范圍的性能測試的概念的界定，性能測試可包括如下幾種方法：?性能測試（ Performance Testing）；? 負載測試（ Load Testing

46、）；?壓力測試（ Stress Testing ）；?配置測試（ Configuration Testing）；?并發(fā)測試（ Concurrency Testing）；?可靠性測試（ Reliability Testing）；?失效恢復(fù)測試（ Failover Testing）；性能測試（ Performance Testing）性能測試（ Performance Testing ）方法是通過模擬生產(chǎn)運行的業(yè)務(wù)壓力量和使用場景組合，測試系統(tǒng)的性能是否滿足生產(chǎn)性能要求。Performance Testing是一種最常見的測試方法，通俗地說，這種測試方法就是要在特定的運行條件下驗證系統(tǒng)的能力狀況。

47、這種方法的特點有：（ 1） 這種方法的主要目的是驗證系統(tǒng)是否有系統(tǒng)宣稱具有的能力。Performance Testing方法包括確定用戶場景、給出需要關(guān)注的性能指標(biāo)、測試執(zhí)行和測試分析這幾個步驟， 這是一種完全確定了系統(tǒng)運行環(huán)境和測試行為的測試方法，其目的只能是依據(jù)事先的性能規(guī)劃，驗證系統(tǒng)有沒有達到其宣稱具有的能力。（ 2） 這種方法需要事先了解被測試系統(tǒng)典型場景，并具有確定的性能目標(biāo)。Performance Testing方法需要首先了解被測西歐他能夠的典型場景，所謂的典型場景，就是指具有代表性的用戶業(yè)務(wù)操作，一個典型場景包括操作序列、并發(fā)用戶數(shù)量條件。其次，這種方法需要有確定的性能目標(biāo)，性

48、能目標(biāo)的描述基本上是這樣的方式：“要求系統(tǒng)在 100 個并發(fā)用戶的條件下進行某業(yè)務(wù)操作，響應(yīng)時間不超過5 秒”。（ 3） 這種方法要求在已確定的環(huán)境下運行。Performance Testing方法的運行環(huán)境必須是確定的。軟件系統(tǒng)的性能表現(xiàn)與非常多的因素相關(guān)，無法根據(jù)系統(tǒng)在一個環(huán)境上的表現(xiàn)趨推斷其在另一個不同環(huán)境中的表現(xiàn)，因此對這種驗證性的測試，必須要求測試時的環(huán)境（硬件設(shè)備、軟件環(huán)境、網(wǎng)絡(luò)條件、基礎(chǔ)數(shù)據(jù)等）都已經(jīng)確定。負載測試（ Load Testing ）負載測試（ Load Testing ）方法通過在被測系統(tǒng)上不斷增加壓力，直到性能指標(biāo)，例如“響應(yīng)時間”超過預(yù)定指標(biāo)或者某種資源使用已經(jīng)

49、達到飽和狀態(tài)。這種測試放大可以找到系統(tǒng)的處理極限，為系統(tǒng)調(diào)優(yōu)提供數(shù)據(jù)。在某些情況下，這種方法有時也被稱為可量性測試（Scalability Testing）。該方法有這樣一些特點：（ 1） 這種性能測試方法的主要目的是找到系統(tǒng)處理能力的極限。Load Testing方法通過“檢測 - 加壓 - 直到性能指標(biāo)超過預(yù)期”的手段，其主要目的是找到系統(tǒng)處理能力的極限，這個極限一般會用“在給定條件下最多允許120 個并發(fā)用戶訪問”或是“在給定條件下最多能夠在1 小時內(nèi)處理 2100 筆業(yè)務(wù)” 這樣的描述來體現(xiàn)。 而“預(yù)期的性能指標(biāo)” 一般會被定義為 “響應(yīng)時間不超過10 秒”“、服務(wù)器平均 CPU利用率低于65%”等指標(biāo)。（ 2）這種性能測試方法需要在給定的測試環(huán)境下進行，通常也需要考慮被測系統(tǒng)的與唯物壓力量和典型場景，使得測試結(jié)果具有業(yè)務(wù)上的意義。Load Testing方法由于涉及到“預(yù)定的性能指標(biāo)”等需要進行比較的數(shù)據(jù)，也必須在給定的測試環(huán)境下進