目錄結構

一、效能測試需求分析與定義
    1.效能需求關注的常規量化指標項
    2.分析確定業務測試點，提取效能指標的策略
二、效能指標分析與定義
    1.併發數
    2.響應時間
    3.吞吐量
    4.系統資源耗用
    5.業務成功率
    6.TPS
三、綜合分析：測試需求&指標分析

一、效能測試需求分析與定義

通過前文效能測試需求分析對效能測試的必要性評估之後，敏捷開發團隊確定利用開源工具JMeter實施效能測試工作。根據被測物件的應用特性，首先需要獲取具體的效能測試需求。

1.效能需求關注的常規量化指標項

一般而言，被測物件的效能需求，會在使用者SRS（需求規格說明書）中給出，如：單位時間內的訪問量需達到多少、業務響應時間不超過多少、業務成功率不低於多少、硬體資源耗用要在一個合理的範圍中，效能指標以量化形式給出。

對於相對規範的產品，產品團隊一般會給出相對明確量化的效能測試要求，如下表所示：

可以看出，上表給出的效能指標比較明確。效能測試活動實施過程中，測試工程師只需收集隨機購買商品的 [響應時間、訪問成功率、併發數、CPU使用率、記憶體使用率] 等相關指標的監測資料，與表中的量化指標比對即可。滿足相關指標，則測試通過；若未滿足，則需要進行問題分析定位，最終進行調優與迴歸，直至達到效能測試需求。

2.分析確定業務測試點，提取效能指標的策略

在有明確性能需求時，測試活動相對來說較為容易開展，但實際工作中，經常會碰到沒有明確的效能需求

的測試要求。因此，測試工程師需要具備根據不同輸入（業務使用者視角、終端使用者調研、專案團隊視角、運營團隊視角、公司未來發展視角）分析，獲取效能需求的能力。

以本次專案為例，產品團隊並未指明效能測試需求，那麼測試工程師如何分析提取量化的效能指標呢？
從使用者應用角度考慮，若被測物件常用的業務的效能存在瓶頸，則很可能引起客戶的反感。以登入功能為例，輸入使用者名稱和密碼，點選登入按鈕到顯示成功登入資訊，若耗時1min，使用者絕對無法忍受。使用者不常用的功能，如年度報表彙總功能，一個季度甚至是一年才使用一次，等幾分鐘or更長時間也有可能被接受。

So，不同的應用頻率，決定了使用者的使用感受，也決定了測試的需求。

針對本次ECShop電商系統而言，商城使用者經常使用的功能，且存在大量使用者使用的業務有：使用者註冊、登入、隨機瀏覽商品、購買業務等，而其他功能則相對使用者較少。若電商系統已經正式運營，則可從系統運營日誌中分析具體的資料。若尚未上線運營，則需要調研使用者or根據自身經驗進行分析獲取。
根據[JPT_01]效能測試需求分析中的描述，分析哪些是使用者常用or交易佔比超過80%的業務；從運營及專案組角度分析，哪些業務相對重要，然後確定為業務測試點。

綜合分析，本次專案實踐以使用者登入、隨機瀏覽併購買商品為測試點。確定業務測試點後，即可進行詳細的業務需求分析，從而明確性能測試指標。

二、效能指標分析與定義

通常情況下，效能測試關注被測物件的時間特性、資源利用特性、穩定性。

• 時間特性：被測物件實現業務交易過程中所需的處理時間。從使用者角度來說，越短越好
• 資源利用特性：被測物件的系統資源佔用情況。一般Web系統不關注客戶端的資源佔用情況，僅關注伺服器端，①通常為 服務端 的CPU、記憶體、網路頻寬、磁碟等。根據被測物件架構設計，②還可分為 Web伺服器、中介軟體、資料庫、負載均衡...
• 穩定性：關注被測物件在一定負載情況下，持續穩定提供服務的能力

不同的被測物件，不同的業務需求，可能有不同的指標需求，但大多數測試需求中都包含以下幾種效能指標：

1.併發數

併發數：①廣義而言，是單位時間內同時傳送給伺服器的業務請求數，不限定具體業務型別；②狹義而言，是單位時間內同時傳送給伺服器的相同的業務請求數，需限定具體的業務型別。（在效能測試過程中需要區分二者）

