一种基于主机平台的嵌入式模块和子系统的通用测试装置

(一)技术领域本发明涉及一种基于主机平台的嵌入式模块和子系统的通用测试装置。

(二)背景技术现有的大型嵌入式系统软件的测试主要包括以下几个方面：源码测试、模块测试、集成测试、规程测试以及性能测试等。对于源码测试、集成测试、规程测试以及性能测试一般都有第三方提供的相应测试工具，如源码测试工具有LogicScope(一种软件程序度量测试工具)和Rational Purify(一种软件程序覆盖率测试工具)；很多测试仪器提供商都有相应的仿真器、规程测试仪以及安全性测试工具。

但对于模块和子系统测试，由于与系统的具体功能、实现技术以及采用的平台密切相关，所以很难找到一种第三方提供的通用的模块测试工具。现在的通常做法是，由软件测试人员针对特定的模块和子系统，编写特定的测试工具，但因为一个大型的嵌入式系统通常有几十，甚至几百个模块组成，且对于一个大型系统，每个模块的状态转移可能非常复杂，要覆盖所有的可能情况需要编写的测试代码量很大，且缺乏通用性，代码利用率低，测试周期长，同时，由于不同开发人员编写测试代码时可能产生的错误与遗漏，导致部分本应该在模块测试时发现的缺陷引入到系统集成测试阶段，甚至导致测试结果的不可靠性。另外，这种测试方法一般还需要特定的硬件测试环境的支持，影响了软件测试的进度。

(三)发明内容本发明的目的是，为所有的嵌入式模块和子系统，提供一个基于公共Host(主机)平台的通用的测试装置，从而最大限度的避免测试工具的重复开发，缩短模块和子系统的测试周期，提高软件开发效率。

本发明所提供的一种基于主机平台的嵌入式模块和子系统的通用测试装置，基于公共资源库对运行于主机抽象虚拟环境上的模块和子系统进行测试，其特征在于：它包括一个测试用例编辑单元、一个测试用例池、一个测试单元、一个调试单元和一个分析单元，其中：测试用例池，存放测试用例的数据库；测试用例编辑单元，与测试用例池相连，主要完成测试用例的编辑、修改、检查、管理功能，测试用例表现为消息的数据结构形式，消息头中包括测试对象信息，消息体中包括输入参数信息，并可将测试用例组成一个有效的测试用例集，根据预先定义的规则，检查测试用例的合法性，以决定是否存储到测试用例池中；测试单元，与测试用例池相连，包括选择发送功能实体和接收发送功能实体，选择发送功能实体提供用户界面，方便测试人员从测试用例池中选取测试用例或测试用例集，通过发送测试消息激励模块或子系统，由接收发送功能实体接收模块或子系统的响应，完成对测试用例指定的测试对象的测试，并把最后测试的结果发送给测试装置的分析单元；调试单元，与测试用例池相连，包括选择发送功能实体和接收显示功能实体，对模块内重要的消息完成跟踪功能，针对模块或子系统里的调试代码，通过编译开关设置激活，使模块内部发送和接受的重要消息透明地传送到本调试单元，由本调试单元进行解码分析，从而实现了消息跟踪调试功能，为了实现特定的调试，由选择发送功能实体从测试用例池中读取特定的测试用例驱动模块或子系统，接收显示功能实体直接显示跟踪的消息原语内容；分析单元，与调试单元相连，包含三个功能实体，即接收功能实体、分析功能实体及记录和显示功能实体，用作对测试结果记录进行分析，除了完成基本功能，包括整个测试耗时、通过和未通过的测试项数、记录每个未通过项，还完成高级测试结果分析功能，包括代码覆盖率、关键函数的执行频率、各个模块与函数的相对执行时间，并可将分析结构反馈给测试用例编辑单元，用于调整测试用例或测试用例集进入测试用例池的准则，同时将分析结果记录到文件和进行界面呈现。

