自動化性能測試(2)

　　構建階段包括建立和配置測試系統和基礎設施，并且使用自動化性能測試解決方案來構建測試腳本和負載場景。

　　執行階段由運行負載場景和測量系統性能組成。

　　診斷和調整反復迭代的階段超出了測量系統性能和負載測試，達到另外一個層次，關鍵是要查明問題來快速幫助解決問題，并且調整系統參數來最優化性能

　　讓我們詳細分析關系到每個階段成功與否的必要任務。

　　設計

　　這是性能測試團隊向業務部門搜集性能需求的主要階段。需求可以被認為分為四個方面—業務，技術，系統和團隊需求。

　　業務需求一般通過與主題專家(SME,subject matter expert)的會議來搜集。這些人可以是業務分析師和最終用戶。當下面內容準備好后，一套全面的業務需求就形成了：

　　應用概要：系統用法的演示使得性能團隊得到更高層次的理解，應用是如何被使用的。

　　業務過程列表：最終用戶在系統上所執行的關鍵業務過程列表。

　　業務流程：Word文檔，詳盡記錄每個業務過程的精確步驟和屏幕。

　　事務列表：業務過程中關鍵活動的列表—例如登錄或轉移資金—需要在負載下測量。

　　業務過程圖：業務流程圖說明業務流程的分支條件。

　　技術需求可以通過與系統管理員和數據庫管理員(DBA)的會議來搜集。這些人可以隸屬于開發或運營部門，或者隸屬于兩者。一套全面的技術需求僅當以下內容齊備時完成：

　　環境評審：按照測試體系結構由系統或基礎設施組進行走查評審。

　　系統范圍的會議：召開會議，討論和確認在測試過程中系統需要排出的部分。

　　生產圖：一個生產基礎設施圖，用于說明測試與生產環境的差異，當從QA向生產遷移時可能對性能造成影響。

　　最后，重要的是，必須收集系統需求。這些是系統的高層次目標，決定著負載測試過程的通過/失敗狀態。這些一般在與LOB的項目經理工作中達成一致。系統需求包括對以下問題的回答：

　　系統在正常和最高峰時期必須支持多少用戶?

　　每秒鐘它必須處理多少個事務?

　　對于可業務關鍵事務最大和最小可接受的響應時間是多少?

　　用戶群體如何聯系?

　　生產中系統承受的工作負載是什么?以及混合的事務?

　　團隊需求是進展到構建階段前需要解決的最后一個問題。這只不過是決定適合的性能團隊成員來參與到未來的負載測試。最初，這也許被自動的確定(例如，當只有一個團隊)。然而，如果性能測試成為卓越中心(CoE)的一部分，那么資源分配，內部后勤就應該在設計階段考慮和解決。

　　預先收集一套完整的業務，技術，系統，和團隊需求是使負載測試有效和成功的基礎。

　　構建

　　構建階段將在設計階段確定的業務過程和工作負載轉變為自動化組件，這部分可以驅動可重復的，實際的負載。這可以分為兩個方面：自動化設置和環境設置。自動化設置是由性能工程師完成的一系列連續的工作。

　　腳本：將確定的業務過程記錄為自動腳本。

　　事務：插入定時器來產生業務所需的邏輯計時。

　　參數化：用一個池替代所有的輸入數據，例如ID和密碼，這樣每個虛擬用戶用唯一的數據訪問應用。

　　場景：通過給用戶組分配不同的腳本，連通性和用戶行為等方法，創建生產工作負載。

　　監測器：確定負載下所要監控的服務器或機器。

　　環境設置由執行成功，現實的負載測試所需的硬件，軟件，和數據組成。這些可能涉及到系統，DBA，運營和業務團隊。

　　構建階段的最終成果就是可以執行在可用的，已配置的環境上的一系列自動化“資產”。

　　執行

　　對于剛接觸性能測試的新手來說，經常存在一個誤解，就是執行是一個單一事件。實際上，它是一個由多種類型的性能測試組成的多步驟的過程。每種測試都提供了理解發布應用所帶來風險的必要信息。負載測試的類型包括：

　　基線測試驗證了系統和其周圍環境可在合理的技術參數下運行。性能測試按5到10個用戶執行，作為最終用戶事務性能的基線。這些測試應該在性能測試的開始和結束時執行，來測量響應時間的絕對改進。

　　性能測試在環境中模仿負載，并確定系統可以支撐的最佳和最大用戶數量。這些測試應該仿效平均和峰值時間的生產用法，他們應當最大限度地仿真用戶的真實行為，例如思考時間，調制解調器的仿真，和各種類型的瀏覽器。同時，采用其它專用的監控和診斷工具，有效地查看系統內部行為，診斷系統衰變和瓶頸。

原文轉自：http://www.uml.org.cn/Test/200801231.asp