-
-
-
lxw19881017 | 当前状态：离线
总积分：0 2024年可用积分：0
注册时间： 0001-01-01
最后登录时间： 0001-01-01
-
-
基于CodeTest工具的DCS系统嵌入式测试设计
lxw19881017 发表于 2012/9/6 19:42:23 1703 查看 1 回复 [上一主题] [下一主题]
手机阅读
3．2 一个小的测试方案的分析与设计图l已经给出了DCS系统的体系结构．这里将结合CodeTest设计测试方案。
为了便于理解，先举个简单的设计实例：设一个小的软件系统在A机和B机上运行。A机上运行着两个进程(或任务模块)：A1.exe和A2.exe，A1.exe使用ALIB1.1ib和ALIB2.1ib库文件，A2.exe使用A.dll动态链接库；B.exe运行在B机上，B.exe上的操作将引起A机上的两个进程A1和A2。
现在对A1、A2和B三个任务模块组成的系统进行系统测试，监视其覆盖率、内存泄漏、运行性能等重要测试指标。
测试方案如图2，设C机(C机也可以是A机或者B机)用于收集测试数据。
对于这个简单的系统，其测试系统已经不算简单，而对于总共有60多个工程，至少有20个以上的进程同时运行的DCS综合自动化控制系统，其测试方案图就更复杂了，要考虑的问题就更多了。
图2的子系统测试方案中，还有一些难点需要解决：
(1)对于A1和A2，怎样同时采集代码执行测试数据，调用lib静态库文件或者dll动态链接库文件，怎样才能查看这些库文件的执行情况，是否在库程序中存在内存泄呢?
经过探索得到解决方法如下：采用CodeTest的追加打点方法，将Al和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采集系统服务器、操作员站和工程师站的各个模块的测试数据。这样服务器、操作员站、工程师站只需运行采集测试数据的服务器ctservei，从而大太减轻测试系统的额外负担。
电脑H成为测试数据的集中地，主要基于以下几点考虑：
(1)测试数据集中起来，可直接导出测试报告进行合并，便于分析。尤其对覆盖率太低的模块，便于测试经理和开发工程师根据代码的执行情况，找出哪些功能没有相对应的测试用例，然后交给测试工程师进一步丰富测试用例。
(2)节省测试成本。集中收集测试信息，可以减少工作量。另一方面，也是受CodeTest的license的限制，当时只有一个网卡和一个license，只能在一台机器上运行CodeTest Manager。当然，在条件好的情况下，用几台电脑分别收集服务器、操作员站和工程师站的数据，测试效果会更好。对软件系统的影响最小，但成本也会相应增加。
综上所述，制定DCS系统的测试方案如图3所示。
从图3可以看到，用到的ctserver比较多，主要原因有两个，一是系统模块比较多，而且很多模块是不同的开发工程师负责开发维护，并且由另一个测试工程师测试。采用不同的ctserver可以把收集的测试信息分开，便于测试用例的分析讨论、bug的分析、测试力度的分析。二是系统中每个模块担负着不同的任务或者完成某些功能，从而为功能测试提供便利。
3．4 DCS系统嵌入式测试方案实现
至此，测试方案设计完毕，由前面小系统的示例性实验作指引，实现环节难点不多。按照codeTest的测试过程，先插桩，再搭建系统。由于系统庞大，exe工程和库文件工程多，所以插桩本身就是一个难点，而且工作量也不小。但是，一旦插桩完成，生成exe文件后，就一直用这些可执行文件测试。系统源码要放在CodeTestManager所在机器上，以便在以追踪方式查看代码执行情况时，追踪到源码的每一页每一行。
笔要遇到的困难者主有以下两点：
(1)插桩上的困难：系统用刊的库文件比较多，每个库都是一个vc工程。关键在于这个库会被多个exe工程包含。为了避免测试系统搭建好后，出现idb符号数据库与插桩后的程序不符，必须按照exe分别插桩。每插桩一个exe工程，先查一查它所依赖的库文件，把库文件的vc工程以idb符号数据库追加方式插桩，把exe工程插桩后的符号数据库追加在最后。
(2)测试系统运行的困难：系统的进程比较多，加上多个ctsever进程就更多。而系统的启动过程，尤其是服务器的启动是有规律有顺序的。如果手动启动程序，则启动服务器将是一件痛苦的事。解决办法是采用Windows脚本。例如连续启动两个进程，方法如下：
对于分布式系统和嵌入式系统，CodeTest的确能提供独特的测试方案，尤其硬件辅助软件版的CodeTest工具，功能更加强大。CodeTest工具可以在测试的各个阶段设计不同的测试方案，还可以作为软件开发过程中的辅助工具。
3．2 一个小的测试方案的分析与设计图l已经给出了DCS系统的体系结构．这里将结合CodeTest设计测试方案。
为了便于理解，先举个简单的设计实例：设一个小的软件系统在A机和B机上运行。A机上运行着两个进程(或任务模块)：A1.exe和A2.exe，A1.exe使用ALIB1.1ib和ALIB2.1ib库文件，A2.exe使用A.dll动态链接库；B.exe运行在B机上，B.exe上的操作将引起A机上的两个进程A1和A2。
现在对A1、A2和B三个任务模块组成的系统进行系统测试，监视其覆盖率、内存泄漏、运行性能等重要测试指标。
测试方案如图2，设C机(C机也可以是A机或者B机)用于收集测试数据。
对于这个简单的系统，其测试系统已经不算简单，而对于总共有60多个工程，至少有20个以上的进程同时运行的DCS综合自动化控制系统，其测试方案图就更复杂了，要考虑的问题就更多了。
图2的子系统测试方案中，还有一些难点需要解决：
(1)对于A1和A2，怎样同时采集代码执行测试数据，调用lib静态库文件或者dll动态链接库文件，怎样才能查看这些库文件的执行情况，是否在库程序中存在内存泄呢?
经过探索得到解决方法如下：采用CodeTest的追加打点方法，将Al和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采集系统服务器、操作员站和工程师站的各个模块的测试数据。这样服务器、操作员站、工程师站只需运行采集测试数据的服务器ctservei，从而大太减轻测试系统的额外负担。
电脑H成为测试数据的集中地，主要基于以下几点考虑：
(1)测试数据集中起来，可直接导出测试报告进行合并，便于分析。尤其对覆盖率太低的模块，便于测试经理和开发工程师根据代码的执行情况，找出哪些功能没有相对应的测试用例，然后交给测试工程师进一步丰富测试用例。
(2)节省测试成本。集中收集测试信息，可以减少工作量。另一方面，也是受CodeTest的license的限制，当时只有一个网卡和一个license，只能在一台机器上运行CodeTest Manager。当然，在条件好的情况下，用几台电脑分别收集服务器、操作员站和工程师站的数据，测试效果会更好。对软件系统的影响最小，但成本也会相应增加。
综上所述，制定DCS系统的测试方案如图3所示。
从图3可以看到，用到的ctserver比较多，主要原因有两个，一是系统模块比较多，而且很多模块是不同的开发工程师负责开发维护，并且由另一个测试工程师测试。采用不同的ctserver可以把收集的测试信息分开，便于测试用例的分析讨论、bug的分析、测试力度的分析。二是系统中每个模块担负着不同的任务或者完成某些功能，从而为功能测试提供便利。
3．4 DCS系统嵌入式测试方案实现
至此，测试方案设计完毕，由前面小系统的示例性实验作指引，实现环节难点不多。按照codeTest的测试过程，先插桩，再搭建系统。由于系统庞大，exe工程和库文件工程多，所以插桩本身就是一个难点，而且工作量也不小。但是，一旦插桩完成，生成exe文件后，就一直用这些可执行文件测试。系统源码要放在CodeTestManager所在机器上，以便在以追踪方式查看代码执行情况时，追踪到源码的每一页每一行。
笔要遇到的困难者主有以下两点：
(1)插桩上的困难：系统用刊的库文件比较多，每个库都是一个vc工程。关键在于这个库会被多个exe工程包含。为了避免测试系统搭建好后，出现idb符号数据库与插桩后的程序不符，必须按照exe分别插桩。每插桩一个exe工程，先查一查它所依赖的库文件，把库文件的vc工程以idb符号数据库追加方式插桩，把exe工程插桩后的符号数据库追加在最后。
(2)测试系统运行的困难：系统的进程比较多，加上多个ctsever进程就更多。而系统的启动过程，尤其是服务器的启动是有规律有顺序的。如果手动启动程序，则启动服务器将是一件痛苦的事。解决办法是采用Windows脚本。例如连续启动两个进程，方法如下：
对于分布式系统和嵌入式系统，CodeTest的确能提供独特的测试方案，尤其硬件辅助软件版的CodeTest工具，功能更加强大。CodeTest工具可以在测试的各个阶段设计不同的测试方案，还可以作为软件开发过程中的辅助工具。