上述的基于主机平台的嵌入式模块和子系统的通用测试装置，其中，测试装置与被测试的模块或子系统间的通信机制采用消息形式，并且调用主机平台上的抽象虚拟环境提供的应用编程接口发送和接受消息，消息的格式由特定的测试用例提供。

上述的基于主机平台的嵌入式模块和子系统的通用测试装置，其中，测试单元的测试是串行进行的，即当前一个测试用例完成时，才能进行下一个测试，或当前的测试用例集完成后，才能进行下一个测试用例集的测试。

上述的基于主机平台的嵌入式模块和子系统的通用测试装置，其中，测试包括由测试单元实现的黑盒测试和由调试单元实现的白盒测试两种，且对于一个测试用例驱动的测试是否完成的判断，可由调试单元自动完成或者由测试人员灵活指定。

通过本发明，为大型嵌入式系统的开发提供了一种基于主机平台的模块和子系统的通用测试方法，将本来需要下载到硬件系统中才能进行的测试，无缝的移植到公共Host(主机)平台上进行，不仅减少了软件测试对硬件资源的依赖性及繁琐性，有效的提高了软件调试的效率；而且更为重要的是，该测试装置能根据不同的测试用例，对不同的模块和子系统进行测试。测试装置的绝大部分直接运行于主机平台，以后即使抽象虚拟环境需要改写时，只要HOST平台不变，测试装置仍具有较好的通用性，从而最大限度的避免了测试工具的重复开发，缩短了模块和子系统的测试周期。从实际测试的效果来看，该测试装置比通常的方法能更早、更多的发现模块或子系统设计中的缺陷，有效的检查出如消息参数错误、模块状态转移错误、以及状态处理错误等缺陷，较以前的方法能缩短近50％的模块和子系统测试时间。同时，上述模块测试缺陷的发现概率能够达到80％，有效的避免了将上述缺陷引入到系统测试阶段。

(四)附图说明图1本发明测试装置的总体结构图；图2本发明中的测试用例数据结构图；图3本发明中的测试单元结构图；图4本发明中的分析单元结构图；图5本发明中的调试单元结构图。

(五)具体实施方式本发明基于这样一个事实前提：对于大型嵌入式系统，由于所采用的操作系统(OS)可能变化，一般开发者在软件设计之初就考虑到了系统的可移植性，在底层使用一种虚拟层的机制将操作系统封装，从而实现上层应用与操作系统的无关性。所以可以通过一种基于公共Host(主机)平台的抽象单元，提供一个与设备虚拟层相当的等价层，从而能够无缝的将一个嵌入式系统移植到公共Host平台，通过提供编译文件单元(包括主机抽象虚拟环境)，由嵌入式系统的源代码编译成的可执行文件能够在主机平台上运行。

如图1所示，本发明是测试装置5，其绝大部分实体运行于HOST平台1，只有少量涉及到与模块和子系统3通信的消息接口函数调用了主机抽象虚拟环境2提供的API(应用编程接口)，并且它还利用了公共资源库4。在此环境中测试装置5对模块和子系统3提供测试功能。

HOST平台1物理上是一台运行Windows2000(微软公司的一种计算机操作系统)的PC(个人电脑)。

主机抽象虚拟环境2是一层基于Windows2000的虚拟机，对上提供与VxWorks(一种实时操作系统)虚拟机一样的API(应用编程接口)，封装了Windows2000的具体细节。VxWorks(一种实时操作系统)虚拟机是为模块和子系统3开发的，封装了VxWorks的具体细节，运行在VxWorks上，图1中没有给出。主机抽象虚拟环境2是为移植模块和子系统3到HOST平台1上开发的，以配合测试装置5的使用。

模块和子系统3是在VxWorks虚拟机上开发的RNC(无线资源控制器)、NodeB(基站收发信机B)以及MT(移动终端)的上层协议软件，正常情况下运行于VxWorks，此处，通过主机抽象虚拟环境2把它移植到HOST平台1运行。

