2關鍵詞

性能測試中的關鍵詞有響應時間、並發用戶數、吞吐量、性能計數器、思考時間，這是性能測試中常用的幾個概念，必須要有清晰的認識。

（1）響應時間

響應時間的定義可以參考下圖，通常的響應時間是指從C1一直到C2全部的時間，這裏我想補充的一個知識點是，由於前端性能這些年越來越受重視，用戶感受到的時間並不是“客戶端收到最後一個字節的時間”，而是越來越多的引入了“用戶感受到的響應時間”。兩者的區別在數據量龐大，頁面渲染需要花費大量時間的情況下極為明顯，即，我們優化系統響應時間的一個方向是讓用戶感受到的響應時間變短。

（2）並發用戶數

並發用戶數主要與在線用戶數、系統用戶總數區分。最簡單的認知就是被測系統是一個QQ群，用戶總是就是全體群成員，在線用戶數就是在線的成員，並發用戶數就是在聊天的成員。這麽一來就很明顯了，我們都知道一個QQ群裏真正活躍的往往是少數人，所以被測系統的並發用戶數也是遠小於系統用戶總數的。

如何確定並發用戶數，這個問題常見的答案就是看具體情況，或者用戶總數的10%~20%。事實上，確實沒有可以適用於大部分軟件的確定並發用戶數的方法。一般而言，針對於企業內部的信息系統而言，采用經驗公式選擇10%~20%的用戶總數作為並發用戶數是比較合理的。

（3）吞吐量

吞吐量能直接反應系統的性能承載能力，反應的是系統在單位時間內處理請求的能力。常見的吞吐量衡量指標是請求數/秒或者字節數/小時，當然具體的系統可以選擇不同的指標如頁面數/秒，處理業務數/小時，等等。

註意：要區分這裏的吞吐量與loadrunner的analysis的吞吐量概念並不完全相同，loadrunner中的吞吐量是字節數/秒，而且引入了平均事務響應時間TPS的概念，分別從不同維度展示被測系統的吞吐量。

（4）性能計數器

性能測試的執行階段需要記錄服務器的資源占用率，一般使用性能計數器來衡量被測系統當前的情況並且進行性能測試的結果分析。

性能計數器包括很多種類，通常需要我們關註的就是服務器的資源占用率、內存使用率、磁盤I/O，當然還有其他很多的性能計數器，這裏不詳細贅述。通過這些資源的占用情況我們能得到表征，但是具體的性能瓶頸還需要深入的分析。

由於服務器使用操作系統不同，所以需要選擇不同的工具，對於Windows系統可以使用系統自帶的資源監視器，對於Linux系統可以使用nmon工具，這類的工具有很多選擇適用的就可以。

（5）思考時間

關於思考時間，很多時候我們都認為設置成0是最合理的，因為這樣可以模擬一種盡量大的壓力，以研究系統在巨大壓力下的表現；但是如果要驗證系統具有預期的能力，則需要盡量模擬真實用戶在處理業務時的思考時間。

2.3測試的方法

性能測試的方法主要包括驗收性能測試、負載測試、壓力測試、配置測試、並發測試、可靠性測試、失敗恢復測試。

（1）驗收性能測試

驗收性能測試的主要目的是驗證系統是否具有所宣稱的能力，這需要在被測系統有確定的性能目標，以及確定的被測環境。性能測試人員在確定的條件下，通過模擬生產運行的業務壓力量和使用場景組合的方式來進行驗收性能測試。

（2）負載測試

負載測試指通過在被測系統上不斷增加壓力，直到性能指標例如響應時間超過預定指標或者某種資源已經達到飽和狀態。這種測試的目的是找到系統的處理能力極限，另一方面這種方法可以了解系統的容量，為性能調優提供依據。

（3）壓力測試

壓力測試的主要目的是檢查系統在一定壓力下的性能表現。通過模擬負載等方法，使得系統資源占用達到較高水平。壓力測試一般也用來驗證系統的穩定性

（4）配置測試

配置測試的目的是通過對系統軟硬件調整，了解不同配置對系統性能影響程度，從而找到最優分配原則。這種測試一般在對系統的性能表現有了一定了解後進行，用於系統的性能調優和規劃能力。

