1、0性能測試基本理論和流程規范1主要學習內容/要點：性能測試基本理論，術語以及模型介紹性能測試的基本過程，各階段的介紹性能測試流程實例課程概覽課程名稱 性能測試理論基礎以及基本流程基本描述本課程介紹性能測試的理論基礎，性能測試的基本流程課程目標： 了解性能測試的基本理論了解性能測試的基本過程了解性能測試流程各階段規范2第一部分 性能測試基本理論，術語及模型介紹第二部分 性能測試基本流程，各階段介紹第三部分 性能測試流程典型的企業信息服務系統架構圖：常見企業級系統架構一般分為：客戶端；網絡；防火墻；負載均衡服務器（硬件如F5、軟件Apache等）；Web服務器；應用服務器（中間件Weblogic、

2、Tomcat等）；數據庫服務器等涉及專業人員包括：性能測試工程師；系統管理員；網絡工程師；DBA；程序設計人員；架構示例3第一部分 性能測試基本理論，術語及模型介紹什么是性能系統實現其功能的能力,對性能進行描述可以從宏觀和微觀兩個層面 宏觀上：系統能穩定運行，高并發訪問量下系統不宕機,一定數量的促銷或 搶購活動系統處理完需要的時間，系統能夠支撐的訪問量，系統每 秒 能夠處理的交易或者事務數，系統的容量，系統能否支撐未來一段時間內訪問量增加等。 微觀上：每筆交易或者每個事務的資源開銷，包括CPU，磁盤的IO，網絡傳輸，服務器的連接數，各種線程鎖，線程池的使用情況，JVM heap的使用，內存的分

3、配，回收，對象占用內存的大小，緩存的規則，條目大小，緩存的大小，命中率不未命中率，接口調用的響應時間，系統間交互的響應快慢等等4第一部分 性能測試基本理論，術語及模型介紹性能指標衡量性能的好壞，需要使用一些性能指標來描述，以下是一些最常使用的性能指標： 響應時間(Response Time)：請求或者某個操作從發出的時間不收到服務器響應的時間的差值, 一般統計的是事務的響應時間，響應時間是衡量系統性能的一個很重要的性能指標。 吞吐率(TPS Transaction Per Second)：系統每秒鐘能夠處理的交易或事務的數量,一般統計的是每秒通過的事務數，TPS也衡量系統性能的一個很重要的性能

4、指標響應時間和TPS 兩個非常重要的性能指標，任何系統的性能都可以用這兩個指標來描述，針對不用的應用系統會衍生出一些別的指標，但都是從這兩個指標轉化而來的事務：自定義的某個操作或者是一組請求的集合。例如在登錄頁面，輸入完賬號密碼，從點擊登錄按鈕開始到跳轉到新的頁面且頁面加載完全，這一步操作，我們定義為一個事務，對于打開一個頁面，從瀏覽器中輸入URL地址到頁面加載完全，我們把這一過程定義為一個事務，它包括若干個HTTP請求，所以事務也是一組請求的集合。5第一部分 性能測試基本理論，術語及模型介紹 資源開銷（SD Server Demand）:每個交易或者事務對系統資源的消耗，是一個可量化的概念，

5、用來衡量不同交易或者事務對資源的消耗程度。例如對CPU的消耗程度用消耗的CPU秒數來衡量，其計算邏輯為(1*CPU個數*CPU利用率)/TPS=每個事務或者交易的CPU開銷。其他的磁盤IO以及網絡傳輸有類似的計算方法。 并發用戶(Concurrency) ：真實用戶的相鄰操作之間會有一定的間隔時間(稱之為思考時間)，所以并發用戶有絕對和相對之分。狹義的并發是某個時間點同時向服務器發出請求的并發用戶數。廣義上的并發是一段時間內向服務器發出請求的并發用戶數例如電商的訂單流程包括登錄，瀏覽產品頁面，加入購物車，去結算，確認商品清單，確認地址信息，使用券，提交訂單，去支付。100個人同時在網站上下訂單

