程序测试工程自动生成系统和方法与流程

1.本发明涉及计算机程序测试技术领域，特别是涉及一种程序测试工程自动生成系统和方法。


背景技术：

2.程序测试工具软件,例如c++test、test bed、visual unit，通常具有工程(project)菜单，包含新建工程、打开工程、工程属性等命令。软件测试工具的工程称为程序测试工程或称为测试工程。
3.这里说的程序测试，是指代码级的测试，也就是对被测试程序进行以下一种或多种测试:
4.静态测试：包括代码规范检查和静态扫描代码缺陷；
5.动态测试，包括：
6.单元测试：针对代码单元(如函数或类)的测试；
7.集成测试：也叫组装测试或联合测试，将模块组装成子系统或系统进行测试；
8.接口测试、部件测试等，这些测试，实际上就是对部分代码的单元或集成测试。
9.所以，这里说的程序测试工程，是指为了对被测试程序进行代码级测试，测试工具所建立的工程。
10.建立可用的测试工程，是当前代码级测试的难点和痛点：
11.1、要建立真正可用的测试工程，步骤多，配置复杂，难以掌握。初学者一开始就遇到陡峭的学习曲线，容易放弃。建立工程并非日常工作，难以做到熟练，且每个被测试项目各有不同，因此，即使是经验丰富者，也会在建立工程上耗费大量时间。有些测试工具的建立工程过程看起来很简单，只要指定被测试代码的目录就行了，但这通常离“可用”还有很远的距离，后续需要把缺少的数据补充设置好才“可用”。
12.2、一个单位可能多达十几二十种开发环境，不同环境对应的测试工程，建立过程可能不同，很容易误入岐途，浪费时间，耗费耐心。
13.3、失败率高。动态测试能够进行的前提是能够构建出可执行程序，但在实际工作中，常常会产生大量错误并且难以解决，无法构建出可执行的测试程序，使测试无法进行。
14.4、技术支持成本高。建立可用测试工程的困难，使用户严重依赖工具厂商的技术支持。前面所述的测试工具visual unit是本发明申请人广州凯乐软件技术公司的产品，就visual unit而言，建立可用测试工程方面的技术支持成本，达到总的技术支持成本的一半以上。对于无法提供充分技术支持的厂商来说，用户通常会因为测试“跑不起来”而放弃，一方面导致高价采购的测试工具搁置，另一方面，造成代码级测试工作无法完成，影响软件产品质量、延长开发周期、增加开发成本。
15.可用的测试工程包含哪些基本要素？为什么建立可用的测试工程难度会这么高？
16.可用的测试工程，必须包含被测试工程的工程数据，而被测试工程的工程数据，由被测试工程的开发环境管理，这些工程数据，是经过不断修改、增减、积累形成的，连被测试
工程的开发者，也未必能完整列出，特别是有些被测试工程，已有十年甚至二十多年的历史，经历了很多代开发者，更是连设置这些工程数据的开发者也找不到了。
17.被测试工程的工程数据，具体包括哪些内容呢？为什么可用的测试工程，必须包含被测试工程的工程数据呢？
18.被测试工程，就是软件开发过程中的产品工程，产品工程用于构建一个或一组目标程序，形成软件产品。软件开发的常用工具是集成开发环境，简称ide，例如visual studio、eclipse、codeblocks等。多数ide都具有工程(project,也可称为项目)菜单，一般有以下命令：新建工程、打开工程、工程属性、清理工程、编译工程、构建工程等。产品工程需要测试时，就是被测试工程。
19.如果用ide新建一个工程，ide所做的，通常是建立一个或多个工程文件，保存工程数据。如果用ide打开一个工程，ide所做的，通常是读取指定的工程文件，将工程数据载入内存。新建或打开工程后，就可以执行构建工程命令，以产生软件产品，ide会调用构建工具软件完成构建，如果缺少必要的数据或资源，构建工具软件会报告错误。所以，产品工程(即被测试工程)的工程数据，是指用于构建一个或一组目标程序的数据，这些数据，通常保存在一个或多个工程文件中。有些开发工具，使用makefile文件或中间文件(例如，cmake的cmakelists.txt文件)来管理工程数据，这些，也是工程文件，这类开发环境可能不具有新建工程、打开工程、工程属性等命令，而是由用户直接编辑工程文件。
20.工程数据具体有哪些呢？或者说，构建一个或一组目标程序需要哪些数据呢？这是由构建过程的内容和步骤决定的。构建过程，把高级程序设计语言所编写的程序代码，翻译成计算机可执行的机器语言，并结合其他必要的资源或外部程序，构建成一个或一组可供计算机执行(单独执行或作为其他可执行程序的一部分)的目标程序。目标程序，也就是产品工程的构建输出，常见形式有：可执行程序、动态库、静态库。高级程序设计语言，是指人类能够编写和阅读的计算机语言，也就是开发语言，如c语言或c++语言(c/c++)。不同的开发语言，构建过程有所不同，例如，c/c++语言的工程，构建过程一般有以下步骤：
21.1.预处理步骤，由预处理器完成：
22.1)将所有的#define删除，并且展开所有的宏定义。
23.2)处理所有的条件预编译指令，比如#if、#ifdef、#elif、#else、#endif等。
24.3)处理#include预编译指令，将被包含的文件直接插入到预编译指令的位置。
25.4)删除所有的注释。
26.5)添加行号和文件标识，以便编译时产生调试用的行号及编译错误警告行号。
27.2.前端编译步骤,一般由编译器前端完成：
28.1)词法分析：扫描器将源代的字符序列分割成一系列的记号(token)。
29.2)语法分析：语法分析器分析记号系列产生语法树(syntax tree)。
30.3)语义分析：进行静态语义分析和动态语义分析。静态语义是编译期可以确定的语义，动态语义是运行期才能确定的语义。
31.4)源代码优化：将整个语法树转化为中间代码(intermediate code,中间代码是与目标机器和运行环境无关的)。中间代码使得编译器被分为前端和后端。编译器前端负责产生机器无关的中间代码；编译器后端将中间代码转化为目标机器代码。
32.3.目标代码生成与汇编，一般由编译器后端和汇编器完成：
33.1)生成目标代码，如生成计算机可识别的机器码。
34.2)目标代码优化，提升执行效率，降低代码体积。
35.3)汇编步骤，由汇编器完成：
36.将目标机器代码翻译成机器语言指令，把这些指令打包成称为可重定位目标程序的文件，文件后缀一般为.o或.obj。
37.4.链接步骤，由链接器完成：
38.将各种代码和数据片段收集并组合成为一个单一文件，这个文件可被加载(复制)到内存并执行。链接可以执行于编译时(compile time)，也就是在源代码被翻译成机器代码时；也可以执行于加载时(load time)，也就是在程序被加载器(loader)加载到内存并执行时；甚至执行于运行时(run time)，也就是由应用程序来执行。一个工程，通常需要链接外部的已编译代码，称为库，例如，ide自带的基础库，或第三方库。
39.5.其他步骤
40.例如，qt工程还具有前置处理步骤，在预处理步骤前，用前置处理器qmake生成qt环境的支持文件，例如元数据文件。
41.从以上构建步骤可以看出，构建出一个或一组目标程序是一个复杂的过程。代码的复用性，使构建过程进一步复杂化。为了减少工作量，降低开发成本，开发人员会尽可能提高代码的复用性。代码复用，是指同一份代码，可在不同的工程中使用。代码复用，通常是部分复用，一个工程只使用部分文件，一个文件还可能只使用部分代码。因此，被测试工程的工程数据，通常要指定具体编译哪些文件(如c/c++的源文件清单)，以及本工程使用的编译条件(如c/c++的条件宏)，用以区分本工程使用和不使用的代码，以使编译器编译到正确的代码。
42.以c/c++为例，为了完成构建，通常需要以下工程数据(部分或全部)：
43.源文件清单及源文件目录，目录就是文件的存放位置；
44.包含文件的搜索目录，包括用户头文件搜索目录以及系统头文件搜索目录；
45.预定义数据，如：条件宏，通常用于指定编译哪些代码，也称为编译条件；内置宏，一般用于指定常量的值；内置数据类型，指定构建工具自行定义的数据类型；
46.前置包含的头文件，即自动包含的头文件；
47.使用的库文件，即需链接的库文件清单；
48.库文件的搜索目录，告诉链接器到何处去查找库文件；
49.不使用的缺省库文件，链接器通常有缺省的库文件清单，可以指定全部或部分排除；
50.编程语言名称及版本，语言如c或c++，版本如c99、c++11、c++14。
51.还可能需要更多的工程数据，例如预编译头文件、字节对齐数、其他编译或链接选项。
52.工程数据通常保存在一个或多个工程文件中。不同的开发环境，具有不同形式的工程文件，大致可以分为三类：
53.1、私有格式的工程文件，例如visual studio系列的工程文件，多数嵌入式项目开发环境的工程文件；
54.2、makefile文件，例如使用gcc、g++作为编译器的开发环境，通过make程序，解析
makefile文件并执行构建过程；
55.3、中间文件，用于生成私有格式的工程文件或makefile文件，例如cmakelists.txt，是cmake支持的中间文件，cmake可以依据其内容，生成私有格式的工程文件或makefile文件。
56.后两种工程文件，并非ide私有，而是通过调用cmake或make之类的工具来生成工程文件或完成构建，但由于cmake或make之类的工具也有众多版本，因此，中间文件或makefile文件也有大同小异的众多版本。
57.在缺少工程数据的情形下，一般是无法构建出目标程序的，例如，只知道源文件的保存目录，就试图构建目标程序的话，可能会面临以下问题：
58.不确定哪些源文件是有效的，目录下可能保存无效的或无关的源文件。
59.不了解头文件搜索位置及顺序，可能找不到头文件或找到错误的头文件。
60.不掌握编译条件，可能读到错误的代码，抛弃正确的代码。
61.可能还会面临更多的问题，例如数据类型缺少定义、常量的值不了解、适用的语言版本不明，等等。
62.显然，不掌握工程数据，连最基本的预处理都可能无法进行。
63.以上说明了被测试工程的工程数据，这些数据，是开发者根据需要自行设置的，项目开发过程中，随时可能修改(一般是不断补充)，通常，项目历史越长、规模越大，工程数据越复杂。
64.要建立可用的测试工程，测试工具需要掌握被测试工程的工程数据，因为，测试过程需要对被测试代码进行解析和编译(静态测试只需要解析)，要完成解析和编译，掌握被测试工程的工程数据是前提条件。只有掌握被测试工程的工程数据，测试工具才能准确掌握需要测试的具体代码，以及了解如何去解析、编译、执行这些代码。
65.下面以c/c++为例，简述测试工具的一般工作步骤：
66.1、对被测试工程进行预处理，相当于构建被测试工程的预处理步骤；
67.2、解析被测试代码，对被测试代码进行词法分析、语法分析、语义分析，得到语法树，也就是完成编译器前端的工作，但不需要生成目标代码，相当于构建被测试工程的前端编译步骤；
68.3、根据测试种类，进行后续工作：
69.3.1静态测试：以步骤2生成的语法树为输入，进行代码规范检查和代码缺陷扫描。
70.3.2动态测试：生成桩代码、测试驱动代码，自动添加用例或用户添加用例，并调用构建工具，构建出可执行程序执行测试。构建可执行程序的过程中，既要编译链接被测试代码，也要编译和链接测试工具添加的代码。
71.从以上步骤可以看出,对于动态测试，测试工具需要掌握被测试工程几乎全部工程数据，对于静态测试，测试工具需要掌握除链接属性及执行属性以外的被测试工程的工程数据。被测试工程可能是不完整的，例如，开发初期的工程，可能只有一两个源文件和少量代码，还不能构建出最终的目标程序。对于代码级测试来说，也不一定针对整个被测试工程，而可能只测试其中的部分文件或代码。即使被测试工程不完整，或者只测试部分代码，测试工具也必须掌握如何编译被测试代码，仍然需要掌握除链接属性及执行属性以外的被测试工程的工程数据。
72.因此，测试工程的工程数据，包括两部分：
73.1、被测试工程的工程数据。
74.2、用于测试工作的数据，如：
75.测试工程的工作目录；
76.测试结果保存目录；
77.需测试的源文件清单。
78.视需要还可能需要其他数据，例如，桩代码目录、驱动代码目录等。
79.可以看出，测试工程中，第2部分数据是自主添加的(由用户设定或根据被测试工程的目录自动设置)，视需添加即可，没有难度。有难度的是第1部分，即被测试工程的工程数据。测试工具要取得被测试工程的工程数据，一般有两种方式：
80.1、手工方式，即由用户自行设置。
81.2、导入方式，从被测试工程的工程文件导入。
82.导入方式是当前自动化程度较高的方式，以visual unit 4.7为例，有两个导入方式：
83.直接解析工程文件或makefile文件。扫描工程文件或makefile文件，从中提取被测试工程的工程信息。缺点有：
84.1、工程文件是ide的私有文件，不同的ide，文件格式不同，ide升级时，旧版本的导入方式可能失效。
85.2、ide数量较多，例如，嵌入式的开发环境种类繁多，难于实现全覆盖。
86.3、部分ide的工程文件是二进制文件，无法提取信息。
87.4、从makefile文件提供信息，通常失败或只能提取小部分信息。
88.5、工程文件中的数据本身不完整，ide可能有内置的设定，并未在工程文件中体现。
89.用make程序生成命令行并导入。有些make程序提供了不编译直接打印编译命令行的功能，一般使用以下命令，可以生成命令行：make-b-k-n》filename.txt。缺点有：
90.1、仅适用部分工程。对于使用makefile的工程，也并不是全部都可以生成命令行。对于不使用makefile的工程，则完全不适用。
91.2、对于测试人员有一定难度。生成命令行文件对于开发人员难度不大，但对于测试人员则有一定难度，需要花一些时间学习和尝试。由于完成一个工程的测试可能需要较长时间，等建立下一个项目的测试工程时，通常已经忘了以前的做法，又要重新学习。
92.3、生成的命令行实际上是make程序的输出，有一定随意性，并可能混杂了较多无效信息，可能干扰对工程数据的提取。make程序本身有很多版本，不同版本生成的命令行文件有各种差异，工具对命令行文件的解析功能不具有确定的能用性，常常解析失败。
93.4、此方式比直接解析工程文件或makefile文件实际上还多了一个步骤，增加了复杂度。
94.以上是visual unit 4.7导入被测试工程数据的过程。即使成功导入，仍然需要人工检查，并可能需要手工选择或设置一些被测试工程的工程数据，因为导入的数据常常是不完整的。
95.从目前常见的代码级软件测试工具的建立测试工程的方式来看，visual unit是
自动化程度较高的一款。visual unit从2002年开始研发，2005年发布v1.0，如果从开始研发算起，至今已超过20年。20年来，在建立测试工程这一功能上，visual unit研发团队持续投入，不断改进，开发了较为完整的自动导入功能，支持visual c++系列、keil、iar、qt等开发环境下的被测试工程的自动导入，也支持一些makefile项目的命令行导入，并且尽全力提供技术支持，基本上避免了因建立测试工程后无法执行测试而不得不放弃的情形，但建立可用测试工程的困难，使用户严重依赖工具厂商的技术支持，此方面技术支持成本达到总的技术支持成本的一半以上。对于无法提供充分技术支持的厂商来说，用户通常会因为测试“跑不起来”而放弃，一方面导致高价采购的测试工具搁置，另一方面，造成代码级测试工作无法完成，影响软件产品质量、延长发周期、增加开发成本。
96.综上所述，迫切需要一种自动生成测试工程的技术，以自动建立可用的测试工程。


