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