• 服務端視角
  併發，即同時出發，從應用系統架構層面來看，併發數為單位時間內服務端接收到的請求數。

• 客戶端視角
  客戶端的某個具體業務行為包括多個請求，併發數可被抽象理解為客戶端單位時間內傳送給伺服器端的請求數。

• 使用者行為視角
  客戶端的業務請求一般為使用者操作行為，併發數也可理解為併發使用者數，而這些使用者是虛擬的，又可稱為虛擬使用者數。

2.響應時間

目前，大多數軟體系統客戶端與伺服器互動的過程，如下：

• 系統視角
  在整個處理流程中，系統的響應時間：T_s = t1+t2+t3。該時間沒有包括客戶端對資料處理並呈現的時間t4。
• 使用者視角
  從使用者角度看，使用者通過客戶端發出業務請求，到客戶端展現相應的請求結果，這個過程的時間越短越好。此時使用者視角的響應時間：T_u = t1+t2+t3+t4。
• 伺服器視角
  從伺服器角度看，伺服器接收到客戶端傳送的請求，並給出結果的響應，這個過程所消耗的時間，記錄為響應時間，即伺服器僅關注t2的處理時間。

因此，不同的視角，衡量的響應時間指標也各不相同。實際測試過程中，需明確以什麼視角驗證被測物件的效能。
大多數情況下，效能測試響應時間主要以客戶端發出請求，直至接收到服務端的響應資料過程中所消耗的時間作為參考。

嚴格來講：響應時間=呈現時間+網路傳輸時間+伺服器端響應時間+應用延時時間

Tips：
不建議嘗試在公網進行效能測試，原因如下：
①可能影響現網使用者。實施效能測試過程中，可能產生大量壓力與垃圾資料，從而破壞生產環境，導致缺陷的產生，影響實際的業務。
②壓力模擬可能無法體現真實場景。實施效能測試時，利用壓測工具模擬大併發數，會產生大量業務資料。因負載生成器與伺服器所在的網路不同，or伺服器特定的網路安全設定，導致壓力資料無法達到被測伺服器，整個網路環境不可控，從而導致測試失敗。
有一種情況除外，模擬固定頻寬網路訪問的場景，可在區域網中使用限制頻寬的手段進行測試。

總之，需要遵循一個原則：在測試過程中，任何資源都必須可控。

3.吞吐量

吞吐量：單位時間內系統處理使用者請求的數量。吞吐量指標直接體現了軟體系統的業務處理能力，尤其適用於系統架構選型時做對比測試。

衡量方式：

• 請求數 / 單位時間
• 點選數 / 單位時間
• 位元組數 / 單位時間

其中，[位元組數 / 單位時間] 的計算方式，與當前的網路頻寬比較，可找出網路方面的問題。

吞吐量計算：例如1分鐘內系統可以處理1000次轉賬交易，則吞吐量為1000/60=16.7 (次/秒)

4.系統資源耗用

系統資源耗用：客戶端與服務端系統各項硬體資源的耗用情況，如CPU使用率、記憶體使用率、網路頻寬佔用率、磁碟I/0輸入輸出量等。

一個系統的高效執行，除了軟體效能要求外，還需要對硬體資源進行監控。若使用者需求、專案組or其他利益相關方均未提出效能指標要求，則可參考行業經驗，CPU使用率≤80%、記憶體使用率≤80%、網路頻寬佔用≤50% ...

• CPU使用率
  1）當CPU使用率超過80%時，表明CPU應用繁忙，如果持續維持在90%甚至更高，很可能導致機器響應慢、宕機等問題
  2）當CPU使用率過低時，說明CPU比較空閒，可能存在資源浪費的問題

• 記憶體使用率
  對於記憶體，同樣存在類似以上的問題

PS：
80%只是作為一個經驗參考值，最終的效能測試指標需要經過專案相關各方評審才能確定

通過上述業務資料分析，最終得到本次專案測試的效能需求指標，如下：

5.業務成功率

業務成功率：使用者發起了多筆業務請求中，成功筆數所佔的比率。業務成功率展示了在特定壓力or負載情況下，伺服器正確、穩定處理業務請求的能力。

