獲取效能需求
01需求一：使用者數資訊
1）調查系統當前和未來使用的使用者數
系統使用者數=本系統目前註冊的使用者數，註冊使用者數並不代表他會每天並且無時無刻的使用著。
線上使用者數=同時線上對系統進行操作的使用者數量（相當於混合場景）
併發使用者數=同時線上並且同時操作同一個功能（單場景新增集合點）
估算未來一到五年使用此使用者的數量，可以根據一些日誌資料估算出來的。
2）調查系統當前和未來的每日、月活躍使用者數
當前活躍使用者數，即某天大概有多少使用者使用本系統：那麼這部分資料一說來也就是當前真正對系統構成壓力的數量。
02需求二：業務資料量
1）調查當前和未來背景資料量
因為從100條資料中查10條也許很快，但是未來資料量變成100w那你懂得...
2）調查當前和未來業務每天使用的總筆數
每個使用者每天可能下多少筆單，平均需要多少次來執行這個操作？那麼根據使用者數，我們就可以確定每天下單的筆數。如50人，平均每人每天下10次，每次下100筆，那麼總筆數就是50*10*100=50000筆。注意此資料根據TPS換算後，我們可以換算出系統的業務總處理量是否能達到這個資料，這也是一個很重要的指標。
3）調查當前和未來高峰時業務的總筆數
即上面所描述的特殊情況，這也是必須要考慮，並且拿到的資料。
03需求三：場景業務的調查
1）系統關鍵、核心的業務
從系統亮點出發，以主要的業務邏輯點為第一核心：這些功能對系統或公司來說往往具有舉足輕重的地位，無論怎樣都必須要優先執行滿足這以功能的效能測試
2）高訪問量的功能，經常承受壓力的功能點
系統中表現在系統關鍵、核心業務前面必須要經過的地方：比如對於百度搜索來說，其核心業務是搜尋功能，但是首先要面對的其高訪問量對是搜尋輸入框載入的首頁，百度首頁載入即高訪問量的請求
3）業務複雜度高
往往說來業務邏輯複雜度的都具備1、2點的要素，可能其功能使用的人數較少但是對系統有很嚴重影響：這些功能由於其業務邏輯具有的複雜度，往往出錯的可能性也比較高，所以這些功能也是必須要進行測試的。
04需求四、與效能指標指標相關的調查
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.載入和退出方式
一般採用緩慢登入的方式，以便觀察當用戶數降低時其伺服器的資源情況。但登入和退出功能除外，更多的登入和退出是集中在一個時間段。