公共资源库4包含以前在VxWorks上开发测试模块和子系统3时定义的消息结构，测试用例等数据文件，以帮助测试用例编辑单元51根据不同的模块和子系统3生成对应的测试用例；另外还有一些工具软件包。

在使用测试装置5开始测试模块和子系统3前，必须先在HOST平台1上完成主机抽象虚拟环境2，移植模块和子系统3到HOST平台1，并准备好公共资源库4。

测试装置5包括一个测试用例编辑单元51，一个测试用例池52，一个分析单元53，一个测试单元54，一个调试单元55。

测试用例编辑单元51提供友好易用的人机界面，用户可以通过界面，根据被测试的模块和子系统3，利用公共资源库4，完成Test Case(测试用例)、Test Case Set(测试用例集，即：多个相关的测试用例组成)的生成、删除、修改等编辑功能，然后根据某种规则验证测试用例和测试用例集的有效性，若有效则输出到测试用例池52中。

如图2，为了简化后续的消息路由处理，测试用例的格式直接定义为包括消息头56和消息体57两部分，消息体57的格式与模块和子系统3要求的输入消息格式完全一致，包含具体的输入参数，消息头56定义包括：测试对象561，测试类型562，测试序列号563。测试对象561类型定义为一个最大长度为128个字节的以0结尾的字符串，包括图1中的接收消息的模块和子系统3的名字，定义测试类型的目的是便于按类型组织测试用例数据。测试类型562定义为一个字节的无符号整数，可选值如下：#Define MeasureType_Debug 1             /*此测试用例只用于调试*/#Define MeasureType_Test_Funtion 2      /*此测试用例只用于功能测试*/#Define MeasureType_Test_Performance 3  /*此测试用例只用于性能测试*/……测试序列号563定义为一个2字节的无符号整数，测试用例编辑单元51忽略此项。它由测试单元54和调试单元55在发送和接收消息时填入一个测试消息序列号，此序列号可与消息体57中可能包括的消息序列号相同，也可不同，它只对测试装置5有意义，对于模块和子系统3是透明的。

对于不同的模块和子系统3，测试用例的消息头56的格式相同，但消息体57的格式可能不同，其格式可从图1中的公共资源库4得到。这样，就把需要针对不同的模块和子系统3编写不同的测试程序的繁琐任务简化为：只需通过用户界面动态编辑模块和子系统3要求的特定消息格式，大大的减少了软件测试的工作量。

测试用例池52提供后台存储功能，采用了两种方式，第一种方式是文件存储系统：利用多个文本文件来存储所有的测试用例，并按测试的模块和子系统来生成并命名文件，每个文件内，分成用于测试单元54和调试单元55的两个数据段，分别存储测试用例和调试用例，两个数据段内的内容有部分重合，因为一个测试用例可能既能给测试单元54使用，也能给调试单元55使用，为简化实现，每个数据段内的数据不再提供索引。第二种方式是采用商业数据库管理软件MS Microsoft SQLServer(美国微软公司的一种数据库管理软件)来存储所有的测试用例，根据一个或多个需要测试的模块和子系统来生成表格，每个测试用例存储在表格的一行内，作为一个记录，记录的字段值依次是图2中的测试对象561，测试类型562，测试序列号563，消息体57，索引字段包括测试对象561和测试类型562。文件系统方式适合于测试用例较少的场合，实现简单，不需要专业的数据库软件，数据库管理软件方式适用于管理复杂的测试用例数据，并能提供强大的索引功能，便于测试用例数据的有效管理。

如图3，测试单元54包括选择发送功能实体541和接收发送功能实体542两个部分。选择发送功能实体541实现为一个独立的任务，它包括三个模块：用户界面模块5411，读测试用例池模块5412和测试消息发送模块5413。接收发送功能实体542实现为另一个独立的任务。

