基于CodeTest工具的DCS系統嵌入式測試設計

摘要：介紹了CodeTest嵌入式測試工具廈其在大型DCS系統嵌入式測試中一種獨特測試方案的設計和實現。
關鍵詞：插樁覆蓋率內存泄漏嵌入式測試
隨著DCS系統的發展，迫切需要一種工具能夠在軟件開發的集成階段、系統階段等對DCS系統的軟件進行實時在線的測試與分析，以保證系統的性能和可靠性。
DCS系統長期運行的穩定性、實時性等特點，使得廠家對其軟件質量有著非常苛刻的要求，而DCS系統的分布式特點，又使得其集成測試、系統級測試非常困難。本文介紹一種獨特的DCS分布式系統的測試方案，對分布在一個網絡中多臺電腦上的各個系統模塊(每臺電腦運行多個系統模塊)同時測試，監視其覆蓋率、內存泄漏、運行性能等重要測試指標。測試工具選用美國Metrowerks公司的CodeTest嵌入式測試工具。
1 DCS系統概述
DCS系統一般是物理上分布的控制系統，有兩種基本結構：總線網結構和星型網結構。有些DCS客戶由于生產規模小，可能對系統要求不高，把服務器、工程師站、操作員站集于一臺機器上即可，但就其控制站和上機系統而言，整個系統在物理上、邏輯上仍然是分布式的。以總線結構為例，系統結構如圖l所示。

2 CodeTest嵌入式測試工具概述
CodeTest具有強大的測試分析功能。
由于CodeTest對軟件打點技術和從總線捕獲數據進行了改善和提升，正是這種原理上的優勢，使得CodeTest具有強大的性能分析、內存分析、高級覆蓋率分析和代碼跟蹤功能。
CodeTest工具主要有三個版本：一個是純硬件版，由于它不能滿足用戶的需求，早已被淘汰；另外兩個是純軟件版和硬件輔助軟件版，其中以硬件輔助軟件版最好。
純軟件測試工具的測試原理有兩個必需的任務——插樁函數和預處理任務。由于插入插樁函數和預處理任務的存在，使系統的代碼增大，對系統的運行效率有一定的影響。但是，隨著CPU速度和存儲技術不斷提高，純軟件版方案仍然可行。
3 DCS系統嵌入式測試方案設計
由于DCS系統比較復雜，服務器上有15個lib文件、20個exe任務，操作員站有4個dll工程和6個exe任務，這些模塊在管理網層構成一個實時運行的整體。測試一個程序或者一個測試用例，必將影響其他任務，例如：在操作員站上寫一個值到I／0控制站，改變一個閥門的開關狀態，這個值會被傳到實時數據庫，完成操作歷史記錄，然后送到系統網驅動，由與I／0站通信的gateway.exe和GatewayMonitor模塊發到現場控制站。工程師站主要用于離線組態，其dll工程和exe工程一共有十幾個，在進行工程組態時，會出現多個模塊同時運行。在下裝時，下裝任務模塊和服務器操作員站程序會同時運行(至少與操作員站、服務器的守護程序同時運行)，此時，要想把覆蓋率數據收集齊全，在以前是非常困難的。因為測試者的一個動作將會引起幾臺機器上的多個模塊的代碼執行。使用CodeTest測試工具，運用其設計巧妙的測試方案，終于解決了這個難題。
3．1 純軟件版CodoTest測試方法
用純軟件版CodeTest工具測試時，先用CodeTest進行插樁(打點)，生成exe或者其他可執行文件，然后在裝載測試程序的機器A上運行CodeTest的ctserver.exe,并設定其收集測試數據的端口，格式如下：
ctserver-p 3050
接著在機器B上(A和B也可以是同一臺機器)運行CodeTest Manager(ctmgr)，創建workspace，指定插樁文件、內存檢查目標文件、端口和etserver所在機器的IP地址，連接ctserver并執行。最后在A上運行需要測試的程序C.exe，這樣C.exe的執行情況、性能、覆蓋率、內存是否泄漏等數據都被采集在CodeTest Manager的Software Probe中。CodeTest Manager提供了友好的窗口界面，可以查看每個函數的運行覆蓋率，也可以查看每個文件的覆蓋率，還可以對測試結果進行保存、導出、合并等。
3．2 一個小的測試方案的分析與設計
圖l已經給出了DCS系統的體系結構．這里將結合CodeTest設計測試方案。
為了便于理解，先舉個簡單的設計實例：設一個小的軟件系統在A機和B機上運行。A機上運行著兩個進程(或任務模塊)：A1.exe和A2.exe，A1.exe使用ALIB1.1ib和ALIB2.1ib庫文件，A2.exe使用A.dll動態鏈接庫；B.exe運行在B機上，B.exe上的操作將引起A機上的兩個進程A1和A2。現在對A1、A2和B三個任務模塊組成的系統進行系統測試，監視其覆蓋率、內存泄漏、運行性能等重要測試指標。
測試方案如圖2，設C機(C機也可以是A機或者B機)用于收集測試數據。