（5）並發測試

並發測試的主要目的是發現系統中可能隱藏的並發訪問問題，通過模擬用戶並發訪問實現，主要關註內存泄露、線程鎖、資源爭用等。並發測試可以在開發的各階段針對不同的對象使用。

（6）可靠性測試

可靠性測試主要的目的是驗證系統能否支持長時間穩定運行。通過給系統加載一定的業務壓力（如資源在70%~90%使用率），讓應用持續運行一段時間，通過關註系統的運行狀態測試系統是否穩定。

這裏我認為需要對負載測試、壓力測試、可靠性測試加以區分，通過測試的目的區分這三個概念是比較容易的，負載測試的目的在於發現系統的性能瓶頸；壓力測試的目的是在一定壓力下驗證系統性能表現，重點關註響應時間等內容；可靠性測試則是近乎破壞式地讓系統保持在業務的高峰期，關註的是系統能否正常工作，這時就不那麽關註系統的響應時間了。

（7）失效恢復測試

失效恢復測試針對有冗余備份和載均衡的系統設計，可以用來檢驗如果系統局部發生故障，用戶能否繼續使用系統，以及用戶將受多大程度的影響。一般只有對持續運行指標有明確需求的系統才需要這類性能測試。

2.4應用領域

性能測試的應用領域主要有能力驗證、規劃能力、性能調優、發現缺陷和性能基準比較五個領域。其中性能基準比較使用於敏捷開發過程中，在這裏不做講述。下面主要講述常用的四個領域。

（1）能力驗證

能力驗證通常是對已部署系統的性能進行驗證。一般采用性能測試，可靠性測試，壓力測試，失效恢復測試

（2）規劃能力

規劃能力主要用於了解系統的性能並且獲得擴展性能的方法，如系統能否支持未來一段時間內的用戶增長，是一種探索性測試。一般采用負載測試，配置測試和壓力測試

（3）性能調優

性能調優通常是確定基準的環境和性能指標，通過調整環境和實現方式進行測試，進而發現性能優化的方式，一般采用配置測試，負載測試，壓力測試和失效恢復測試

（4）缺陷發現

這一領域的目的就是發現系統中可能存在的性能缺陷，沒有需要達到的性能指標，因此主要采用並發測試，如果需要關註壓力或者失效恢復過程中的問題，也可以采用壓力測試和失效恢復測試。

（5）性能測試應用領域和測試方法的關系

通過下方的表格，可以幫助讀者更好地理解應用領域與測試方法的關系。

3.性能測試過程模型（PTGM）

性能測試過程模型PTGM（Performance Testing General Model），將性能測試過程分為測試前期準備、測試工具引入、測試計劃、測試設計與開發、測試執行和管理以及測試分析等6個步驟。另一種模型是敏捷性能測試模型（APTM），通常敏捷開發的項目如果存在性能需求才會用到這樣的性能測試模型，由於目前本人的性能測試經驗都是集中在系統或者驗收測試的階段展開，因此本文中只介紹性能測試過程模型PTGM。

2.1測試前期準備

前期準備工作主要完成的工作是確保系統穩定和建立性能測試團隊具體的活動包括如下的幾個方面：

（1）系統基礎功能驗證

這一步的目的是確定系統功能能夠正常使用，毫無疑問性能的基礎就是系統可以使用，如果系統的正常使用都存在問題，那追求性能也不具備太大的意義。因此，性能測試展開的前提就是確保被測系統經過至少一輪的功能測試。通常接近驗收階段的項目的測試順序是功能測試→安全測試→性能測試，因為如果系統需要引入安全策略或者某些設備的話同樣會對被測系統的性能產生影響。

（2）組建測試團隊

一個性能測試團隊包括的角色如下表，組建性能測試團隊時可以根據如下的表格，選擇具有相應能力的成員。

（3）測試工具選擇

關於性能測試使用的工具，本人想要向讀者說明，性能測試中工具並不會起到決定性的作用，通常在進行測試工具的選擇時，需要考慮被測系統的環境，如操作系統環境、應用服務器環境、數據庫環境、應用使用的協議、網絡環境等，只要性能測試工具滿足這些環境的需求，無論是使用loadrunner或者是jmeter都是可以的。

