如何制定一份詳盡的性能測試計劃
作者: 未知 來源: 網絡轉載
進行任何性能測試之前，都需要制定一份詳盡的測試計劃，從業務角度到技術角度詳細地說明性能測試將如何進行。一份性能測試計劃應該至少包含以下方面：
總體方法
依據與基本假定
性能測試前的操作
性能測試方法
性能測試操作
業務范圍內的過程
業務范圍外的過程
性能測試方案
性能測試的執行
性能測試指標
和任何測試計劃一樣，這份性能測試計劃的文字要做到盡量精簡，可以使用列表清晰明確地將信息表達出來。這將減少因為溝通問題產生的誤解。
總體方法
這一部分是指用非技術性術語將性能測試的總體方法描述出來。目標受眾是管理部門與業務部門。樣例如下：
“此性能測試方法主要用來對新部署的系統所支持的業務過程進行測試。通過部署這次性能測試，我們將：
以減少這次新部署所帶來的性能問題為主要目的。
做出基本的運行假定，確定部署中需要進行性能測試的部分。
就這些假定取得一致意見，決定性能與壓力測試的適當等級，并在有限的任務時間內完成。
這份文件是即時更新的。隨著我們收集到越來越多的信息，并就適當的性能測試方法達成一致協議時，將再次更新這份文件�！�
依據與基本假定
在這一部分中，要清晰地描述測試前必須滿足的依據（必須完成的任務）與基本假定（測試時假定為真）。樣例如下：
“繼續部署任何性能測試之前，必須滿足以下條件：
要進行性能測試的組件必須能完全正常運行。
要進行性能測試的組件要安裝在可以代表（或按比例可調的）預期的生產系統的硬件或固件中。
數據存儲庫要能代表（或按比例可調）預期的生產系統。
有確定的性能測試目標，包括運行情況的假定與測試方案。
安裝好性能測試工具并提供所需的技術支持�！�
性能測試前的操作
這部分要清楚地說明在正式進行性能測試之前為確定系統已經就緒而進行的預測試操作。相當于功能測試中的煙霧測試（smoke testing）。樣例如：
“為減少性能測試中的風險，可以進行幾項預測試操作：
在質量保證測試環境下利用‘樁(stub)’或‘實用程序（utilities）’測試事務處理能力，即投影最大負載（projected peak loads）。
用‘樁’或‘實用程序’代替無需測試或只需進行有限測試的B2B類事務。這將取消任何關于B2B事務的依據。
用‘樁’或‘實用程序’代替性能測試中無法使用的內部組件。這將移除所有關于此類組件的依據。
在所有大規模服務器上部署合適的性能監控器�！�
性能測試方法
這一部分是前面總體方法的擴展，但考慮到了業務與技術兩個方面。樣例如：
“本性能測試方法主要用來測試新部署的系統的邏輯。通過部署這次性能測試，我們將：
以減少這次新部署所帶來的性能問題為主要目的。
做出基本的運行假定，確定部署中需要進行性能測試的部分。
就這些假定取得一致意見，確定即將完成的性能的適當等級。
使用可以模擬預期生產規模的一流的性能測試工具。
模擬需要進行性能測試的組件（將在生產中使用的組件）構成測試環境，檢測所有異常。
在性能測試期間同時使用生產與非生產（測試）監控器器檢測系統的性能�！�
性能測試操作
這一部分詳細說明了性能測試中所進行的操作。樣例如：
“性能測試中將進行以下操作：
根據既定方案對系統進行合適的負載測試。方案包括：
> 用戶操作（業務流程）
> 既定負載（每分鐘的事務處理次數）
> 既定指標（響應時間）
性能測試期間將進行手工測試和自動化的功能測試，保證在當前負載下用戶操作不會受到影響。
將使用系統監控器監測測試涉及的所有服務器的性能，保證其達到預期的性能要求。
部署后支持團隊將在性能測試現場觀察性能測試結果并提供支持�！�
業務范圍內的過程
這一部分指定系統的哪些方面屬于業務范圍內（基于標準）。樣例如：
“性能測試時將以下過程視為業務范圍內的過程：
用戶注冊
登錄/訪問
用戶對內容進行瀏覽
銷售條款與執行
賬目計算
業務過程目錄與以下人員商議制定：業務分析員、市場分析員、基礎組織和業主�！�
業務范圍外的過程
這一部分指定系統的哪些方面屬于業務范圍外（基于標準）。樣例如：
“性能測試時將以下過程視為業務范圍外的過程：
信用檢查
> 前提：信用檢查將委托第三方進行――因此不會對性能產生明顯的影響。
所有在當前未被列為業務范圍內或范圍外的業務功能。
> 前提：所有未在本文件中列出的范圍內或范圍外的業務都不會對業務產生明顯的性能影響�！�
制定性能測試方案
這一部分在測試計劃中的位置要取決于企業在性能測試領域的成熟度。如果企業幾乎或者完全沒有這一領域的經驗，就在計劃中包括這一部分，否則可以將其作為附錄部分。樣例如：
“制定性能測試方案需要大量來自IT與業務部門的信息。
業務方案
> 業務方案首先要用簡單的文本描述待測的業務過程。
> 然后業務方案擴展到一系列包含準確的數據需求的詳細步驟。
> 最后直到當IT部門確定了應用/服務器的行為（比如緩存）需要（或不需要）哪些額外的數據需求，業務方案就算完成。
預期吞吐量（峰值）
> 預期吞吐量首先要說明高峰時段和非高峰時段用戶對某一業務的預期操作量。
> 然后擴展到一系列不同的、終端用戶可能無法分辨（或可以分辨）的業務過程。
> 直到IT部門確定哪些額外的因素（如果有的話）會影響到負載（比如負載平衡），預期吞吐量這部分就算完成了。
驗證性能標準（驗證不同負載條件下的響應時間）
> 性能標準驗證是指在低、中、高負荷條件下可接受的業務響應時間。根據一天的系統負載情況為參考。這可以用其它的性能方案進行模擬。
> 然后性能測試團隊便能用可測的系統事件對驗證標準進行闡述。然后這些標準就提交到業務部門以供驗證。
> 直到IT部門確定了如何在性能測試過程中對系統性能進行監控，驗證標準過程部分就完成了。這其中包括性能測試團隊的指標。
數據需求（方案與部署的具體內容）
> 業務部門確定會影響到終端用戶體驗的主要數據部分。
> IT部門對這些數據需求進行擴展以包含終端用戶不可見的一些因素，比如緩存。
> 性能測試團隊與IT和業務部門合作創建所需的數據存儲庫以支持性能測試�！�
性能測試的執行
這一部分在測試計劃中的位置仍然取決于企業在性能測試領域的成熟度。如果企業有大量的性能測試經驗，那么這一部分可以作為輔助性的附錄。樣例如：
“性能測試通常按照一定的順序進行：
制定性能測試方案。
根據制定的方案定義一天的負載。
單獨執行性能測試以檢測特定的業務流程中可能存在的問題。
以封包的方式執行性能方案，模擬一天的活動，并根據性能標準進行評測。
報告性能測試的結果。
調節系統。
根據需要重新進行測試�！�
性能測試指標
性能測試指標是與性能測試方案中制定的性能驗證標準相對應的。如果企業預備將其作為性能要求，那么就應該在性能測試計劃中增加性能要求的部分。最基本的性能測試指標包括檢測響應時間和給定性能負載下事務處理的失敗率（如性能測試方案中所述）。然后用這些指標與性能要求對比，確定系統是否符合業務要求。
結束語
本文只能描述性能測試計劃的一般情況，具體則要根據所測試的系統和情況而定。最后要說的是，許多非性能測試操作經常被視為性能測試——我喜歡稱之為假寐的（warm-and-fuzzy）性能測試。如果你沒有模擬預期的生產負載，那就不能說是在做性能測試。
文章來源于領測軟件測試網 http://www.kjueaiud.com/