性能測試最開始的需求分析工作細致與否，與后面的性能測試結果息息相關。需求分析是一個繁雜的過程，它并非我們想象的那么簡單。做需求分析除了要對系統的業務非常了解，還需要有深厚的性能測試知識，這樣才能夠挖掘分析出真正的性能測試需求。

很多時候，性能測試的需求是比較模糊的，需要性能測試工程師去挖掘和分析。在工作中，作者經常被問到的一個問題是: 應該設置多少個JMeter線程去壓測? 還有不懂技術的客戶提出想要做性能測試，但是沒有提供指標，只說系統支持100萬用戶。這些都是我們日常工作中司空見慣的泛泛的需求

此時，我們可以通過“3步法”對產品進行正確的需求分析和用戶模型建立。

一、剖析被測系統

(1) 了解系統架構。首先我們需要與開發人員溝通，了解清楚系統的部署架構采用了哪些中間件、數據庫、容器、緩存等，以及它們之間的架構關系，并畫出對應的網絡拓撲圖和系統部署架構圖

(2) 了解業務模型。首先我們需要采用用戶行為分析，分析用戶使用產品的習慣，確定系統的典型業務及發生時間。很多大型系統的業務使用都有流量高峰。這類系統業務使用的流量高峰可能出現在天、一月、一年中的某個時間點上或時間段內。對于新浪、網易等門戶網站，在周一到周五的早上剛上班時，可能使用郵件系統的用戶比較多，而在中午休息時間瀏覽熱點新聞的用戶較多;對于一般的OA系統，早上閱讀公告的用戶較多，在其他時間可能沒有用戶使用系統或者僅有少量的用戶，比如秘書或領導使用系統起草和審批公文;對于電信繳費系統，在月末很可能會出現用戶集中使用繳費業務的情況。

然后是調研歷史統計數據，通過分析數據確定熱點模塊。如果產品已上線，可以統計和分析線上歷史數據。對于web類產品，我們可以獲取和分析獨立用戶數、頁面訪問量和最大在線用戶數;對于后臺類產品，則可以分析如Nginx的Access log，從而得出最大的訪問量對于數據庫類產品，我們還可以分析出熱點SQL等。如果產品未上線有同類產品參考，可以參考公司內同類產品或者同行的同類產品進行熱點模塊預估，雖然不能完全照搬，但可以根據業務增長數據進行統計分析，輸出用戶訪問熱點軌跡圖。

二、選取性能測試點

選取性能測試點是性能測試需求分析中非常重要的一個環節。面對一個功能繁雜的系統，要設計出有效的測試場景，最大程度上覆蓋系統的性能問題和瓶頸，需要較多的經驗積累。目前我們可以按照以下原則來進行性能測試點的選取:

(1)核心業務模塊，例如支付業務、核心算法;

(2)并發量較高的業務模塊;

(3) 邏輯較復雜的業務模塊

(4) 有復雜數據庫操作或事務的模塊;

(5) 有較頻繁的磁盤讀寫操作的模塊

然后根據不同類型的系統應用，選取的原則也可以進一步細分。

對于Web應用，其性能測試點的選取原則為:

(1)依據業務數據統計中幾種典型業務的用戶使用數比例:

(2) 調用頻繁、占用空間大的數據庫表的交易，

(3) 占用最大存儲空間或其他資源的交易;

(4) 對磁盤、常駐內存的數據過度訪問的交易

對于后臺類應用，其性能測試點的選取原則為:

(1) 讀 (查詢)、寫 (增刪改) 、讀寫 (增刪改查) 合的業務模塊;

(2)配置服務器的業務模塊；

(3)功能的實現方式，如同步和異步，輪詢和notify等:

(4) 分布式業務模塊，如單客戶端和多客戶端，單節點和多節點；

(5) 數據規模，如數據庫已存在大量記錄，存儲可用空間少:

(6)緩存，如對文件系統緩存和數據庫緩存的利用等;

(7)負載均衡，如多節點情況下是否負載均衡。

對于分布式數據庫，其性能測試點的選取原則為:

(1) 數據庫讀寫混合業務模塊;

(2) 數據庫之間數據同步

(3) SQL語句;

(4) 數據規模4

比外，當系統應用包含長連接消息服務時，其性能測試點的選取原則為:

(1)單機能支撐的最大并發長連接數;

(2)并發一定數量的用戶時的消息推送情況，包括消息到達時間、消息丟失率等

三、量化測試目標

梳理出來性能測試場景后，就需要進一步明確各個場景的測試指標，而大部分的產品經理給出的指標是不完整的，通常情況下可以結合采集的數據和二八定律進行具體量化，讓性能測試指標更明確。

下面舉個例子來說明性能測試指標量化方法。

例如，某互聯應用，預計推廣群體達500萬人，用戶使用應用的時間是每天早上8點至晚上8點，共12h。

分析建模過程如下:

（1）注冊用戶轉化率預估為5%，那么注冊用戶數為5000000x5%=250000

（2）高峰時段 (比如有活動時) 每日在線用戶活躍率預估為10%，那么活躍用戶數為250000x 10%=25000

（3）用戶常用下單到成功觸發20個請求，總請求量為25000x20=500000

（4）利用二八定律計算，得出的吞吐量為500000x0.8/(12x3600x0.2)=46.7個每秒

若是更新需求，如發布新產品，定時搶購優惠活動 (某日10點開始搶購，12點結束，共2h)。

重新建模如下:

（1）注冊用戶數為25萬不變

（2）高峰時段在線用戶在線率預估為20%，那么這2h的在線用戶數為250000x20%=50000

（3）用戶常用下單到成功觸發20個請求，總請求量為50000x20=1000000

（4）利用二八定律計算，得出的吞吐量為1000000x0.8/(2x3600x0.2)=555.6個每秒

由此可見，評估出來的TPS值和需求業務模型息息相關。

在性能測試的前期，通過上述“3步法”整理分析的詳盡程度將直接決定后續性能測試的有效性和準確性。

注意

在評定服務器的性能時，應該結合TPS和并發用戶數，以TPS為主‘并發用戶數為輔來衡量系統的性能。如果必須要并發用戶數來衡量的話，則需要一個前提，那就是交易在多長時間內完成，因此只用并發用戶數來衡量系統的性能沒太大的意義。

提示

• 響應時間：根據國外的資料，一般操作的響應時間為2秒、5秒和8秒，即2秒內為優秀、5秒內為良好、8秒內為可接受；對于其它一些特殊的操作，如上傳、下載，可以依據用戶體驗的情況延長響應時間。
• 二八定律：又稱帕累托效應，例如，一些系統一天中80%的訪問量集中在20%的時間內。