基于CodeTest工具的DCS系統(tǒng)嵌入式測試設(shè)計

    隨著DCS系統(tǒng)的發(fā)展，迫切需要一種工具能夠在軟件開發(fā)的集成階段、系統(tǒng)階段等對DCS系統(tǒng)的軟件進行實時在線的測試與分析，以保證系統(tǒng)的性能和可靠性。

    DCS系統(tǒng)長期運行的穩(wěn)定性、實時性等特點，使得廠家對其軟件質(zhì)量有著非?？量痰囊螅鳧CS系統(tǒng)的分布式特點，又使得其集成測試、系統(tǒng)級測試非常困 難。本文介紹一種獨特的DCS分布式系統(tǒng)的測試方案，對分布在一個網(wǎng)絡(luò)中多臺電腦上的各個系統(tǒng)模塊(每臺電腦運行多個系統(tǒng)模塊)同時測試，監(jiān)視其覆蓋率、 內(nèi)存泄漏、運行性能等重要測試指標(biāo)。測試工具選用美國Metrowerks公司的CodeTest嵌入式測試工具。

1 DCS系統(tǒng)概述
    DCS 系統(tǒng)一般是物理上分布的控制系統(tǒng)，有兩種基本結(jié)構(gòu)：總線網(wǎng)結(jié)構(gòu)和星型網(wǎng)結(jié)構(gòu)。有些DCS客戶由于生產(chǎn)規(guī)模小，可能對系統(tǒng)要求不高，把服務(wù)器、工程師站、操 作員站集于一臺機器上即可，但就其控制站和上機系統(tǒng)而言，整個系統(tǒng)在物理上、邏輯上仍然是分布式的。以總線結(jié)構(gòu)為例，系統(tǒng)結(jié)構(gòu)如圖l所示。

2 CodeTest嵌入式測試工具概述
    CodeTest具有強大的測試分析功能。

    由于CodeTest對軟件打點技術(shù)和從總線捕獲數(shù)據(jù)進行了改善和提升，正是這種原理上的優(yōu)勢，使得CodeTest具有強大的性能分析、內(nèi)存分析、高級覆蓋率分析和代碼跟蹤功能。

    CodeTest工具主要有三個版本：一個是純硬件版，由于它不能滿足用戶的需求，早已被淘汰；另外兩個是純軟件版和硬件輔助軟件版，其中以硬件輔助軟件版最好。

    純軟件測試工具的測試原理有兩個必需的任務(wù)——插樁函數(shù)和預(yù)處理任務(wù)。由于插入插樁函數(shù)和預(yù)處理任務(wù)的存在，使系統(tǒng)的代碼增大， 對系統(tǒng)的運行效率有一定的影響。但是，隨著CPU速度和存儲技術(shù)不斷提高，純軟件版方案仍然可行。

3 DCS系統(tǒng)嵌入式測試方案設(shè)計
    由于DCS系統(tǒng)比較復(fù)雜，服務(wù)器上有15個lib 文件、20個exe任務(wù)，操作員站有4個dll工程和6個exe任務(wù)，這些模塊在管理網(wǎng)層構(gòu)成一個實時運行的整體。測試一個程序或者一個測試用例，必將影 響其他任務(wù)，例如：在操作員站上寫一個值到I／0控制站，改變一個閥門的開關(guān)狀態(tài)，這個值會被傳到實時數(shù)據(jù)庫，完成操作歷史記錄，然后送到系統(tǒng)網(wǎng)驅(qū)動，由 與I／0站通信的gateway.exe和GatewayMonitor模塊發(fā)到現(xiàn)場控制站。工程師站主要用于離線組態(tài)，其dll工程和exe工程一共有 十幾個，在進行工程組態(tài)時，會出現(xiàn)多個模塊同時運行。在下裝時，下裝任務(wù)模塊和服務(wù)器操作員站程序會同時運行(至少與操作員站、服務(wù)器的守護程序同時運 行)，此時，要想把覆蓋率數(shù)據(jù)收集齊全，在以前是非常困難的。因為測試者的一個動作將會引起幾臺機器上的多個模塊的代碼執(zhí)行。使用CodeTest測試工 具，運用其設(shè)計巧妙的測試方案，終于解決了這個難題。

