本文主要介紹下效能測試的基本流程，效能測試從實際執行層面來看，測試的過程一般分為這麼幾個階段，如下圖：
下面分別介紹下每個階段具體需要做什麼：
一、效能需求分析：
效能需求分析是整個效能測試工作開展的基礎，如果連效能的需求都沒弄清楚，後面的效能測試執行其實是沒有任何意義的，而且效能需求分析做的好不好直接影響到效能測試的結果。
一些效能測試人員常犯的錯誤就是測試一開始就直接用工具對系統進行加壓，沒有弄清楚效能測試的目的，稀裡糊塗做完了以後也不知道結果是否滿足效能需求。市面上的書籍也大都是直接講效能測試工具如LR，jmeter如何使用，導致很多新手一提到效能測試就直接拿工具來進行錄製回放，使得很多人認為會使用效能測試工具就等於會效能測試了，殊不知工具其實只是效能測試過程中很小的一部分。
在需求分析階段，測試人員需要與專案相關的人員進行溝通，收集各種專案資料，對系統進行分析，建立效能測試資料模型，並將其轉化為可衡量的具體效能指標，確認測試的目標。所以效能測試需求分析過程是繁雜的，需要測試人員有深厚的效能理論知識，除此之外還需要懂一些數學建模的知識來幫助我們建立效能測試模型。
首先，讓我們來看看通過效能需求分析我們需要得出哪些結論或目標：
- 明確倒底要不要做效能測試？效能測試的目的是什麼？
- 明確被測系統是什麼？被測試系統的相關技術資訊如：架構、平臺、協議等
- 明確被測系統的基本業務、關鍵業務，使用者行為
- 明確效能測試點是什麼？哪些需要測，為什麼？哪些不需要測，又是為什麼？
- 明確被測系統未來的業務擴充規劃以及效能需求？
- 明確效能測試策略，即應該怎麼測試？
- 明確效能測試的指標，知道測試出來的結果怎麼算通過？
其次，需求分析階段我們可以從以下幾個方面入手：
1、系統資訊調研：
指對被測試系統進行分析，需要對其有全面的瞭解和認識，這是我們做好效能測試的前提，而且在後續進行效能分析和調優時將會大有用處，試想如果連繫統的架構、協議都不瞭解，我們如何進行準確的效能測試？如果進行效能分析與調優？
需要分析的系統資訊如下（包括但不僅限於如下這些）：
2、業務資訊調研：
指對被測試的業務進行分析，通過對業務的分析和了解，方便我們後續進行效能測試場景的確定以及效能測試指標的確定。
需要分析的業務資訊如下（包括但不僅限於如下這些）：
3、效能需求評估：
在實施效能測試之前，我們需要對被測系統做相應的評估，主要目的是明確是否需要做效能測試。如果確定需要做效能測試，需要進一步確立效能測試點和指標，明確該測什麼、效能指標是多少，測試通過or不通過的標準？效能指標也會根據情況評估，要求被測系統能滿足將來一定時間段的業務壓力。
判斷是否進行效能測試主要從下面兩個方面進行思考：
- 業務角度:
系統是公司內部 or 對外？系統使用的人數的多少？如果一個系統上線後基本沒幾個人使用，無論系統多大，設計多麼複雜，併發性的效能測試都是沒必要的，前期可以否決。當然，除非在功能測試階段發現非常明顯的效能問題，使得使用者體驗較差的，此時可進行效能測試來排查問題。
- 系統角度：系統又可以從以下3個方面進行分析
a）系統架構：
如果一個系統採用的框架是老的系統框架（通常大公司都有自己的統一框架），只是在此框架上增加一些應用，其實是沒有必要做效能測試，因為老框架的使用肯定是經過了驗證的。如果一個系統採用的是一種新的框架，可以考慮做效能測試。
b）資料庫要求：
很多情況下，效能測試是大資料量的併發訪問、修改資料庫，而瓶頸在於連線資料庫池的數量，而非資料庫本身的負載、吞吐能力。這時，可以結合DBA的建議，來決定是否來做效能測試。
c）系統特殊要求：
從實時性角度來分析，某些系統對響應時間要求比較，比如證券系統，系統的快慢直接影響客戶的收益，這種情況就有作併發測試的必要，在大併發量的場景下，檢視這個功能的響應時間。
從大資料量上傳下載角度分析，某些系統經常需要進行較大資料量的上傳和下載操作，雖然此種操作使用的人數不會太多，但是也有必要進行效能測試，確定系統能處理的最大容量，如果超過這個容量時系統需要進行相關控制，避免由於不人工誤操作導致系統記憶體溢位或崩潰。
4、確定效能測試點：
在上面第3點中，我們簡單分析瞭如何確定一個系統是否需要做效能測試。下面簡單總結下如果一個系統確定要做效能測試，我們如何確定被測系統的效能測試點？
我們可以從下面幾個方面進行分析：
- 關鍵業務：
確定被測專案是否屬於關鍵業務，有哪些主要的業務邏輯點，特別是跟交易相關的功能點。例如轉賬，扣款等介面。如果專案（或功能點）不屬於關鍵業務（或關鍵業務點），則可轉入下面。
- 日請求量：
確定被測專案各功能點的日請求量（可以統計不同時間粒度下的請求量如：小時，日，周，月）。如果日請求量很高，系統壓力很大，而且又是關鍵業務，該專案需要做效能測試，而且關鍵業務點，可以被確定為效能點。
- 邏輯複雜度：
判定被測專案各功能點的邏輯複雜度。如果一個主要業務的日請求量不高，但是邏輯很複雜，則也需要通過效能測試。原因是，在分散式方式的呼叫中，當某一個環節響應較慢，就會影響到其它環節，造成雪崩效應。
- 運營推廣活動：
根據運營的推廣計劃來判定待測系統未來的壓力。未雨綢繆、防患於未然、降低運營風險是效能測試的主要目標。被測系統的效能不僅能滿足當前壓力，更需要滿足未來一定時間段內的壓力。因此，事先了解運營推廣計劃，對效能點的制定有很大的作用。例如，運營計劃做活動，要求系統每天能支撐多少 PV、多少 UV，或者一個季度後，需要能支撐多大的訪問量等等資料。當新專案（或功能點）屬於運營重點推廣計劃範疇之內，則該專案（或功能點）也需要做效能測試。
以上 4 點，是相輔相成、環環相扣的。在實際工作中應該具體問題具體分析。例如，當一個功能點不滿足以上 4 點，但又屬於資源高消耗（記憶體、CPU），也可列入效能測試點行列。
5、確定效能指標：
效能需求分析一個很重要的目標就是需要確定後期效能分析用的效能指標，效能指標有很多，可以根據具體專案選取和設定，而具體的指標值則需要根據業務特點進行設定，本文不詳細進行闡述，後續可考慮就此單獨寫一篇。
二、效能測試準備
1、測試環境準備：
a）系統執行環境：這個通常就是我們的測試環境，有些時候需求比較多，做效能測試擔心把環境搞跨了影響其它的功能測試，可能需要重新搭建一套專門用來做效能測試的環境。
b）執行機環境：這個就是用來生成負載的執行機，通常需要在物理機上執行，而物理機又是稀缺資源，所以我們每次做效能測試都需要提前準備好執行機環境。
2、測試場景設計：根據效能需求分析來設計符合使用者使用習慣的場景，場景設計的好不好直接影響到效能測試的效果。
3、效能工具準備：
a）負載工具：根據需求分析和系統特點選擇合適的負載工具，比如LR、Jmeter或galting等
b）監控工具：準備效能測試時的伺服器資源、JVM、資料庫監控工具，以便進行後續的效能測試分析與調優。
4、測試指令碼準備：如果效能測試工具不能滿足被測系統的要求或只能滿足部分要求時，需要我們自己開發指令碼配合工具進行效能測試。
5、測試資料準備：
a）負載測試資料：併發測試時需要多少資料？比如登入場景？
b）DB資料量大小：為了儘量符合生產場景，需要模擬線上大量資料情況，那麼要往資料庫裡提前插入一定的資料量。這可能需要花費一些時間，特點是關聯絡統較多，邏輯複雜的業務可能同時涉及多張表。
6、其它：如果需要其它其它關聯絡統或專業人士如DBA配合的，也需要提前進行溝通。
三、效能測試執行
1、人工邊執行邊分析
通常我們做效能測試都是人工執行並隨時觀察系統執行的情況、資源的使用率等指標。效能測試的吸引力之一就在於它的不可預知性。當我們在做效能測試的時候遇到跟預期不符的情況很正常，這個時候需要冷靜的分析。但這個過程可能會很慢長，需要不斷的調整系統配置或程式程式碼來定位問題，耗時耗人力。特別是在當前敏捷開發模式比較流行的大環境下，版本釋出非常頻繁且版本週期短（通常1~2週一個版本），沒有那麼長的時間來做效能測試。
2、無人值守執行效能測試
無人值守是最理想化的目標，目前我們也朝著這個方向努力。無人值守不是說沒有人力介入，而是把人為的分析和執行過程分離，執行過程只是機器服從指令的執行而已。通常測試環境在白天比較繁忙，出現效能問題及定位難度較大且會影響功能測試。所以一般效能測試最好在晚上或週末進行，在相對較安靜的條件有利於測試結果的穩定性。這種方法也相對比較適合敏捷的模式，不需要人工一直守著。只需要在拿到結果後進行分析就好了。同進，這種方式對測試人員能力的要求比較高，需要我們能進行自動化的收集各種監控資料、生成報表便於後續分析。
四、結果分析與調優
關於效能分析與調優這是一個比較大的話題，後續會單獨進行總結和分析。
五、測試報告與總結
效能測試報告是效能測試的里程碑，通過報告能展示出效能測試的最終成果，展示系統效能是否符合需求，是否有效能隱患。效能測試報告中需要闡明效能測試目標、效能測試環境、效能測試資料構造規則、效能測試策略、效能測試結果、效能測試調優說明、效能測試過程中遇到的問題和解決辦法等。
效能測試工程師完成該次效能測試後，需要將測試結果進行備案，並做為下次效能測試的基線標準，具體包括效能測試結果資料、效能測試瓶頸和調優方案等。同時需要將測試過程中遇到的問題，包括程式碼瓶頸、配置項問題、資料問題和溝通問題，以及解決辦法或解決方案，進行知識沉澱。