测试单元54的对外接口为：读测试用例池模块5412从测试用例池52读数据，支持两种数据格式：文本文件系统和数据库管理软件MS Microsoft SQL Server；测试消息发送模块5413发送消息到模块和子系统3，接收发送功能实体542从模块和子系统3接收消息响应，进行初步分析后，将测试结果发送给分析单元53。

测试单元54的内部接口和工作流程为：用户界面模块5411提供给测试人员友好的操作界面，根据测试人员的图形操作命令，调用读测试用例池模块5412，读取测试用例并显示，以方便用户选取，最后以测试人员选取的一个或多个测试用例(或测试用例集合)为参数(一个内存起始地址，代表一块存放测试用例的内存区域)，调用测试消息发送模块5413，测试消息发送模块5413将从测试消息中提取消息体57向模块和子系统3发送，同时启动测试定时器。为便于测试消息发送模块5413和接收发送功能实体542之间通信，采用一个简单的实现策略：定义两个全局变量：structHeader(结构变量)，包括图2中的消息头56的所有内容：测试对象561，测试类型562，测试序列号563，图3中的测试消息发送模块5413每次发送消息时，都将此结构中的测试序列号563成员变量的值加1，测试对象561和测试类型562成员变量的值由测试用例预先指定。

objectTimeout：(对象变量)，测试消息发送模块5413在发送测试消息时启动的定时器，是一个对象变量。

正常情况下，当测试消息发送模块5413发送测试消息后，过一段时间接收发送功能实体542将接收到测试响应消息，这时，接收发送功能实体542首先将objectTimeout清零，并读取structHeader的值，与刚收到的测试响应消息一起，组合成完整的测试结果消息，发送给分析单元53，测试结果消息的消息头格式与图2中的格式类似，但消息体格式可能不同，因为针对模块和子系统的激励消息和响应消息的格式可能不同；同时接收发送功能实体542还要发送测试完成通知消息到测试消息发送模块5413，指示一个测试的正常完成，可以进行下一个测试，测试是严格串行化的。

异常情况下，当测试消息发送模块5413发送测试消息后，接收发送功能实体542一直不能接收到测试响应消息，objectTimeout将自动清零并发送超时消息给测试消息发送模块5413和接收发送功能实体542：测试消息发送模块5413停止该测试用例的测试，进入下一个测试用例的测试，同时，接收发送功能实体542读取structHeader的值，将测试响应消息内容设置为“测试失败”，然后同样组合成完整的测试结果消息发送到分析单元53。

测试的正常情况并不表示测试结果的正确，只是表示在规定的时间内有测试响应。测试定时器的超时值可以根据不同的模块和子系统设置。异常情况下测试消息发送模块5413没有实现测试消息的重传机制。

如图4所示，分析单元53由接收功能实体531，分析功能实体532、记录和显示功能实体533组成，与测试单元54之间采用消息通信接口。接收功能实体531实现为一个任务，测试单元54没有测试结果消息发送时，该任务处于阻塞状态，分析功能实体532实现为一个过程函数，记录和显示功能实体533实现为一个过程函数。它的工作流程是这样的：当接收功能实体531发现其消息队列中有测试单元54发送来的测试结果消息时，将调用分析实体532处理此消息，分析功能实体532根据为图2中的消息头56中的各子项所定义的一些特定规则，实时分析每个消息中的测试结果。分析功能实体532还具有一定的本地存储功能，可根据一定规则，对多个相关的测试结果消息进行集中分析，比较，根据图2中的测试序列号563可分析被测试系统某些测试项的时间特性，并统计多项测试指标。最后，记录和显示功能实体533的过程函数被调用，将分析结果记录到文件中，并同时对用户提供界面显示。

