摘要：介紹了CodeTest嵌入式測試工具廈其在大型DCS系統(tǒng)嵌入式測試中一種獨特測試方案的設(shè)計和實現(xiàn)。

關(guān)鍵詞：嵌入式測試CodeTest工具DCS系統(tǒng)

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

DCS系統(tǒng)長期運行的穩(wěn)定性、實時性等特點，使得廠家對其軟件質(zhì)量有著非?？量痰囊?，而DCS系統(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ù)的端口。

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

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。

現(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ù)。注意，為了在CodeTestManager的CoverageData中追蹤到代碼每一行的執(zhí)行情況，必須在Configuration窗口內(nèi)SourceCodeDirectories中加入各源碼的路徑。

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

3．3大型DCS綜合自動化控制系統(tǒng)的測試方案

大型DCS綜合自動化控制系統(tǒng)的測試方案與上述小系統(tǒng)的測試方案類似，但要考慮插樁函數(shù)對DCS系統(tǒng)的影響。為了減輕這種影響，單獨用一個配置很高（內(nèi)存1.5GB）的電腦H，運行codeTestManager采集系統(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，只能在一臺機器上運行CodeTestManager。當(dāng)然，在條件好的情況下，用幾臺電腦分別收集服務(wù)器、操作員站和工程師站的數(shù)據(jù)，測試效果會更好。對軟件系統(tǒng)的影響最小，但成本也會相應(yīng)增加。

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

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

3．4DCS系統(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ī)律有順序的。如果手動啟