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