6、，但因為每個人執行訂單流程中的步驟有快有慢，所以在同一時間點向服務器發出請求的是不會有100個的，會遠小于100這個值，我們假設為10.那么這個100 是相對的并發用戶數，10為絕對的并發用戶數。6第一部分 性能測試基本理論，術語及模型介紹 PV (Page View)：即頁面瀏覽量，或點擊量；用戶每1次對網站中的每個網頁訪問均被記錄1次。用戶對同一頁面的多次訪問，訪問量累計。 PV是衡量電子商務網站性能容量的重要指標。PV統計有全天PV,平均每小時PV以及高峰1小時的PV UV (Unique Visitor)：UV(獨立訪客), 訪問網站的一臺電腦客戶端為一個訪客。00:00-24:00內

7、相同的客戶端只被計算一次。UV統計也會有全天UV,平均每小時UV和高峰1小時的UVPV和UV是衡量web站點的兩個重要的指標。PV/S由TPS通過一定的模型轉化為PV。例如若把一個完整的頁面定義為一個transaction,則TPS就可以等同于PV/S。PV于UV之間存在一個比例，PV/UV可以理解為平均每個人瀏覽的頁面個數。這個比值會有一定 的波動，促銷期間的PV/UV比會略高于平時的PV/UV。所以用PV來衡量web站點的容量更準確。7第一部分 性能測試基本理論，術語及模型介紹 每秒點擊率（Hit/S）：每秒的Hit數，反映了客戶端每秒鐘向服務器端提交的請求數量，一個hit對應一次HTTP

8、請求，性能測試過程中一般不請求靜態的資源(JS，CSS，圖片文件等)，所以Hit/s一般指動態請求。 訂單轉化率：訪客訪問網站時，把訪客轉化成網站的常駐用戶進而再提升成網站的消費用戶，而由此產生的消費率就是訂單轉化率，它是衡量電子商務網站運營水平的重要指標。計算方法是一段時間內(一般為1小時)的有效訂單數(訂單狀態為C+M)/訪問人數(UV)8第一部分 性能測試基本理論，術語及模型介紹性能測試通過自動化的測試工具模擬多種正常、峰值以及異常負載條件來對系統的各項性能指標進行測試測試類型針對不同的測試目的有以下的幾種常見的測試類型： 性能測試：系統在正常負載的情況的各項性能指標,即通過調整,找到合

9、適的負載,使系統的資源的利用率處于中等的情況下,采集系統的各項指標 負載測試：系統在不同的負載的情況的性能表現,可以得到系統在不同負載下的性能變化趨勢，尋求性能的拐點。例如其他條件相同，分別測試系統在20,50,100并發用戶下的各項性能指標，找到其變化的規律，找到系統的能達到的最大TPS，統計對應的響應時間和資源消耗9第一部分 性能測試基本理論，術語及模型介紹 壓力測試：系統在高負載的情況下的性能表現，尋找系統能夠承受的最大負載以 及對應的系統吞吐率 基準測試：針對確定的測試系統，代碼版本執行的測試，采集性能指標，作為后期的版本對比 穩定性測試: 以正常負載或者稍高于正常負載施加于系統，進行

10、長時間的測試，檢測統能夠穩定的運行，以及系統的各項性能指標會不會隨著時間發生變化。 擴展性測試: 通常用于新系統，新環境的搭建，通過先測試單臺服務器的處理能力,然后逐漸增加服務器數量，測試集群環境下的單臺服務器的處理能力是否有損耗。10第一部分 性能測試基本理論，術語及模型介紹業務場景與測試場景 業務場景即業務流程，具體的業務操作的總和。描述的是具體的用戶行為，可以通過對用戶的行為進行分析得到，也可以根據以往的數據對業務場景進行估計。業務場景對性能測試非常重要,是性能測試場景的設計的重要來源。 測試場景測試場景是對業務場景的模擬，測試場景應該盡可能的貼近真實的業務場景，但是有時由于條件所限制，

11、會做一些調整和特殊的設置11第一部分 性能測試基本理論，術語及模型介紹單場景與混合場景 單場景測試場景中只涉及到單個的業務流程，目的是測試系統的單個業務在響應時間正常，系統資源利用正常的情況下所能達到的最大的TPS，測試系統的單個業務的容量。 混合場景測試場景中涉及到多個業務流程，且各業務流程在混合的業務流程中占的比重會不同。目的是為了測試系統的混合業務在響應時間正常，系統資源利用正常的情況下所能達到的最大的TPS，測試系統的混合業務的容量。編號業務流程訪問量占比（%）1瀏覽首頁10%2瀏覽產品頁40%3瀏覽三級頁面20%4關鍵字查詢25%5訂單流程5%6總和100%12第一部分 性能測試基本

