電子商務之性能測試

首先提供oracle性能監控的小工具：spotlight

註釋：在此特別感謝

bonjoui 博主

原文地址：http://bonjoui.iteye.com/blog/1901417

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總結
  性能測試不是一錘子買賣，隨着系統不斷升級，性能測試須要做爲一個常態被關注。性能測試領導者也需保持對業務的關注，及時調整測試策略。