@import url(http://m.tkk7.com/CuteSoft_Client/CuteEditor/Load.ashx?type=style&file=SyntaxHighlighter.css);@import url(/css/cuteeditor.css);

　1引言

　　互聯網和電子商務技術的發展，人們可以足不出戶完成在線購物、實時通訊、信息檢索等操作，這些系統大部分是B/S架構。對于系統本身而言，其性能直接決定了可容納的在線用戶數和用戶體驗滿意度，而用戶數的攀升意味著廣告等收入增長，所以性能測試在B/S系統中起到了一個非常關鍵的作用，尤其是面向公眾的互聯網系統。

　　2什么是性能測試

　　性能測試是通過自動化的測試工具模擬多種正常、峰值以及異常負載條件來對系統的各項性能指標進行測試，包括負載測試，強度測試，批量測試等類型。在性能測試過程中，會發現很多系統潛在的問題，這些問題往往與一定規模的訪問量有關，所以無法通過簡單手工測試發現。借助于測試工具或者自己編寫的腳本，模擬實際場景對目標系統進行全方位性能測試，能夠將問題暴露在上線之前，減少后期維護成本。

　　3性能測試階段劃分

　　性能測試整個過程大體可以劃分為測試規劃、測試執行和結果分析。本文引入一個測試模型用于實例講解，相關信息見下表1：

　　表1 測試模型

　　模型系統名稱 網上購物系統

　　模型系統架構 基于MVC三層架構的B/S系統

　　模型系統功能 商品瀏覽：用戶隨意進入網站進行商品瀏覽。

　　訂單提交：注冊用戶登錄后，下訂單購買商品，系統返回成功與否。

　　后臺處理：數據庫每天晚上11點自動執行數據庫腳本，清算當日的交易數據。

　　4性能測試規劃

　　測試規劃是整個性能測試最復雜，也最有價值的一部分。測試規劃包括：確認測試目標、整理業務流程、制定量化指標、制定測試用例與場景、準備測試資源、安排測試計劃。

　　4.1確認測試目標

　　針對不同被測系統，需首先明確本次測試的目標。比如設定為“檢驗當前系統各業務功能的并發處理能力”，由于系統參與人員的職責不同，對性能測試的目標定位也不相同，需綜合實際情況來確定。在本文測試模型中，假定有產品經理和技術經理兩個角色，他們對于性能測試目標簡要歸納為表2所述，綜合兩者就能確認本次測試目標。

　　表2 測試目標

　　職責 測試目標

　　產品經理 檢驗系統能夠支撐的最大用戶訪問量、最佳用戶訪問量、每秒鐘最大事務處理數、是否能夠滿足預期業務量7 * 24小時運行需要。

　　技術經理 檢驗系統性能瓶頸所在、有沒有內存泄漏、中間件和數據庫的資源利用率是否合理。

　　一般而言，性能測試是作為一個上線之前的驗收環節。處于這個階段的系統功能基本都已開發完成，測試目標主要是對系統整體的一個性能測驗。此時發現核心組件需要修改，調整的代價是很昂貴的。我們可以在項目建設初期就可以引入性能檢測，在開發過程中就對各業務模塊進行測試，進一步細化各階段的測試目標，如下圖所示：

　　圖 1. 性能測試切入點

　　從圖1可以看出，系統本身有很多測試切入點。當用戶界面層還不穩定的話，可以從業務邏輯層著手，對系統進行性能檢測。如果把系統看作是一幢大樓，則至下而上的每一層就是一個組件，組件本身牢固了，房子整體才結實。

　　4.2整理業務流程

　　測試目標確認之后，就需要針對這個目標，對業務流程進行整理，對于功能復雜的系統，還需要業務和開發人員的參與，以下方面可以關注：

　　1：區分用戶操作流程與系統的處理流程。兩者都是業務流程，但是系統處理流程是后臺發起，用戶不可見。例如，本文測試模型中，商品瀏覽屬于用戶操作流程；數據庫自動執行批處理是系統處理流程。

　　2：站在用戶的角度模擬業務操作，要覆蓋到所有的操作分支，包括容易產生的操作中斷。

　　業務流程整理直接關系到后續的測試用例和場景設計，兩者決定了性能測試數據是否能夠真實反映系統狀況，當遇到性能測試實施團隊不熟悉業務的情況，性能測試項目經理需安排支援。

　　4.3制定量化指標

　　在性能測試報告中，系統性能狀況會體現為一堆測試指標及對應的數值。被測目標不同，指標集合也不同，針對本文測試模型，可以制定以下簡單的指標（更加細化的指標可參閱相關文檔）。

　　功能層：事務平均響應時間、每秒完成的事務數、成功的事務數、失敗的事務數。

　　中間件：JVM內存使用情況、中間件隊列、線程池利用率。

　　數據庫：隊列長度、最占資源的SQL、等待時間、共享池內存使用率。

　　操作系統：CPU平均利用率、CPU隊列、內存利用率、磁盤IO。

　　有了指標，我們還需要根據測試目標，設定其對應的數值范圍。例如根據產品經理要求，在并發一千人訪問的情況下，系統平均一次事務響應時間不超過5秒，則可以設定響應時間的數值范圍是小于5秒成功，大于5秒失敗。還可以指定CPU利用率、JVM內存利用率等性能指標的數值范圍（表3），需要說明的是，不同測試工具支持的指標集是不同的，可利用多個測試工具進行協同收集。

　　表3 性能指標數值范圍

　　指標項目 測試場景 合理指標值

　　平均CPU利用率 并發一千用戶 < 85%

　　平均JVM利用率 并發一千用戶 < 80%

　　量化的性能指標能夠給系統帶來優化的目標，當我們說性能符合預期，指的是所有指標的值都在理想范圍以內，那么如何制定正確的數值范圍呢，這個就必須靠經驗和系統歷史數據來進行分析。前者是類比同類型系統的性能指標，后者需要挖掘運維數據，包括用戶訪問峰值，每秒最高事務處理數等。
4.4制定測試用例與場景

　　性能測試用例是對整理過的業務流程進行再分解，描述其成為可測試的功能點，結合性能指標轉換為測試執行代碼。本文測試模型中，用戶登錄的用例簡要描寫如下（省略掉用例前置條件，例如系統配置和部署信息）：

　　表4 測試用例1

　　登錄測試用例

　　1：用戶打開網站首頁，頁面應該正常展現，超過60秒則算失敗。

　　2：用戶輸入賬號和密碼，點擊登錄按鈕，等待系統提示成功或失敗，如果等待超過60秒，則算登錄失敗。

　　測試用例1中，用戶與系統有兩次交互（打開網址和點擊登錄按鈕），需分別統計每一次交互的等待時間?？紤]到用戶實際操作的話，會有一定的停頓，我們可在腳本中添加思考時間來模擬（固定或隨機等待時間）。不要小看這個設置，在用戶量大的情況下，對系統施加的壓力是完全不同的，然后在在統計的時候，去掉這部分思考時間。

