基于時間模擬率的測試方法研究

劉洋+徐超+王凱+趙鵬

【摘 要】通信產品迭代速度快、測試周期短、軟件穩定性測試時間不足，造成了隱含缺陷的產品流入市場的情況。針對以上問題，提出一種時間模擬率的穩定性測試方法，測試一天可模擬產品實際運行N天，并通過TETRA平臺框架層面的通信接口進行了測試實驗，實驗表明該測試方法可以有效地縮短測試周期，在有限的研發周期內更大程度地提高產品穩定性。

【關鍵詞】穩定性測試 時間模擬率 TETRA D-Bus

Study on the Testing Method Based on the Time Simulation Rate

[Abstract] Communication products have characteristics of quick renewed products， the short testing period and the insufficient testing time of the software stability， leading to impliedly defective products entering the market. In view of this situation， a stability testing method based on the time simulation rate was proposed in this paper， which can simulate the practical operation of N days in one day. In addition， it was tested by means of the communication interface on the architecture of the TETRA platform. Experiments show that the testing method can effectively reduce the testing period and highly enhance the stability of products in the limited R&D cycle.

[Key words]stability test time simulation rate TETRA D-Bus

1 引言

隨著當今通信技術的日益迅猛發展，專業通信產品的市場越來越龐大，但同時競爭也越發激烈，在產品更新迭代加快推動通信產業不斷發展的同時，也暴露了由于研發周期短，產品穩定性測試驗證時間不足，導致流入消費者手中的產品在使用過程中出現各式各樣的問題的情況發生，嚴重影響了客戶體驗。因此，在有限時間內，如何更有效地加強產品穩定性性能測試已經成為通信行業急需攻克的難題。目前已提出的測試理論多偏重測試流程和開發流程；而實際上，在產品的實際使用和測試中，其質量問題會更多的體現在產品業務和技術方面，傳統的測試理論對此卻缺乏關注。特別是對于需較長時間測試才能暴露的問題，實驗室有限時間的測試難以百分百地發現，這就要求有一套理論來評估產品的質量，并基于此進一步加強測試。針對以上問題，本文提出一種時間模擬率的測試概念，即實驗室測試1天可以模擬產品實際運行N天，通過壓縮測試時間，力爭在盡可能短的時間內發現更多的產品隱患。對基于時間模擬率開發的TETRA的平臺框架層面的接口測試方案進行測試驗證，并將測試結果與產品實際運行結果進行對比，表明該方法具有可行性高、可擴展性強的特點。作為評估產品質量的一個度量衡，對于其他非通信類型產品的測試，希望能提供比較好的借鑒和啟發意義。

2 測試時間模擬率及應用策略

測試時間模擬率是一種測試時間相對產品實際運行時間進行壓縮的比值，在測試時間和測試設備數量均受限的情況下，通過在實驗室測試環境以一定的時間比例模擬產品實際運行，從而發現更多的產品穩定性問題。該模擬率可以用數學比例1：N來代替，“1”指實驗室環境下的測試時間，N則是對應的可以模擬的實際系統的運行時間。

測試時間模擬率區別于常規的壓力測試，后者旨在發現系統能支持的最大負載，常規地為了檢查系統的反應、運行速度等性能指標，發現產品的性能瓶頸；測試時間模擬需要結合壓力測試、性能測試和自動化測試等手段對測試時間進行壓縮。

在應用策略方面，一般而言，測試時間模擬率的具體應用需要結合產品的業務和技術特點，給出多角度多維度的評判。一般來說，基于產品面臨的外部挑戰，應用策略可以分為以下兩種。

業務角度的應用策略：針對產品的業務模型，分析在一定測試時間內所能觸發的業務量、業務復雜度與現場時間的比值，則可推演出要達到同等業務量，實驗室測試所需時間與實際系統運行所需時間的比值。如測試系統與實際系統單位時間內的在線用戶數比值、用戶業務請求量比值等。因產品業務的差異，應用策略千差萬別。

技術角度的應用策略：從產品自身的技術特性可以分析其技術角度的模擬率比值。如單位時間內產品涉及到的配置組合（產品所采用的服務器類型、參數類型等）、所經歷的外部環境情況（工作溫度范圍、GPS信號變化情況等）等。

結合產品自身的設計，可以從產品組成模塊/網元的角度，進一步分析模擬比，模塊可以分為：

業務模塊：直接處理產品業務的模塊；

平臺模塊：不直接處理產品業務，但支撐業務模塊，比如操作系統，可以通過分析其內存使用，發現線程掛死等異常發生幾率的比值。

下文以通訊系統中的D-Bus平臺為例，深入展示測試時間模擬率的應用。

3 模擬率測試案例及驗證

3.1 D-Bus通信簡介

