通信網管系統OMC的性能測試研究

燕鵬飛，張厚保

（中國交通通信信息中心，北京 100011）

1 引言

本文從實踐角度，闡述通信網管軟件OMC性能測試的理論和方法，希望能引領讀者從抽象的軟件性能測試理論，映射到實際項目中，對OMC系統的性能測試有所了解。

2 性能測試概述

2.1 性能測試在軟件開發生命周期中的位置

圖1 性能測試在軟件開發生命周期中的位置

軟件生命周期分為：需求、設計、編碼、單元測試、集成測試、系統測試。以V模型為例，呈現如上圖。而性能測試屬于軟件系統級測試，其基礎是一個已經完成功能測試的相對穩定的軟件版本。

2.2 軟件性能測試的概念

軟件性能可以看作是一種指標，是產品需求中明確約定軟件系統所要求達到的一種和時間相關或者與處理能力相關的指標。

軟件性能的定義通常為：軟件系統對于及時性要求的符合程度。對于時間方面規定的軟件性能通常用響應時間來定義。處理能力是另一個重要指標，包括上行、下行以及系統內部的消息處理等。可靠性同樣是軟件性能的一個重要的指標，可靠性關乎到系統能否穩定可靠，關乎到客戶對該系統的認可程度。通信網管作為通信網絡的一部分，必須做到高可靠性。

軟件的性能測試，就是通過測試工具，測試軟件在各種使用環境下，是否能滿足既定的軟件性能指標。

3 OMC的性能測試

3.1 OMC的性能測試過程

軟件的性能測試不是一勞永逸的，性能測試伴隨著軟件的生命周期持續開展。在通信網管軟件OMC的測試過程中，隨著OMC的一系列版本發布，其性能測試過程可以描述為一個螺旋模型，如圖2所示：

圖2 OMC的性能測試過程

3.2 OMC的性能測試方法

性能測試的方法有多種，根據不同階段的需求，可以分別采用不同測試方法的組合。

3.3 性能測試

此處提到的性能測試，是狹義的性能測試，是軟件性能測試的基本方法。性能測試方法是通過模擬實際運行場景的業務壓力量進行測試，驗證系統的性能是否滿足預期的性能指標。這種方法針的測試結果，可以具體考量系統的響應時間、處理能力等性能指標。OMC系統，根據電信運營商的測試規范，有諸多性能指標，如界面響應時間、設備上報消息延時、告警呈現延時、性能文件上報等。OMC性能測試中，通過模擬規模數據的網元，構造批量變化的配置數據、告警數據、性能上報數據等場景，測試系統的各個性能指標。這個測試方法貫穿于OMC性能測試的始終。

3.3.1 配置測試

配置測試是指通過被測系統的軟/硬件環境調整，了解不同環境對系統性能影響的程度。具體地說，就是服務器類型和操作系統類型的不同，對于OMC系統的性能指標影響不同。軟件系統的性能都是在一定的環境下表現出來的綜合性能。環境因素包括很多：硬件環境（CPU主頻，個數，單個CPU的核數，單核CPU的并發線程數；物理內存大小，虛擬內存大小；磁盤的I/O處理能力）；所依賴的軟件環境（操作系統的相關配置，數據庫的相關配置）；自身的軟件環境（如：并發線程的設置；虛擬機內存設置等）。

進行同一個典型業務在不同的配置環境下的測試，并進行結果對比分析可以有效的發現系統的性能瓶頸，可以找到對系統進行優化的依據；也可以根據對比結果選擇最適合系統的硬件環境，以及評估如何調整才能實現系統的拓展性。

在OMC的設備選型測試中，此處采用了多輪配置測試方法，對系統進行評估、優化，以及優化后進行設備選型。

3.3.2 負載測試

負載測試是模擬實際軟件系統所承受的負載條件的系統負荷，通過不斷加載（如逐漸增加模擬用戶的數量）或其他加載方式來觀察不同負載下系統的響應時間和數據吞吐量、系統占用的資源（如CPU、內存）等。用這種測試方法，可以找到系統的處理極限。在網管軟件OMC的選型測試中，使用了負載測試方法，對于不同的軟硬件配置環境，對比系統運行的性能容量，為OMC的軟硬件選型提供依據。

3.3.3 壓力測試

壓力測試是在強負載（大數據量、大量并發用戶等）下的測試，查看應用系統在峰值使用情況下操作行為，從而有效地發現系統的某項功能隱患、系統是否具有良好的容錯能力和可恢復能力。壓力測試分為高負載下的長時間（如24小時以上）的穩定性壓力測試和極限負載情況下導致系統崩潰的破壞性壓力測試。在OMC的穩定性測試環節，采用了壓力測試的方法。

3.3.4 并發測試

并發測試驗證系統的并發處理能力。一般是和服務器端建立大量的并發連接，通過客戶端的響應時間和服務器端的性能監測情況來判斷系統是否達到了既定的并發能力指標。

OMC系統是通信網管軟件，其重點應用場景不是多用戶的并發場景，而是大量業務并發場景。因此，在實際測試中，并發測試針對的是OMC系統內部實現的并發，多線程并發、數據庫死鎖、數據庫事務處理等方面。

3.3.5 可靠性測試