　　性能測試用例執行需對應的場景，用于模擬系統實際運行狀況。全面的系統測試在理論上是不可行的，所以設計測試場景的時候，主要定位是用戶典型的應用場景。可粗略劃分為兩類：功能點測試場景和復雜業務測試場景。前者的目標主要是檢驗系統某個功能點的并發能力，后者更加貼近系統實際運行情況。對于測試模型的用戶登錄功能，設計功能點測試場景1如下：

　　表5 測試場景1

　　并發用戶數：總共300，起始數量100，每1秒鐘增加10個用戶。

　　運行方式：每一個并發用戶循環執行登錄測試用例，持續15分鐘。

　　考慮到業務流程可以交叉進行，例如測試模型中數據庫批處理與用戶操作混搭，我們設計一個復雜的測試場景如表6所示：

　　表6 測試場景2

　　并發用戶數：總共300，起始數量100，每1秒鐘增加10個用戶。

　　運行方式：數據庫啟動批處理清算，同時并發200個用戶進行循環登錄，另外100個用戶隨機瀏覽商品。

　4.5準備測試資源

　　測試資源包括4個方面：

　　1：硬件資源。性能測試環境應該采用與生產環境一致的硬件條件，嚴格來說，如果硬件環境不一致，性能測試報告是不具備說服力的。

