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

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

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

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

　　1 DCS系統(tǒng)概述

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

　　2 CodeTest嵌入式測試工具概述

　　CodeTest具有強大的測試分析功能。

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

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

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

　　3 DCS系統(tǒng)嵌入式測試方案設計

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

　　3．1 純軟件版CodoTest測試方法

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

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

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

　　為了便于理解，先舉個簡單的設計實例：設一個小的軟件系統(tǒng)在A機和B機上運行。A機上運行著兩個進程(或任務模塊)：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三個任務模塊組成的系統(tǒng)進行系統(tǒng)測試，監(jiān)視其覆蓋率、內存泄漏、運行性能等重要測試指標。

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

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

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

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

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

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

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

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

　　電腦H成為測試數(shù)據(jù)的集中地，主要基于以下幾點考慮：

　　(1)測試數(shù)據(jù)集中起來，可直接導出測試報告進行合并，便于分析。尤其對覆蓋率太低的模塊，便于測試經理和開發(fā)工程師根據(jù)代碼的執(zhí)行情況，找出哪些功能沒有相對應的測試用例，然后交給測試工程師進一步豐富測試用例。

　　(2)節(jié)省測試成本。集中收集測試信息，可以減少工作量。另一方面，也是受CodeTest的license的限制，當時只有一個網卡和一個license，只能在一臺機器上運行CodeTest Manager。當然，在條件好的情況下，用幾臺電腦分別收集服務器、操作員站和工程師站的數(shù)據(jù)，測試效果會更好。對軟件系統(tǒng)的影響最小，但成本也會相應增加。

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

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

　　3．4 DCS系統(tǒng)嵌入式測試方案實現(xiàn)

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

　　筆要遇到的困難者主有以下兩點：

　　(1)插樁上的困難：系統(tǒng)用刊的庫文件比較多，每個庫都是一個vc工程。關鍵在于這個庫會被多個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)的啟動過程，尤其是服務器的啟動是有規(guī)律有順序的。如果手動啟動程序，則啟動服務器將是一件痛苦的事。解決辦法是采用Windows腳本。例如連續(xù)啟動兩個進程，方法如下：

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