對于目前以 B/S 結構為主的產品來說，性能是一項必測的內容。
關于性能方面的測試，在很多地方又被細分為：負載測試、強度測試、容量測試、壓力測試等等。這種細分在概念描述上有一些用處，但在實際工作中很少會只單獨的進行其中的某一項測試，實際測試基本上都是交叉性的。我們這里把所有與性能相關的測試統稱為性能測試，不做具體區別。
我們在這里所說的性能測試，指的是對系統整體性能的測試，不涉及單元模塊的性能檢測。
我們在這里討論的內容主要是基于 B/S 架構的應用。
要討論性能測試，很難不涉及測試工具，我們在這里以 MI 公司的 LoadRunner 為默認的測試工具。
性能測試的介入時機
性能測試應該在什么時候開始？對測試人員來說，在產品的功能穩定下來后，就應該盡早開始對產品進行性能測試。一般建議在產品的 3 輪完整功能測試后開始。
測試過程
性能測試的整體測試過程如下：
1.3.1 制定性能測試計劃
1.3.2 搭建測試環境
1.3.3 編寫測試程序/腳本
1.3.4 測試執行和分析
1.3.5 編寫測試報告，結束測試
1.4 過程說明
各個子過程的具體說明：
1.4.1 制定性能測試計劃
分析被測試系統的情況，收集性能測試需求。制定測試計劃，形成文檔。測試計劃應考慮以下內容：
測試對象和場景。即我們要測試的內容是什么。系統最后對外提供的功能有很多，我們不可能也沒有必要對系統所有的功能點都進行性能測試。挑選性能測試對象的一般原則是：選取那些在系統實際投入使用后，并發訪問量較大的、算法比較復雜的、占用系統資源較多的功能點，也就是壓力點。設定好要測試的壓力點后，需要詳細的描述出具體的操作過程，以及預期應該達到的性能指標。
注：在制定測試計劃時，對于系統預期應該達到的性能指標，常常是不能獲得一個準確的數字。但即使是在沒有任何參考數據的情況下，也應該和開發人員一起，設定一個初步的性能指標，作為后面測試的一個參照。有一個初步指標，也比沒有任何指標要好。
測試環境。具體包括：選用什么樣的硬件環境（計算機配置，網絡結構）；什么樣的軟件環境（操作系統，數據庫，應用服務器， Web 服務器）；多大的數據量（數據庫，文件系統）。
需要監控的資源。進行性能測試時，需要監控的系統軟硬件資源的占用情況。這和產品的具體情況有關，一般可以考慮的因素包括： CPU 使用情況、 Memory 的使用情況、磁盤的 I/O 、網絡的占用情況、數據庫運行狀況、 Web/ 應用服務器運行狀況等。
測試工具。選用什么工具進行性能測試，是自己開發，還是選用第三方的測試工具。
進度安排。各階段的工作內容、時間安排。
1.4.2 搭建測試環境
依照測試計劃中的測試環境要求，搭建實際的測試環境，安裝配置還好硬件、軟件，準備好測試數據。
1.4.3 編寫測試程序/腳本
編寫實際的測試程序或腳本。如果能夠使用現有的成熟測試工具則盡量選用，如果現有工具不能滿足測試要求，則需要編寫定制的測試程序。
同時，要為腳本編寫說明文檔，文檔的內容主要是腳本的名稱，以及其對應的測試內容。
1.4.4 測試執行和分析
設定多種測試場景組合，反復運行測試，記錄結果數據，逐步優化系統，最后達到一個可接受的性能結果。測試執行過程中，注意每次測試后下次測試開始前的測試環境恢復工作。
性能測試和功能測試一樣，也有測試迭代的過程，也會有產品版本的更新。在性能測試過程中，需要和開發人員協同工作，一起調優系統。
1.4.5 編寫測試報告，結束測試
整理測試數據，總結測試結果，編寫測試報告，結束測試。
附錄 1 保證LoadRunner測試腳本的正確性
在用 LoadRunner 編寫完測試腳本后，要保證腳本在以下情況下能夠正確運行：
在腳本編輯器中：單用戶單循環運行腳本；單用戶多循環運行腳本。
在 controller 中：多用戶單循環運行腳本；多用戶多循環運行腳本。
附錄 2 性能測試術語解釋
測試場景：包含一個或多個腳本，設定并發數量，運行方式，模擬系統在現實中的一個情景。
事務：是指一組相關的操作，是性能測試中的計時單位。比如‘登錄應用系統’就可以作為一個事務。
集合點：設置集合點后，先到達的請求會等待，直到所有的請求都到達，然后一起發送請求。設置集合點，是為了進行更嚴格和精確的并發測試。
checkpoint ：也叫檢查點。和功能測試一樣，性能測試也需要檢驗結果的正確性。 當返回標準的 HTTP 錯誤時（狀態碼不是 200 +時），Loadrunner能夠識別出來，但如果返回的不是標準HTTP錯誤，Loadrunner則無法識別，這時只能通過我們設置的check point來發現錯誤。
參數化：為了更真實的模擬現實操作，我們經常需要對測試輸入進行參數化。比如登錄時的用戶名。
關聯：對于腳本中動態變化的部分，需要對其進行參數化， Loadrunner 提供了對這種變量進行參數化的功能，叫做關聯。比如下面這種情況： 在一個基于 WEB 的應用中，用戶每次登錄時會被服務端賦予了一個 SessionID ，該用戶的后續操作都必須給出這個 SessionID 。在這種情況下，由于被賦予的 SessionID 是由服務端給出的，每次執行腳本時，獲得的 SessionID 都會不同，因此就需要在腳本中取得用戶每次登錄，服務端返回的 SessionID ，在后續步驟中使用。這時我們就需要對 SessionID 進行參數化。即 Loadrunner 提供的關聯功能。
迭代次數：在性能測試中，對于一個場景，我們需要運行多次取其平均值，即迭代運行多次。目的是為了避免意外因素對測試結果的影響。
think time ：思考時間。在進行長時間的穩定性測試時，要考慮在腳本中加入適當的 think time ，來更好的模擬現實中的情況。
文章來源于領測軟件測試網 http://www.kjueaiud.com/
