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

劉洋+徐超+王凱+趙鵬

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

【關(guān)鍵詞】穩(wěn)定性測試 時間模擬率 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 引言

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

2 測試時間模擬率及應(yīng)用策略

測試時間模擬率是一種測試時間相對產(chǎn)品實際運行時間進行壓縮的比值，在測試時間和測試設(shè)備數(shù)量均受限的情況下，通過在實驗室測試環(huán)境以一定的時間比例模擬產(chǎn)品實際運行，從而發(fā)現(xiàn)更多的產(chǎn)品穩(wěn)定性問題。該模擬率可以用數(shù)學(xué)比例1：N來代替，“1”指實驗室環(huán)境下的測試時間，N則是對應(yīng)的可以模擬的實際系統(tǒng)的運行時間。

測試時間模擬率區(qū)別于常規(guī)的壓力測試，后者旨在發(fā)現(xiàn)系統(tǒng)能支持的最大負載，常規(guī)地為了檢查系統(tǒng)的反應(yīng)、運行速度等性能指標，發(fā)現(xiàn)產(chǎn)品的性能瓶頸；測試時間模擬需要結(jié)合壓力測試、性能測試和自動化測試等手段對測試時間進行壓縮。

在應(yīng)用策略方面，一般而言，測試時間模擬率的具體應(yīng)用需要結(jié)合產(chǎn)品的業(yè)務(wù)和技術(shù)特點，給出多角度多維度的評判。一般來說，基于產(chǎn)品面臨的外部挑戰(zhàn)，應(yīng)用策略可以分為以下兩種。

業(yè)務(wù)角度的應(yīng)用策略：針對產(chǎn)品的業(yè)務(wù)模型，分析在一定測試時間內(nèi)所能觸發(fā)的業(yè)務(wù)量、業(yè)務(wù)復(fù)雜度與現(xiàn)場時間的比值，則可推演出要達到同等業(yè)務(wù)量，實驗室測試所需時間與實際系統(tǒng)運行所需時間的比值。如測試系統(tǒng)與實際系統(tǒng)單位時間內(nèi)的在線用戶數(shù)比值、用戶業(yè)務(wù)請求量比值等。因產(chǎn)品業(yè)務(wù)的差異，應(yīng)用策略千差萬別。

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

結(jié)合產(chǎn)品自身的設(shè)計，可以從產(chǎn)品組成模塊/網(wǎng)元的角度，進一步分析模擬比，模塊可以分為：

業(yè)務(wù)模塊：直接處理產(chǎn)品業(yè)務(wù)的模塊；

平臺模塊：不直接處理產(chǎn)品業(yè)務(wù)，但支撐業(yè)務(wù)模塊，比如操作系統(tǒng)，可以通過分析其內(nèi)存使用，發(fā)現(xiàn)線程掛死等異常發(fā)生幾率的比值。

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

3 模擬率測試案例及驗證

3.1 D-Bus通信簡介

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

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

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

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

3.2 案例驗證背景

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

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

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

3.3 自動化測試工具設(shè)計

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

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

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

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

3.4 測試環(huán)境

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

3.5 模擬率估算及測試結(jié)果分析

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

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

項目團隊對缺陷問題出現(xiàn)的數(shù)量及所需時間進行過統(tǒng)計，

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

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

4 結(jié)束語

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

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

參考文獻：

[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] 中國電子學(xué)會通信學(xué)分會. TETRA在中國的應(yīng)用和發(fā)展[J]. 移動通信， 2013，37（11）： 52-55.

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

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

[7] 鄭曉軍. 無線通信TETRA系統(tǒng)簡述[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系統(tǒng)的接口開放性研究