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

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

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

一、剖析被測系統(tǒng)

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

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

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

二、選取性能測試點

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

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

(2)并發(fā)量較高的業(yè)務模塊;

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

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

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

然后根據(jù)不同類型的系統(tǒng)應用，選取的原則也可以進一步細分。

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

(1)依據(jù)業(yè)務數(shù)據(jù)統(tǒng)計中幾種典型業(yè)務的用戶使用數(shù)比例:

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

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

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

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

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

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

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

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

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

(6)緩存，如對文件系統(tǒng)緩存和數(shù)據(jù)庫緩存的利用等;

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

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

(1) 數(shù)據(jù)庫讀寫混合業(yè)務模塊;

(2) 數(shù)據(jù)庫之間數(shù)據(jù)同步

(3) SQL語句;

(4) 數(shù)據(jù)規(guī)模4

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

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

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

三、量化測試目標

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

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

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

分析建模過程如下:

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

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

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

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

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

重新建模如下:

（1）注冊用戶數(shù)為25萬不變

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

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

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

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

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

注意

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

提示

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