（4）性能預備測試

這一步是探索性的測試，是非正式的測試，其目的主要是用來對被測系統的性能表現建立初步印象，得到的結論也是各有不同。當然，如果對被測系統已經有了初步的印象，這一步也是可以跳過的。

2.2測試工具引入

（1）選擇工具

對於性能測試來說，沒有合適的工具配合簡直是不可能實現性能測試的，雖然說選擇了好的測試工具也不一定就能做好性能測試，但是選擇一個適合的測試工具顯然是更利於測試活動的開展與實現的。通常是選定幾種測試工具，根據被測系統的環境來選擇最適合項目的測試工具。

（2）工具應用的技能培訓

工具使用方面的培訓主要是針對測試開發、測試執行、測試分析三類角色，目的是保證測試活動參與者具備測試所需的技能。

（3）確定工具的應用過程

這個步驟主要是明確工具可以完成的功能，測試工具使用過程中出現了問題如何解決、測試腳本如何管理等各種相關的問題，這些問題是測試過程中必須解決的問題。

2.3測試計劃

（1）性能測試領域分析

性能測試計劃就是為了實現性能測試的目標，根據性能測試的目標我們就可以分析出本次性能測試的領域。不同應用領域的性能測試的性能測試目標和性能目標如下表

（2）用戶活動剖析業務建模

用戶活動剖析的方法主要分為系統日誌分析和用戶調查分析。

系統日誌分析是指通過應用系統的日誌了解用戶的活動，分析出用戶最關註、最常用的業務功能，以及達到業務功能的操作路徑；用戶調查分析是在不具備系統日誌分析條件的時候（例如，該系統尚未交付用戶運行實際的業務）時采用的一種估算方法，可以通過用戶調查問卷、同類型系統對比的方法獲取用戶最關註、最常用的業務功能等內容。

業務建模主要是采用流程圖畫出各進程之間的交互關系和數據流向，對業務復雜的系統來說，業務建模可以清晰地呈現系統業務，為性能測試提供指導作用

（3）確定性能目標

性能測試目標根據性能測試需求和用戶活動分析結果來確定，確定性能測試目標的一般步驟是首先從需求和設計中分析出性能測試需求，結合用戶活動剖析與業務建模的結果，最終確定性能測試的目標。

對於性能目標，不能是一句響應時間不能太慢，或是要能穩定運行就完了的，因為這樣的目標在測試執行時會遺留下無盡的麻煩。一個較為詳細的性能目標如下：

系統在5秒響應時間內處理100個並發用戶對業務A的訪問，此時服務器的CPU占用率小於75%，內存使用率小於70%。

當然客戶給出的需求可能只關註響應時間，或者關註其他的某些場景下的性能指標，但都需要保證確定的性能目標，這樣才能保證性能測試良性地進行下去。

（4）制定測試時間計劃

主要是給出性能測試的各個活動起止時間，為性能測試的執行給出時間上的估算。

2.4測試設計與開發

（1）測試環境設計

測試環境設計是測試設計中不可缺少的環節。性能測試的結果與測試環境之間的關聯性非常大，無論是哪種領域內的性能測試，都必須首先確定測試的環境。

對於“能力驗證”領域的性能測試來說，測試首先就已經明確了是在特定的部署環境上進行，因此不需要特別為性能測試設計環境，只需要保證用於測試的環境與今後系統運行的環境一致即可。

對於“規劃能力”領域的性能測試來說，測試環境不特定，但也需要設計一個基準的環境。

對於“性能調優”領域的性能測試來說，需要有性能測試來衡量調優的效果，因此必須在開始就給出一個用於衡量的環境標準，並在整個調優過程中，保證每次測試時的環境保持不變。

這裏的測試環境包括的不僅僅是軟件環境和硬件環境，還有一個大家都容易忽略的數據庫環境，在一個幾乎為空的數據庫和一個已有50000條數據庫的環境上，同樣執行查詢、增加和刪除數據的操作得到的響應時間明顯是不同的。因此如果保證數據庫環境穩定，建議備份數據庫，每次性能測試開始時恢復相同的數據庫備份。

