0 引言

繼電保護及自動裝置是電力系統(tǒng)的重要組成部分。對保證電力系統(tǒng)的安全經(jīng)濟運行，防止事故發(fā)生和擴大起到關(guān)鍵性的決定作用。由于電力系統(tǒng)的特殊性，電氣故障的發(fā)生是不可避免的。一旦發(fā)生局部電網(wǎng)和設(shè)備事故而得不到有效控制，就會造成對電網(wǎng)穩(wěn)定的破壞和大面積停電事故。現(xiàn)代化大電網(wǎng)對繼電保護的依賴性更強，對其動作正確率的要求更高，也造成了對繼電保護裝置的測試要求越來越高。

各大繼電保護的廠家對保護裝置的測試也非常重視，基本上采用的都是黑盒測試的方法，通過測試人員和工程人員采用商用測試儀進行加量進行閉環(huán)的保護功能測試，這種測試方式雖然能檢查出一部分系統(tǒng)的漏洞，但是遠遠達不到對于可靠性要求極高的繼電保護裝置的測試要求。并且數(shù)字化的測試依賴于外部的數(shù)字化測試儀[1]。這種測試方法的不足體系在以下幾點：

1）無法進行軟件平臺的各模塊代碼覆蓋率測試。

2）無法進行系統(tǒng)的自動回歸測試。

3）無法進行自動測試用例管理，測試質(zhì)量由測試人員的專業(yè)素質(zhì)決定，而不是由各測試和開發(fā)人員的測試積累組成。

4）無法規(guī)范地進行測試報告記錄，不能詳細記錄研發(fā)人員關(guān)心的測試量信息。

5）商用測試儀不能與保護裝置進行交互。

鑒于傳統(tǒng)測試的上述問題，設(shè)計了一種滿足研發(fā)人員、人員以及工程人員使用的統(tǒng)一測試體系，該測試體系包括上位機、測試儀和被測裝置，覆蓋了研發(fā)階段和單板測試階段以及整機測試各階段。

*近兩年，也有一些裝置廠家[2-4]也通過自主研發(fā)開發(fā)一套適合自身產(chǎn)品的自動測試系統(tǒng)，但是目前這些測試也集中在保護功能的閉合測試上，沒有考慮裝置中平臺部分的功能隱蔽性，一般功能測試很難系統(tǒng)地對其進行邏輯測試。本文將重點介紹自動測試系統(tǒng)中的白盒測試實現(xiàn)方法。

1 系統(tǒng)結(jié)構(gòu)

保護裝置的軟硬件體系結(jié)構(gòu)圖如圖 1 所示。

測試主機的功能分成兩個部分，離線功能包括完成測試用例的編寫、測試用例的管理、測試用例程序編譯等離線功能。在線功能包括測試用例下載，測試參數(shù)下載，測試命令發(fā)送和測試報告生成等。平臺系統(tǒng)軟件包含下面模塊：任務(wù)調(diào)度、系統(tǒng)監(jiān)視、對時、異常處理、調(diào)試及下載模塊。平臺管理通信模塊包括：MANAGER 管理、事件錄波、IEC103 模塊、IEC61850 模塊；LCD 模塊；PRINT模塊。平臺裝置的板卡通常由三大部分組成：管理CPU 板、計算處理 CPU/DSP 板和 I/O 板。

測試主機通過以太網(wǎng)采用內(nèi)部通信的協(xié)議與調(diào)試代理插件相連，調(diào)試代理駐留在 PPC 插件上，內(nèi)部通信協(xié)議具有下載文件、調(diào)試變量、修改變量等功能。整個測試過程的上位機與裝置的交互都是以該協(xié)議為基礎(chǔ)。

自動測試系統(tǒng)和平臺設(shè)計同時進行，完成對平臺的軟件模塊和通信管理模塊的自動測試，并將測試結(jié)果直觀地反映到測試終端。

2 白盒測試架構(gòu)

白盒測試時需要保護裝置運行一個測試支撐系統(tǒng)，白盒測試包括測試裝置中所有智能插件上的程序，尤其是平臺系統(tǒng)軟件程序，這部分程序在整組的功能測試實驗（黑盒測試）中不是測試重點，所以需要通過周密的白盒測試來覆蓋測試路徑。測試支撐系統(tǒng)運行在 Manager 插件上。