3．1 純軟件版CodoTest測試方法
    用純軟件版CodeTest工具測試時，先用CodeTest進行插樁(打點)，生成exe或者其他可執(zhí)行文件，然后在裝載測試程序的機器A上運行 CodeTest的ctserver.exe,并設(shè)定其收集測試數(shù)據(jù)的端口，格式如下：
    ctserver-p 3050

    接著在機器B上(A和B也可以是同一臺機器)運行CodeTest Manager(ctmgr)，創(chuàng)建workspace，指定插樁文件、內(nèi)存檢查目標(biāo)文件、端口和etserver所在機器的IP地址，連接 ctserver并執(zhí)行。最后在A上運行需要測試的程序C.exe，這樣C.exe的執(zhí)行情況、性能、覆蓋率、內(nèi)存是否泄漏等數(shù)據(jù)都被采集在 CodeTest Manager的Software Probe中。CodeTest Manager提供了友好的窗口界面，可以查看每個函數(shù)的運行覆蓋率，也可以查看每個文件的覆蓋率，還可以對測試結(jié)果進行保存、導(dǎo)出、合并等。[!--empirenews.page--]

3．2 一個小的測試方案的分析與設(shè)計
    圖l已經(jīng)給出了DCS系統(tǒng)的體系結(jié)構(gòu)．這里將結(jié)合CodeTest設(shè)計測試方案。

    為了便于理解，先舉個簡單的設(shè)計實例：設(shè)一個小的軟件系統(tǒng)在A機和B機上運行。A機上運行著兩個進程(或任務(wù)模塊)：A1.exe和A2.exe， A1.exe使用ALIB1.1ib和ALIB2.1ib庫文件，A2.exe使用A.dll動態(tài)鏈接庫；B.exe運行在B機上，B.exe上的操作將 引起A機上的兩個進程A1和A2?，F(xiàn)在對A1、A2和B三個任務(wù)模塊組成的系統(tǒng)進行系統(tǒng)測試，監(jiān)視其覆蓋率、內(nèi)存泄漏、運行性能等重要測試指標(biāo)。

    測試方案如圖2，設(shè)C機(C機也可以是A機或者B機)用于收集測試數(shù)據(jù)。

    對于這個簡單的系統(tǒng)，其測試系統(tǒng)已經(jīng)不算簡單，而對于總共有60多個工程，至少有20個以上的進程同時運行的DCS綜合自動化控制系統(tǒng)，其測試方案圖就更復(fù)雜了，要考慮的問題就更多了。

    圖2的子系統(tǒng)測試方案中，還有一些難點需要解決：

    (1)對于A1和A2，怎樣同時采集代碼執(zhí)行測試數(shù)據(jù)，調(diào)用lib靜態(tài)庫文件或者dll動態(tài)鏈接庫文件，怎樣才能查看這些庫文件的執(zhí)行情況，是否在庫程序中存在內(nèi)存泄呢?

    經(jīng)過探索得到解決方法如下：采用CodeTest的追加打點方法，將Al和A2以及它們的庫文件打點到一個符號數(shù)據(jù)庫文件(CodeTest打點生成的 IDB文件，追加打點命令格式：-CTidb=E：importan＼test.idb。CodeTest使用有很多細節(jié)上的技巧，請參見用戶手冊和軟 件自帶的幫助文件)，用一個ctserver、一個通信端口采集測試數(shù)據(jù)。注意，為了在CodeTest Manager的Coverage Data中追蹤到代碼每一行的執(zhí)行情況，必須在Configuration窗口內(nèi)Source Code Directories中加入各源碼的路徑。

    (2)A1和A2可能是由兩個工程師開發(fā)的，他們可能不愿意把測試數(shù)據(jù)混在一起。在這種情況下，可以在A機上運行兩個不同端口各自采集測試數(shù)據(jù) ctserver，在CodeTest Manager中也要多開一個Software Probe，并指定相應(yīng)的配置。插樁時，也要分開插樁，生成各自的IDB符號庫文件。

