性能測試配置生成工具設計與實現(xiàn)

陳曉軒 喬艷茹

（卡斯柯信號有限公司上海測試部 上海市 200071）

1 引言

近年來，隨著我國現(xiàn)代化鐵路進程的推進，軌道交通逐漸而又深刻的改變著國民的出行方式，高效便捷的出行得益于列車運行控制系統(tǒng)的更新升級。所謂列車運行控系統(tǒng)，就是根據(jù)列車在線路上的客觀運行條件、實際運行狀況，通過列車車載和地面設備對列車進行實施控制、監(jiān)督和調整，以保證行車安全，提高運輸能力；目前，我國時速300 公里/時以上的高鐵，主要采用CTCS-3 系統(tǒng)，這是基于無線通信、軌道電路和固定的移動閉塞開發(fā)的一套準移動閉塞技術的列車控制系統(tǒng)；未來的列車控制系統(tǒng)，或將取消軌道電路，基于移動閉塞、北斗導航和5G 通信技術，由無線閉塞中心和列控車載設備共同完成列車定位和完整性檢查，實現(xiàn)虛擬移動閉塞和移動閉塞，形成“空天地一體化”網(wǎng)絡系統(tǒng)，這將是我國高鐵列控技術里程碑式的重大技術變革。

為了實現(xiàn)這一目標，國家投入大量的科研力量，然而列車控制系統(tǒng)龐大而復雜，需要與不同設備廠商的設備進行互聯(lián)互通，軟硬件之間的耦合度要低，軟件的可配性要求很高，因此，大量的信息需要存儲在配置文件中，生成高質量的配置文件也成為當下列車控制系統(tǒng)驗證過程中亟需解決的問題。隨著軟件迭代周期縮短，頻率提高，由人的過錯或者失誤導致的軟件失效而造成巨大的經(jīng)濟損失，甚至危及人身安全的概率也與日俱增[1]；而軟件測試是保障質量的重要手段和環(huán)節(jié)[5]，對軟件測試的準確度和完備性要求也越來越高，尤其對性能測試提出了更高的要求和挑戰(zhàn)。

一般傳統(tǒng)的嵌入式計算機軟件測試都是基于各種通用儀器或專用設備，采用各種儀器設備對被測系統(tǒng)的運行進行監(jiān)測，這種測試憑條的開發(fā)周期長，成本高，復用性差[6]，無法在其他嵌入式系統(tǒng)中進行復用，而我們的測試方法采用主流的上位機、下位機模式[2]；上位機負責外圍輸入信息模擬，下位機即被測對象負責處理收到的信息和反饋，如圖1所示。

其中，上位機測試平臺是運行在Windows 操作系統(tǒng)上，主要功能是管理自動化測試工具和測試活動管理[7]；下位機被測試對象是由工控機，主板，顯示器等組成，運行實時操作系統(tǒng)通過網(wǎng)絡、RS232、RS422、RS485、CAN 等系統(tǒng)提供的IO 和總線進行被測設備與實時主機間進行數(shù)據(jù)通信接收、解析與執(zhí)行測試主機的配置文件和腳本，進行實時通信，控制或采集數(shù)據(jù)[3]。

結合被測系統(tǒng)要適配多種硬件，外圍設備，多種數(shù)據(jù)，可配性高的特點，將測試活動分為測試數(shù)據(jù)準備，測試環(huán)境搭建，測試執(zhí)行和測試結果分析；于被測系統(tǒng)而言，編寫配置文件的過程變成一項復雜而繁重的體力勞動，且配置出來的文件質量低下，導致上下位機調試不順利，成為嵌入式軟件性能測試的一道瓶頸，因此上下位機配置不匹配的問題亟待解決，以降低聯(lián)調成本、提高測試效率，推動研發(fā)測試并進，保證項目進度的同時保障高質量交付。因此，本文提出并實現(xiàn)了基于Python 語言開發(fā)的性能測試配置生成工具軟件；之所以選用Python 語言，是因為Python 擁有豐富的庫文件和完備生態(tài)系統(tǒng)，具有良好的開放性和靈活性，適合快速開發(fā)。

2 框架設計

圖1：嵌入式測試模型

圖2：上位機配置文件生成過程

圖3：改進配置生成過程

圖4：數(shù)據(jù)關系圖

現(xiàn)有項目所采用的配置生成流程圖如圖2所示。

其中，Input Files 是上層用戶配置文件，需經(jīng)過Offline Tool 處理生成相應的二進制下位機配置文件Output Files，該Output Files是被測系統(tǒng)能夠正常啟動的必須配置，要使上位機測試平臺與下位機建立通訊，必須將下位機的相關信息配置到模擬器中，因此須根據(jù)下位機配置文件按照一定規(guī)則配置上位機配置文件；而該配置過程起初是由人工完成的，過程復雜且易錯，當通信節(jié)點數(shù)量指數(shù)上升的時候，幾乎成了不可能完成的任務，嚴重阻礙項目推進。更致命的是，節(jié)點數(shù)量不算龐大時，人工制作的配置文件也會因為一些疏漏導致上下位機聯(lián)調進展不順而使項目進度遲滯，這在當今形勢下的軟件迭代活動中是不可接受的，性能測試更成了紙上談兵無法落地。