目標板上的測試支撐模塊包括測試用例運行管理、PC 通信管理、測試運行信息采集及管理、系統(tǒng)信息處理、信息上送等模塊。測試用例運行管理是運行在目標板上與 PC 機同步執(zhí)行同一測試用例的管理程序；PC 通信管理是與 PC 機通信，接收 PC下發(fā)的參數(shù)信息，下載的程序信息、啟停測試用例命令和測試數(shù)據(jù)上送等功能；測試運行信息采集及管理是指采集某一個測試用例執(zhí)行后的一些變量數(shù)據(jù)信息，組織成特定的數(shù)據(jù)報文；系統(tǒng)信息處理是目標板上的其他應(yīng)用模塊，當這一測試用例運行時其他應(yīng)用模塊的數(shù)據(jù)信息采集（例如 SOE 事件測試用例會收集 103 模塊的報文信息）；信息上送是通過組織報文發(fā)送到 PC 機，由 PC 機進行結(jié)果比對。

運行在 Manager 插件上的測試用例的測試流程如圖 2 所示。

**步：PC 測試主機下載 ppc 測試用例可執(zhí)行程序 out 到目標板上。

**步：PC 測試主機發(fā)送啟動測試命令到測試代理。

第三步：測試代理裝載測試用例程序。

第四步：PC 測試主機啟動主機上運行的相應(yīng)測試 dll。

第五步：目標板上測試用例測試過程中，與 PC機上對應(yīng)的比對 dll 進行參數(shù)以及測試結(jié)果交換。

第六步：PC 機對結(jié)果進行比對，形成測試報告。

運行在其他智能 IO 上的測試用例框架結(jié)構(gòu)如圖3 所示。

測試用例運行在從板上時，測試用例目標文件首先下載到 Manager 系統(tǒng)中，重新上電后加載到從、板中運行。MANAGER 負責與從板系統(tǒng)的信息交互。

平臺模塊在設(shè)計時，設(shè)計了測試代理程序的接口，確保測試代理程序可以通過該接口進行功能測試和性能評估。該代理程序通過平臺的測試接口，實現(xiàn)對平臺代碼的測試，并通過網(wǎng)絡(luò)通信將測試結(jié)果上送給測試終端。同時通過網(wǎng)絡(luò)接收測試終端的測試用例，并根據(jù)給定的測試用例進行相關(guān)測試。運行在裝置中的每個模塊在設(shè)計初期即考慮了測試方案，通過自動測試系統(tǒng)可確保測試的代碼覆率達到 90％以上。有效的壓力測試可以發(fā)現(xiàn)并解決平臺的隱藏問題，為平臺的可靠性及穩(wěn)定性提供了保證。

3 測試框架實現(xiàn)

測試系統(tǒng)上位機的主要功能有：測試用例管理，測試用例的執(zhí)行流程、測試結(jié)果比對和測試報告生成四個模塊。

3.1 測試用例管理

測試用例管理包括：1）對測試時所需要的源代碼的管理，需要鏈接的庫和 obj 文件的管理；2）生成 hex 文件；3）界面模板 tpl 文件；4）測試用例tpl 文件的管理。

保護裝置的測試打樁程序以源程序的形式保存在上位機中，當用戶選擇某個測試用例時，需要編譯對應(yīng)的 c 文件和鏈接相應(yīng)的庫，生成 obj 文件，一組測試用例生成一個.out 或者一個 hex 執(zhí)行文件下載到目標板中?？紤]到目標系統(tǒng)的空間大小，一次全測試過程可以生成多個 hex 文件，在測試過程中分別下載。

下位機上執(zhí)行的每一種類型的測試用例需要在上位機中配置一個解析該測試用例的比對程序，比對程序以 dll 的形式駐留在上位機中，當上位機啟動下位機某一個測試用例的同時，需要裝載相對應(yīng)的比對 dll。該比對 dll 負責與下位機測試用例進行交互，得到測試結(jié)果返回給上位機測試報告模塊，統(tǒng)一形成測試報告。

一個 hex 文件中包含了多個測試用例，測試用例的啟動是通過上位機來啟動的，上位機告訴下位機現(xiàn)在執(zhí)行某個測試用例，這樣保證了上位機測試比對程序與下位機測試用例的一致性。當用例配置完成后，根據(jù)所配置的測試用例和測試用例的執(zhí)行順序生成測試用例入口源程序，并鏈接測試函數(shù)和系統(tǒng)庫函數(shù)，生成 hex 文件。

例如：在***.tpl 文件中，配置了測量量、CAN網(wǎng)、和事件 3 個測試點，測量并配置了刷新測試項和置值測試項，且 3 個測試點均在 DSP 板上運行。

