性能測試點的選取
* 發生頻率非常高的（例如：某郵箱核心業務系統中的登錄、收發郵件等業務，它們在每天的業務總量中占到90%以上）
* 關鍵程度非常高的（產品經理認為絕對不能出現問題的，如登錄等）
* 資源占用非常嚴重的（導致磁盤I/O非常大的，例如某個業務進行結果提交時需要向數十個表存取數據，或者一個查詢提交請求時會檢索出大量的數據記錄）
對性能需求點的描述
准確
如系統必須在不超過 10 秒的響應時間內,處理 20 起登錄任務。再如發郵件時間最大不超過5秒以及平均時間在2秒以內。
一致
用戶和性能測試工程師對有關術語的理解要一致,如:並發用戶數、在線用戶數、注冊用戶數:
特定
性能測試的需求一定是有條件的。
檢查系統后台關鍵業務數據10G、操作數據量為20K, 1500 個用戶、500 個並發用戶運行的負載下，連續運行12小時過程中,業務操作是否滿足性能需求。
常見性能需求
1、響應速度-比如：API請求的平均響應時間應低於1s, WEB首頁打開速度5s以下，web登陸速度 15s以下。
2、服務支持50萬個在線用戶
3、某接口支持200個用戶同時調用（平均3秒調用一次）
3、計費請求成功率達到99.999%以上。
4、在100個並發用戶的高峰期，郵箱的基本功能，處理能力至少達到10TPS
5、系統能在高於實際系統運行壓力1倍的情況下，穩定的運行12小時
6、這個系統能否支撐200萬的vu（每天登錄系統的人次） vu----Virtual user(虛擬用戶)
"不成文"的性能需求指標：
響應時間：根據國外的一些資料，一般操作的響應時間為2，5，8秒，2秒內優秀，5秒內良好，8秒內可接受，其它一些特殊的操作，如上傳，下載可以依據用戶體驗的情況，延長響應時間。
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封
集中發送的時間：24*20%=4.8小時=17280秒
每秒發送郵件數：2880000/17280=166.7封/秒
方式二，根據 某某郵箱業務模型表，每天忙時集中郵件系數0.15，郵件平均峰值系數2,則：
峰值郵件量=3600000*0.15*2/3600=300封/秒
注：忙時集中系數=忙時業務量/全天業務量
在兩種方式的分析中，方法二得出的結果是方法一的將近一倍，我們不要根據經驗理所當然的去分析，要深入的了解系統，我們要對行業指標及計算方式。如果按照第一種方式，性能測試達標了，但系統真正上線后可能遠遠超出了我們的評估。2008年北京奧運運門票系統就是一個典型的案例。
再來分析系統的登錄：
去年全年處理“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
----------------------
上面的小案例算是拋出的一塊磚，需求開發難度要遠遠大於需求管理，在實際工作中常常需要我們為客戶開發這部分性能需求。所以，在追求技術的基礎上，請更多的了解分析你的項目及行業指標。