1、系統基礎功能驗證
一般情況下，只有在系統基礎功能測試驗證完成、系統趨於穩定的情況下，才會進行效能測試，否則效能測試是無意義的。
2、測試團隊組建
根據該項目的具體情況，組建乙個幾人的效能測試team，其中dba是必不可少的，然後需要一至幾名系統開發人員（對應前端、後台等），還有效能測試設計和分析人員、指令碼開發和執行人員；在正式開始工作之前，應該對指令碼開發和執行人員進行一些培訓，或者應該由具有相關經驗的人員擔任。
3、工具的選擇
綜合系統設計、工具成本、測試團隊的技能來考慮，選擇合適的測試工具，最起碼應該滿足一下幾點：
①支援對web（這裡以web系統為例）系統的效能測試，支援http和https協議；
②工具的執行平台必須是公司常用的平台；
③支援對webserver、前端、資料庫的效能計數器進行監控；
4、預先的業務場景分析
對系統較重要和常用的業務場景模組進行分析，針對性的進行分析，以對接下來的測試計畫設計進行準備
1、效能測試領域分析
根據對專案背景，業務的了解，確定本次效能測試要解決的問題點；是測試系統能否滿足實際執行時的需要，還是目前的系統在哪些方面制約系統效能的表現，或者，哪些系統因素導致
系統無法跟上業務發展？確定測試領域，然後具體問題具體分析。
2、使用者場景剖析和業務建模
根據對系統業務、使用者活躍時間、訪問頻率、場景互動等各方面的分析，整理乙個業務場景表，當然其中最好對使用者操作場景、步驟進行詳細的描述，為測試指令碼開發提供依據
3、確定效能目標
預設本次效能測試各子模組的起止時間，產出，參與人員等等
三、效能測試方案設計
1、測試環境設計
本次效能測試的目標是需要驗證系統在實際執行環境中的效能外，還需要考 慮到不同的硬體配置是否會是制約系統效能的重要因素。因此在測試環境中，需 要部署多個不同的測試環境，在不同的硬體配置上檢查應用系統的效能，並對不同配置下系統的測試結果進行 分析，得出最優結果（最適合當前系統的配置）。
這裡所說的配置大概是如下幾類：
①資料庫伺服器
②應用伺服器
③負載模擬器
④軟體執行環境，平台
測試環境測試資料，可以根據系統的執行預期來確定，比如需要測試的業務場景， 資料多久執行一次備份轉移，該業務場景涉及哪些表，每次運算元據怎樣寫入， 寫入幾條，需要多少的 測試資料來使得測試環境的資料保持一致性等等；
可以在首次測試資料生成時，將其匯出到本地儲存，在每次測試開始前導入資料， 保持一致性。
2、測試場景設計
通過和業務部門溝通以及以往使用者操作習慣，確定使用者操作習慣模式，以及不同 的場景使用者數量，操作次數，確定測試指標，以及效能監控等。
3、測試用例設計
確認測試場景後，在系統已有的操作描述上，進一步完善為可對映為指令碼的測試用例描述。
用例大概內容如下：
用例編號：查詢表單_***_x1（命名以業務操作場景為主，簡潔易懂即可）
用例條件：使用者已登入、具有對應許可權等。。。
操作步驟：
①進入對應頁面。。。。。。
②查詢相關資料。。。。。。
③勾選匯出資料。。。。。。
④修改上傳資料。。。。。。
1、根據效能測試用例的描述，根據公司的實際情況完成測試指令碼的開發：
① 公司有介面設計文件
直接把測試用例中需要用到的介面通過介面文件提供的資訊錄入到效能測試工具。
② 公司無介面設計文件
可利用錄製工具進行錄製或者結合抓包工具進行手工編寫指令碼。
2、在工具中完成測試指令碼後，進行對效能測試指令碼的除錯與調優操作（如：關聯、引數化、檢查點設定、指令碼邏輯設定等）
1、建立測試環境
按照之前已經設計好的測試環境，部署對應的環境，由運維或開發人員進行部署，檢查，並仔細調整，同時保持測試環境的乾淨和穩定，不受外來因素影響。
2、測試資料準備
可以利用測試指令碼自動生成業務測試資料、利用工具生成資料或者匯入生產環境的業務資料等方式
3、執行測試指令碼
這一點比較簡單，在已部署好的測試環境中，按照業務場景和編號，按順序執行我們已經設計好的測試指令碼
4、測試結果記錄
根據測試採用的工具不同，結果的記錄也有不同的形式；現在大多的效能測試工具都提供比較完整的介面圖形化的測試結果，當然，對於伺服器的資源使用等情況，可以利用一些計數器或第三方監控工具來對其進行記錄，執行完測試後，對結果進行整理分析。
1、測試環境的系統效能分析
根據我們之前記錄得到的測試結果（圖表、曲線等），經過計算，與預定的效能指標進行對比，確定是否達到了我們需要的結果；如未達到，檢視具體的瓶頸點，然後根據瓶頸點的具體資料，進行具體情況具體分析（影響效能的因素很多，這一點，可以根據經驗和資料表現來判斷分析）
2、硬體裝置對系統效能表現的影響分析
由於之前設計了幾個不同的測試環境，故可以根據不同測試環境的硬體資源使用狀況圖進行分析，確定瓶頸是再資料庫伺服器、應用伺服器抑或其他方面，然後針對性的進行優化等操作
3、其他影響因素分析
影響系統效能的因素很多，可以從使用者能感受到的場景分析，**比較慢，**速度尚可，這裡可以根據2\5\8原則對其進行分析
1、確定問題
應用程式**：在通常情況下，很多程式的效能問題都是寫出來的，因此對於發現瓶頸的模組，應該首先檢查一下**。
資料庫配置：經常引起整個系統執行緩慢，一些諸如oracle 的大型資料庫都是需要dba進行正確的引數調整才能投產的
作業系統配置：不合理就可能引起系統瓶頸。
硬體設定：硬碟速度、記憶體大小等都是容易引起瓶頸的原因，因此這些都是分析的重點
網路：網路負載過重導致網路衝突和網路延遲。
2、確定問題產生的原因
當確定了問題之後，我們要明確這個問題影響的是響應時間吞吐量，還是其他問題？是多數使用者還是少數使用者遇到了問題？如果是少數使用者，這幾個使用者與其它使用者的操作有什麼不用？系統資源監控的結果是否正常？cpu的使用是否到達極限？i/o 情況如何？問題是否集中在某一類模組中？ 是客戶端還是伺服器出現問題？ 系統硬體配置是否夠用？實際負載是否超過了系統的負載能力？ 是否未對系統進行優化？
通過這些分析及一些與系統相關的問題，可以對系統瓶頸有更深入的了解，進而分析出真正的原因
3、確定調整目標和解決方案
一般由效能測試團隊中的dba、核心開發、運維根據測試的實際情況進行確定並出詳細的解決方案進行評審，比如新增伺服器方式、調整**架構等
4、測試解決方案
對通過解決方案調優後的系統進行基準測試。（基準測試是指通過設計科學的測試方法、測試工具和測試系統，實現對一類測試物件的某項效能指標進行定量的和可對比的測試）
5、分析調優結果
系統調優是否達到或者超出了預定目標，系統是整體效能得到了改善，還是以系統某部分效能來解決其他問題。調優是否可以結束了
負載：
對被測系統不斷施加壓力，直到效能指標超過預期或某項資源使用達到飽和， 以驗證系統的處理極限，為系統效能調優提供依據，如模擬100個使用者進行發帖 操作
併發：
①狹義上的併發：所有使用者在同一時間點進行同樣的操作，一般指同一型別的業 務場景，比如1000個使用者同時登入系統；
②廣義上的併發：多個使用者與系統發生了互動,這些業務場景可以是相同的也可以是不同的,交叉請求和處理較多,比如1000個使用者登入系統後，部分在查詢、 部分在下單等
事務：
效能測試中，事務指的是從端到端，乙個完整的操作過程，比如一次登入、一次 篩選條件查詢，一次支付等；
負載測試
在一定的軟體、硬體及網路環境下，通過執行一種或多種業務在不同虛擬使用者數量情況下，測試伺服器的效能指標是否在使用者的要求範圍內，用於確定系統所能承載的最大使用者數、以及不同使用者數下的系統響應時間及伺服器的資源利用率。強調系統的穩定性。
是通過逐步增加系統負載，測試系統效能的變化，並在滿足最終確定效能指標的情況下，系統所能承受的最大負載量的測試。
壓力測試
在一定的軟體、硬體及網路環境下，通過模擬大量的虛擬使用者向伺服器產生負載，使伺服器的資源處於極限狀態下長時間連續執行，以測試伺服器在高負載情況下是否能夠穩定工作。
壓力測試與負載測試兩者比較：
相同點：都是效能測試的一種型別
不同點：負載測試強調系統正常工作情況下的效能指標；壓力測試的目的是發現在什麼條件下系統的效能變得不可接受，發現應用程式效能下降的拐點
Jmeter效能測試2 效能測試常見分類
效能測試包括 負載測試 強度測試和容量測試等。負載測試是指通過測試系統在資源超負荷情況下的表現，來發現設計上的錯誤或驗證系統的負載能力。在這種測試中，將使測試物件承擔不同的工作量，以評測和評估測試物件在不同工作量條件下的效能行為，以及持續正常執行的能力。負載測試的目標是確保系統在超出最大預期工作量的...
效能測試 Jmeter
如何更快速的入門jmeter 建議通過錄製指令碼的方式，快速的了解乙個效能測試應該包括的元件以及它們的層級關係。關於錄製方式，請參考 jmeter基礎之 錄製指令碼 如下，通過badboy 工具錄製的乙個指令碼 指令碼過程 登入 126郵箱，給自己發一封郵件，祝自己聖誕快樂！並可以方便的將指令碼匯出...
jmeter效能測試
請參考 jmeter效能測試文章集合 jmeter 菜鳥入門到高階 系列 開源效能測試工具jmeter jmeter badboy環境搭建 badboy使用手冊 壓力測試之badboy和jmeter的簡單使用方法 jmeter 菜鳥入門到高階 系列 jmeter是我從事軟體測試工作以來接觸的第乙個效...