生成的 init.c 源代碼為Init(uint8 testcase){ switch(testcase)Case 1:

SetMeasureValue(**,**,**);//測量量置值用例Break；Case 2：

P=SetMeasureByTimer(**,**,**) //p 為定時器中斷的函數(shù)指針Break;Case 3:

P= sendMessage (**,**,**) //CAN 網(wǎng)發(fā)送……………}

該測試用例入口函數(shù)由上位機生成，上位機通過內(nèi)部調(diào)試協(xié)議修改下位機變量 testcase 來控制測試用例的啟動，通過修改參數(shù)變量的值，來傳遞函數(shù)的參數(shù)。當生成源碼后，需要在 makefile 中添加鏈接 init.o、以及各測試函數(shù)所在的.o 文件，生成一個 hex 文件。

界面模板的 tpl 管理是指為了實現(xiàn)參數(shù)配置，界面風格是通過用戶根據(jù)測試項自定義的，本測試框架程序提供了一套可視化界面配置前端程序提供給用戶配置自定義的參數(shù)界面，配置后生成 tpl 文件，由測試工具解析顯示相應(yīng)的界面。

3.2 測試流程管理

流程控制功能包括以下兩個方面。

1）流程控制的配置

執(zhí)行順序表示測試項的順序執(zhí)行順序。

異?？刂票硎驹摐y試項如果不正確執(zhí)行，是繼續(xù)執(zhí)行、退出執(zhí)行或者跳轉(zhuǎn)執(zhí)行。

表示該測試項測試前是否具有初始化操作、測試完成后是否需要復位操作、斷開連接并重建連接操作，是否具有重新下載程序等操作。這些流程控制的配置信息在配置完成后都是以模板配置的形式保存在 PC 上位機中。

2）流程的自動控制

配置完測試用例的執(zhí)行順序后，系統(tǒng)根據(jù)配置信息，進行自動執(zhí)行。

3.3 測試結(jié)果的比對

測試結(jié)果的回送通過兩種方式：通過通信端口報文回送到 PC 機進行回讀判斷，通過 PC 機讀取變量的形式讀測試結(jié)果。

測試結(jié)果比對由測試用例對應(yīng)的 dll 完成，將測試結(jié)果的詳細信息送到測試報告模塊。

3.4 測試報告生成

在測試過程中，對于每個測試項會有一個簡單的結(jié)論，在測試完成后，生成一個詳細的測試報告。測試報告中的詳細信息，需要在測試比較模塊主動向測試報告的數(shù)據(jù)結(jié)構(gòu)輸入，生成測試用例時，按照一定的格式，生成測試報告。

4 CAN 網(wǎng)測試舉例

上文大篇幅地闡述了白盒測試的實現(xiàn)方法，如何通過白盒測試體系架構(gòu)來實現(xiàn)測試覆蓋率，進行各種邊緣測試、壓力測試以及負荷測試等具體功能及性能測試則依賴于測試用例的編寫以及實現(xiàn)上。

下面以 CAN 網(wǎng)測試為例，進行網(wǎng)絡(luò)壓力測試、CPU 負荷測試、疲勞測試及持久性測試。測試平臺的基本架構(gòu)如圖 4 所示。

CAN1 驅(qū)動模塊測試的單次測試過程為

1）PC 機通過調(diào)試變量下裝參數(shù)/控制命令到PPC 板和 GOOSE 板；

2）PPC 板或 GOOSE 板讀取到控制命令后，啟動[CAN1 測試程序]；

3）在[CAN1 測試程序]的執(zhí)行過程中，PPC 板或 GOOSE 板向 CAN1 網(wǎng)發(fā)、收數(shù)據(jù)；

4）PPC 或 GOOSE 板將[CAN1 測試程序]的執(zhí)行結(jié)果通過調(diào)試變量返回到 PC 機；

5）PC 機利用返回的調(diào)試變量值驗證測試結(jié)果。

在測試用例中對 CAN 網(wǎng)收發(fā)程序的語句進行靜態(tài)分析，對條件判斷等邏輯分支進行測試覆蓋，在一次測試用例中發(fā)送雙方發(fā)送各種異常/正確報文，使測試能夠覆蓋 CAN 網(wǎng)模塊的所有語句。

連續(xù)進行多次 CAN 網(wǎng)測試，從每秒 1 000 幀連續(xù)發(fā)送10 s 到每秒10 000幀連續(xù)發(fā)送10 s 進行遞增，對每次測試過程中，通過裝置中變量來記錄測試的信

息，然后將這些測試過程信息上送到 PC 機，由 PC機得出 CAN 網(wǎng)的穩(wěn)定性能時負荷值等重要參數(shù)。

5 結(jié)論

在ARP保護裝置系統(tǒng)中設(shè)計了一整體測試系統(tǒng)，不僅包括白盒測試來測試系統(tǒng)程序或者應(yīng)用程序，還包括整機測試和整屏系統(tǒng)。整機和整屏系統(tǒng)是閉環(huán)功能測試系統(tǒng)，但都融于本文介紹的這套測試體系框架之內(nèi)。這套測試系統(tǒng)為裝置的出廠測試、現(xiàn)場測試提供了很大的便利。