3．3 大型DCS綜合自動化控制系統(tǒng)的測試方案
    大型DCS綜合自動化控制系統(tǒng)的測試方案與上述小系統(tǒng)的測試方案類似，但要考慮插樁函數(shù)對DCS系統(tǒng)的影響。為了減輕這種影響，單獨用一個配置很高(內(nèi)存 1.5GB)的電腦H，運行codeTest Manager采集系統(tǒng)服務(wù)器、操作員站和工程師站的各個模塊的測試數(shù)據(jù)。這樣服務(wù)器、操作員站、工程師站只需運行采集測試數(shù)據(jù)的服務(wù)器 ctservei，從而大太減輕測試系統(tǒng)的額外負擔(dān)。

    電腦H成為測試數(shù)據(jù)的集中地，主要基于以下幾點考慮：
    (1)測試數(shù)據(jù)集中起來，可直接導(dǎo)出測試報告進行合并，便于分析。尤其對覆蓋率太低的模塊，便于測試經(jīng)理和開發(fā)工程師根據(jù)代碼的執(zhí)行情況，找出哪些功能沒有相對應(yīng)的測試用例，然后交給測試工程師進一步豐富測試用例。
    (2)節(jié)省測試成本。集中收集測試信息，可以減少工作量。另一方面，也是受CodeTest的license的限制，當(dāng)時只有一個網(wǎng)卡和一個 license，只能在一臺機器上運行CodeTest Manager。當(dāng)然，在條件好的情況下，用幾臺電腦分別收集服務(wù)器、操作員站和工程師站的數(shù)據(jù)，測試效果會更好。對軟件系統(tǒng)的影響最小，但成本也會相應(yīng) 增加。[!--empirenews.page--]

    綜上所述，制定DCS系統(tǒng)的測試方案如圖3所示。

    從圖3可以看到，用到的ctserver比較多，主要原因有兩個，一是系統(tǒng)模塊比較多，而且很多模塊是不同的開發(fā)工程師負責(zé)開發(fā)維護，并且由另一個測試工 程師測試。采用不同的ctserver可以把收集的測試信息分開，便于測試用例的分析討論、bug的分析、測試力度的分析。二是系統(tǒng)中每個模塊擔(dān)負著不同 的任務(wù)或者完成某些功能，從而為功能測試提供便利。

3．4 DCS系統(tǒng)嵌入式測試方案實現(xiàn)
    至此，測試方案設(shè)計完畢，由前面小系統(tǒng)的示例性實驗作指引，實現(xiàn)環(huán)節(jié)難點不多。按照codeTest的測試過程，先插樁，再搭建系統(tǒng)。由于系統(tǒng)龐大， exe工程和庫文件工程多，所以插樁本身就是一個難點，而且工作量也不小。但是，一旦插樁完成，生成exe文件后，就一直用這些可執(zhí)行文件測試。系統(tǒng)源碼 要放在CodeTestManager所在機器上，以便在以追蹤方式查看代碼執(zhí)行情況時，追蹤到源碼的每一頁每一行。

    筆要遇到的困難者主有以下兩點：
    (1)插樁上的困難：系統(tǒng)用刊的庫文件比較多，每個庫都是一個vc工程。關(guān)鍵在于這個庫會被多個exe工程包含。為了避免測試系統(tǒng)搭建好后，出現(xiàn)idb符 號數(shù)據(jù)庫與插樁后的程序不符，必須按照exe分別插樁。每插樁一個exe工程，先查一查它所依賴的庫文件，把庫文件的vc工程以idb符號數(shù)據(jù)庫追加方式 插樁，把exe工程插樁后的符號數(shù)據(jù)庫追加在最后。
    (2)測試系統(tǒng)運行的困難：系統(tǒng)的進程比較多，加上多個ctsever進程就更多。而系統(tǒng)的啟動過程，尤其是服務(wù)器的啟動是有規(guī)律有順序的。如果手動啟動 程序，則啟動服務(wù)器將是一件痛苦的事。解決辦法是采用Windows腳本。例如連續(xù)啟動兩個進程，方法如下：    　　　　　

    對于分布式系統(tǒng)和嵌入式系統(tǒng)，CodeTest的確能提供獨特的測試方案，尤其硬件輔助軟件版的CodeTest工具，功能更加強大。CodeTest工 具可以在測試的各個階段設(shè)計不同的測試方案，還可以作為軟件開發(fā)過程中的輔助工具。