随着DCS系统的发展，迫切需要一种工具能够在软件开发的集成阶段、系统阶段等对DCS系统的软件进行实时在线的测试与分析，以保证系统的性能和可靠性。
　　DCS系统长期运行的稳定性、实时性等特点，使得厂家对其软件质量有着非常苛刻的要求，而DCS系统的分布式特点，又使得其集成测试、系统级测试非常困难。本文介绍一种独特的DCS分布式系统的测试方案，对分布在一个网络中多台电脑上的各个系统模块（每台电脑运行多个系统模块）同时测试，监视其覆盖率、内存泄漏、运行性能等重要测试指标。测试工具选用美国Metrowerks公司的CodeTest嵌入式测试工具。
1 DCS系统概述
　　DCS系统一般是物理上分布的控制系统，有两种基本结构：总线网结构和星型网结构。有些DCS客户由于生产规模小，可能对系统要求不高，把服务器、工程师站、操作员站集于一台机器上即可，但就其控制站和上位机系统而言，整个系统在物理上、逻辑上仍然是分布式的。以总线结构为例, 系统结构如图1所示。

2 CodeTest嵌入式测试工具概述
　　CodeTest具有强大的测试分析功能。
　　由于CodeTest对软件打点技术和从总线捕获数据进行了改善和提升，正是这种原理上的优势，使得CodeTest具有强大的性能分析、内存分析、高级覆盖率分析和代码跟踪功能。
　　CodeTest工具主要有三个版本：一个是纯硬件版，由于它不能满足用户的需求，早已被淘汰；另外两个是纯软件版和硬件辅助软件版，其中以硬件辅助软件版最好。
　　纯软件测试工具的测试原理有两个必需的任务——插桩函数和预处理任务。由于插入插桩函数和预处理任务的存在，使系统的代码增大，对系统的运行效率有一定的影响。但是，随着CPU速度和存储技术不断提高，纯软件版方案仍然可行。
3 DCS系统嵌入式测试方案设计
　　由于DCS系统比较复杂，服务器上有15个lib文件、20个exe任务，操作员站有4个dll工程和6个exe任务，这些模块在管理网层构成一个实时运行的整体。测试一个程序或者一个测试用例" title="测试用例">测试用例，必将影响其他任务，例如：在操作员站上写一个值到I/O控制站，改变一个阀门的开关状态，这个值会被传到实时数据库，完成操作历史记录，然后送到系统网驱动，由与I/O站通信的gateway.exe和GatewayMonitor模块发到现场控制站。工程师站主要用于离线组态，其dll工程和exe工程一共有十几个，在进行工程组态时，会出现多个模块同时运行。在下装时，下装任务模块和服务器操作员站程序会同时运行（至少与操作员站、服务器的守护程序同时运行），此时，要想把覆盖率数据收集齐全，在以前是非常困难的。因为测试者的一个动作将会引起几台机器上的多个模块的代码执行。使用CodeTest测试工具，运用其设计巧妙的测试方案，终于解决了这个难题。
3.1 纯软件版CodeTest测试方法
　　用纯软件版CodeTest工具测试时，先用CodeTest进行插桩（打点），生成exe或者其他可执行文件，然后在装载测试程序的机器A上运行CodeTest的ctserver.exe，并设定其收集测试数据的端口，格式如下：
　　ctserver－p 3050
　　接着在机器B上(A和B也可以是同一台机器)运行CodeTest Manager(ctmgr)，创建workspace，指定插桩文件、内存检查目标文件、端口和ctserver所在机器的IP地址，连接ctserver并执行。最后在A上运行需要测试的程序C.exe，这样C.exe的执行情况、性能、覆盖率、内存是否泄漏等数据都被采集在CodeTest Manager的Software Probe中。CodeTest Manager提供了友好的窗口界面，可以查看每个函数的运行覆盖率，也可以查看每个文件的覆盖率，还可以对测试结果进行保存、导出、合并等。
3.2 一个小的测试方案的分析与设计
　　图1已经给出了DCS系统的体系结构，这里将结合CodeTest设计测试方案。
　　为了便于理解，先举个简单的设计实例：设一个小的软件系统在A机和B机上" title="机上">机上运行。A机上运行着两个进程(或任务模块)：A1.exe和A2.exe，A1.exe使用ALIB1.lib和ALIB2.lib库文件，A2.exe使用A.dll动态链接库；B.exe运行在B机上，B.exe上的操作将引起A机上的两个进程A1和A2。现在对A1、A2和B三个任务模块组成的系统进行系统测试，监视其覆盖率、内存泄漏、运行性能等重要测试指标。
　　测试方案如图2，设C机（C机也可以是A机或者B机）用于收集测试数据。

　　对于这个简单的系统，其测试系统" title="测试系统">测试系统已经不算简单，而对于总共有60多个工程，至少有20个以上的进程同时运行的DCS综合自动化控制系统，其测试方案图就更复杂了，要考虑的问题就更多了。
　　图2的子系统测试方案中，还有一些难点需要解决：
　　(1)对于A1和A2，怎样同时采集代码执行测试数据，调用lib静态库文件或者dll动态链接库文件，怎样才能查看这些库文件的执行情况，是否在库程序中存在内存泄漏呢？
　　经过探索得到解决方法如下：采用CodeTest的追加打点方法，将A1和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采集系统服务器、操作员站和工程师站的各个模块的测试数据。这样服务器、操作员站、工程师站只需运行采集测试数据的服务器ctserver，从而大大减轻测试系统的额外负担。
　　电脑H成为测试数据的集中地，主要基于以下几点考虑：
　　(1)测试数据集中起来，可直接导出测试报告进行合并，便于分析。尤其对覆盖率太低的模块，便于测试经理和开发工程师根据代码的执行情况，找出哪些功能没有相对应的测试用例，然后交给测试工程师进一步丰富测试用例。
　　(2)节省测试成本。集中收集测试信息，可以减少工作量。另一方面，也是受CodeTest的license的限制，当时只有一个网卡和一个license，只能在一台机器上运行CodeTest Manager。当然，在条件好的情况下，用几台电脑分别收集服务器、操作员站和工程师站的数据，测试效果会更好，对软件系统的影响最小，但成本也会相应增加。
　　综上所述，制定DCS系统的测试方案如图3所示。
　　从图3可以看到，用到的ctserver比较多，主要原因有两个，一是系统模块比较多，而且很多模块是不同的开发工程师负责开发维护，并且由另一个测试工程师测试。采用不同的ctserver可以把收集的测试信息分开，便于测试用例的分析讨论、bug的分析、测试力度的分析。二是系统中每个模块担负着不同的任务或者完成某些功能，从而为功能测试提供便利。