例如，測試銀行營業系統的併發處理效能，有100個網點，上午10:00-11:00的一個小時高峰期裡，要求能支援50000筆開戶業務，其中成功率不低於98%，也就是需要成功開戶49000筆，其他的1000筆可能是超時，或者其他錯誤導致未能開戶成功。

6.TPS

單位時間內伺服器處理的事務數。該指標值越大越好。一般情況下，使用者業務操作過程可能細分為若干個事務，單位時間處理的事務數越多，說明伺服器的處理能力越強。

三、綜合分析：測試需求&指標分析

根據上述各指標，結合被測物件本身的業務情況，進行測試需求及指標分析：

1. ECShop是一個面向廣大網路使用者的電子商務系統，大部分使用者會在某個時間段對平臺訪問、網購。
2. 確定使用者訪問的峰值時間段：若新系統沒有上線，沒有歷史資料可以依據，可通過競品分析，獲取友商系統的運營資料作為參考。
   如業務峰值時間段：15:00-17:00、21:00-23:00，業務峰值期持續2h。若要測試穩定性，則需根據實際業務情況模擬使用者應用場景。

3. 確定在業務峰值時間段完成的業務量：需要統計有多少人在峰值時間段使用ECShop電商系統。
   根據產品團隊的業務規劃、產品設計給出一個參考值，比如系統初期設計規模在單天15w業務量，峰值交易5000筆，最高併發100使用者（如秒殺業務）。

通過對預設業務目標的分析，可得出以下資料：

-峰值持續時間：2h
-單天訪問業務量：15w
-峰值交易筆數：5000
-最高併發數：100

4. 在滿足以上需求的同時，還需要考慮業務的響應時間。被測物件的響應時間，作為一個很直觀的使用者體驗資料，可很好的衡量被測物件是否讓使用者體驗良好，當然還需要把“體驗良好”轉換為量化的指標。

• Apdex聯盟-響應時間經驗值
  響應時間在業內的一個經驗值，採用Apdex聯盟的建議值：3s、3-12s，12s以上。0-3s的業務處理響應時間是非常理想的，而3-12s則是普遍可容忍的時間，但超過12s的響應時間，使用者一般不會接受，可能選擇重新整理，甚至放棄操作。

• “258原則”-響應時間參考值
  1）當用戶能夠在2s以內得到響應時，會感覺系統的響應很快
  2）當用戶在2-5s內得到響應時，會感覺系統的響應速度還可以
  3）當用戶在5-8s內得到響應時，會感覺系統的響應速度很慢，但還可以接受
  4）當用戶在超過8s後仍然無法得到響應時，會感覺系統糟透了，or認為系統已經失去響應，而選擇離開這個Web站點，or發起第二次請求

5. 響應時間還應該根據業務型別確定，而不能僅從使用者的主觀感覺考慮。本次專案測試採用常規的5s為目標，也就是說ECShop平臺處理登入、商品隨機瀏覽購買等業務的伺服器響應時間均不超過5s。

6. 單天15w業務量，表明在一天內的總業務量為15w，但未明確是哪些業務的資料量疊加，還是每項業務都是此要求（假定單項業務每天都有15w的業務量）。
   從上圖 [訪問時間-訪問使用者量] 座標圖中可以看出，使用者訪問並非是均分在24h內。在沒有歷史資料可依據的情況下，可利用經濟學中的“28原則”進行分析，即80%的業務量集中在20%的時間段內完成。而單天峰值時間段共有2個：15:00-17:00、21:00-23:00。

計算業務量的分解資料：

80%的業務量：15w*80% = 12w
20%的時間段：24h*20% = 4.8h
單天峰值時間：2+2 = 4h
全天峰值時間 / 20%時間：4h/4.8h = 83.3%

以15:00-17:00、21:00-23:00為考察時間段，則預期業務量為：
12w*(4h/4.8h) = 10w

以15:00-17:00為考察時間段，則預期業務量為：
12w*(2/4.8) = 5w

綜上，需要測試ECShop電商平臺在2h內支援5w使用者登入、隨機瀏覽商品進行購買的業務。