軟件性能測試（連載4）

• 2020 年 2 月 19 日
• 筆記

1.7 性能測試的判斷標準

對於功能測試，判斷測試用例是否測試通過，往往是比較容易的，只要不發生錯誤並且滿足用戶的需求即可。而對於性能測試該如何來評判性能測試是否通過呢？可以考慮以下三個方面。

•根據用戶需求來判斷。

如果用戶對性能有明確的需求，比如登錄操作，不得小於3秒，那麼測試工程師就可以就這個需求來進行測試。另外系統運行過程不發生內存溢出、死鎖等故障也應該屬於隱性的性能需求。

•根據業內標準來判斷。

比如第1.4-1節提到的2/5/10法則，前端響應時間不得超過全部響應時間的30%等都是業內不成文的性能標準。

•根據基準測試結果來判斷。

一般而言，本次測試的度量指標不得小於上次版本的95%以下。

1.8性能測試的場景

一般根據性能測試的類型及各個類型的組合來設計性能場景，常見的性能測試場景如下。

•普通測試場景。

•並發測試場景。

•容量測試場景。

•疲勞測試場景。

•強度測試場景。

•配置測試場景。

•並發+疲勞場景。

一般採用65%-75%的並發峰值，持續測試48小時。

•容量+疲勞場景。

一般採用65%-75%的容量峰值，持續測試48小時。

•容量+並發+疲勞場景

65%的並發峰值，65%的容量峰值，持續測試48小時。

•多業務測試場景。

有多個業務組合形成的測試場景，一般將前面的性能場景測試完畢以後再進行，否則發生問題難於定位。

1.9 性能測試的干係人

由於各種原因都可能造成性能問題，所以性能測試干係人包括。

•客戶代表。

•產品經理。

•銷售人員。

•市場人員。

•項目經理。

•研發人員。

包括需求分析師、架構設計師、開發工程師、測試工程師等。

•運維人員。

包括DBA、技術支持工程師等。

1.10 負載測試的二分法找拐點法

負載測試包括並發測試和容量測試，尋找性能拐點往往是這種測試的關鍵。以往尋找拐點往往採取遞進法，即給出一個起點，比如500個並發用戶，進行並發測試，如果通過，再加100，變成600個並發用戶，進行並發測試。通過這樣的方法進行層層遞進來尋找拐點。可以想像一下，如果並發拐點為3000，豈不需要測試25次才可找到拐點。這裡來介紹二分法找拐點的方法。

二分法找拐點的方法請參看圖3-17所示。

圖3-17 二分法找拐點的方法

（1）尋找m,n兩個值，其中m<n,建議初始的時候m與n之間的差距拉得大一些。

（2）對m進行並發/容量測試。

（3）如果m測試不通過，說明拐點比m小，尋找新的m值a，假設以前測試過的最小值為x（如果沒有，令x=0）。那麼a=( m + x)/2，返回第（1）步。

（4）如果m測試通過，說明拐點比m大，對n進行並發/容量測試。

（5）如果n測試通過，說明拐點比m大比n小，選擇新的n值a，a=(m+n)/2，返回第（1）步。

（6）如果n測試不通過，說明拐點比n大，尋找新的n值b，假設以前測試過的最大值為y（如果沒有，令y=∞）。那麼a=( n + y)/2，返回第（1）步。

（7）當n-m<=某一固定的值，當前值即為拐點值，遞歸結束。

案例3-10：負載測試的二分法找拐點法

使用二分法測試尋找並發測試的拐點，如果n-m<50，即為找到拐點。

（1）令m=1000, n=5000，對1000進行並發測試，持續10分鐘，沒有發現異常，測試通過，說明拐點比1000大。

（2）對5000進行並發測試，持續10分鐘，發現異常，測試失敗，說明拐點比5000小。此時n-m=5000-1000=4000>50。

（3）選擇新的n=(1000+5000)/2=3000，此時n-m=5000-3000=2000>50，對3000進行並發測試，持續10分鐘，發現異常，測試失敗，說明拐點比1000大但比3000小。

（4）選擇新的m=(1000+3000)/2=2000，此時n-m=3000-2000=1000>50，對2000進行並發測試，持續10分鐘，沒有發現異常，測試通過，說明拐點比2000大但比3000小。

（5）選擇新的m=(2000+3000)/2=2500，此時n-m=3000-2500=500>50，對2500進行並發測試，持續10分鐘，沒有發現異常，測試通過，說明拐點比2500大但比3000小。

（6）選擇新的m=(2500+3000)/2=2750，此時n-m=3000-2750=250>50。對2750進行並發測試，持續10分鐘，沒有發現異常，測試通過，說明拐點比2750大但比3000小。

（7）選擇新的m=(2750+3000)/2=2875，此時n-m=3000-2875=125>50。對2875進行並發測試，持續10分鐘，沒有發現異常，測試通過，說明拐點比2875大但比3000小。

（8）選擇新的m=(2875+3000)/2=2938，此時n-m=3000-2938=62>50。對2938進行並發測試，持續10分鐘，沒有發現異常，測試通過，說明拐點比2938大但比3000小。

（9）選擇新的m=(2938+3000)/2=2969，此時n-m=3000-2969=31<50，所以認為並發拐點為2938。

這樣僅對8個數值進行了測試就找到了拐點。

另外需要說明的是並發測試的拐點沒有容量測試那麼明顯，所以在找到拐點之後，需要對這個值進行多次驗證，確保是真正的拐點。而容量測試的拐點往往表現特別明顯，拐點上與拐點下的性能表現得很明顯。

1.11 全鏈路壓測

正如第1.2-3節描述，2018年雙11，淘寶「退貨退款」模塊癱瘓。對於「退貨退款」模塊往往是一個被忽視的性能測試模塊，但是自從這個事故發生之後。各大互聯網公司對全鏈路壓測試得到了非常重視。京東、淘寶、騰訊等網商企業現在都在雙11到來之前至少半年就開始籌劃全鏈路壓測了。全鏈路壓測往往在晚上00:00-5:00在線進行測試，但是也要看公司具體而定。由於LoadRunner是通過並發用戶的License收費的，並且收費是相當昂貴的。而JMeter是一個基於Java多線程來實現虛擬用戶的開源工具，自身就佔用很多的系統資源，所以也被排除。而現在作為全鏈路壓測工具基本上選用Gatling。

Gatling是一個開源的基於Scala、Akka、Netty 實現的高性能壓測框架，較之其他基於線程實現的壓測框架，Gatling 基於AKKA Actor 模型實現，請求由事件驅動，在系統資源消耗上低於其他壓測框架（如內存、連接池等），使得單台壓測機可以模擬更多的用戶。

另外由於全鏈路壓測是在線上進行的，所以要確保測試數據與真實數據分離，在全鏈路壓測完畢，需要把壓測數據全部刪除。