需要監控的資源。進行性能測試時，需要監控的系統軟硬件資源的占用情況。這和產品的具體情況有關，一般可以考慮的因素包括： CPU 使用情況、 Memory 的使用情況、磁盤的 I/O 、網絡的占用情況、數據庫運行狀況、 Web/ 應用服務器運行狀況等。
測試工具。選用什么工具進行性能測試，是自己開發，還是選用第三方的測試工具。
進度安排。各階段的工作內容、時間安排。
4.2 搭建測試環境
依照測試計劃中的測試環境要求，搭建實際的測試環境，安裝配置還好硬件、軟件，準備好測試數據。
4.3 編寫測試程序/腳本
編寫實際的測試程序或腳本。如果能夠使用現有的成熟測試工具則盡量選用，如果現有工具不能滿足測試要求，則需要編寫定制的測試程序。
同時，要為腳本編寫說明文檔，文檔的內容主要是腳本的名稱，以及其對應的測試內容。
4.4 測試執行和分析
設定多種測試場景組合，反復運行測試，記錄結果數據，逐步優化系統，最后達到一個可接受的性能結果。測試執行過程中，注意每次測試后下次測試開始前的測試環境恢復工作。
性能測試和功能測試一樣，也有測試迭代的過程，也會有產品版本的更新。在性能測試過程中，需要和開發人員協同工作，一起調優系統。
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/