　　2：軟件資源。性能測試目標系統需要部署與生產一致的軟件，在系統上生產之后，往往會增加一個監控軟件，但監控軟件也是有資源損耗的，尤其是B/S系統，頻繁的抓取JVM數據，會造成較大的壓力。

　　3：數據資源。數據量對性能的影響非常大，分兩種情況考慮測試數據，第一種是已經運行的系統做改造，則可以把生產環境的數據備份到測試環境。另外一種是首次上線的系統，這個時候業務數據是空的，需要造一些測試數據。至于數據量的級別，可以預測兩年后，業務數據量會有多少，性能測試需要有一定的前瞻性。

　　4：人力資源。性能測試會發現很多問題，而問題的定位和解決，需要更加專業的人來完成，包括商業軟件提供商。測試過程中，保持與開發團隊的緊密溝通，是順利開展項目的關鍵。

　　4.6安排測試計劃

　　當測試資源、可執行代碼準備好之后，就需制定一個測試計劃并分階段實施，簡單示例如表7所示。

　　表7 測試計劃

　　測試項 描述 測試類型/測試目標（簡要）

　　基準測試 收集系統基準測試性能指標 強度測試，獲取基準測試數據數據。

　　開發調試 開發修復性能測試發現的Bug

　　功能點測試 對各業務功能點進行性能測試 強度測試，獲取系統最大并發值等數據。

　　復雜業務測試 復雜業務場景性能測試 容量測試，獲取最佳用戶訪問值等數據。

　　開發調試 開發修復性能測試發現的Bug

　　長時間負載測試 系統在一定負載的情況下，長時間運行。 疲勞測試，發現內存泄漏等情況。

　　表7測試計劃說明如下：

　　1：表7中省略掉了測試項目的起止時間，包括了開發調試的工作。這是因為在實施過程中，如果遇到性能問題，開發是需要時間去修復的，性能測試有可能需要暫停。

　　2：首先進行功能點測試，通過之后再進行復雜業務測試，這是因為單個功能點相對簡單，業務邏輯復雜度不高，資源競爭與數據鎖等問題不太容易暴露。

　　3：基準測試是系統日后升級的性能比較對象，例如在硬件升級后，同樣的測試場景，是否會得到更優的結果，系統新技術的引進或版本升級，對性能的影響是正面還是負面，都可以通過與基準測試比較得出。

　　4：每一個測試階段都有相應的測試目標，采用的測試類型也不同，具體需根據之前的測試規劃來制定。

　　5性能測試執行

　　執行過程需要注意以下事項：

　　1：注意保存測試運行過程的數據，作為測試結果的佐證。

　　2：有問題盡快反饋，系統的修改可能導致測試返工。

　　3：基準功能點測試過程中，需清理測試現場后再進行后續的測試，因為系統可能存在緩存。

　　4：按優先級測試各業務場景。

　　6測試結果分析

　　每次執行完測試后，會得到一個測試結果。先別著急完成后續的測試任務，可以先簡要的分析一下本次測試結果，看看數據是否符合邏輯。例如，對于同一個測試場景，增加并發用戶數（強度測試中常見），卻發現響應時間反而變短，這就不符合邏輯。當所有的測試任務完成后，分析數據并提交測試報告，注意以下方面：

　　1：針對不同角色的人員出具不同的測試報告，對于技術人員，可以有較多的性能數據和分析。

　　2：進行一些前瞻性的預測，綜合本次測試的資源情況和指標數據，分析系統性能擴展的瓶頸。

　　7總結

　　性能測試不是一錘子買賣，隨著系統不斷升級，性能測試需要作為一個常態被關注。性能測試領導者也需保持對業務的關注，及時調整測試策略

天貓 軟件自動化測試開發