D-Bus是一種高級的進程通信機制，具有低延遲、低開銷、高可用性等特性，是desktop-bus的簡稱。該通信協議由freedesktop.org開源項目組提供，并基于GPL進行許可發行。其主要概念為總線，注冊之后的進程可通過總線發送和接收報文信息，或者等待內核相應事件響應，例如系統某種服務狀態變更或是主機發出某種內核操作指令。由于基于D-Bus協議的消息傳遞相對比較高效且穩定，目前已被廣泛地應用到多個版本的Linux操作系統當中，而且軟件開發人員能利用D-Bus協議去實現復雜多樣的通信軟件開發。

作為D-Bus的進程間通信機制，總線通常會在一個操作系統中存在很多條，并由D-Bus總線守護程序進行相應管理。以系統總線（System Bus）為例，其在Linux操作系統內核引導時，就會被載入到系統的內存當中，此時只有內核級別的程序、Linux桌面程序以及高權限級別的軟件程序才能進行總線的消息寫入，以確保操作系統的安全，并且能有效預防惡意或未授權的程序進行的相應寫入嘗試。會話總線（Session Buses）能同時存在很多條，一般由普通進程創建，并且被某個進程私有獨占，其被用于進程間消息的傳遞。其中，程序進程首先必須進行注冊，之后才能進行總線消息的接收。

D-Bus提供了一種匹配器（Matchers）機制，以使程序能有選擇性地進行消息接收。同時運行中的進程程序均會注冊一個回調函數，便于在收到指定消息時進行相應的業務處理。這種機制能有效防止不相關消息的接收，從而避免導致程序運行時的性能較弱。

在D-Bus機制中，對象、服務、消息等概念相對比較重要。其中對象是一個封裝后的匹配器與回調函數實體，它以端到端（peer-to-peer）方式使每個消息都具有唯一的源地址以及目的地址，以便確定通信路徑。當一個進程在總線注冊時，需要創建相應的消息對象。在進程注冊到某個地址后，相應的總線服務會被自動獲取。D-Bus提供了服務查詢接口，進程可通過該服務查詢接口判斷服務是否存在。注冊的進程能通過發送信號的方式將消息放到總線上，此時，其他進程則通過總線接收并解析消息。回調函數會在注冊進程收到相關信息后，自動做出反應并且返回相應的方法。

3.2 案例驗證背景

一般而言，在系統測試中，一些系統隨機性問題（尤其較嚴重問題）隨著時間的推移會不斷被暴露出來，繼而被研發人員改進和修復；在版本的不斷演進中，問題被暴露的概率越來越低，甚至難以被日常的測試所發現。對此，需要明確缺陷問題有無根本修復；問題在實驗室有限的環境和有限的測試時間下是否能夠充分暴露；如何確保此類問題不會在項目現場發生。要對此類問題進行一個時間比的探討，才能使其在某一數量級的硬件條件和一定的運營時間內不會暴露出來。

下文將分析一個平臺的接口級壓力測試，實驗室的人員和設備極其有限（尤其是系統設備數遠遠小于現場設備數）。以某一中型項目現場為例，TETRA系統基站數高達70個，基于有限的設備和人員，如何盡可能地模擬現場設備運行的多種交互，這對系統的模擬覆蓋測試提出了更高的要求。

目前TETRA系統業務層面的壓力測試由于比較常見而容易被關注，且一般TETRA系統廠家會進行比較廣泛的測試。而平臺框架層面的接口測試往往會被一般的廠家所忽略，在現場大業務量運行時，除了業務模塊軟件承載巨大壓力，底層接口同樣也承載巨大的壓力。因此，為了提高測試模擬率，自動化測試開發團隊基于通用平臺的通信流程，開發設計了相應的通信程序，并且基于測試環境測試，最終根據測試結果進行了模擬率的驗證。

3.3 自動化測試工具設計

底層平臺接口層面的通信分為客戶端及服務端兩部分，通信基于D-Bus協議。該D-Bus平臺主要實現通信包的轉發，其中，服務端程序功能主要為設計實現接口，并發布接口對象，從而生成對象路徑及總線名；客戶端程序功能主要為通過總線訪問對應服務端程序中的接口，客戶端連接到服務端需要設定服務端的IP地址、端口號以及總線名。

為了測試這個通用平臺的穩定性，分別用C++和Python語言對同一平臺接口開發了自動化測試工具，不僅涉及到軟件的線程間通信、主機內進程間通信，還涉及到跨主機的進程間通信。其中，測試程序設計中不涉及系統中各類實際存在的通信程序的交互，如基站守護進程、網元程序等，即模擬測試程序和實際基站系統運行程序均基于D-Bus通用平臺，但模擬程序不會影響實際程序的運行，僅加大接口模擬的力度，使實際程序調用接口時更易發生、暴露缺陷問題。整體測試通信模型如圖2所示：

為了盡可能地模擬現場業務，在測試軟件設計中加入了線程間通信、主機內進程間通信、跨主機間進程間通信，這樣底層平臺的多種業務能夠得到有效模擬。