如图5所示，调试单元55包括选择发送功能实体551和接收显示功能实体552两个部分，选择发送功能实体551实现为一个独立的任务，它包括三个模块：用户界面模块5511，读测试用例池模块5512和测试消息发送模块5513。接收显示功能实体552实现为另一个独立的任务。它的实现与工作流程与测试单元54比较类似，主要区别如下：1.测试目的不同，选取的测试用例也不同。调试单元55用于测试模块和子系统内部的重要接口和参考点上的消息流，选取的是用于白盒测试的用例，而测试单元54通过测试模块外部接口，测量模块的功能和性能等，选取的是黑盒测试用例。

2.对于测试单元54(黑盒测试)，一个测试消息一般只有一个测试响应消息，但对于调试单元55(白盒测试)，一个测试消息通常有分别对应模块内部多个观测点的多个测试响应消息，针对一个测试消息的所有测试响应消息是否都已收到？由于测试的复杂性，我们采用两种方式判断：由接收显示功能实体552自动判断，或者由测试人员根据专业经验人工判断。若测试响应消息都已收到，将由接收显示功能实体552或者用户界面模块5511发送测试完成通知消息到测试消息发送模块5513，指示一个测试的正常完成，可以进行下一个测试。

3.调试单元55的接收显示功能实体552只简单的直接显示测量结果消息以原语格式显示给测试人员，不再把此消息传送给分析单元53。因为模块内部消息格式的种类较多，需要对模块内部细节有较多的了解，从实用性角度出发，不再把此测试结果消息交给分析模块，对其分析主要依靠开发测试人员的专业经验完成。

使用该测试装置的完整流程如下：第一步：如图1，在HOST平台1，也就是Windows2000上，为需要测试的模块和子系统3编写主机抽象虚拟环境2，收集相关资料到公共资源库4。为了实现的简化，测试装置5里的测试单元54和调试单元55里与模块和子系统3的消息通信接口调用了主机抽象虚拟环境2提供的消息通信API(应用编程接口)，所以需要模块和子系统3的消息调用API(应用编程接口)与测试单元54和调试单元55里采用的尽量一致，在设计测试装置5时已考虑到这一点，其调用的消息API(应用编程接口)比较通用；当模块和子系统3和测试装置5里的测试单元54和调试单元55的消息调用API(应用编程接口)不能一致时，可在主机抽象虚拟环境2里单独为测试单元54和调试单元55提供格式一致的接口函数，该接口函数可以封装模块和子系统3的消息调用API(应用编程接口)。

第二步，如图1和图2，利用该装置的测试用例编辑单元51，按照图2的格式，为模块和子系统3编写测试用例，存放到测试用例池52。

第三步，如图3，利用测试单元54里的用户界面5411任务，调用读测试用例池5412模块，从测试用例池52里读取测试用例并选择，然后通过调用测试消息发送5413模块，从选择的测试用例中取出测试消息，向模块和子系统3发送，进行黑盒测试，接收发送功能实体542任务接收到测试响应消息，将最后的测试结果发送给分析单元53。

第四步，如图4，分析单元53的接收功能实体531，分析功能实体532，记录与显示功能实体533，自动、实时的对测试结果分析、显示并记录到文件。

第五步，如图5，通过调试单元55里的用户界面5511任务，调用读测试用例池5512模块，从测试用例池52里读取调试用的测试用例并选择，然后通过调用测试消息发送模块5513，从选择的测试用例中取出测试消息，向模块和子系统3发送，进行白盒测试，接收显示功能实体552任务接收到测试响应消息，直接显示消息原语给测试人员，实现对模块内部重要消息的跟踪调试。第五步也可以在第三步进行，但这两步应避免同时进行。

曾利用6周的时间按照上述方法在Windows2000上开发了测试装置5，对一些上层协议软件在PC(个人电脑)上进行了试验测试。结果表明，该方法能有效的检查出如消息参数错误、模块状态转移错误、以及状态处理错误等缺陷。较以前的方法能缩短尽50％的模块和子系统测试时间。同时，上述模块测试缺陷的发现概率能够达到80％，有效的避免了将上述缺陷引入到系统测试阶段。