在之前的文章中，我都提到過QPS計算的兩種公式，今天特意來研究一下在固定線程模型下，兩種統計公式誤差問題。
QPS = 總請求量除以總時間，以下：
QPS = count(r)/T
QPS = 線程數除以平均響應時間
QPS = thread/rt
計算模型
如圖所示，這是單個線程單個請求的耗時簡易模型，分成三部分：請求前（對應before）、請求與響應（對應request and response）和請求後（對應after）。其中T代表三個部分的總時間，rt代表了請求與響應的時間。
誤差來源
理論誤差
這部分誤差來源其實就是before和after兩部分。不同於FunTester測試框架中的before()與after()方法。這裏代表的是每次請求之前和請求之後進行的各種處理。
請求前的時間消耗在性能測試中，經常會進行請求前的數據引入、參數處理和請求設置等等。舉個例子：在請求之前要拼裝URL，獲取字符型和數字型參數（可能是隨機參數亦或從配置中獲取），組裝成請求對象HttpRequestBase等等。這些都需要時間，但是很短。耗時比較長的有可能是讀取MySQL、巨量的數據、加鎖的數據和參數運算等。
在請求後的時間消耗，大多數都是請求結果的解析和響應，例如測試工具和框架的基本驗證，用戶自己編寫的各類斷言，解析數據賦值變量等等。其中工作中常遇到的使用正則表達式和其他腳本引擎（即使用SDK）進行響應解析會消耗比較長的時間。可以參考文章：JMeter吞吐量誤差分析中的例子。
在利用微基準測試修正壓測結果中，遇到一種參數簽名導致消耗時間過長，導致測試結果誤差偏大，必需要進行空轉的基準測試修正壓測結果。
實際誤差
這類誤差來源是我根據經驗劃分的，是一些通用的理論上影響不大，或者在實際工作中發現脫離理論之外的情況。就如上圖請求計算模型中所示，這其實也是一種理想化模型。
下面是我總結的一些來源：
日誌打印
這個日誌打印包括了正常日誌和測試中文件讀寫。
由於性能測試數據量比較大，如果不加以區分和過濾，直接將所有日誌都輸出到文件中，那麼必然會導致整個測試用例執行過程中的較大誤差。之前經常能夠看到有粉絲提問如果處理JMeter的測試日誌中的數據。這些文件往往不只是幾百M，而是以G爲單位。試問，如果是串行日誌輸出，那麼單單寫入這些日誌的時間消耗就必需進行數據的修正了。
在實際測試中，很多人並不會在意JMeter等工具的系統日誌，因爲實在太多了。而是會通過使用某個元器件（假設存在這個功能）或者工具的API進行個性化的日誌輸出。比如我之前寫過的：用Groovy處理JMeter斷言和日誌中使用Groovy腳本引擎獨立個性化處理日誌和用Groovy記錄JMeter請求和響應中根據響應結果分別記錄異常的請求的功能。如果數據量比較小，消耗基本都在微秒級別，但是一旦發生以外情況，需要大量的數據記錄時，又會回到日誌記錄相同的問題，影響測試結果。
數據實時處理
在部分的測試框架和測試工具中，測試中的數據是會實時展示的，包括常用的QPS、rt、95%、total等指標，還會監控服務端的各項指標。包括將這些指標計算繪圖等等操作，都是非常耗時的，而且消耗更多硬件資源，不利於測試準確性的提高。大部分工具卡死都是因爲在GUI執行測試用例的時候，各種實時數據處理佔用過多硬件資源導致的，實不可取。目前我一直採用數據的後處理，既在測試完成之後進行數據的統計和分析。
-
未完待續……
FunTester，騰訊雲年度作者、Boss直聘簽約作者，GDevOps官方合作媒體，非著名測試開發er。
-
2021年自動化測試流行趨勢【譯】 -
Appium 2.0速覽 -
FunTester測試框架架構圖初探 -
FunTester測試項目架構圖初探 -
單鏈路性能測試實踐 -
自動化策略六步走 -
性能測試框架中QPS取樣器實現 -
鏈路壓測中的支路問題初探 -
不要浪費自己的求知慾 -
利用微基準測試修正壓測結果
本文分享自微信公衆號 - FunTester（NuclearTester）。
如有侵權，請聯繫 [email protected] 刪除。
本文參與“OSC源創計劃”，歡迎正在閱讀的你也加入，一起分享。