技术实现要素：

97.针对现有技术的不足，本发明提供一种自动生成测试工程的系统和方法。
98.为了解决上述技术问题，本发明提出的技术方案是：
99.一种程序测试工程自动生成系统，用于为被测试工程的代码级测试生成测试工程，包括：
100.监听标的设定装置，用于设定需监听的构建进程；所述构建进程，是指正在运行的构建工具软件的实例；所述构建工具软件，是指用于将所述被测试工程的用高级语言编写的程序转换成低级语言形式的目标程序的计算机软件；
101.监听装置，用于监听所述构建进程，获取所述构建进程的环境数据；
102.解析装置，用于解析所述环境数据，获取所述被测试工程的工程数据；
103.生成装置，用于存储测试工程的工程数据，所述测试工程的工程数据，包括所述被测试工程的工程数据。
104.另一方面，本发明还提供了一种程序测试工程自动生成方法，用于为被测试工程的代码级测试生成测试工程，包括：
105.监听标的设定步骤：设定需监听的构建进程；所述构建进程，是指正在运行的构建工具软件的实例。所述构建工具软件；是指用于将所述被测试工程的用高级语言编写的程序转换成低级语言形式的目标程序的计算机软件；
106.监听步骤：监听所述构建进程，获取所述构建进程的环境数据；
107.解析步骤：解析所述环境数据，获取所述被测试工程的工程数据；
108.生成步骤：存储测试工程的工程数据，所述测试工程的工程数据，包括所述被测试工程的工程数据。
109.本发明提出的自动生成测试工程的系统和方法，突破了从被测试工程的工程文件中获取被测试工程的工程数据的惯例和思维惯性，改为自动监听被测试工程的构建进程的临时环境数据从而获取被测试工程的工程数据。
110.被测试工程的工程文件，是可见的、可读的、长期存在的、通常也是可直接或间接解析的，同时，能构建的工程都存在这类文件，因此，从这些文件中提取工程数据，看起来是理所当然的路径，甚至是唯一的路径，在实践中，这条件路径也为无数的项目成功地构建了测试工程。
111.被测试工程的构建进程，是短暂的(例如，有些ide的编译进程，一次只编译一个源文件，执行时间长则几秒，短则以毫秒计)，其环境数据，一般不是自然可见的，正因为如此，其对测试工具的意义长期被忽略。
112.作为一个全新的技术方案，与现有技术相比，本发明具有以下优点：
113.1、自动化程度高。通过自动监听及自动解析来获取被测试工程数据，不需要手工设置被测试工程数据；
114.2、完整性及准确性高。可以获取被测试工程的完整工程数据，生成测试工程后，通常不再需要添加或修改工程数据；
115.3、使用同一方式来生成测试工程。对于用户来说，所有开发环境，都采用同样的方式生成测试工程。在现有技术下，不同的开发环境，可能要选择不同的模板、选择不同的导入数据方式等，容易让新手无所适从；
116.4、便以迁移。测试工程经常需要迁移到其他计算机上，同一个被测试项目，在不同计算机上可能保存在不同位置，所依赖的环境更是可能安装在不同位置，给迁移造成困难。利用本发明，迁移后可以重新获取被测试工程的工程数据，从而解决迁移问题。
附图说明
117.下面结合附图对本发明的具体实施方式作进一步详细的说明：
118.图1是本发明的实施例一种自动生成测试工程的系统的结构示意图；
119.图2是本发明实施例监听装置所获得的环境数据示例；
120.图3a是本发明其中一实施例中开始监听的界面；
121.图3b是本发明其中一实施例中接收到监听信息的界面；
122.图3c本发明其中一实施例中显示测试工程数据供用户确认后生成测试工程；
123.图4a为现有技术生成测试工程过中用于选择模板的界面截屏图；
124.图4b为现有技术生成测试工程过中用于导入数据的界面截屏图；
125.图4c为现有技术生成测试工程过中用于常规设置的界面截屏图；
126.图4d为现有技术生成测试工程过中用于测试目标选择的界面截屏图；
127.图4e为现有技术生成测试工程过中用于编译选项设置的界面截屏图；
128.图4f为现有技术生成测试工程过中用于链接选项设置的界面截屏图；
129.图4g为现有技术生成测试工程过中用于高级选项设置的界面截屏图。
具体实施方式
130.本发明实施例使用的术语是c语言或c++语言的术语，但不代表本发明只适用于c语言和c++语言，也不代表是对本发明的限制。
131.图1是本发明的基本实施例的总体构成示意图，如图1所示，本实施例包括下述装置：监听标的设定装置101、监听装置102、解析装置103、生成装置104，其中
132.监听标的设定装置101，用于设定需监听的构建进程。监听标的设定装置101的基本功能，是为监听装置102提供监听标的。无论使用何种方式，只要让监听装置102了解哪个进程需要监听，就实现了监听标的设定装置101的功能。下面是几种实施方式：
133.一、实现为清单装置，预先设定需监听的构建进程清单，这样就可以让监听装置
102了解哪些进程需要监听，这是最直接的方式。构建进程，是指正在运行的构建工具软件的实例，例如，名称为cl.exe的构建工具软件，当它正在运行的时候，形成一个进程，就是构建进程，进程的名称通常与程序名称相同，也是cl.exe，因此，构建进程清单，大致相当于构建工具软件清单。构建工具软件，是指用于将被测试工程的用高级语言编写的程序转换成低级语言形式的目标程序的计算机软件，比较常用的是编译器和链接器，因此，构建进程清单可以只列出编译器和链接器。清单的目的，是为了让监听装置102识别构建进程，因此，凡是能表达构建进程的特征供监听装置102识别的数据项都可以作为清单的内容，例如，构建进程的名程、窗口标题、路径片段。其中，最简单的特征是构建工具软件的名称，例如，visual c++各个版本的编译器名称均为cl.exe，链接器名程均为link.exe；gnu c/c++的编译器，在windows上时，名称一般为gcc.exe/g++.exe，链接器为gcc.exe/g++.exe或ld.exe，在linux上时，名称一般为gcc/g++，链接器为gcc/g++或ld。列出多少种开发环境的构建进程，是由测试工具的支持能力决定的，例如，测试工具只支持使用gnu c的开发环境下的项目，那么，构建进程清单可以只列出gcc.exe/ld.exe或gcc/ld，由于gnu c/c++可能直接使用gcc/g++作为链接器，因此，构建进程只列出gcc也是可以的。
134.至于清单装置的实现方式，可以提供一个界面，让用户填写构建进程清单，然后保存到文件。也可以指定一个文件，让用户直接填写。当然，测试工具可以提供预设的构建进程清单数据供用户增减。总之，只要把需监听的构建进程列出来就可以了。
135.除了编译器和链接器，构建工具软件还可能是预处理器、汇编器，甚至是集成开发环境本身，总之，参以构建被测试工程的所有构建工具软件，凡是进程的环境数据含有被测试工程的工程数据的，都可以列入构建进程清单。
136.综上所述，构建工具软件，是指用于将被测试工程的用高级语言编写的程序转换成低级语言形式的目标程序的计算机软件；构建进程，是指正在运行的构建工具软件的实例。构建工具软件包括：编译器、链接器、预处理器、前置处理器、汇编器、集成开发环境等，其中，最常用的是编译器和链接器。清单装置列出需要监听的构建进程清单，供监听装置102使用。
137.二、实现为配置装置，预先设定配置，每一配置包括各自的构建进程清单，并生成总的需监听的构建进程清单。即由配置装置来生成构建进程清单，为监听装置102提供监听标的。这种方式优于前一种方式，因为可以通过配置装置来提供更多的功能，提升自动化水平。
138.配置(configuration)，通常是指供程序使用的参数或初始设置。在这里，配置是指用以建立测试工程的初始设置。一种开发环境，对应的所有测试工程，可能需要相同的初始设置，也就是需要一个配置，供这种开发环境下的所有测试工程使用。例如嵌入式开发环境keil，自定义了一些非标准关键字(如code,data,idata,xdata等)，测试工具按标准语法解析被测试代码，是无法正确解析的，因此，要把这些非标准关键字标识出来，屏蔽或替换为标准语法，通过为开发环境keil预先准备一个配置，每当测试由keil开发的项目时，在生成测试工程时自动加入对非标准关键字的处理设置。
139.配置装置的基本功能是预先设定一个或多个配置，每一配置包括各自的构建进程清单，并生成总的需监听的构建进程清单。为了提升自动化水平，配置装置还可以增加一个匹配装置，用于设定匹配特征，并与构建进程的环境数据进行比较，自动选择对应的配置。
140.实现方式上，配置装置需要提供由用户设置和管理配置数据的途径，例如，可以提供两级界面，一级为配置清单界面，供用户添加、修改、删除配置，二级为详细配置界面，为指定配置提供添加、修改、删除数据项等功能。配置装置还需要实现把数据保存到存储设施(如文件)中，并且能读取并解析它的内容。这些，是软件开发领域的常规技术。
141.除了使用用户界面方式，也可以使用其他实现方式，例如：以xml格式保存配置文件，并提供一个xml编辑界面，配置装置使用xml解析器读写配置数据。或者，以文本格式保存配置文件，用户直接可以编辑配置数据，配置装置包含一个解析程序来解析配置数据。总之，配置装置在实现方式上可以有多种选择。
142.在内容上，配置装置管理一个配置清单(配置列表)，每个配置至少要包括构建工具软件清单(列表)，例如，编译器名称、链接器名称。配置装置把这些构建进程集中为一个总的构建进程清单，提供给监听装置102作为监视进程清单。
143.如果给配置装置添加匹配装置，可以实现自动选择配置。自动选择配置是软件开发领域的常见技术，例如，下面的实施方式可以实现自动选择配置：
144.1、每个配置指定一个或多个识别特征，例如：编译器/链接器名称、版本号、安装路径片段等。
145.2、根据监听装置102获取的构建进程的环境信息，或解析装置103获取的被测试工程的工程数据，对比每一个配置的识别特征，匹配一项记一分，然后从配置清单中选项得分最高的配置。配置装置可以进一步完善，为不同的测试工程各自提供需要的预设数据，包括：
146.替换代码片断：
147.常用于测试嵌入式开发环境下的代码，例如，将非标准关键字替换为标准关健字或屏蔽，或者，将类似于@0x1234；之类的特殊代码片断屏蔽。
148.将表示内存地址的数字替换为指针：
149.常用于测试嵌入式开发环境下的代码。一些嵌入式项目的代码，直接引用内存位置，如*(int*)0x00ff0000＝n；，0x00ff0000是一个数字，通过强制类型转换使它在语法上合规，在逻辑上表示一个内存地址。如果在pc上测试这类代码，可能因内存地址不合法导致运行崩溃。一种解决方法是定义一个全局变量，将数字替换为该全局变量的地址，这样，在不改变代码逻辑的前提下，可以实现在pc上运行测试。测试工具可以自动识别并完成替换。
150.不展开的宏定义：
151.指定某些宏不展开，例如，#definenull 0，null表示空指针，展开后就是0，与数字0混淆，可以指定为不展开。
152.不生成桩的文件：
153.指定一些文件不生成桩代码，例如，c标准库的头文件。
154.不生成桩的函数：
155.指定一些函数不生成桩代码，例如，常规的内存处理函数。
156.不测试的函数：
157.指定一些函数不测试。
158.系统头文件搜索目录：
159.有些ide的系统头文件搜索目录可能无法从构建进程环境数据中获得，可以在配
置中设定，例如，可以设定系统头文件所在目录相对于编译器所在目录的相对路径，而编译器所在目录可以从构建进程的环境数据中获取，从而可以计算出系统头文件搜索目录的绝对路径。
160.前述各项预设数据，不一定需要全部实现，可以视需要取舍和组合。配置装置还可以视需要预设其他数据，使测试工程生成后，拥有尽可能完整的工程数据，实现不需要用户增加和修改设置，就使测试工程能够顺利解析、编译和运行的目的。
161.综上所述，配置装置实现了清单装置的功能，列出需要监听的构建进程清单，供监听装置102使用。同时，配置装置为不同开发环境下的测试工程提供了预设的数据，进一步实现自动化。
162.三、实现为进程识别装置，自动识别构建进程。进程识别装置可以隐形实现，即不提供用户界面，自动完成识别功能。具体实现方式有多种，例如：
163.1、测试工具内部预先设置构建进程的名称或其他特征，监听装置102在监听过程中，对进程特征进行分析，对比预设的构建进程的名称或其他特征，从而识别出构建进程。此方式与实现为清单装置并无本质区别，只是将其实现隐藏，不对用户开放。
164.2、分析进程的命令行参数，判断是否为构建进程，例如，编译器的命令行参数一般包含源文件名，或包含其他有明显特征的数据，如-dxxx或/dxxx，表示一个宏定义。
165.3、分析进程的行为来判断是否为构建进程，例如，编译器通常会生成中间文件，链接器通常会生成最终文件。
166.4、根据时间段来判断是否为构建进程，例如，提供“开始”和“结束”按钮，用户按下“开始”按钮后，执行被测试工程的构建，完成后按下“结束”按钮，“开始”和“结束”之间所启动并退出的进程可以大致判断为构建进程。
167.进程识别装置可以由监听装置102调用，即监听装置102在抓取到进程信息时，就调用进程识别装置来判断是否为构建进程。
168.以上列举了进程识别装置的一些实现方式，均可实现准确或大致识别构建进程。这是一种次佳方案，有其局限性，例如，上述第1种方式，丢失了用户增减监听对象的灵活性，而第2、3、4种方式则有可能识别错误。
169.以上说明了监听标的设定装置101的三种实施方式，前两种提供了需监听的构建进程清单，第三种不提供清单，用自动识别来代替。监听标的设定装置101实施方式不限于以上几种，只要提供需监听的构建进程清单，或提供自动识别需监听的构建进程的功能，能够让监听装置102了解哪个进程需要监听，就实现了监听标的设定装置101的功能。
170.监听装置102的功能是监视计算机中的进程，根据监听标的设定装置101提供的构建进程清单，识别出构建进程，并抓取这些进程的环境数据。如果监听标的设定装置101未提供构建进程清单，则调用监听标的设定装置101的进程识别装置，判断构建进程。
171.构建工具软件的调用方式通常是间接调用，例如，由ide或make程序调用。一般来说，被测试工程有不定数量的源文件，每个源文件是一个编译单元，编译后生成一个保存编译结果的中间文件。全部源文件编译完成后，再调用一次链接器，把中间文件链接成一个最终文件(可执行文件或一个供其他可执行文件使用的库文件)。有些ide每个编译单元分别调用一次编译器，有些则一组编译单元调用一次编译器。调用编译器执行一个或一组源文件的编译，就形成了一个编译进程。调用链接器生成最终文件，就形成一个链接进程。编译
进程和链接进程都是构建进程。构建进程一般是临时进程，例如，编译一个源文件，形成编译进程，编译完成，编译进程立即退出。构建进程的驻留时间可长或短，如果编译简单的单个源文件，时间可能以毫秒计，编译一个复杂的源文件，时间可能需要一秒到几秒，编译一组源文件，时间则可能比较长。
172.构建进程虽然是临时进程，但进程管理是现代计算机的基本技术，根据进程名或其他特征识别进程是现有技术，例如，用一个不断重复的循环，反复遍历操作系统中的驻留进程，每个进程可以取得它的id或句柄、对应的程序名称与路径，将进程特征(例如对应的程序名称)与监听标的设定装置101提供的构建工具软件清单对比，就可以及时识别出构建进程。如果监听标的设定装置101未提供构建进程清单，则调用监听标的设定装置101的进程识别装置，判断是否为构建进程。
173.识别出构建进程后，可以依据进程信息，如进程id或句柄，进一步获取进程的环境数据。进程在执行前或执行时，操作系统会临时存储进程信息，供操作系统和进程使用，这些进程信息称为进程环境数据。
174.例如，在window上，进程环境数据存放在名为peb的内存块上。peb，即process environment block，意为进程环境块，而在linux上，进程环境数据一般保存在/proc/pid文件夹下，其中，pid即进程编号。
175.一般来说，以下两种环境数据最为重要：
176.1、构建工具软件的命令行参数；
177.2、构建工具软件的工作目录。
178.当被测试工程比较简单时，仅凭命令行参数就能解析出被测试工程的基本工程数据。
179.作为一个次佳方案，不使用命令行参数，只凭构建工具软件的工作目录，也有获取被测试工程的工程数据的可能，例如，有些ide会将构建工具软件的工作目录，设为被测试工程的工程文件所在目录，因此，测试工具可以在构建工具软件的工作目录下，查找被测试工程的工程文件，找到后，对工程文件进行解析，从而获取被测试工程的工程数据。与传统的从工程文件导入相比，本次佳方案有一个优点：用户不需手动选择工程文件，测试工具可以自动找到工程文件。
180.综上所述，获取构建工具软件的命令行参数或构建工具软件的工作目录，都可能获取被测试工程的工程数据，所以，可以只使用其中之一。但更好的方案是两者结合使用，普遍可以获得完整准确的工程数据。在解析命令行参数过程中，构建工具软件的工作目录具有重要意义，因为它是相对路径的起始目录，是将相对路径转换为绝对路径的必要条件。
181.有时，还需要以下两种进程环境数据(使用其中之一或两者都使用)：
182.3、构建工具软件本身的路径；
183.4、构建工具软件的环境变量。环境变量是环境数据中的一种，保存预先定义的一些变量及值，例如，windows环境下，path环境变量通常保存文件的搜索目录。
184.获取进程环境数据的具体方法：
185.对于windows来说，读取某一进程的peb是现有技术，在百度等搜索引擎上，搜索“获取进程peb”，可以找到获取及解析peb的具体方法，并且能找到现成的代码。上述四种环境数据，均可从peb获得，获取每种数据的具体方法，可以在互联网搜索代码，也可以在取得
peb的基地址后，用调试方法去分析每种数据的位置，这也是软件开发人员的常用技能，这里不作详述。
186.对于linux来说，环境数据保存在可直接读取的文本文件中，一般在/proc/pid文件夹下，可以直接读取，例如：
187.构建工具软件的工作目录：文件名为cwd；
188.构建工具软件的命令行参数：文件名为cmdline；
189.构建工具软件本身的路径：文件名为exe；
190.构建工具软件的环境变量：文件名为environ。
191.当然，含有被测试工程数据的环境数据，均可以是装置102的获取标的，并不局限于上述四种。
192.综上所述，监听装置102可以实现为一个无限循环，不断遍历系统中的驻留进程，并将进程特征(例如进程名称)与监听标的设定装置101提供的清单(例如所有需监听的进程名称)对比或调用监听标的设定装置101的进程识别装置，识别出构建进程，并获取进程的环境数据。
193.作为监听装置，监听装置102可以实现为自动启动监听(如当用户执行新建测试工程操作时，自动启动监听)，也可以提供“开始监听”的命令供用户手动启动。监听启动后，用户可以像平时构建被测试工程一样，执行构建(例如，执行ide的rebuildproject命令，或执行make程序)，监听装置102就可以获取构建进程的环境数据。对于用户来说，被测试工程通常是可构建的，并且用户也知道如何执行构建，并且尝试过构建过程，这通常是能够进行代码级测试的前提，因此，执行构建只是把以前执行过的命令或操作再执行一次，并不需要额外的工作。构建过程不一定需要构建出最终的目标程序，例如，开发初期的工程，可能只能编译，不能产生最终的目标程序，或者，只测试部分文件，这些情形，可以只执行被测试文件的编译。构建结束后，可以由用户通知监听装置102(例如，提供“结束监听”命令供用户手动通知)，也可以由监听装置102自行判断是否已结束(例如，已监视到一些构建进程，且在一定时间内未监视到新的构建进程可判断为结束)。监听结束后，监听装置102可将获得的数据作一些简单的整理，然后以文件等方式提供给解析装置103进行下一步工作。数据可以整理成xml格式，或者按特定顺序排列，或者加上标记，以便解析装置103读取和识别。图2是监听装置102所获得的环境数据示例，监听装置102对这些数据以添加标记方式进行了简单整理。
194.解析装置103的功能是解析装置102所获得的环境数据,获取被测试工程的工程数据。测试工程比较常用的被测试工程的工程数据如下：
195.源文件清单及源文件目录；
196.包含文件的搜索目录，包括用户头文件搜索目录以及系统头文件搜索目录；
197.预定义数据，如：宏定义，也称为编译条件，通常用于指定编译哪些代码，或用于指定常量的值；内置数据类型，指定构建工具自行定义的数据类型；
198.前置包含的头文件，即自动包含的头文件；
199.使用的库文件，即需链接的库文件清单；
200.所述库文件的搜索目录，告诉链接器到何处去查找库文件；
201.不使用的缺省库文件，链接器通常有缺省的库文件清单，可以指定排除；
202.编程语言名称及版本，语言如c或c++，版本如c99、c++11、c++14。
203.还可能需要更多的工程数据，例如预编译头文件、字节对齐数、其他编译或链接选项。
204.另外，还可能需要掌握构建工具软件或构建进程本身的路径，如：
205.编译器本身的路径；
206.链接器本身的路径。
207.图2是监听装置102所获得的环境数据示例，监听装置102已对这些数据以添加标记方式进行了简单整理。如图2所示，@exe@开始的字符串，是构建工具软件本身的路径，@cwd@开始的字符串，是构建进程的工作目录，@cmd@开始的字符串，是命令行参数。图2是三个构建进程的环境数据：前两个为编译进程，各自编译了一个源文件，第三个为链接进程，链接进程生成最终的可执行文件codeblocks.exe。
208.解析装置103主要解析命令行参数。命令行参数含义可以通过查询编译器链接器的参数说明书获得，例如，对gcc/g++而言，-dxxx＝1，表示定义一个宏，名为xxx，值为1；-ixxx，表示添加一个头文件搜索目录xxx。源文件或源文件目录，通常直接列出。
209.构建工具软件在启动后，通常会对命令行参数进行解析，获取构建工作所需要的数据，例如，编译哪些源文件，头文件到哪里去找，有哪些编译条件。因此，解析命令行参数是软件开发中的现有技术，具体解析过程这里不作详述。
210.对图2所示的环境数据解析后，至少可以获得以下信息：
211.源文件清单：
212._3t_myclass.cpp
213._4t_databasic.cpp
214.源文件目录：
215.d:\test\demo。
216.包含文件搜索目录：
217.d:\test\demo\include\inc1
218...\include\inc2
219.预定义数据(如宏定义)：
220.mymacro＝1
221.mymacro2＝2
222.库文件搜索目录：
223...\lib
224.c:/program files(x86)/codeblocks/mingw/bin/../lib/gcc/mingw32/4.9.2
225.(数量较多，未全部列出)
226.使用的库文件(需链接的库文件)：
227.mingw32
228.gcc
229.(数量较多，未全部列出)
230.以上数据含有相对路径，相对路径的起始目录是构建进程的工作目录，如图2所示，@cwd@开始的字符串，是构建进程的工作目录，值为d:/test/demo/codeblocks/，因此，
相对路径..\include\inc2，可以转换为绝对路径：d:/test/demo/include/inc2。
231.构建工具软件本身的路径，有两方面用途：
232.1、用来编译测试代码，构建测试程序；
233.2、测试工具可以主动调用构建工具软件，以查询更多的数据。
234.图2的示例，不包括构建工具软件的环境变量。环境变量通常有上百条甚至几百条数据，有可能含有测试工程可以使用的数据，例如，系统头文件的搜索目录、系统库文件的搜索目录等，但环境变量并不是必须的。
235.生成装置104，功能是生成测试工程。
236.生成工程，在软件开发和测试领域，是一个常见的操作。例如，用ide开始一个新的项目，首先要做的，可能就是新建一个工程，设定一些数据，例如，文件放在什么位置，项目名称是什么，然后，工具就生成一个新的工程。生成工程的最基本的操作，就是把用户设定的数据，以及工具添加的一些数据，这些数据称为工程数据，保存到工程文件，此外，也可能有其他操作，例如，新建一些目录，生成一些支持文件，包括自动生成一些代码。工程数据是可以动态添加的，因此，最初的工程数据，可以是空的，例如，多数ide都会允许新建一个空工程。
237.生成测试工程也类似，最基本的操作，是存储测试工程的工程数据，例如，保存到一个或多个文件中。测试工程数据也是可多可少、甚至是空的，但所缺少的，并不是不需要，以后必须补上，所以测试工程要尽可能完整地保存测试所需要的数据。
238.本发明所述的测试工程数据，应该包括解析装置103获取的被测试工程的工程数据，有了这些数据，测试工具才能掌握被测试工程构建过程中涉及到的数据。测试工具通常要对被测试代码进行解析，解析过程相当于编译器前端，因此，只有掌握了被测试工程的工程数据，测试工具才具备对被测试代码进行解析的条件。对于动态测试来说，掌握了被测试工程的工程数据，才能够对被测试代码进行编译、并链接成可执行文件，然后执行测试。
239.把测试数据保存到文件，是生成测试工程的一般操作。当然，也可以存储到其他介质或位置，如云服务器、在使用期内不断电的内存等，也可以临时存储，例如，临时存放在内存中备用。
240.生成装置104的基本实施方式，是存储测试工程的工程数据，而被测试工程的工程数据，是测试工程的工程数据中的基本部分，因此，生成装置104的基本实施方式，是永久或临时存储被测试工程的工程数据。只要有了这些数据，测试工具就可以了解被测试工程的基本信息，例如，测试哪些文件、有哪些编译条件、包含的文件到保处去查找等等，测试工具就可以开始下一步的工作，这样就完成了测试工程的生成，这是生成装置104最基本的实施方式。
241.如果实现了配置装置，配置装置提供的数据，也是测试工程的工程数据，例如，什么样的代码需要替换、哪些文件或函数不测试等。
242.测试工具可以根据需要，以自动或由用户设定的方式，增加测试工作需要的其他工程数据，常见的有：
243.测试工程的工作目录；
244.测试结果保存目录；
245.需测试的源文件清单，当测试任务并非整个被测试工程，而是只包括其中的部分
文件时，用户可以指定具体测试哪些文件；
246.测试工程的名称等等。
247.在掌握了被测试工程的工程数据后，生成装置104还可以对被测试代码进行解析，并提供进一步功能，例如：
248.生成测试驱动代码；
249.生成桩代码；
250.生成测试用例数据，等等。
251.这些是当前测试工具的常用技术，属于现有技术，这里不作详述。
252.以上说明了本发明基本方案的一个实施例的各个组成部分。监听标的设定装置101设定需监听的构建进程清单或自动识别构建进程，监听装置102监听计算机中的进程，根据监听标的设定装置101提供的构建进程清单或调用监听标的设定装置101的进程识别装置，识别出构建进程，并抓取这些进程的环境数据，供解析装置103解析。解析装置103解析监听装置102所获得的环境数据,获取被测试工程的工程数据，提供给生成装置104。生成装置104利用解析装置103提供的被测试工程的工程数据，必要时由用户添加或工具自动添加测试工作需要的其他数据，生成测试工程。
253.图3是本发明的应用效果示意图。本发明已在凯乐visual unit 4.8实施，图3是凯乐visual unit 4.8使用本发明后的新建测试工程界面截屏图，其中，图3a是开始监听的界面；图3b是接收到监听信息的界面；图3c显示测试工程数据供用户确认后生成测试工程。
254.图3a是开始监听的界面。用户执行“新建工程”命令时，自动显示此界面，然后，用户可以打开被测试项目的开发环境，执行被测试工程的构建。
255.图3b是接收到监听信息的界面，可以看到已接收到的字节数。用户在编译完成后，点击“编译已完成”，自动解析监听到的信息，获取被测试工程的工程数据。监听标的设定装置101选用了配置装置，并添加了匹配装置。监听完成后，匹配装置自动执行，自动选择合适的配置。
256.图3c显示测试工程数据(包含被测试工程的工程数据)供用户确认，用户点击“生成测试工程”，即可完成测试工程的生成。
257.为了直观地展示本发明在实际应用中的重要意义，作为对比，图4a到图4g是现有技术建立测工程过程示意图，其中，图4a为现有技术生成测试工程过中用于选择模板的界面截屏图；图4b为现有技术生成测试工程过中用于导入数据的界面截屏图；图4c为现有技术生成测试工程过中用于常规设置的界面截屏图；图4d为现有技术生成测试工程过中用于测试目标选择的界面截屏图；图4e为现有技术生成测试工程过中用于编译选项设置的界面截屏图；图4f为现有技术生成测试工程过中用于链接选项设置的界面截屏图；图4g为现有技术生成测试工程过中用于高级选项设置的界面截屏图。这些示意图是凯乐visual unit4.7的生成测试测试工程过程的界面截屏图。在现有技术下，图4c、图4d、图4e、图4f所示出的功能是必不可少的，图4a和图4b示出的功能用于减少工作量、降低难度，通常也是不能省略的，图4g所示出的功能是可选的高级设置，在很多场景下也是必不可少的。
258.从图3a到图3c可以看出，新建工程的过程很简单，用户要做的，只是把产品工程的构建过程再次执行一下(通常只需要执行一下开发环境的构建命令)，自动化程度高，更重要的是，被测试工程的工程数据从被测试工程的构建过程中自动获得，准确而完整，可以快
速建立可用的测试工程。
259.从图4a到图4g可以看出，建立测试工程过程中，涉及的数据项繁多，在现有技术下，即使使用导入数据功能，也不能保证数据的完整性，需要用户检查和补充，因此一直到图4g才出现“完成”按扭，点击“完成”按钮后，工具才会开始生成测试工程。
260.综合以上，与现有技术相比，本发明具有以下优点：
261.自动化程度高。本发明通过自动监听及自动解析来获取被测试工程数据，不需要手工设置被测试工程数据；
262.完整性及准确性高。本发明可以获取被测试工程的完整工程数据，生成测试工程后，通常不再需要添加或修改工程数据。
263.另外，利用本发明，所有开发环境，都可以采用同样的方式生成测试工程。而现有技术下，不同的开发环境，可能要选择不同的模板、选择不同的导入方式等，容易让新手无所适从。本发明使用同一方式来生成测试工程，显著降低了用户的学习难度。
264.本发明也解决了代码级测试的另一个难题：测试工程迁移。测试工程经常需要迁移到其他计算机上，同一个被测试项目，在不同计算机上可能保存在不同位置，所依赖的环境(例如编译器、系统头文件及库文件、第三方库等)更是可能安装或放置在不同位置，给迁移造成困难。在传统技术下，测试工程迁移后往往要重设各种数据，而利用本发明，迁移后只要重新监听构建过程，就可以自动重新获取被测试工程的工程数据，从而解决迁移问题。
265.另一方面，本发明还提供了一种程序测试工程自动生成方法，用于为被测试工程的代码级测试生成测试工程，其特征在于，包括：
266.监听标的设定步骤：设定需监听的构建进程；所述构建进程，是指正在运行的构建工具软件的实例。所述构建工具软件；是指用于将所述被测试工程的用高级语言编写的程序转换成低级语言形式的目标程序的计算机软件；
267.监听步骤：监听所述构建进程，获取所述构建进程的环境数据；
268.解析步骤：解析所述环境数据，获取所述被测试工程的工程数据；
269.生成步骤：存储测试工程的工程数据，所述测试工程的工程数据，包括所述被测试工程的工程数据。
270.其中，构建工具软件包括编译器、链接器、预处理器、前置处理器、汇编器和集成开发环境中的一种或几种。
271.进一步的，监听标的设定步骤包括以下的一种或几种：
272.预先设定需监听的构建进程清单；
273.预先设定配置，每一配置包括各自的构建进程清单，并生成总的需监听的构建进程清单；
274.根据进程信息，自动识别需监听的构建进程。
275.在本发明实施例中，所述预先设定配置，每一配置包括各自的构建进程清单，并生成总的需监听的构建进程清单的步骤还包括：
276.设定匹配特征，并与所述构建进程的所述环境数据进行比较，自动选择对应的配置。
277.对于本发明实施例所述的测试工程自动生成方法，其实现步骤已包含于前面关于程序测试工程自动生成系统的说明中，这里就不再赘述。
278.以上实施例仅是本发明的较佳实施方式，仅用以说明本发明而非限制，对本发明进行修改、变形或者等同替换而不脱离本发明的精神和范围，均应涵盖于本发明的范围之内。

