【文章內(nèi)容簡介】 則找出并加以解決；l 發(fā)現(xiàn)一些應用程序在功能實現(xiàn)方面的缺陷；l 對一些存在性能問題的系統(tǒng)，找出瓶頸并加以解決；l 為用戶部署系統(tǒng)提供性能參考；l ……通過分析性能測試的種種目標，不難總結(jié)出性能測試主要應用在幾個領域中，下面分別予以介紹。系統(tǒng)的性能瓶頸定位系統(tǒng)的性能瓶頸定位是性能測試最常見的應用領域。借助LoadRunner等工具，可以在測試場景運行過程中監(jiān)控系統(tǒng)資源、Web服務器資源等運行數(shù)據(jù)，與響應時間進行同步分析，可以在一定程度上進行性能瓶頸的分析與定位。系統(tǒng)的參數(shù)配置通過性能測試可以測試系統(tǒng)在不同參數(shù)配置下的性能表現(xiàn)，進而找出令系統(tǒng)表現(xiàn)更優(yōu)的系統(tǒng)配置參數(shù)，為應用系統(tǒng)投產(chǎn)提供最佳配置建議。實際上，操作系統(tǒng)、數(shù)據(jù)庫、中間件服務器等的參數(shù)配置是應用系統(tǒng)發(fā)生性能問題的重要原因。例如分配給Oracle的內(nèi)存大小與系統(tǒng)自身的業(yè)務特點有極大關(guān)系，配置不同的數(shù)據(jù)庫，性能表現(xiàn)就會不同；而即使在內(nèi)存一定的情況下，SGA的分配也會對性能產(chǎn)生很大的影響。因此，要通過測試，以確定內(nèi)存的最佳配置。發(fā)現(xiàn)一些軟件算法方面的缺陷一些多線程、同步并發(fā)算法在單用戶模式下測試是很難發(fā)現(xiàn)問題的，只有通過模擬多用戶的并發(fā)操作，才能驗證其運行是否正常與穩(wěn)定。例如作者就經(jīng)歷過在一次性能測試過程中，測試人員模擬多個用戶并發(fā)時發(fā)現(xiàn)的一個明顯的缺陷：測試對象是一個隨機分配任務的模塊，只要有用戶申請，就會給用戶分配任務。這個算法在單用戶情況下調(diào)試沒有任何問題，但是當多個用戶同時申請任務時，就發(fā)生了把同一任務分配給多個不同用戶的現(xiàn)象。經(jīng)證實，這個缺陷就是“同步算法”發(fā)生了問題而引起的。系統(tǒng)的驗收測試系統(tǒng)驗收測試經(jīng)常會驗證一些預期的性能指標，或者驗證系統(tǒng)中一些事務指標是否符合用戶期望，這時就需要借助性能測試來完成驗證工作。隨著用戶對性能的重視，現(xiàn)在性能測試幾乎是系統(tǒng)驗收測試中必不可少的內(nèi)容之一。用戶甚至自己進行專門的性能測試來驗證系統(tǒng)上線前的性能，以保證運行時的性能穩(wěn)定。因此，性能測試在用戶驗收測試中越來越重要。系統(tǒng)容量規(guī)劃通過總結(jié)系統(tǒng)在不同硬件環(huán)境下的性能表現(xiàn)，可以為系統(tǒng)部署時提供非常好的參考。對于一些性能要求較高的系統(tǒng)，性能測試可以為硬件規(guī)劃提供很好的參考數(shù)據(jù)，使用戶在購買硬件時“有據(jù)可依”。例如同一系列機型：兩顆CPU系統(tǒng)支持500用戶并發(fā)、四顆CPU支持800用戶并發(fā)，這些都是用戶根據(jù)自身需求來規(guī)劃硬件的重要依據(jù)。產(chǎn)品評估/選型產(chǎn)品評估/選型是性能測試的又一應用領域。通過性能測試，可以對產(chǎn)品的軟硬件性能進行更全面的評估，選出更適合自己的產(chǎn)品類型。性能測試的應用領域越來越廣，因此在實際工作中，性能測試往往會一次應用在一個或多個領域。對于軟件性能測試設計人員，應該根據(jù)測試的具體應用領域、測試原則和目標來進行性能測試的規(guī)劃與設計。 性能測試常見術(shù)語本節(jié)將介紹一些性能測試中的常見術(shù)語，只有掌握這些基礎的性能測試知識，才可以進一步開展測試工作。性能測試常見的術(shù)語主要有并發(fā)、并發(fā)用戶數(shù)量、請求響應時間、事務響應時間、吞吐量、吞吐率、TPS、點擊率、資源利用率等，下面分別介紹它們。并發(fā)狹義的并發(fā)一般分兩種情況。一種是嚴格意義上的并發(fā)，即所有的用戶在同一時刻做同一件事情或操作，這種操作一般針對同一類型的業(yè)務。例如在信用卡審批業(yè)務中，一定數(shù)目的用戶在同一時刻對已經(jīng)完成的審批業(yè)務進行提交（操作的不是同一記錄）；還有一種是特例，即所有用戶進行完全一樣的操作，目的是測試數(shù)據(jù)庫和程序?qū)Σl(fā)操作的處理。例如在信用卡審批業(yè)務中，所有的用戶可以一起申請業(yè)務，或者修改同一條記錄。另外一種并發(fā)是廣義的并發(fā)。這種并發(fā)與狹義的并發(fā)的區(qū)別是盡管多個用戶對系統(tǒng)發(fā)出了請求或進行了操作，但是這些請求或操作可以是相同的，也可以是不同的。對整個系統(tǒng)而言，仍然有很多用戶同時對系統(tǒng)進行操作，因此，仍然屬于并發(fā)的范疇?？梢钥闯?，廣義的并發(fā)是包含狹義的并發(fā)的，而且廣義的并發(fā)更接近用戶的實際使用情況，因為對大多數(shù)系統(tǒng)而言，只有數(shù)量很少的用戶進行“嚴格意義上的并發(fā)”。對于性能測試而言，這兩種并發(fā)一般都需要進行測試，通常做法是先進行嚴格意義上的并發(fā)測試。嚴格意義上的并發(fā)一般發(fā)生在使用比較頻繁的模塊中，盡管發(fā)生的概率不是特別高，但是一旦發(fā)生性能問題，后果很可能是致命的。嚴格意義上的并發(fā)測試往往和功能測試關(guān)聯(lián)起來，因為只要并發(fā)功能遇到異常通常都是程序的問題，這種測試也是健壯性和穩(wěn)定性測試的一部分。并發(fā)用戶數(shù)量關(guān)于并發(fā)用戶的數(shù)量，有兩種常見的錯誤觀點。一種錯誤觀點是把并發(fā)用戶數(shù)量理解為使用系統(tǒng)的全部用戶的數(shù)量，理由是這些用戶可能同時使用系統(tǒng)；還有一種比較接近正確的觀點是把用戶在線數(shù)量理解為并發(fā)用戶數(shù)量。實際上，在線用戶不一定會和其他用戶發(fā)生并發(fā)，例如正在瀏覽網(wǎng)頁信息的用戶，對服務器是沒有任何影響的。但是，用戶在線數(shù)量是統(tǒng)計并發(fā)用戶數(shù)量的主要依據(jù)之一。并發(fā)主要針對服務器而言，是否并發(fā)的關(guān)鍵是看用戶的操作是否對服務器產(chǎn)生了影響。因此，并發(fā)用戶數(shù)量的正確理解是，在同一時刻與服務器進行交互的在線用戶數(shù)量。這些用戶的最大特征是和服務器發(fā)生了交互，這種交互既可以是單向傳送數(shù)據(jù)的，也可以是雙向傳送數(shù)據(jù)的。并發(fā)用戶數(shù)量的統(tǒng)計方法目前還沒有準確的公式，因為不同的系統(tǒng)會有不同的并發(fā)特點。例如OA系統(tǒng)統(tǒng)計并發(fā)用戶數(shù)量的經(jīng)驗公式為：使用系統(tǒng)的用戶數(shù)量（5％～20％）。對于這個公式，沒有必要拘泥于計算出的結(jié)果，因為為了保證系統(tǒng)的擴展空間，測試時的并發(fā)用戶數(shù)量都會稍稍大一些，除非要測試系統(tǒng)能承受的最大并發(fā)用戶數(shù)量。舉例說明：如果一個OA系統(tǒng)的期望用戶為1 000個，只要測試出系統(tǒng)能支持200個并發(fā)用戶就可以了。請求響應時間請求響應時間是指從客戶端發(fā)出請求到得到響應的整個過程的時間。這個過程從客戶端發(fā)送一個請求開始計時，到客戶端接到從服務器端返回的響應結(jié)果計時結(jié)束。在某些工具中，請求響應時間通常會被稱為“TTLB”，即“Time to last byte”，意思是從發(fā)送一個請求開始，到客戶端收到最后一個字節(jié)的響應為止所耗費的時間。請求響應時間的單位一般為“秒”或“毫秒”。請求響應時間的分解如圖11所示。圖11 Web請求過程分解圖從圖11可以看出，請求響應時間為“網(wǎng)絡響應時間”和“應用程序與系統(tǒng)響應時間”之和，具體由7個部分組成，即(N1+N2+N3+N4)+(A1+A2+A3)。事務響應時間事務可能由一系列請求組成，事務的響應時間主要針對用戶而言，屬于宏觀上的概念，是為了向用戶說明業(yè)務響應時間而提出的。例如：跨行取款事務的響應時間就是由一系列的請求組成的。事務響應時間和后面的業(yè)務吞吐率都是直接衡量系統(tǒng)性能的參數(shù)。吞吐量指在一次性能測試過程中網(wǎng)絡上傳輸?shù)臄?shù)據(jù)量的總和。吞吐量/傳輸時間，就是吞吐率。吞吐率（Throughput）通常用來指單位時間內(nèi)網(wǎng)絡上傳輸?shù)臄?shù)據(jù)量，也可以指單位時間內(nèi)處理的客戶端請求數(shù)量。它是衡量網(wǎng)絡性能的重要指標。但是從用戶或業(yè)務角度來看，吞吐率也可以用“請求數(shù)/秒”或“頁面數(shù)/秒”、“業(yè)務數(shù)/小時或天”、“訪問人數(shù)/天”、“頁面訪問量/天”來衡量。例如在銀行卡審批系統(tǒng)中，可以用“千件/每小時”來衡量系統(tǒng)的業(yè)務處理能力。TPS(Transaction Per Second)每秒鐘系統(tǒng)能夠處理的交易或事務的數(shù)量。它是衡量系統(tǒng)處理能力的重要指標。TPS是LoadRunner中重要的性能參數(shù)指標。點擊率（Hit Per Second）每秒鐘用戶向Web服務器提交的HTTP請求數(shù)。這個指標是Web應用特有的一個指標：Web應用是“請求響應”模式，用戶發(fā)出一次申請，服務器就要處理一次，所以“點擊”是Web應用能夠處理交易的最小單位。如果把每次點擊定義為一次交易，點擊率和TPS就是一個概念。不難看出，點擊率越大，對服務器的壓力也越大。點擊率只是一個性能參考指標，重要的是分析點擊時產(chǎn)生的影響。需要注意的是，這里的點擊不是指鼠標的一次“單擊”操作，因為在一次“單擊”操作中，客戶端可能向服務器發(fā)出多個HTTP請求。資源利用率資源利用率指的是對不同系統(tǒng)資源的使用程度，例如服務器的CPU利用率、磁盤利用率等。資源利用率是分析系統(tǒng)性能指標進而改善性能的主要依據(jù)，因此，它是Web性能測試工作的重點。資源利用率主要針對Web服務器、操作系統(tǒng)、數(shù)據(jù)庫服務器、網(wǎng)絡等，是測試和分析瓶頸的主要參數(shù)。在性能測試中，要根據(jù)需要采集具體的資源利用率參數(shù)來進行分析。 全面性能測試模型 全面性能測試模型通過前面的內(nèi)容可以看出，性能測試的很多內(nèi)容都是關(guān)聯(lián)的。這就提供了一條思路：性能測試的很多內(nèi)容可以經(jīng)過一定的組織來統(tǒng)一進行。統(tǒng)一開展性能測試的最大好處是，可以按照由淺入深的層次對系統(tǒng)進行測試，進而減少不必要的工作量，以實現(xiàn)節(jié)約測試成本的目的。為此，本書提出了“全面性能測試模型”?！叭嫘阅軠y試模型”提出的主要依據(jù)是：一種類型的性能測試可以在某些條件下轉(zhuǎn)化成為另一種類型的性能測試，而這些測試的實施方式很類似。例如：對一個網(wǎng)站進行測試，模擬10個到50個用戶就是常規(guī)的性能測試。當用戶增加到1000乃至上萬時就變成了壓力/負載測試。如果同時對系統(tǒng)進行大量的數(shù)據(jù)查詢操作，就包含了大數(shù)據(jù)量測試。在“全面性能測試模型”中，把常見的性能測試分為8個類別，然后結(jié)合測試工具把性能測試用例歸納為5類來進行設計。下面首先介紹這8個性能測試類別的主要內(nèi)容：預期指標的性能測試系統(tǒng)在需求分析和設計階段都會提出一些性能指標，完成和這些指標相關(guān)的測試是性能測試的首要工作。本模型把針對預先確定的一些性能指標而進行的測試稱為預期指標的性能測試。這些指標主要指諸如“系統(tǒng)可以支持1000個并發(fā)用戶”、“系統(tǒng)響應時間不得長于10秒”等這些在產(chǎn)品說明書等文檔中規(guī)定得十分明確的內(nèi)容。對這種預先承諾的性能要求，測試小組應該首先進行測試驗證。獨立業(yè)務性能測試獨立業(yè)務實際是指一些與核心業(yè)務模塊對應的業(yè)務，這些模塊通常具有功能比較復雜、使用比較頻繁、屬于核心業(yè)務等特點。這類特殊的、功能比較獨立的業(yè)務模塊始終都是性能測試的重點。因此，不但要測試這類模塊和性能相關(guān)的一些算法，還要測試這類模塊對并發(fā)用戶的響應情況。核心業(yè)務模塊在需求設計階段就可以確定，在集成或系統(tǒng)測試階段開始單獨測試其性能。如果是系統(tǒng)類軟件或特殊應用領域的軟件，通常從單元測試階段就開始進行測試，并在后繼的集成測試、系統(tǒng)測試、驗收測試中進一步進行，以保證核心業(yè)務模塊的性能穩(wěn)定。何時開始測試核心模塊主要由性能測試策略決定，“性能測試用例模型”部分。組合業(yè)務性能測試通常所有的用戶不會只使用一個或幾個核心業(yè)務模塊，一個應用系統(tǒng)的每個功能模塊都可能被使用到。所以性能測試既要模擬多用戶的“相同”操作（這里的“相同”指很多用戶使用同一功能），又要模擬多用戶的“不同”操作（這里的“不同”指很多用戶同時對一個或多個模塊的不同功能進行操作），對多項業(yè)務進行組合性能測試。組合業(yè)務測試是最接近用戶實際使用情況的測試，也是性能測試的核心內(nèi)容。通常按照用戶的實際使用人數(shù)比例來模擬各個模板的組合并發(fā)情況。由于組合業(yè)務測試是最能反映用戶使用情況的測試，因而組合測試往往和服務器（操作系統(tǒng)、Web服務器、數(shù)據(jù)庫服務器）性能測試結(jié)合起來進行。在通過工具模擬用戶操作的同時，還通過測試工具的監(jiān)控功能采集服務器的計數(shù)器信息，進而全面分析系統(tǒng)的瓶頸，為改進系統(tǒng)提供有利的依據(jù)。疲勞強度性能測試疲勞強度測試是指在系統(tǒng)穩(wěn)定運行的情況下，以一定的負載壓力來長時間運行系統(tǒng)的測試。其主要目的是確定系統(tǒng)長時間處理較大業(yè)務量時的性能。通過疲勞強度測試基本可以判斷系統(tǒng)運行一段時間后是否穩(wěn)定。大數(shù)據(jù)量性能測試大數(shù)據(jù)量測試通常是針對某些系統(tǒng)存儲、傳輸、統(tǒng)計查詢等業(yè)務進行大數(shù)據(jù)量的測試。主要測試運行時數(shù)據(jù)量較大或歷史數(shù)據(jù)量較大時的性能情況，這類測試一般都是針對某些特殊的核心業(yè)務或一些日常比較常用的組合業(yè)務的測試。由于大數(shù)據(jù)量測試一般在投產(chǎn)環(huán)境下進行，所以把它獨立出來并和疲勞強度測試放在一起，在整個性能測試的后期進行。大數(shù)據(jù)量測試可以理解為特定條件下的核心業(yè)務或組合業(yè)務測試。網(wǎng)絡性能測試網(wǎng)絡性能測試主要是為了準確展示帶寬、延遲、負載和端口的變化是如何影響用戶響應時間的。在實際的軟件項目中，主要是測試應用系統(tǒng)的用戶數(shù)目與網(wǎng)絡帶寬的關(guān)系。網(wǎng)絡性能測試一般有專門的工具，本書不加詳述。網(wǎng)絡測試的任務通常由系統(tǒng)集成人員來完成。服務器性能測試（操作系統(tǒng)、Web服務器、數(shù)據(jù)庫服務器）服務器性能測試主要是對數(shù)據(jù)庫、Web服務器、操作系統(tǒng)的測試，目的是通過性能測試找出各種服務器的瓶頸，為系統(tǒng)擴展、優(yōu)化提供相關(guān)的依據(jù)。一些特殊測試主要是指配置測試、內(nèi)存泄漏測試等一些特殊的Web性能測試。這類性能測試或/和前面的測試結(jié)合起來進行，或者在一些特殊的情況下獨立進行，本書重點討論前一種情況。后一種情況由于投入較大往往通過特有的工具進行，可以不納入性能測試的范疇?！叭嫘阅軠y試模型”是在以上性能測試分類和總結(jié)的基礎上提出來的，主要包含3部分內(nèi)容：第1部分：性能測試策略模型，這是整個性能測試模型的基礎。軟件類型決定著性能測試的策略，同時用戶對待軟件性能的態(tài)度也影響性能測試策略的制定。本部分內(nèi)容主要結(jié)合軟件類型和用戶特點來討論性能測試策略制定的基本原則和方法。第2部分：性能測試用例模型，這是整個性能測試模型的核心部分。其主要思想就是結(jié)合測試工具，把以上性能測試的8項內(nèi)容進一步歸納，形成5類測試用例：l 預期指標的性能測試；l 并發(fā)用戶的性能測試；l 疲勞強度和大數(shù)據(jù)量的性能測試；l 服務器性能測試；l 網(wǎng)絡性能測試。在具體的測試設計中，性能測試用例往往和測試工具結(jié)合起來，把服務器、網(wǎng)絡性能測試的用例設計與前三種類型結(jié)合起來。例如LoadRunner就可以在進行壓力測試的同時，完成后面兩類測試的數(shù)據(jù)采集工作。因此，后面兩部分的測試用例只進行總體設計就可以了。第3部分：模型的使用方法。本部分內(nèi)容討論如何在工作中使用“全面性能測試模型”。 性能測試策略模型本節(jié)主要介紹性能測試策略的制定方法。性能測試策略一般從需求設計階段就開始討論如何制定了，它決定著性能測試工作將要投入多少資源、什么時間開始實施等后繼工作的安排。其制定的主要依據(jù)是“軟件自身特點”和“用戶對性能的關(guān)注程度”兩個因素，其中軟件的自身特點起決定作用。軟件按照用途的不同可以分為兩大類：系統(tǒng)類軟件和應用類軟件。系統(tǒng)類軟件通常對性能要求比較高，