此外，為了盡可能模擬實際現場，項目團隊通過設計異常程序，以實現網絡傳輸、網絡接口異常及系統服務級的自動化異常干擾。客戶現場真實環境會不定期地出現網絡傳輸等問題，周期約為1～3天一次，采用該方法，設定一個小周期（5分鐘到半小時），通過隨機數產生器，在網絡傳輸層面會隨機產生丟包、亂序、亂碼等狀況，且網絡接口會定時啟用、禁用，系統服務也會在隨機時間段內進行服務的禁用及啟用。據此，能較充分且隨機地模擬現場易出現的多種突發狀況以進行測試，暴露問題缺陷，最終保證系統運行的健壯性及穩定性。圖3為網絡傳輸及接口異常模擬程序框架圖：

3.4 測試環境

由于實驗室設備資源有限且多數資源用于其它多種測試，最終分別在一臺兩載波基站、9臺Linux虛擬機主機（模擬基站）環境上部署了開發的測試程序，并分別設定主機間和同一主機內的單一業務和多業務交叉通信場景，以達到時間模擬上的效果。其中，每主機新增40個通信測試進程并活躍運行，每進程調用25個線程，所以主機內運行1000個線程，10主機共運行1萬線程來進行平臺通信。

3.5 模擬率估算及測試結果分析

在實驗室常規測試環境中，一臺基站的活躍進程為5～10個左右，取平均值為7，每進程中活動線程為10個左右。在模擬測試程序設計運行后，一臺真實基站（加上虛擬主機）一天的模擬量約等于“10000/（7×10×4）=35.7”臺基站一天的模擬量，即模擬率約為1： 35.7。

經過測試分析發現，相應通信平臺的接口缺陷問題只能被常規測試有限地發現，但有了自動化模擬程序后，能更多更快地發現相關缺陷，且自動化模擬程序發現的問題能覆蓋到常規測試中發現的同樣問題。

項目團隊對缺陷問題出現的數量及所需時間進行過統計，

實際模擬的概率提升為“15/0.47”，約為32倍，即實際模擬率為1： 32，接近理論估算值1： 35.7。

根據上述結果對比，通過模擬程序測試效率和質量得到了大幅提升，測試覆蓋到了業務層面的壓力測試、平臺框架層面的通信及異常干擾等盡可能多的場景。因此在實驗室可快速模擬項目現場長時間的通信量，盡早暴露問題，以避免問題遺落在現場而導致隱形及難以估量的損失。

4 結束語

本文通過一個較典型的通信接口級壓力測試案例來闡述模擬時間比這個概念，值得關注的是，真正做到系統級的時間模擬的估算和測試需要針對每一個隨機問題進行技術分析，然后定量地分析，最后根據時間模擬率方法，采取相應的測試手段。

整體而言，本文提供了一個理論標準——問題模擬發現率，并提供了兩個衡量標準：時間比例和覆蓋比例，同時結合項目經歷，就相關理論的驗證進行了舉例說明，使產品的質量有了一個量化的評估標準，有助于產品質量的提升。海能達公司的ACCESSNET-T IP DIB R5是最新專注研制的一款TETRA專網通信系統，由中國總部和德國子公司共同研制，就其架構而言，相比上一代產品，很多特性得到了改進和優化，并且模塊化的程序更高、支持組網方式更靈活、業務流程更合理、功能相對更完善，并且由于測試方法的提升，相應的產品測試也更加充分，保證了產品的可靠性能。

參考文獻：

[1] ETSI EN 300 392-5. Terrestrial Trunked Radio （TETRA）； Voice plus Data （V+D）； Part 1： General Network Design[S]. 2009.

[2] ETS 300 392-2. Trans-European Trunked Radio （TETRA）； Voice plus Data （V+D）； Part 2： Air Interface （AI）[S]. 1996： 76-84.

[3] FREEDESKTOP.ORG. dbus-specification； Part 4： Message Protocol， Revision 0.27[Z]. 2015.

[4] 中國電子學會通信學分會. TETRA在中國的應用和發展[J]. 移動通信， 2013，37（11）： 52-55.

[5] 徐超，冉斌龍，劉洋. TTCN在TETRA系統中的實踐運用[J]. 移動通信， 2016，40（9）： 24-29.

[6] 周俊揚，楊豐瑞，楊程. 基于dbus的QT進程間通信機制的實現與優化[J]. 廣東通信技術， 2014，34（1）： 23-26.

[7] 鄭曉軍. 無線通信TETRA系統簡述[J]. 科技資訊， 2010（1）： 22， 24.

[8] Linuxdianc. 進程間使用D-Bus通信-Linux/UNIX典藏大系[EB/OL]. （2009-12-21）. http：//blog.csdn.net/linuxdianc/article/details/5046331.

[9] 徐超，賈迪非，劉洋. 基于TETRA系統的接口開放性研究