需求分析是個繁雜過程，它並非我們想象的那麼簡單，而效能測試需求除了要對系統的業務非常了解，還需要有深厚效能測試知識。才能夠挖掘分析出真正的效能需求。
如何獲得有效的需求
1、客戶方提出
客戶方能提出明確的效能需求，說明對方很重視效能測試，這樣的企業一般是金融、電信、銀行、醫療器械等；他們一般對系統的效能要求非常高，對效能也非常了解。提出需求也比較明確。
曾經有乙個銀行專案，已經到最後的效能測試極端，因為資料庫設計不合理，導致效能出現很大的問題，最終不得不把整合專案作廢，對於這樣的專案，其實從分析設計階段就應該考慮系統的效能問題。效能測試也一樣，對於某些專案來說越早進行越好。當然，前期的效能測試為單元效能測試、介面效能測試，有別系統效能測試。
有時候也會碰到不懂裝懂的客戶，提出一些無理的需求，比如只能2000人使用的oa系統，客戶要求併發使用者2000，這顯然是不合理的需求。這個就要看你怎麼給客戶溝通了。但是，千萬別偽造資料欺騙客戶。
2、根據歷史資料分析
對於一些面向使用者的獨特產品，比較難定位市場的大小，可以先上一運營一段時間，通過運營可以蒐集客戶資料，比如，每月、每星期、每天的峰值業務量是多少。使用者以 什麼樣的速度在遞增中。使用者對系統的哪些功能模組使用的最多，他們所點的比例等等。
收集到這些資料之後，我們就可評估系統的系統需求指標，從而進行效能測試。
3、需求分析與定位
這裡根據前期的需求分析與定位，來分析確定系統效能指標。例如某省幼兒園管理系統。統計全省有多少家幼兒園，系統的使用時間為幼兒到校之後，管理人員對幼兒的到校情況進行錄入，以及幼兒的午飯，放學情況的錄入時間。經過與需求人員交流分析也能得到比較明確的效能指標。
4、參考歷史專案或其它同行業的專案
如果公司之前有類似的專案經驗，根據專案大小及上次效能測試的一些指標。從根據專案的規模可以制定出相應的效能指標。
即使本公司沒有類似的專案，但其它公司有類似的專案，例如做iptv或者dvb計費系統的測試，可以參考電信計費系統的需求——雖然不能完全照搬資料，但是可以通過其他行業成熟的需求來了解需要測試的專案有哪些，應該考慮到的情況有哪些種。
5、參考其它資料資料
如果你做的是非常獨特的產品，市場上沒有此型別的產品，而且需求及市場也難以估計，那麼只能從與產品相關的資料中尋找痕跡了。不過，相信這樣不確定性的產品，老闆要承擔的風險也是挺大的。^_^
需要說明的是，我上面介紹的方面並非是獨立的，可以綜合的使用，你可以根據客戶提出的指標，再根據歷史資料以及參考同型別專案來進行。這樣可以更確定你的效能指標是客戶（或自己）真正需要的、最符合專案需求的。
效能測試點的選取
* 發生頻率非常高的（例如：某郵箱核心業務系統中的登入、收發郵件等業務，它們在每天的業務總量中佔到90%以上）
* 關鍵程度非常高的（產品經理認為絕對不能出現問題的，如登入等）
* 資源占用非常嚴重的（導致磁碟i/o非常大的，例如某個業務進行結果提交時需要向數十個表訪問資料，或者乙個查詢提交請求時會檢索出大量的資料記錄）
對效能需求點的描述
準確如**系統必須在不超過 10 秒的響應時間內,處理 20 起登入任務。再如發郵件時間最大不超過5秒以及平均時間在2秒以內。
一致特定
效能測試的需求一定是有條件的。
檢查系統後台關鍵業務資料10g、運算元據量為20k, 1500 個使用者、500 個併發使用者執行的負載下，連續執行12小時過程中,業務操作是否滿足效能需求。
常見效能需求
1、web首頁開啟速度5s以下，web登陸速度 15s以下。
3、計費話單成功率達到99.999%以上。
4、在100個併發使用者的高峰期，郵箱的基本功能，處理能力至少達到10tps
5、系統能在高於實際系統執行壓力1倍的情況下，穩定的執行12小時
6、這個系統能否支撐200萬的vu（每天登入系統的人次） vu----virtual user(虛擬使用者)
"不成文"的效能需求指標：
peter bickford 在調查使用者反應時發現：在連續27次即使反饋之後，第28次操作進，計算機讓使用者等待2分鐘，結果半數人在第8.5秒左右就走開或者按下種啟鍵。使用了滑鼠指標變成漏斗提示的介面會把使用者的等待時間延長到20秒左右，使用動畫的滑鼠指標漏斗提示介面則會讓使用者的等待時間超過1分鐘，而進度條則可以讓使用者等待到最後。peter bickford的調查結果被廣泛用到web軟體系統的效能需求的響應時間定義中。
第三方研究表明，如果網頁是逐步載入的，先出現橫幅，再出現文字，最後出現影象。在這樣的條件下，使用者會忍受更長的等待時間，使用者會把延遲在39秒內的也標識為「good」，超過56秒的才認為是「poor」的。
80/20原則：又稱帕累託效應，比如，某一些系統一天中80%的訪問量集中在20%的時間內。
如何根據效能需求進行測試
其實我們上面得到的需求指標仍然是不明確的：
是驗證當前硬體和軟體配置能否支撐200萬vu？
是測試當前的硬體和軟體配置最多能支撐多少vu?
是幫助開發尋找效能瓶頸？
根據需求進行效能測試的過程：
首先，請你們當前軟體和硬體配置下驗證能否支撐200萬vu。如果可以支撐200萬，再增加到300萬看是否可以支撐。如果不能達到200萬，那麼就需要尋找一下是否有效能瓶頸，將主要的效能瓶頸解決後，再看一下是否可以支撐200萬，如果可以支撐，輸出測試結果。仍然不能，請評估需要新增多少硬體裝置。
通過上面流程的分析，那麼我們對於需求實施過程就非常明確了。
下面看來分析某郵箱系統的需求：
按照 某某 郵箱20000萬註冊使用者，其中日活躍使用者數為1.5%的規模計算：
日活躍使用者=20000*1.5%=300萬
日活躍使用者人均每天發6封郵件，使用者使用客戶端收發郵件比例20%，則：
每天發郵件投遞量=300萬*6*20%=360萬封
如何得到每秒的郵件數？
方式一： 嚴格的根據2/8原則 ，80%的郵件集中在20%的時間傳送。
集中發郵件數： 3600000*80%=28800000封
每秒傳送郵件數：2880000/17280=166.7封/秒
方式二，根據 某某郵箱業務模型表，每天忙時集中郵件係數0.15，郵件平均峰值係數2,則：
峰值郵件量=3600000*0.15*2/3600=300封/秒
注：忙時集中係數=忙時業務量/全天業務量
在兩種方式的分析中，方法二得出的結果是方法一的將近一倍，我們不要根據經驗理所當然的去分析，要深入的了解系統，我們要對行業指標及計算方式。如果按照第一種方式，效能測試達標了，但系統真正上線後可能遠遠超出了我們的評估。2023年北京奧運運門票系統就是乙個典型的案例。
再來分析系統的登入：
去年全年處理「web登入」交易約 100 萬筆，考慮到 3 年後交易量遞增到每年 200萬筆。
假設每年交易量集中在 8 個月，每個月 20 個工作日，每個工作日 8 小時，試採用 80～20 原理估算系統伺服器高峰期「web登入」的交易吞吐量應達到怎樣的乙個處理能力
200萬/8=25萬/月
25萬/20=1.25萬/日
1.25萬*80%/(8*20%*3600)=1.74tps
----------------------
上面的小案例算是丟擲的一塊磚，需求開發難度要遠遠大於需求管理，在實際工作中常常需要我們為客戶開發這部分效能需求。所以，在追求技術的基礎上，請更多的了解分析你的專案及行業指標。
效能測試 效能需求分析
乙個真實的需求 測試某系統切換成https協議之後效能的下降情況 需求分析 1 對比 http https 2 求出http協議下的效能 3 求出https協議下的效能 4 求出兩者的差異 5 確定效能指標 tps 6 測試報告裡體現 tps的變化 測試策略 1 基準測試 1.1http作為基準 1...
效能需求分析
通過技術的手段模擬大量使用者同時訪問被測應用，觀察 記錄和分析系統的各項效能指標的過程。評估系統的效能瓶頸，系統的最大使用者負載能力 1 能夠有效評估系統的效能指標，用於系統的效能評估2 能夠識別系統的效能瓶頸，協助效能調優3 能夠指導突發流量承載方案的制定4 能夠用於系統運維成本的預算 測試 根據...
效能需求分析
效能測試需求應包括以下內容 a 測試場景及用例，用例訪問url b 目標介面方法的入參 出參 c 外部依賴的服務細節 d 關鍵資料 資料量 高峰業務pv量 e 預期效能指標 響應時間 qps tps等 1.2.1資料量 測試環境的資料量，應該跟線上環境保持一致，至少要在乙個數量級。舉例有，中文站線上...