下面分別介紹下每個階段具體需要做什麼：
一、效能需求分析：
效能需求分析是整個效能測試工作開展的基礎，如果連效能的需求都沒弄清楚，後面的效能測試執行其實是沒有任何意義的，而且效能需求分析做的好不好直接影響到效能測試的結果。
一些效能測試人員常犯的錯誤就是測試一開始就直接用工具對系統進行加壓，沒有弄清楚效能測試的目的，稀里糊塗做完了以後也不知道結果是否滿足效能需求。市面上的書籍也大都是直接講效能測試工具如lr，jmeter如何使用，導致很多新手一提到效能測試就直接拿工具來進行錄製回放，使得很多人認為會使用效能測試工具就等於會效能測試了，殊不知工具其實只是效能測試過程中很小的一部分。
在需求分析階段，測試人員需要與專案相關的人員進行溝通，收集各種專案資料，對系統進行分析，建立效能測試資料模型，並將其轉化為可衡量的具體效能指標，確認測試的目標。所以效能測試需求分析過程是繁雜的，需要測試人員有深厚的效能理論知識，除此之外還需要懂一些數學建模的知識來幫助我們建立效能測試模型。
首先，讓我們來看看通過效能需求分析我們需要得出哪些結論或目標：
其次，需求分析階段我們可以從以下幾個方面入手：
1、系統資訊調研：
指對被測試系統進行分析，需要對其有全面的了解和認識，這是我們做好效能測試的前提，而且在後續進行效能分析和調優時將會大有用處，試想如果連系統的架構、協議都不了解，我們如何進行準確的效能測試？如果進行效能分析與調優？
需要分析的系統資訊如下（包括但不僅限於如下這些）：
2、業務資訊調研：
指對被測試的業務進行分析，通過對業務的分析和了解，方便我們後續進行效能測試場景的確定以及效能測試指標的確定。
需要分析的業務資訊如下（包括但不僅限於如下這些）：
3、效能需求評估：
在實施效能測試之前，我們需要對被測系統做相應的評估，主要目的是明確是否需要做效能測試。如果確定需要做效能測試，需要進一步確立效能測試點和指標，明確該測什麼、效能指標是多少，測試通過or不通過的標準？效能指標也會根據情況評估，要求被測系統能滿足將來一定時間段的業務壓力。
判斷是否進行效能測試主要從下面兩個方面進行思考：
系統是公司內部 or 對外？系統使用的人數的多少？如果乙個系統上線後基本沒幾個人使用，無論系統多大，設計多麼複雜，併發性的效能測試都是沒必要的，前期可以否決。當然，除非在功能測試階段發現非常明顯的效能問題，使得使用者體驗較差的，此時可進行效能測試來排查問題。
a）系統架構：
如果乙個系統採用的框架是老的系統框架（通常大公司都有自己的統一框架），只是在此框架上增加一些應用，其實是沒有必要做效能測試，因為老框架的使用肯定是經過了驗證的。如果乙個系統採用的是一種新的框架，可以考慮做效能測試。
b）資料庫要求：
很多情況下，效能測試是大資料量的併發訪問、修改資料庫，而瓶頸在於連線資料庫池的數量，而非資料庫本身的負載、吞吐能力。這時，可以結合dba的建議，來決定是否來做效能測試。
c）系統特殊要求：
從實時性角度來分析，某些系統對響應時間要求比較，比如**系統，系統的快慢直接影響客戶的收益，這種情況就有作併發測試的必要，在大併發量的場景下，檢視這個功能的響應時間。
4、確定效能測試點：
在上面第3點中，我們簡單分析了如何確定乙個系統是否需要做效能測試。下面簡單總結下如果乙個系統確定要做效能測試，我們如何確定被測系統的效能測試點？
我們可以從下面幾個方面進行分析：
以上 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、無人值守執行效能測試
無人值守是最理想化的目標，目前我們也朝著這個方向努力。無人值守不是說沒有人力介入，而是把人為的分析和執行過程分離，執行過程只是機器服從指令的執行而已。通常測試環境在白天比較繁忙，出現效能問題及定位難度較大且會影響功能測試。所以一般效能測試最好在晚上或週末進行，在相對較安靜的條件有利於測試結果的穩定性。這種方法也相對比較適合敏捷的模式，不需要人工一直守著。只需要在拿到結果後進行分析就好了。同進，這種方式對測試人員能力的要求比較高，需要我們能進行自動化的收集各種監控資料、生成報表便於後續分析。
四、結果分析與調優
關於效能分析與調優這是乙個比較大的話題，後續會單獨進行總結和分析。
五、測試報告與總結
效能測試報告是效能測試的里程碑，通過報告能展示出效能測試的最終成果，展示系統效能是否符合需求，是否有效能隱患。效能測試報告中需要闡明效能測試目標、效能測試環境、效能測試資料構造規則、效能測試策略、效能測試結果、效能測試調優說明、效能測試過程中遇到的問題和解決辦法等。
效能測試工程師完成該次效能測試後，需要將測試結果進行備案，並做為下次效能測試的基線標準，具體包括效能測試結果資料、效能測試瓶頸和調優方案等。同時需要將測試過程中遇到的問題，包括**瓶頸、配置項問題、資料問題和溝通問題，以及解決辦法或解決方案，進行知識沉澱。
效能測試之二 常用的效能測試策略
效能測試的常用策略有 1 基準測試 單使用者測試需要開啟控制台，獲取analysis結果 2 併發測試 併發測試是嚴格的測試，考查aut承受瞬時壓力的能力 3 綜合場景測試 通過對系統結構和功能的分析，對使用者的分布和使用頻率的分析，來構造系統綜合場景的測試模型，模擬不同的使用者執行不同的操作 4 ...
NMS 效能測試方案 二
1 概述 1.1 被測物件概述 終端管理系統 以下簡稱 定位於業務管理系統，主要管理帳號 密碼 vlan virtual local area network ip等。系統提供了整套管理wlan wireless local area network 裝置的解決方案，實現對ac ap control...
Android 效能測試初探（二）
書接前文 android 效能測試初探 一 上回大體介紹了下在 android 端的效能測試項，現在我們就細節測試項做一些闡述 包括如何自己 diy 測試 首先我們來說說啟動時間。關於應用的啟動時間的測試，分為三類 1.首次啟動 應用首次啟動所花費的時間 2.非首次啟動 應用非首次啟動所花費的時間 ...