技術分享｜To B 複雜系統的性能測試要注意哪些？

**源寶導讀：**To B (To Business)，指面向企業或特定用戶羣體，通常面向企業，比如 ERP。To C(To Customer), 面向最終客戶，主要爲個體消費者，比如各種消費類手機 App。兩者之者的差異導致對性能測試的方法會有所不同。本文將分享 To B 複雜系統的性能測試過程中的技術實踐。

一、背景

To B 的用戶量比 To C 的用戶量要小，所以 To B 在性能測試時，一般爲百人、千人、萬人用戶數，而 To C 併發承載十萬、百萬、千萬、上億的用戶數。

To B 面向專業人士，比如銷售、成本、計劃、費用等系統的業務操作、權限設置會比 To C 要複雜很多。To B 性能測試時，需要着重業務場景和對數據權限的驗證。

To B 一般爲私有化的部署，比如咱們明源雲的客戶，軟硬件環境多種多樣，從單 WEB + 單 DB，到多 WEB + 單 DB、多 WEB + 多 DB，近年來的公有云、私有云、混合雲，再到如今的 K8S 容器化集羣部署，部署差異會導致性能差異，所以 To B 的性能測試需要高度依賴環境。

如下圖 1，To B 的一個完整性能測試方案，應該對業務場景、測試方法、場景設置、監控項、系統設置、部署環境都加以考慮。

圖 1

二、業務場景

To B 的業務場景相對複雜，性能測試場景主要組成部分爲：併發量、數據量、業務操作、數據權限。如下圖 2。

圖 2

首先併發依據子系統和功能模塊的不同，併發量會有所不同，如客服類系統，併發量會較小一般爲百人併發，成本類系統併發量一般爲千人併發，雲端面向客戶類系統併發量要驗證上萬。然後數據量，也就是數據庫的數據容量，是基於業務換算而來，比如銷售系統年銷售萬億規模，那麼轉換成數據庫，需要多少公司、多少項目、多少樓棟、多少房間等等，他們涉及到的表的數據量是多少，這些都需要和產品經理共同參與。

另外 “併發量、數據量、業務操作、數據權限” 這 4 項中“數據權限“最容易被忽視，測試用戶數據權限的分配要從崗位權限、數據類型權限、數據量等去綜合考慮。不同權限用戶前端查到的數據可能差異不大，但崗位權限、數據類型權限判斷時 SQL 運算的笛卡爾積相差會較遠。做數據準備時，最好是參考實際客戶的權限分配模型進行測算。2020 年我們在驗證一個客戶的實際環境中，就出現了不同角色用戶，導致數據權限不一樣，從而影響測試結果響應時間相差近 10 倍的問題。如下圖 3 爲我們統計的某項目組織分佈數據表，並針對性設計了測試方法。

圖 3

二、測試方法

To C 重在驗證接口性能，單點功能，而 To B 依賴複雜的業務流程，測試方法中要結合業務操作流程進行驗證，比如單場景併發性能測試、組合場景併發性能測試、穩定性可靠性容錯性等，如下圖 4。

圖 4

To B 的穩定性可靠性容錯性的驗證，一方面業務場景要覆蓋儘量多的核心業務，二是要考慮不同部署環境的設定。比如穩定性，在模擬結合業務場景的同時，需要監控 WEB 環境、DB 環境、服務環境的 CPU、內存、磁盤的指標在整個壓測過程中是否平穩，不會出現無限制增長或造成系統越來越慢。還有可靠容錯性在分離部署和集羣環境中非常重要，需要針對性驗證分離的子系統、集羣異常情況發生時，其它系統的可靠與容錯能力。

如下圖 5，就是我們某次穩定性測試過程中，子系統無性能問題，而某服務內存資源不釋放，內存越用越多的情況。

圖 5

三、壓力場景設置

可以通過使用性能測試工具的場景設置調整用戶加載模式、步進時間、思考時間等，真實的模擬客戶的不同場景的需求，比如模擬開盤場景，通過 “壓力測試場景設置 “模擬可以確定開盤需要的終端數、帶寬流量分佈、開盤效率、進場安排等。

圖 6

壓力場景設置中，還有一個就是對靜態資源的請求，是容易被忽視的。下載靜態資源和不下載靜態資源，吞吐量能有 5 倍以上的差距。在驗證業務系統本身的性能時，確認瀏覽器緩存生效的情況下，可以不下載靜態資源進行驗證。但對於網絡設備、服務器整體壓力，需要下載靜態資源進行驗證，以防止因大量新用戶的出現，導致網絡設備和服務器壓力過大引起異常。由於客戶部署環境不同，不同的網絡設備轉發能力、服務器處理能力不同，確實存在靜態緩存擊穿時負載均衡設備和 WEB 服務器異常的情況。這個我們也碰到過，某客戶負載均衡 5 年未維護且設備老舊，在大量靜態頁面請求時，負載均衡出現轉發性能，如下圖 7，靜態頁面負載均衡轉發間歇性 504。

圖 7

四、監控項

監控是 To B 和 To C 性能測試都需要做的，方法也類似。測試工具統計出的響應時間、成功率、吞吐量等是性能測試通過與否的標誌。內存、CPU、磁盤、.net 相關計數器的靈活運用，能幫助分析定位問題、估算系統容量。SQL 跟蹤也是測試過程中定位數據庫瓶頸的關鍵手段。

五、系統設置

系統設置在 To B 模式下，因爲私有化部署的原因，設置可能存在差異。這些差異直接影響着併發度、流量、超時時間、集羣穩定等，需要 To B 的性能測試人員去掌握單 WEB + 單 DB、多 WEB + 多 DB、公有云、私有云、混合雲，再到如今的 K8S 容器化集羣部署，他們之間的特性差異。

圖 8

比如多 WEB 部署，需要加負載均衡，而加負載均衡就需要有健康檢查、會話保持、權重設置，還有設備本身的轉發能力、緩存設置等，這些需要在性能測試過程中去驗證，需要把針對 WEB 集羣的性能、可靠性、容錯策略加到測試方案裏面，比如 F5、深信服、nginx 通過多種設置後對程序的響應時間影響 1~3 倍。又比如多 DB，會涉及到數據庫故障轉移集羣，故障轉移集羣讀寫分離對性能的影響、故障轉移發生時系統的可靠性也需要驗證，還有 SQL Server 快照緩存並行度等等，有時候也需要驗證。再比如私有云，因爲宿主機設備不同、虛擬技術不同，可能在資源識別和利用效率上有差異，這裏面也要針對性補充性能測試方案和問題分析。比如我們就發現 CPU 利用率偏高，最後發現私有云 CPU 識別異常，虛擬了 8 核，只能識別 4 核，如下圖 9。

圖 9

上面我們簡單談了一下 To B 性能測試思考的要點，分別提到性能測試應該對業務場景、測試方法、場景設置、監控項、系統設置、部署環境都加以考慮**，**如下圖 10，爲完整的 To B 複雜系統的性能測試應該要注意的點。

圖 10

具體這些點要怎麼去識別，用什麼工具去驗證，怎麼去分析定位問題，後面我將分享多篇文章，歡迎大家訂閱。

PS：下篇文章，我們將分享 K8S 容器化環境下的性能測試方法和需要使用的工具。

作者簡介

趙同學： 測試專家，目前負責天際平臺性能測試相關工作。

本文由 Readfog 進行 AMP 轉碼，版權歸原作者所有。
來源：https://mp.weixin.qq.com/s/Rn9N5Htknu2_gQcYRUIVlw