對于這個簡單的系統，其測試系統已經不算簡單，而對于總共有60多個工程，至少有20個以上的進程同時運行的DCS綜合自動化控制系統，其測試方案圖就更復雜了，要考慮的問題就更多了。
圖2的子系統測試方案中，還有一些難點需要解決：
(1)對于A1和A2，怎樣同時采集代碼執行測試數據，調用lib靜態庫文件或者dll動態鏈接庫文件，怎樣才能查看這些庫文件的執行情況，是否在庫程序中存在內存泄呢?
經過探索得到解決方法如下：采用CodeTest的追加打點方法，將Al和A2以及它們的庫文件打點到一個符號數據庫文件(CodeTest打點生成的IDB文件，追加打點命令格式：-CTidb=E：\importan＼test.idb。CodeTest使用有很多細節上的技巧，請參見用戶手冊和軟件自帶的幫助文件)，用一個ctserver、一個通信端口采集測試數據。注意，為了在CodeTest Manager的Coverage Data中追蹤到代碼每一行的執行情況，必須在Configuration窗口內Source Code Directories中加入各源碼的路徑。
(2)A1和A2可能是由兩個工程師開發的，他們可能不愿意把測試數據混在一起。在這種情況下，可以在A機上運行兩個不同端口各自采集測試數據ctserver，在CodeTest Manager中也要多開一個Software Probe，并指定相應的配置。插樁時，也要分開插樁，生成各自的IDB符號庫文件。
3．3 大型DCS綜合自動化控制系統的測試方案
大型DCS綜合自動化控制系統的測試方案與上述小系統的測試方案類似，但要考慮插樁函數對DCS系統的影響。為了減輕這種影響，單獨用一個配置很高(內存1.5GB)的電腦H，運行codeTest Manager采集系統服務器、操作員站和工程師站的各個模塊的測試數據。這樣服務器、操作員站、工程師站只需運行采集測試數據的服務器ctservei，從而大太減輕測試系統的額外負擔。
電腦H成為測試數據的集中地，主要基于以下幾點考慮：
(1)測試數據集中起來，可直接導出測試報告進行合并，便于分析。尤其對覆蓋率太低的模塊，便于測試經理和開發工程師根據代碼的執行情況，找出哪些功能沒有相對應的測試用例，然后交給測試工程師進一步豐富測試用例。
(2)節省測試成本。集中收集測試信息，可以減少工作量。另一方面，也是受CodeTest的license的限制，當時只有一個網卡和一個license，只能在一臺機器上運行CodeTest Manager。當然，在條件好的情況下，用幾臺電腦分別收集服務器、操作員站和工程師站的數據，測試效果會更好。對軟件系統的影響最小，但成本也會相應增加。
綜上所述，制定DCS系統的測試方案如圖3所示。

從圖3可以看到，用到的ctserver比較多，主要原因有兩個，一是系統模塊比較多，而且很多模塊是不同的開發工程師負責開發維護，并且由另一個測試工程師測試。采用不同的ctserver可以把收集的測試信息分開，便于測試用例的分析討論、bug的分析、測試力度的分析。二是系統中每個模塊擔負著不同的任務或者完成某些功能，從而為功能測試提供便利。
3．4 DCS系統嵌入式測試方案實現
至此，測試方案設計完畢，由前面小系統的示例性實驗作指引，實現環節難點不多。按照codeTest的測試過程，先插樁，再搭建系統。由于系統龐大，exe工程和庫文件工程多，所以插樁本身就是一個難點，而且工作量也不小。但是，一旦插樁完成，生成exe文件后，就一直用這些可執行文件測試。系統源碼要放在CodeTestManager所在機器上，以便在以追蹤方式查看代碼執行情況時，追蹤到源碼的每一頁每一行。
筆要遇到的困難者主有以下兩點：
(1)插樁上的困難：系統用刊的庫文件比較多，每個庫都是一個vc工程。關鍵在于這個庫會被多個exe工程包含。為了避免測試系統搭建好后，出現idb符號數據庫與插樁后的程序不符，必須按照exe分別插樁。每插樁一個exe工程，先查一查它所依賴的庫文件，把庫文件的vc工程以idb符號數據庫追加方式插樁，把exe工程插樁后的符號數據庫追加在最后。
(2)測試系統運行的困難：系統的進程比較多，加上多個ctsever進程就更多。而系統的啟動過程，尤其是服務器的啟動是有規律有順序的。如果手動啟動程序，則啟動服務器將是一件痛苦的事。解決辦法是采用Windows腳本。例如連續啟動兩個進程，方法如下：