技术特征：
1.一种程序测试工程自动生成系统，其特征在于，包括：监听标的设定装置，用于设定需监听的构建进程；所述构建进程，是指正在运行的构建工具软件的实例；所述构建工具软件，是指用于将所述被测试工程的用高级语言编写的程序转换成低级语言形式的目标程序的计算机软件；监听装置，用于监听所述构建进程，获取所述构建进程的环境数据；解析装置，用于解析所述环境数据，获取所述被测试工程的工程数据；生成装置，用于存储测试工程的工程数据，所述测试工程的工程数据，包括所述被测试工程的工程数据。2.根据权利要求1所述的程序测试工程自动生成系统，其特征在于，所述构建工具软件包括编译器、链接器、预处理器、前置处理器、汇编器和集成开发环境中的一种或几种。3.根据权利要求1所述的程序测试工程自动生成系统，其特征在于，所述监听标的设定装置包括以下装置的一种或几种：清单装置，用于预先设定需监听的构建进程清单；配置装置，用于预先设定配置，每一配置包括各自的构建进程清单，并生成总的需监听的构建进程清单；进程识别装置，用于根据进程信息，自动识别需监听的构建进程。4.根据权利要求3所述的程序测试工程自动生成系统，其特征在于，所述配置装置还包括：匹配装置，用于设定匹配特征，并与所述构建进程的所述环境数据进行比较，自动选择对应的配置。5.根据权利要求3所述的程序测试工程自动生成系统，其特征在于，所述每一配置还包括以下各项的任意组合：替换代码片断；将表示内存地址的数字替换为指针；不展开的宏定义；不生成桩的文件；不生成桩的函数；不测试的函数；系统头文件搜索目录。6.根据权利要求1至5任一所述的程序测试工程自动生成系统，其特征在于，所述环境数据包括：所述构建进程的命令行参数；和/或所述构建进程的工作目录。7.根据权利要求6所述的程序测试工程自动生成系统，其特征在于，所述环境数据还包括以下的一种或几种：所述构建进程本身的路径；所述构建进程的环境变量。8.根据权利要求1至5任一所述的程序测试工程自动生成系统，其特征在于，所述被测试工程的工程数据包括以下各项的任意组合：
源文件清单及源文件目录；包含文件的搜索目录；预定义数据；前置包含的头文件；使用的库文件；所述库文件的搜索目录；不使用的缺省库文件；编程语言名称及版本。9.根据权利要求1至5任一所述的程序测试工程自动生成系统，其特征在于，所述测试工程的工程数据，包括以下各项的任意组合：测试工程的工作目录；测试结果保存目录；需测试的源文件清单。10.根据权利要求9所述的程序测试工程自动生成系统，其特征在于，所述生成装置还用于生成测试驱动代码、生成桩代码和/或生成测试用例数据。11.一种程序测试工程自动生成方法，其特征在于，包括：监听标的设定步骤：设定需监听的构建进程；所述构建进程，是指正在运行的构建工具软件的实例。所述构建工具软件；是指用于将所述被测试工程的用高级语言编写的程序转换成低级语言形式的目标程序的计算机软件；监听步骤：监听所述构建进程，获取所述构建进程的环境数据；解析步骤：解析所述环境数据，获取所述被测试工程的工程数据；生成步骤：存储测试工程的工程数据，所述测试工程的工程数据，包括所述被测试工程的工程数据。12.根据权利要求11所述的程序测试工程自动生成方法，其特征在于，所述构建工具软件包括编译器、链接器、预处理器、前置处理器、汇编器和集成开发环境中的一种或几种。13.根据权利要求11所述的程序测试工程自动生成方法，其特征在于，监听标的设定步骤包括以下的一种或几种：预先设定需监听的构建进程清单；预先设定配置，每一配置包括各自的构建进程清单，并生成总的需监听的构建进程清单；根据进程信息，自动识别需监听的构建进程。14.根据权利要求13所述的程序测试工程自动生成方法，其特征在于，所述预先设定配置，每一配置包括各自的构建进程清单，并生成总的需监听的构建进程清单的步骤还包括：设定匹配特征，并与所述构建进程的所述环境数据进行比较，自动选择对应的配置。

技术总结
本发明公开了一种程序测试工程自动生成系统和方法，其中程序测试工程自动生成系统包括：监听标的设定装置，用于设定需监听的构建进程；监听装置，用于监听构建进程，获取构建进程的环境数据；解析装置，用于解析环境数据，获取被测试工程的工程数据；生成装置：用于存储测试工程的工程数据，测试工程的工程数据包括被测试工程的工程数据。本发明解决了快速建立可用的测试工程的难题，具有自动化程度高、使用同一方式、完整性及准确性高、便以迁移等优点。点。点。


技术研发人员：请求不公布姓名
受保护的技术使用者：广州凯乐软件技术有限公司
技术研发日：2023.05.31
技术公布日：2023/8/6