因此，筆者基于現(xiàn)狀分析配置過程中的難點和要點，提取配置規(guī)則需求，設計和開發(fā)了性能測試配置生成工具，推動配置過程改進如圖3所示。

其中，AutoGenTool 將人工配置過程完全轉化為代碼并且引入反饋機制，其在生成上位機配置文件過程中，發(fā)現(xiàn)下位機配置文件中存在未配置設備，或者下位機配置文件自身存在不匹配問題等會給予記錄并反饋從而促進雙方的提升和獲益。

3 技術實現(xiàn)

筆者通過規(guī)則需求提取和方案設計，選用Python 的configparser 包作為開發(fā)工具包。ConfigParser 包是Python3 中用來解析ini 配置文件的解析器，具有強大的索引功能便于讀取，但卻大小寫不敏感，而源目標文件是大小寫混用，因此需要設計解決該問題。

以下將闡述遇到的問題及解決方案：

（1）信息分散于多個ini 源文件中而目標文件是提取多個文件的相應字段信息處理所得；

（2）源文件中option 字段大小寫混用；

（3）目標文件option 字段需與源文件保持一致以使C 語言生成的.lib 庫文件識別；

（4）協(xié)議本身配置規(guī)則如某些遠端與本端字段需交換；

（5）上下位機約定規(guī)則（自定義規(guī)則）。針對每個問題的具體解決方案如下：

3.1 創(chuàng)建設備協(xié)議映射索引表

分析外部因子對配置生成工具的影響，提取關鍵字段作為Key值，創(chuàng)建鍵值對索引表，用于目標文件生成過程中根據(jù)源文件中SrcAddr 索引Equipment 和Protocol 中某些字段信息，以解決信息分散不便于提取的問題，數(shù)據(jù)關系圖如圖4所示。與此同時，該表也剔除了非主要信息對配置生成工具的影響，對Equipment.ini 和Protocol.ini 而言，不在設備協(xié)議映射索引表中的字段可以隨時增加、刪除、修改而對配置生成工具沒有影響，從而降低了上下位機配置文件之間的耦合度，增加了二者的靈活度。

圖5：創(chuàng)建option 字段映射表

圖6：處理大小寫和協(xié)議字段

圖7：上下位機匹配規(guī)則

圖8：自定義規(guī)則

如圖4所示，下位機信息存儲表（Protocol.ini 和Equipment.ini 文件）主要是存儲網(wǎng)絡相關信息和設備本身信息。Protocol 中包含兩類子表，一類是記錄本地網(wǎng)絡信息的LocalNetInfomation，另一類是與系統(tǒng)相互通信的外部設備信息即RemoteNetInformation；LocalNetInfomation 包括本地IP，網(wǎng)關，端口名稱以及串口信息；RemoteNetInformation 包括設備名，網(wǎng)絡連接數(shù)，本地端口，本地使用IP 編號，遠端使用端口。Equipment 文件中包含了與系統(tǒng)通信的所有設備節(jié)點，信息包括EquipmentName、EquipmentNode 以及各個層的參數(shù)信息，其中EquipmentName 在Equipment.ini 表中是主鍵，在Protocol.ini 中是外鍵，EquipmentNode 在具體協(xié)議配置（源文件）中是主鍵，在Equipement.ini 中是外鍵，利用這個條件，創(chuàng)建了EquipmentMapTable 和ProtocolMapTable，使得用戶在生成目標文件時可以根據(jù)源文件的EquipmentNode 索引到EquipmentName的所有參數(shù)進而獲取網(wǎng)絡配置信息，一次生成與下位機匹配的配置信息，從而實現(xiàn)快速查詢而不需要遍歷多個源文件，節(jié)約了計算時間。

圖9：人工時間成本曲面圖

3.2 創(chuàng)建關鍵字段映射表

由于Python 是小寫處理信息而源文件和目標文件option 字段是大小寫混用的，因此需要創(chuàng)建section 中option 字段的映射表以解決混用問題，而此映射表在生成輸出文件階段也會用到以保障輸出文件與源文件一致。源文件option 字段大小混用映射表的實現(xiàn)過程如圖5所示。

3.3 協(xié)議配置規(guī)則

每個協(xié)議有自身的配置規(guī)則，遠端與本端信息需要做交換處理，因此創(chuàng)建的交換字段Key-Value 索引表，當讀取到源文件中需要做交換處理的字段時進入?yún)f(xié)議規(guī)則處理過程，同時，該字段若為大小寫混用字段需要用圖5 所創(chuàng)建的MAP 表中Value 值替換，以實現(xiàn)輸出格式與源文件保持一致；其處理過程如圖6所示。

