圖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所示。
