“全面性能測試模型”提出的主要依據就是一種類型的性能測試可以在某些條件下轉化成為另外一種類型的性能測試，而這些類型的測試實施也是很類似的。例如：針對一個網站進行測試，模擬10到50個用戶就是在進行常規性能測試，用戶增加到1000乃至上萬就變成了壓力/負載測試。如果同時對系統進行大量的數據查詢操作，就包含了強度測試。
1 全面性能測試模型
在“全面性能測試模型”中，把Web性能測試分為八個類別。下面首先介紹八個性能測試類別的主要內容。
（1） 預期指標的性能測試：系統在需求分析和設計階段都會提出一些性能指標，這些指標是性能測試要完成的首要工作之一，本模型把預先確定的一些性能指標的測試稱為預期指標的性能測試。
這些指標主要是指諸如“系統可以支持并發用戶1000”、“系統響應時間不得高于10秒”等在產品說明書等文檔中中十分明確的內容，對這種預先承諾的性能要求，測試小組應該“首當其沖”完成這類測試。
（2） 獨立業務性能測試：獨立業務主要是指一些核心業務模塊，這些模塊通常具有功能比較復雜、使用比較頻繁、屬于核心業務等特點。這類特殊的、功能比較獨立的業務模塊始終都是性能測試重點。我們通常不但要測試這類模塊的一些和性能相關的算法，還要測試這類模塊對并發用戶的響應情況。
核心業務模塊在需求階段就可以確定，在系統測試階段開始單獨測試其性能。如果是系統類軟件或者特殊應用的軟件，通常從單元測試階段就開始進行測試，在后繼的集成測試、系統測試、驗收測試中進一步進行測試，以保證核心業務模塊的性能穩定。
用戶并發測試是核心業務模塊的重點測試內容，“并發”的主要內容是模擬一定數量的用戶同時使用某一核心模塊的“相同”或者“不同”的功能，并且持續一段時間。對“相同”的功能進行并發測試分為兩種類型，一類是在同一時刻進行完全一樣的操作，例如打開同一條數據記錄進行查看；另外一類是在同一時刻使用完全一樣的功能，例如同時提交數據進行保存�？梢钥闯龊笳呤前扒罢叩�，后者是前者的特例，這種并發測試都要持續一定的時間。
從微觀角度講，同時使用某一核心模塊“不同”的功能，也是一種組合業務性能測試，只不過這種組合的相關業務大分類是一致的。
（3） 組合業務性能測試：通常不會所有的用戶只使用一個或者幾個核心業務模塊，每個功能模塊都可能被使用到，所以Web性能測試既要模擬多用戶的“相同”操作(這里的“相同”指很多用戶使用同一功能)，又要模擬多用戶的“不同”操作(這里的“不同”指很多用戶同時對一個或者多個模塊的不同功能進行操作)，對多個業務進行組合性能測試。組合業務測試是最接近用戶實際使用情況的測試，因而是性能測試的核心內容。我們通常按照用戶的實際使用情況來模擬使用各個模板的人數比例。
由于組合業務測試是最反映用戶使用系統情況的測試，因而組合測試往往和服務器（操作系統、Web服務器、數據庫服務器）性能測試結合起來，在通過工具模擬用戶行為的同時，還通過測試工具的監控功能采集服務器的計數器信息，進而全面分析系統的瓶頸，為改進系統提供有利的依據。
用戶并發測試是組合業務測試的核心內容�！敖M合”并發的突出特點是分成不同的用戶組進行并發，每組的用戶比例要根據實際情況來進行匹配。組合業務測試可以理解為包含了“核心業務模塊并發”和“非核心業務模塊并發”同時進行的并發用戶測試。
（4） 疲勞強度性能測試：疲勞強度測試是在系統穩定運行下模擬較大的用戶數量、并長時間運行系統的測試，通過綜合分析執行指標和資源監控來確定系統處理最大業務量時的性能，主要目的是為了測試系統的穩定性。
（5） 大數據量性能測試：大數據量測試分為兩種：一種是針對某些系統存儲、傳輸、統計查詢等業務進行大數據量的測試,主要是測試數據增多時的性能情況，這類一般都是針對某些特殊的核心業務或者一些日常比較常用的組合業務的測試。
第二種是極限狀態下的數據測試，主要是指系統數據量達到一定程度時，通過性能測試來評估系統的響應情況，測試的對象也是某些核心業務或者日常常用的組合業務。例如系統的數據每年只備份轉移一次，可分別選擇一個季度、半年、一年作為參考，模擬輸入各個時間段的預計數據量，然后測試系統的性能，進而預估系統的性能走向。
由于大數據量仍然是為了測試系統的業務處理能力，因此大數據量性能測試可以獨立進行，也可以和前面的獨立、組合業務測試結合起來進行，主要由性能測試策略來決定。由于大數據量測試一般在投產環境進行，因此把它單獨獨立出來，和疲勞強度測試放在一起，在整個性能測試的后期進行。大數據量測試可以理解為特定條件下的核心業務或者組合業務測試。
（6） 網絡性能測試：網絡性能測試主要是為了準確展示帶寬、延遲、負載和端口的變化是如何影響用戶的響應時間的。在實際的軟件項目中，主要是測試應用系統的用戶數目與網絡帶寬的關系。
（7） 服務器性能測試（操作系統、Web服務器、數據庫服務器）：服務器性能測試分為初級和高級兩種形式�！俺跫壏⻊掌餍阅軠y試”主要是指在業務系統工作或者進行前面其它種類性能測試的時候，監控服務器的一些計數器信息，通過這些數據對服務器進行綜合性能分析，找出系統瓶頸，為調優或者提高性能提供依據�！案呒壏⻊掌餍阅軠y試”一般不由測試人員進行，由專門的系統管理員來進行，例如數據庫服務器由專門的DBA來進行測試和調優。本文主要討論在測試中常用到的“初級服務器性能測試”，既通過工具對服務器資源進行監控的性能測試。
（8） 一些特殊測試：主要是指配置測試、內存泄漏測試一些特殊的Web性能測試。這類性能測試或者和前面的測試結合起來進行，或者在一些特殊情況下會獨立進行，本文重點來討論前一種情況，因為后一種情況往往通過特有的工具、較大投入的進行，可以不作為性能測試的范疇來研究。
2性能測試通用策略
2.1性能測試策略通用方法
本節主要介紹一下通用的性能測試策略制定方法。性能測試策略一般從需求設計階段開始討論制定，策略的內容決定著性能測試工作投入多少資源、什么時間開始實施等后繼工作如何安排。其制定的主要依據是“軟件自身特點”和“用戶對性能的關注程度”兩個因素，其中軟件的自身特點起決定作用。
軟件按照用途的不同分為兩大類：系統類軟件和應用類軟件。系統類軟件對性能一般要求比較高，因此性能測試應該盡早介入。應用類軟件分為特殊類應用和一般類應用，特殊類應用主要指銀行、電信、電力、保險、醫療、安全等領域類的軟件，這類軟件使用比較頻繁，用戶較多，一般也要較早進行性能測試；一般類應用主要指一些普通應用，例如辦公自動化軟件、MIS系統等，一般應用類軟件多根據實際情況決定性能測試策略，比如OA系統，可以早開始、也可以最后進行性能測試，這類軟件受用戶因素影響比較大。
用戶一般可以分為四類：即對性能特別關注、中等重視、一般關注、不怎么關注四類。這里這么劃分并不意味著用戶不關注性能測試人員就可以忽略性能測試。不過，用戶如果特別關注性能，測試人員也應該特別重視性能測試。表1列出了性能測試策略制定的基本原則。（注意：這里的用戶是廣義范圍的用戶，包括所有和我們的產品有利害關系的群體。因而不單單指最終使用產品的用戶，這些用戶既可以是為我們提出需求的產品部，也可以是公司的董事會，甚至是我們研發人員自己。）
從表1我們可以看出（1）“系統類軟件”、“特殊應用類軟件”應該從設計階段開始進行性能測試共，（2）制定性能測試策略的主要依據是由軟件的特點來決定，用戶的態度對策略會有一定的影響，但不是決定因素。
軟件的特點決定性能測試策略另外一個重要原因就是“一般應用類軟件”通常耗費資源較少，因此可以通過提高硬件配置，進而改善運行環境來提高“一般應用類軟件”的性能。從硬件方面解決性能問題往往更容易做到，同時可以降低我們的開發成本，不過也不能過分讓用戶進行較大的硬件投入，否則會降低我們的“客戶滿意度”。我們調整性能最好的辦法還是軟硬件相結合。
用戶對待系統性能的態度影響性能測試策略，但不起決定作用的根本原因是我們最終要把產品交付給用戶來使用，而不是做出來給用戶欣賞。因此不管用戶是否重視性能測試，即使根本不關心，對于性能要求高的軟件產品我們都應該按照測試上面的策略進行合理的安排。同時，如果我們的上帝——用戶如果特別重視，這意味著我們需要進行更多的性能測試方面的投入，因為我們有義務使我們的用戶滿意。
2.2性能測試策略實例
下面我們可以看一些性能測試策略制定的案例。
案例一：一個銀行項目的性能測試策略的制定案例，性能測試策略從立項時開始確定，貫穿整個項目的執行過程。該軟件屬于特殊應用軟件，用戶高度重視性能，因而采取的策略是從設計階段就開始進行性能測試的準備工作，案例具體內容如下：
表2某銀行項目測試制定案例
案例二：一個OA系統的測試案例，我們可以看出性能測試策略和案例一差別很大。
案例三：一個門戶系統的測試案例。
三個案例不足以說明所有的性能測試策略制定的方法，但是通過這三個案例我們對性能測試策略的制定有了更進一步的了解，體會到性能測試策略制定由軟件自身特點決定，同時受用戶的態度影響。實際上，軟件項目的背景、軟件運行環境等許多方面都會影響性能測試策略的制定。因此，本節提出的也是基本的參考方案。制定測試策略是十分復雜的工作，最有效的方法就是“從實際出發”，項目的特點千差萬別，我們只有把用戶當成“上帝”，充分為用戶考慮，綜合各個方面進行考慮，才可以制定出合理的性能測試策略。
本節介紹了性能測試策略制定的基本思路和方法，讀者應該認真體會這些理論，性能測試策略是后期性能測試工作的基礎，決定著性能測試工作的投入。讀者要充分意識到這一工作的重要性，認識到只有做好了前期的“路線”工作，才可以走對后面的“道路”。
3 Web性能測試模型使用方法
“全面性能測試模型”是針對Web性能測試而提出的一種方法，主要目的是為了比較全面的開展性能測試，使Web性能測試更容易組織和開展。本模型包含了測試策略制定的通用方法和測試用例設計通用方案，測試用例的設計覆蓋了應用軟件、服務器、操作系統多方面的內容，按照由淺入深的順利對性能測試進行了合理的組織。
“全面性能測試模型”是一種經很多性能測試項目抽象出來的方法論，主要用來指導測試，它一般不適合具體的性能測試項目，因為任何一個項目都會有它的特定背景。要想通過“Web全面性能測試模型”做好性能測試工作，首先要制定好性能測試策略，同時還要按照一些基本指導原則來使用“Web性能測試用例設計模型”的內容。這些原則主要包括如下的內容：
測試策略遵從最低成本原則。Web性能測試本身是一種高投入的測試，而實際中國內公司通常在測試上進行較低的投入，Web性能測試只是全部測試工作的一部分，很多項目只能進行一些重要的性能內容，這就決定測試經理制定性能測試策略時在資源投入方面一定要遵從最低成本化原則。最低成本的衡量標準主要指“投入的測試成本能否使系統滿足預先確定的性能測試目標”，只要我們經過反復的“測試——系統調優——測試”后，系統符合性能需求并有一定的擴展空間，就可以認為性能測試工作是成功的。反之，如果系統經過測試后不滿足性能需求或者滿足性能需求后仍然投入資源，都可以認為是不合理的。
策略為中心原則。本原則不但對性能測試工作有效，對其他類型的測試工作都具有同樣的指導意義。測試策略不但決定了我們測試用例設計時的主要內容，還決定著我們實施測試工作時如何根據項目的實際情況進行處理，例如：如果項目時間比較緊張，我們完全可以按照測試用例的優先級只執行一部分性能測試用例。因此，性能測試策略應該貫穿整個性能測試過程。
適當裁剪原則。裁剪原則主要是針對性能用例設計而言。Web性能測試用例設計模型主要是針對電信、銀行級的應用而提出的，包含的測試內容比較全面，而這類項目的性能測試一般周期較長、投入較大，作者曾親身經歷過測試周期為一年的銀行項目。要想性能測試用例設計模型在大多數測試項目中使用，必須對測試用例模型包含的內容進行合理的裁剪，這樣做的主要目的是為了適合特定項目的測試需求，進而節約測試成本。
裁減的主要依據是性能測試策略，我們根據策略制定方法制定出測試策略，然后依據策略從“五類性能測試用例”中選擇適當的內容來編寫測試用例。例如有些要求不高的靜態門戶網站，用戶也沒有提出性能方面的要求，我們完全可以只測試一下用戶并發情況作為系統性能的參考。
完善模型原則。本模型只是作者的工作經驗總結，由于不同的性能測試任務都有自己的項目背景，因而需要對模型內容進行不斷的調整、補充、完善，才能使之適合更多的性能測試工作。不斷完善具體來說就是要在工作中不斷總結自己的經驗，形成自己的“Web全面性能測試模型”。只有“自己的”測試模型，才是最符合自己需要的模型。
模型具體化原則。模型具體化主要是指把本模型運用到具體的項目中，是前面所有原則的目標。如果只記住模型的這些條條框框，然后生搬硬套框架來設計測試，只能得到適得其反的結果。要想使模型在Web性能工作中發揮作用，只有根據實際項目的特點制定合理的性能測試策略、編寫適當的性能測試用例，并在測試實施中靈活的執行測試方案。
綜合上面的分析，可以看出模型使用完全可以概括成兩個字——“活用”。要想真正做好性能測試工作，最有效的辦法就是在掌握基本理論和方法后，在工作中不斷的去探索和總結，不斷的完善該模型，形成自己的“Web全面性能測試模型”。
“全面性能測試模型”是一種很有效的做Web性能測試的“兵法”，這正是本篇命名為“兵法篇”的目的�！氨ā笔恰皩洝眰儭按蛘獭钡谋貍渲R，學會了兵法才可以指揮戰爭，但是兵法畢竟不能代替具體的“戰術”，它只是“打勝仗”的前提條件，具體的“仗”怎么去“打”，仍然要根據具體的戰場情況來指揮。因此，具體的Web性能測試工作仍然按照項目的自身特點去組織和實施。
文章來源于領測軟件測試網 http://www.kjueaiud.com/