3.4 上下位機約定規(guī)則

下位機配置文件在Protocol 中約定了與系統(tǒng)通信的所有設備使用的IP 和Port 信息，因此在生成上位機配置文件時需要從下位機配置表中查詢該設備使用的網(wǎng)絡配置信息，而InstanceProtocol 源文件中沒有存儲Protocol 與之對應的EquipmentName 字段，此時需要先查詢設備協(xié)議映射表，通過InstanceProtocl 中的SourceAddr在EquipmentMapTable 中查找到對應的EquipmentName，從而利用EquipmentName 獲取其在ProtocolMapTable 中所有網(wǎng)絡配置索引信息，這也是創(chuàng)建設備協(xié)議索引表的重要作用所在。此外，在創(chuàng)建索引表過程中發(fā)現(xiàn)下位機配置文件本身的問題也會做相應的異常處理并記錄反饋，其處理過程如圖7所示。

3.5 自定義規(guī)則

在實際應用中，系統(tǒng)與外部通信設備不斷增加且由于行業(yè)的特殊要求，同一設備需要熱冗余以便當一系發(fā)生故障時，設備能夠自動切換至另一系繼續(xù)工作從而實現(xiàn)對外輸出透明。體現(xiàn)在配置中就會出現(xiàn)多個EquipmentName 與同一個EquipmentNode 對應，此時上下位機配置匹配時需要按照系統(tǒng)設置的自身規(guī)則進行處理。目前的冗余規(guī)則是，當協(xié)議節(jié)點使用交叉互聯(lián)模式時一個節(jié)點會有4 個EquipmentName 與對應，前兩者默認為A 系，后兩者為B 系；如果采用直連模式會有2 個EquipmentName 與對應，說明只有一系，則默認輸出到A 系。下位機配置文件中允許同一類型協(xié)議直連和交叉互聯(lián)模式同時存在，因此人工處理起來更為繁瑣，而程序按照約定規(guī)則實現(xiàn)大大降低了出錯率，未來用戶也可以約定其他規(guī)則，只需要添加對應的規(guī)則處理函數(shù)即可。具體處理流程圖如圖8所示。

4 技術優(yōu)點分析

本設計方案具有以下優(yōu)點：

（1）松耦合：只須約定下位機配置文件格式而不限制內(nèi)容，建立的相對穩(wěn)定的索引表，從而實現(xiàn)不會因為下位機配置文件某些內(nèi)容的修改、增刪就必須更新配置生成工具，降低了兩者之間的耦合度，給雙方以更多的自由空間和靈活度。

（2）可擴展：如圖4 數(shù)據(jù)關系圖所示，采用3 層映射關系，增強了配置工具的可擴展性。隨著系統(tǒng)支持的協(xié)議增加，InstanceProtocol 可以持續(xù)擴展，當有新的協(xié)議加入下位機配置文件中時用戶只需要給定該協(xié)議的源文件格式（InstanceProtocol 源文件），下位機配置支持該協(xié)議，就可以放入配置生成工具中自動生成與源文件匹配的目標文件，而對其他協(xié)議沒有影響。

（3）工程效應：大幅度提升工作效率，推動性能測試順利開展。以項目實際應用為例，以系統(tǒng)支持的Y（Y＞500）個Protocol1類型節(jié)點，其中直連模式比例為X，交叉互聯(lián)模式比例為（1-X），假設人工配置這樣一個上位機配置文件，一個Connection 至少需要3 次人工索引，15 個字段修改，理想情況下修改一個Connection 需要30 秒時間，而且不能保障準確度，因為人隨著重復度提高，疲勞程度加強，配置文件出錯率也會越高；配置節(jié)點個數(shù)增加與直連模式比例的變動所需要的人工時間成本三維曲面圖如圖 9所示。

從圖9 中可以看到，當節(jié)點數(shù)量劇增、直連比例降低時，人工耗時成本急劇增加。實際上，當人力配置一個文件超過20 分鐘其質量已經(jīng)堪憂，而系統(tǒng)支持超過100 個節(jié)點，人工配置已經(jīng)是不可達狀態(tài)；而采用配置生成工具生成上位機配置文件輕而易舉，1 秒之內(nèi)即有輸出，大大提高了測試效率，推動了性能測試的工作和驗證強度，節(jié)省了人力成本，工程效應顯著。

5 結束語

隨著軟硬件本身的提升，系統(tǒng)可擴展性、靈活性以及性能不斷加強，因此配置文件也越來越龐大而復雜，要對其性能進行完備的驗收，性能測試成了軟件測試過程中的重要環(huán)節(jié)和瓶頸。而完備的性能測試配置及測試數(shù)據(jù)是性能測試成功的必要條件，本文闡述的性能測試配置生成工具為配置完備的性能測試配置提供了有效途徑，該設計方案易于二次開發(fā)，具有良好的擴展性和穩(wěn)定性，有效提高性能測試平臺的開發(fā)效率，推動性能測試的順利開展。