可靠性測試方法通過給系統加載一定的業務壓力，例如資源在70%～90%的情況下，系統持續運行一段時間后，測試系統是否穩定。OMC系統的穩定性測試使用了該測試方法，通過在持續的業務壓力下運行，查看OMC系統的處理能力、響應時間、內存和CPU使用狀況，以及查看是否有錯誤處理等情況。

3.3.6 失敗恢復測試

失敗恢復測試方法是針對有冗余備份和負載均衡系統設計的。這種方法可以用來檢驗系統在局部故障情況下，是否能正常運行。OMC系統采用集群策略部署，針對集群策略，進行主備切換測試、主機或備機宕機測試。測試過程中查看是否有業務丟失（如配置、告警消息丟失、性能文件處理丟失等），查看系統的處理能力是否正常等。

3.3.7 性能測試各階段的方法應用

綜上，OMC系統的性能測試各個階段，對于測試方法的應用分布為：

圖3 測試方法的應用分布

3.4 測試結果分析方法

3.4.1 操作系統計數器分析法

操作系統計數器分析方法，在OMC性能測試結果分析中，起到重要作用。操作系統計數器分析法重點關注內存、處理器（CPU）、磁盤I/O這些方面。

內存：使用操作系統命令，在OMC運行過程中，記錄內存使用情況、內存交換區使用情況。統計記錄的數據，查看內存占用走勢以及內存泄漏情況。然后用代碼走查分析方法，或使用內存查看工具，來對內存使用問題進行定位分析。

處理器（CPU）：用OMC相關進程的%CPU Usage衡量OMC系統對CPU的使用情況。一般上限不超過85%。

磁盤I/O：磁盤I/O也是影響系統性能的一個關鍵因素。在OMC系統測試過程中，發現OMC系統在存儲過程中磁盤I/O是性能瓶頸，因此有針對性的進行了系統優化，同時在磁盤硬件選型方面采取了一定措施，解決這個瓶頸。

3.4.2 分層分析法

OMC系統包含多個邏輯層次。在實際測試中，采用分層分析法對測試結果進行分析。

圖4 分層分析法

無論是上下行數據，都記錄各個邏輯層次處理的時間段耗時。如下行操作：從客戶端界面üü業務層調用üü平臺支撐層處理üü和設備之間交互（或與數據庫交互）。將操作在各個邏輯層次的耗時進行統計，分析得出系統瓶頸產生的層次。當分析出某個邏輯層耗時占比大后，還可以進一步分解該邏輯層次，繼續深入采用此方法進行測試分析，逐步排查系統瓶頸產生的原因。

3.4.3 統計法

對于一個典型的業務進行相同的環境下（軟件，硬件）進行多次測試，對多次測試結果進行統計分析是性能分析的常用辦法。單次測試往往具有偶然性，對同一個操作進行多次測試，通過統計的方法進行結果分析。在進行統計分析的時候，要符合統計要求的樣本數量，同時對異常點進行分離。如下示例：

表1 五次測試情況

圖5 五次測試統計

上面圖表是對同一個操作進行了五次測試，對測試結果進行統計后，可以作為最終的參考測試結果。

3.4.4 性能曲線趨勢分析法

通過分析性能曲線的變化趨勢對系統的性能進行分析。這個方法適用的場景很多，如：典型業務/操作隨著并發數目增多的性能曲線下降的分析方法：性能主要通過時間來衡量。如圖6所示，隨著某一業務的增加，處理時間增加，系統的性能下降。

通常系統的性能曲線是一個平滑的曲線，隨著并發的增加，時間平滑上升，性能平滑下降，找到性能跳變的位置，該位置為系統的性能拐點。在該拐點后，性能急劇下降，超出需求的范圍。在性能評估中，改點可視為系統的處理能力的上限。OMC 系統的網元管理能力，就可以通過這個方法找到上限。圖7是針對硬件環境變更進行性能分析，是OMC系統對于網元上行的消息風暴作受系統主頻的變化的處理能力的變化：

圖6 性能曲線趨勢分析法

圖7 針對硬件環境變更進行性能分析

從圖7可以看出，在一定范圍內提升硬件的CPU 主頻是有助于性能提升的，但是提升到一定水平后系統的性能不再有明顯的改善，說明此時系統的性能瓶頸已經不在處理器的主頻了，需要分析其他因素了。

3.5 測試工具的引入

工欲善其事必先利其器，測試工具在性能測試中其中非常重要的作用。在OMC系統的性能測試過程中，模擬通信網元，構造通信場景的大量數據，使用發包工具模擬通信消息等。除了這些構造測試場景的工具外，還引入了如JProbe、JProfiler等工具協助定位和分析問題。

圖8 使用JProbe工具查看客戶端內存使用情況

如圖8所示，使用JProbe工具查看客戶端內存使用情況，一級一級追究java調用，直到定位出內存溢出調用的代碼，最終使得客戶端內存溢出問題得到定位和解決。

4 結束語

綜上所述，OMC系統的性能測試，在OMC的系列版本開發過程中，做到了及時發現各種性能問題，幫助團隊盡可能的對OMC進行了合理優化，順利通過了性能要求。未來的性能測試方案，針對不同的系統架構，需要不斷重新設計和優化，把理論結合實際，實施適合項目的流程和技術測量，這是工程師們應該完成的責任和使命。