（2）測試場景設計

測試場景模擬的一般是實際業務運行的剖面，其包括業務、業務比例、測試指標的目標以及需要在測試過程中進行監控的性能計數器。測試場景的示例如下：

在性能測試執行中有時是執行單獨的某一功能的性能測試，這樣只能對某一功能驗證，也就是說，其他業務幾乎不產生壓力的情況下，某一功能具有什麽樣的性能表現，這顯然是不符合實際的運行環境的，體現的結果也無法反映被測系統的性能表現。

（3）測試用例設計

測試用例是對測試場景的進一步細化，細化內容包括場景中涉及業務的操作序列描述、場景需要的環境部署等內容。

性能測試的測試用例與功能測試的用例相似，下面是一個登錄業務的測試用例。

1、用戶進入登錄頁面

2、用戶輸入正確的用戶名和口令

3、用戶點擊“登錄”按鈕

4、等待直到出現登錄成功的頁面，判斷該頁面成功顯示的方法是HTML頁面內容中的“歡迎”文本

（4）腳本開發

一個測試腳本一般包含一個業務操作，如登錄的腳本就包含上述測試用例中的登錄業務的程序化描述。測試腳本的開發通常基於“錄制”，依靠工具提供的錄制功能，可以將需要性能測試關註的業務在工具的錄制下操作一遍，然後基於該錄制後的腳本，對其進行修改和調試，確保其可以在性能測試中順利使用。最常用的腳本修改和調試技巧是“參數化”、“關聯”和“日誌輸出”等。

2.5測試執行和管理

（1）建立測試環境

該活動用於搭建需要的測試環境。在設計完成用例之後就會開始該活動，該活動是一個持續性的活動，在測試過程中，可能會根據測試需求進行環境上的調整。

建立測試環境一般包括硬件、軟件系統環境的搭建，數據庫環境建立，應用系統的部署，系統設置參數的調整，以及數據環境準備幾個方面的工作內容。

測試環境的維護，指的是為了測試結果的可比性，一般都需要在每次運行測試結束後恢復初始的測試環境。

（2）部署測試腳本和測試場景

在建立和合適的測試環境之後，接下來的工作是部署測試腳本和測試場景。部署測試腳本和測試場景活動通過測試工具本身提供的功能來實現。

部署活動最終需要保證場景與設計的一致性，保證需要監控的計數器都已經部署好了相應的監控手段。

（3）執行測試和記錄結果

準備好環境和部署好測試腳本以及場景後，就可以執行測試並記錄測試結果了。在測試工具的協助下，測試執行是非常簡單的操作，一般只需要使用菜單或是按鈕就可以完成；記錄測試結果也可以依靠測試工具完成，通過測試工具的Monitor模塊，可以獲取並記錄需要關註的性能計數器的值。

在測試工具本身不提供對需要關註的性能計數器進行監控的功能時，可以用一些操作系統的工具，自行編制部分腳本解決這個問題，一般的方法是用腳本調用操作系統提供的工具，在腳本實現中將各性能計數器值分析出來並按照一定格式記錄在本地文件中。

2.6測試分析

測試分析過程用於對測試結果進行分析，根據測試的目的和目標給出測試結論。

性能測試的挑戰性很大程度上體現在對測試結果的分析上，可以說，每次性能測試結果的分析都需要測試分析人員具有相當程度的對軟件性能的了解、對軟件架構的了解、對各性能指標的了解。

測試分析過程是一個靈活的過程，很難給出一種具體的、能適應各種性能測試需要的統一的過程活動列表。

性能分析的通用方法之一是“拐點分析”的方法。“拐點分析”方法是一種利用性能計數器曲線圖上的拐點進行性能分析的方法，該方法的基本思想是基於這個事實：性能產生瓶頸是由於某個資源的使用達到了極限，此時的表現是隨著壓力增大系統性能表現急劇下降，因此，只要關註性能表現上的“拐點”，獲得“拐點”附近的資源使用情況，就能夠定位出系統的性能瓶頸。

性能測試學習階段性總結