(一)技术领域

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

(二)背景技术

现有的大型嵌入式系统软件的测试主要包括以下几个方面：源码测试、模块 测试、集成测试、规程测试以及性能测试等。对于源码测试、集成测试、规程测试 以及性能测试一般都有第三方提供的相应测试工具，如源码测试工具有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 SQL Server(美国微软公司的一种数据库管理软件)来存储所有的测试用 例，根据一个或多个需要测试的模块和子系统来生成表格，每个测试用例存储在表 格的一行内，作为一个记录，记录的字段值依次是图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％，有效的避免了将上述缺陷引入到系统测试阶段。