第一步獲取性能需求
需求一：用戶數信息
1）調查系統當前和未來使用的用戶數
系統用戶數=本系統目前注冊的用戶數，注冊用戶數並不代表他會每天並且無時無刻的使用着。
在線用戶數=同時在線對系統進行操作的用戶數量（相當於混合場景）
並發用戶數=同時在線並且同時操作同一個功能（單場景添加集合點）
估算未來一到五年使用此用戶的數量，可以根據一些日志數據估算出來的。
2）調查系統當前和未來的每日、月活躍用戶數
當前活躍用戶數，即某天大概有多少用戶使用本系統：那么這部分數據一說來也就是當前真正對系統構成壓力的數量。
需求二：業務數據量
1）調查當前和未來背景數據量
因為從100條數據中查10條也許很快，但是未來數據量變成100w那你懂得...
2）調查當前和未來業務每天使用的總筆數
每個用戶每天可能下多少筆單，平均需要多少次來執行這個操作？那么根據用戶數，我們就可以確定每天下單的筆數。如50人，平均每人每天下10次，每次下100筆，那么總筆數就是50*10*100=50000筆。注意此數據根據TPS換算后，我們可以換算出系統的業務總處理量是否能達到這個數據，這也是一個很重要的指標。
3）調查當前和未來高峰時業務的總筆數
即上面所描述的特殊情況，這也是必須要考慮，並且拿到的數據。
需求三：場景業務的調查
1）系統關鍵、核心的業務
從系統亮點出發，以主要的業務邏輯點為第一核心：這些功能對系統或公司來說往往具有舉足輕重的地位，無論怎樣都必須要優先執行滿足這以功能的性能測試
2)高訪問量的功能，經常承受壓力的功能點
系統中表現在系統關鍵、核心業務前面必須要經過的地方：比如對於百度搜索來說，其核心業務是搜索功能，但是首先要面對的其高訪問量對是搜索輸入框加載的首頁，百度首頁加載即高訪問量的請求
3)業務復雜度高
往往說來業務邏輯復雜度的都具備1、2點的要素，可能其功能使用的人數較少但是對系統有很嚴重影響：這些功能由於其業務邏輯具有的復雜度，往往出錯的可能性也比較高，所以這些功能也是必須要進行測試的。
需求四、與性能指標指標相關的調查
1、調查每秒事務數(TPS)
這是衡量系統處理能力的一個重要指標，同時這個指標在一定程序也關系到業務數量是否能夠及時完成，所以需要獲得。
估算方式一：BS類可以參考以下指標估算：Vuser*TRequest/RPS=TPS（注意1Requset的含義為Resource=0的請求）。Resource=0的含義其實就是保證此次請求能夠真正到達服務器，去掉那些本地可以緩存的東西。
估算方式二：CS類可以參考每小時的業務數/3600s，這是沒辦法的辦法。
估算方式三：API類往往要求是Vuser*1API=TPS，由於公司的API都是提供給機構用戶的，所以API要求往往比較高，所以需要保證其遠算得非常快。
注：Vuser：虛擬用戶數；TRequest：事務中的請求數；RPS：平均響應時間。
2、調查90％（或95％）響應時間
只看平均時間是不太科學的，對於我們的系統來說需要保證絕大多數的用戶其響應時間都是非常快的，所以我們從90％或95％用戶響應時間為指標的標准。
如果拿不到，那么我們仍可以估算：
估算方式一．BS類，按通用的標准2一5一8的標准來進行。不同業務，不同客戶類型要求不同，但對於我們的產品來說絕大多數是不能超過5s
估算方式二：CS類，根據處理的數據量其時間不同，但一般說來是不能超過15s的。
估算方式三：API類，從行業的角度來說，一般要求是毫秒級（<500ms)
3、平均響應時間和TPS的波動率
這是對響應時間的補充，要求其系統響應時間應盡量穩定，TPS的波動率受測試方法和思考、間隔時間的影響。可參考以下的計算方式：
T=（TPS標准差/TPS平均值）*100％一般說來小於10％
T= (RPS標准差/RPS平均值）*100％一般說來小於10%
----小知識：測試的分類-------------------
第一類前端性能測試（客戶端）
B/S：HttpWatch、FireBug、YSlow、JS內存泄漏、大數據量下的功能測試、瀏覽器長時間運行的穩定性測試等。
C/S：內存泄漏、CPU使用、顯卡使用等：
網絡性能測試：利用工具分析網絡傳輸以及延時等，為寬帶拓展做鋪墊。
第二類服務器端性能測試
性能測試，是指以性能預期目標為前提，對系統不斷施加壓力，驗證系統在資源可接受范圍內，是否能達到性能預期。（即：系統是否滿足預定的性能目標？）
負載測試，是指對系統不斷地增加壓力或增加一定壓力下的持續時間，直到系統的某項或多項性能指標達到臨界值，例如某種資源已經達到飽和狀態等：（即，最大並發數是多少？在什么時候，響應時間不可接受”系統的服務器資源瓶頸是什么？）
穩定性測試，是指被測試系統在特定硬件、軟件、網絡環境條件下，給系統加載一定業務壓力，使系統運行一段較長時間，以此檢測系統是否穩定，一般穩定性測試時間為n*12小時。（即系統在一般壓力條件下，是否可以提供連接不斷的優質服務？系統在長時間最大壓力條件下，是否崩潰？）
4、測試前環境的檢查收集
環境檢查包括服務器的架構以及部署方案，服務器的配置、中間件的參數配置，以及需求、功能測試報告、API調用方式等。
服務器的配置需要收集生產環境與實測試環境的服務器的配置。主要收集：
CPU：型號、核心、速度、核數、倍頻、總線速度，己耗費平均CPU
內存：總物理內存、所在磁盤的虛擬內存、可用物理內存
磁盤：轉速（如是舊有電腦，在執行前最好磁盤碎片整理一下）
網卡：一般是100Mb，專用網絡可能在1000MB以上。
業務
跟據客戶實際使用情況，划分業務比例：
某個功能在一段時間內的使用頻率：每天使用此功能大概有多少次？在多長時間內會操作此功能？
如設計腳本用例為：登錄>進入單表查詢（70％）>通過目錄導航（80％）>檢索>下載（80％），根據功能的重要性，這個用例應該首先要測試單場景，並且並發數也可能比其它的功能大一些，所以需要設置集合點。
其它業務相對於使用得少一些的則可以將其與上面的用例組合成混合場景：其它場景也可以繼續細分。
思考時間
觀察、推測用戶操作這一個過程的時間
以一個正常用戶使用系統業務的角色，錄制腳本隨機產生，隨后根據實際情況調整其值：在運行場景的時候，以50％至120％的比例隨機使用思考時間
5.持續時間
用戶操作此功能的時間段，采用二八定理，取80％的場景時間：
注意用戶操作此功能時間段，如果是業務類軟件，中午的時間要去掉：
6.加載和退出方式
一般采用緩慢登錄的方式，以便觀察當用戶數降低時其服務器的資源情況。但登錄和退出功能除外，更多的登錄和退出是集中在一個時間段。
下圖展示了如何將整個系統，按照用戶操作業務的比例來構成一個整體的認識，通過功能的比例，我們很容易就可以得出其性能測試需求覆蓋哪些功能
監控方法
由於監控采集記數器也會消耗資源，所以初次測試的時候應盡量把適合的記數器加上，而當判斷某個資源出現情況時需要添加更詳細的記數器，：
建議初次測試的時候監控值
CPU:%ProcessorTime和%PrivilegedTime和ProcessorQueueLength
Memory：AvailableMbytes和PageFaults/Sec
PhysicalDisk：%DiskTime和Avg.DiskQueueLength
監控所有服務器，另外也需要監控壓力機的資源。