12、理論，術語及模型介紹業務模型或訪問模型混合場景里含有多個業務流程，但是每個業務流程所占的比重會不一樣，針對每個業務以及業務的比重，稱之為業務模型，對于web站點，我們稱之為訪問模型一個簡單的業務訪問模型13第一部分 性能測試基本理論，術語及模型介紹第二部分 性能測試基本流程，各階段介紹第三部分 性能測試流程實例14第二部分 性能測試的基本流程，各階段的介紹性能測試的執行過程系統性能調優LoadRunnerVUGENLoadRunnerCONTROLLER&ANALYSIS階段 5分析測試結果，書寫測試報告階段 4執行測試場景階段 3測試環境檢查確認和準備測試場景階段 2創建虛擬用戶腳本階段 1

13、制定性能測試計劃方案NOTE: 這是LR的一個典型工作流程。15第二部分 性能測試的基本流程，各階段的介紹性能測試計劃/方案 制定計劃/方案前需要做的事情 熟悉業務流程，明確性能測試目的，不開發人員，業務人員，架構師，有經驗的性能測試工程師溝通，找到性能點 熟悉被測系統的架構，不其他系統的交互過程，系統的硬件配置信息，軟件配置信息，對性能測試有重要影響的關鍵配置信息需要明確的列丼出來 明確項目的上線時間點，目前項目的進度，可調配的資源包括環境和性能測試人員16第二部分 性能測試的基本流程，各階段的介紹 制定性能測試計劃/方案性能測試計劃方案是性能測試的指導，是后續一序列測試活動的依據，完整的性

14、能測試計劃方案需要填寫以下的幾個部分： 測試概述 對整個測試項目進行整體的描述 測試目的 計劃中必須有明確的測試目的，它是性能測試退出的判斷條件 測試環境 明確的測試環境的軟硬件信息，若有生產環境，除要有生產環境的詳細信息外，還需要有環境的差異分析 測試數據 明確對測試數據的要求，例如可重復使用，參數的數量級，分布等 測試場景 最初設計的測試場景的細節，包括每個測試場景的設置，測試目的，對環境的調整，對測試數據的特殊要求等 執行計劃 最初設計的測試場景的執行時間計劃 計劃變更 記錄整個測試項目中的未按照計劃執行的部分 參與人員 項目的參與人員以及每個人員的職責和分工 風險控制 預期的風險和不可

15、控的因素以及它們對測試項目進度的影響第二部分 性能測試的基本流程，各階段的介紹創建虛擬用戶腳本虛擬用戶腳本是執行測試的前提條件,對整個性能測試的的結果的準確性有丼足輕重的影響。腳本的制作需要遵循一定的規范.良好的虛擬用戶腳本至少需要滿足以下的幾點要求：虛擬用戶腳本模擬的業務流程不真實用戶的行為應該盡可能的保持一致，不能有過大的偏差。腳本有簡要的描述，一些關鍵的執行步驟有注釋，說明事務的定義準確，即事務的起始邊界和結束邊界位置正確，同時需要對事務的通過不失敗進行明確的檢查和判斷，確保場景運行時事務的統計是準確的。合理進行參數化，是否參數化以及參數的分布，參數的取值和更新方式，參數的數量級等都會影

16、響性能測試結果的準確性腳本中要明確是否需要做關聯以及關聯的位置合理準確，有些請求處理邏輯中的檢查比較弱，雖然腳本能夠運行成功，但服務器會拋exception。測試數據準確，有效，滿足性能測試的要求。避免因為測試數據的不合理影響性能測試的結果腳本中的參數和變量的使用要合理。腳本中加入一些必要的控制邏輯，使腳本健壯，穩定運行。1718第二部分 性能測試的基本流程，各階段的介紹檢查確認測試環境在測試環境搭建好后，需要確認測試環境，需要做以下的一些事情： 收集并檢查測試環境的軟硬件信息 檢查部署的代碼版本。 測試環境各服務器是否部署監控程序，性能測試人員是否具備監控權限 所有服務器的進程是正常對外提供

17、服務 確認系統是否具備執行性能測試的條件(可適當用小負載測試下系統) 確認系統無外界干擾，性能測試執行過程中確保能獨占該環境 確認服務器所在的操作系統的狀態正確，包括CPU,內存使用，磁盤空間剩余是否足夠等 對于數據庫服務器，確保數據庫的基礎數據量滿足測試需求，數據庫中的表若有重大的改變，確認執行過runstat操作等19第二部分 性能測試的基本流程，各階段的介紹設計測試場景測試場景的設置對性能測試的結果影響很大。執行測試之前務必確認場景的設置是否正確。以下為測試場景設置中通常需要確認的檢查點： Schedule中虛擬用戶的Ramp up, Duration, Ramp dump 設置正確，對

18、于設定一段時間后自動運行或者到某個時間點自動運行的場景確認點擊了 start scenario，場景進入倒計時 場景中使用的agent確認能夠連通，agent的資源空閑，無外界的干擾。Agent的C盤的磁盤空間足夠，temp目錄有足夠的空間。Agent的host配置正確，確保請求發送到指定的系統。 場景中若使用到了集合點，確認集合點的釋放規則按需求設置 確認場景的RTS(若是由腳本創建場景的，腳本的RTS會初始化場景的RTS)設置正確，run logic，log已關閉，Download non HTML resources設置正確，Browsersimulation 中的選項設置正確。 執行測

19、試前根據checklist對測試場景進行確認20第二部分 性能測試的基本流程，各階段的介紹執行測試場景性能測試執行是一個發現問題-解決問題，復測-發現新問題的迭代的過程。需要開發人員，系統運維人員，DBA，架構師等共同參與的分析問題，解決問題的過程：性能問題解決系統性能調優測試執行發現問題修復后復測此階段可能涉及邏輯和代碼變更21第二部分 性能測試的基本流程，各階段的介紹收集整理測試結果，書寫測試報告性能測試達到測試目的，則性能測試結束，性能測試人員整理測試過程中的腳本，階段結果，數據，整理問題的發現和解決過程，書寫性能測試報告。最終對外提供性能測試報告作為性能測試項目的終結22第一部分 性能

20、測試基本理論，術語及模型介紹第二部分 性能測試基本流程，各階段介紹第三部分 性能測試流程實例23第三部分 性能測試流程實例24第三部分 性能測試流程實例性能測試過程參與人員 業務部門/項目經理：性能測試需求的提出方，需要明確的提出性能測試的目標，負責講解業務流程和操作 開發人員：具體項目或者功能的開發實施人員，參與性能問題的診斷以及優化 性能測試人員：性能測試的準備以及性能測試執行的實施者 系統運維人員：負責日常系統運維工作。在具體的性能測試項目中負責測試環境的搭建，系統調優的方案的具體實現，系統的監控以及日常的運維。25第三部分 性能測試流程實例需求階段新功能的上線，架構的調整，性能優化點，

21、版本的變更若有性能測試需求，則先需要填寫性能測試需求單 需求來源：性能測試的需求來源主要有四個：日常需求，架構改造，性能優化，新項目。這不目前電商的四類項目：維護型，優化型，標準型，新產成品型并不沖突，只是更細程度的劃分 需求提出的時間點：性能測試需求越早越好。對于新系統，新的項目，需要在立項后提出。26第三部分 性能測試流程實例 需求單中必須明確以下的幾部分：1）需求基本信息 業務聯系人 開發聯系人 計劃上線時間 測試時間要求2）業務需求概述 業務需求概述 預期峰值業務場景 性能測試的目的和意義 是否對其他業務有影響3）預期業務性能指標 用戶訪問量 頁面響應時間 訂單量 訂單轉化率27第三部

22、分 性能測試流程實例測試準備階段在制定好性能測試計劃后，在環境和功能基本穩定可行的情況下，可進入性能測試的準備階段，主要包括測試腳本，測試數據，測試環境的準備以及版本發布等 方案設計：制定了性能測試計劃的同時，需要設計詳細的方案，即按照什么樣的思路和策略去測試，詳細方案中需要設計具體的測試的場景以及測試場景的執行順序，每個場景的重點關注點等 方案評審：性能測試組人員制定了初步的性能測試計劃和方案后，不架構師，項目經理/業務部門共同交流，認論，評估測試方案的設計是否合理，若不合理，則需要進一步修改知道三方都認同該測試方案為止。測試方案評審通過以后進入具體的測試準備步驟 測試腳本：性能測試工程師開發和調試性能測試的腳本28第三部分 性能測試流程實例 測試數據：性能測