CN118012762A - 用于嵌入式操作系统消息传递机制测试的辅助方法 - Google Patents

Abstract

本申请涉及一种用于嵌入式操作系统消息传递机制测试的辅助方法，该方法包括：预先设置参数配置规则；构建用于消息测试的用户态进程；根据用户使用需求，在运行用户态进程时，按照配置参数规则输入相应的命令参数，控制用户态进程为客户端进程或服务端进程中的至少一种。本申请通过在设计测试用例中使用这个辅助工具即用户态进程，可以省去60％‑70％的编码量，维护好这一套测试辅助进程的代码质量，而不是几百个消息收发测试进程，由此降低编码工作量，同时因为代码量的减少，也降低了测试代码本身的bug率。

Description

用于嵌入式操作系统消息传递机制测试的辅助方法

技术领域

本公开涉及数据传输技术领域，尤其涉及一种用于嵌入式操作系统消息传递机制测试的辅助方法。

背景技术

微内核嵌入式操作系统中，进程间交互起着至关重要的作用，而同步的消息传递机制作为进程间交互的一种方式，不需要额外使用同步机制来保证消息传递过程的准确性，类似于微内核嵌入式操作系统的粘结剂，可以让不同进程间方便的实现数据交互。其中，文件系统，网络协议栈，乃至更上层的用户进程相互之间通信，都需要使用消息机制提供的接口来实现，所以消息机制提供的API接口(Application Programming Interface，应用程序编程接口)的测试，就显得颇为重要和基础，只有这些接口功能正确，才能保证上层用户态进程得到的数据是正确的。因此，测试需要考虑在各种使用场景下，消息的接口都能满足预期的功能，但这样会导致需要设计大量的代码来验证这些功能。

消息传递机制的进程间通信，通常需要有服务端接收数据并回复数据，客户端进程发送数据。针对不同的消息通信场景，需要单独设计服务端和客户端数据交互的模型。然而，实际运行中消息的测试场景非常多，例如消息测试的接口有几十个，涉及的黑盒测试用例的个数有数百个，针对每一个消息测试的场景，去设计一套数据收发的代码，且每一套代码都需要调试保证其正确性，这样测试人员的工作量非常大，效率也相对较低。

发明内容

有鉴于此，本申请提出一种用于嵌入式操作系统消息传递机制测试的辅助方法，以解决上述问题。

本申请一方面，提出一种用于嵌入式操作系统消息传递机制测试的辅助方法，包括如下步骤：

预先设置参数配置规则；

构建用于消息测试的用户态进程；

根据用户使用需求，在运行所述用户态进程时，参照所述参数配置规则输入相应的参数命令，以控制所述用户态进程为客户端进程或服务端进程中的至少一种。

作为本申请的一可选实施方案，可选地，所述构建用于消息测试的用户态进程，包括：

获取用户态源码；

将所述用户态源码编译为可执行文件，并指定与所述用户态进程相对应的所述可执行文件的名称和路径；

将所述可执行文件与操作系统打包成镜像文件；

下载所述镜像文件并启动，通过终端命令行工具运行所述用户态进程。

作为本申请的一可选实施方案，可选地，所述参数配置规则包括功能测试参数配置规则，且所述功能测试参数配置规则包括服务端进程配置规则、客户端进程配置规则和组合测试配置规则。

作为本申请的一可选实施方案，可选地，根据用户使用需求，在运行所述用户态进程时参照所述参数配置规则输入相应的参数命令，以控制所述用户态进程为客户端进程或服务端进程中的至少一种时，包括：

运行所述用户态进程；

在用户使用需求为作为独立的消息接收和回复方时，根据所述服务端进程配置规则，在运行所述用户态进程时输入相应的服务端参数命令；

根据所述服务端参数命令控制所述用户态进程为服务端进程。

作为本申请的一可选实施方案，可选地，根据用户使用需求，在运行所述用户态进程时，参照所述参数配置规则输入相应的参数命令，以控制所述用户态进程为客户端进程或服务端进程中的至少一种时，包括：

运行所述用户态进程；

在用户使用需求为作为独立的消息发送方时，根据所述客户端进程配置规则，在运行所述用户态进程时输入相应的客户端参数命令；

根据所述客户端参数命令控制所述用户态进程为客户端进程。

作为本申请的一可选实施方案，可选地，根据用户使用需求，在所述用户态进程中，参照所述参数配置规则，在运行所述用户态进程时输入相应的参数命令，控制所述用户态进程为客户端进程或服务端进程中的至少一种时，包括：

运行所述用户态进程；

在所述用户使用需求为组合使用时，根据所述组合测试配置规则，在运行所述用户态进程时输入相应的服务端参数命令和客户端参数命令；

根据所述服务端参数命令和所述客户端参数命令控制所述用户态进程为服务端进程和客户端进程，利用所述服务端进程与所述客户端进程进行通信。

本申请另一方面，提供一种嵌入式操作系统消息传递机制测试辅助方法运行的软硬件平台，其特征在于，包括：软件环境和硬件环境；

所述软件环境包括支持消息传递机制的嵌入式操作系统，用于为上述任一项所述的所述嵌入式操作系统消息传递机制测试的辅助方法运行提供软件运行环境；

所述硬件环境包括处理器、用于存储处理器可执行指令的存储器和板卡；

其中，所述处理器被配置为执行所述可执行指令时实现上述任一项所述的用于嵌入式操作系统消息传递机制测试的辅助方法。

本发明的技术效果：

本申请通过配置不同的参数使得用户态进程，即辅助消息测试工具，既可以作为消息发送的客户端进程使用，又可以作为消息接收的服务端进程使用，无需针对每个用例去单独设计服务端和客户端，省去60％-70％的编码量。具体的，包括：预先设置参数配置规则；构建用于消息测试的用户态进程；根据用户使用需求，在运行用户态进程时，参照参数配置规则输入相应的参数命令，控制用户态进程为客户端进程或服务端进程中的至少一种。本申请通过在设计测试用例中使用这个辅助工具即用户态进程，可以省去60％-70％的编码量，维护好这一套测试辅助进程的代码质量，而不是几百个消息收发测试进程，由此降低编码工作量，同时因为代码量的减少，也降低了测试代码本身的bug率。

根据下面参考附图对示例性实施例的详细说明，本公开的其它特征及方面将变得清楚。

附图说明

包含在说明书中并且构成说明书的一部分的附图与说明书一起示出了本公开的示例性实施例、特征和方面，并且用于解释本公开的原理。

图1示出为本发明的用于嵌入式操作系统消息传递机制测试的辅助方法的流程示意图；

图2示出为本发明的用于嵌入式操作系统消息传递机制测试的辅助方法中用户态进程的构建流程示意图。

具体实施方式

以下将参考附图详细说明本公开的各种示例性实施例、特征和方面。附图中相同的附图标记表示功能相同或相似的元件。尽管在附图中示出了实施例的各种方面，但是除非特别指出，不必按比例绘制附图。

在这里专用的词“示例性”意为“用作例子、实施例或说明性”。这里作为“示例性”所说明的任何实施例不必解释为优于或好于其它实施例。

另外，为了更好的说明本公开，在下文的具体实施方式中给出了众多的具体细节。本领域技术人员应当理解，没有某些具体细节，本公开同样可以实施。在一些实例中，对于本领域技术人员熟知的方法、手段、元件和电路未作详细描述，以便于凸显本公开的主旨。

操作系统与上层应用的交互中，块消息比短消息的使用更为普遍，因此下文以块消息为例对本申请方法的使用和能够实现的功能进行阐述。

实施例1

如图1所示，本申请一方面，提供一种用于嵌入式操作系统消息传递机制测试的辅助方法，包括如下步骤：

S100、预先设置参数配置规则；

S200、构建用于消息测试的用户态进程；

S300、根据用户使用需求，在运行所述用户态进程时，参照所述参数配置规则输入相应的参数命令，控制所述用户态进程为客户端进程或服务端进程中的至少一种。

本实施例中，通过配置不同的参数使得用户态进程，即辅助消息测试工具，既可以作为消息发送的客户端进程使用，又可以作为消息接收的服务端进程使用，无需针对每个用例去单独设计服务端和客户端，省去60％-70％的编码量。

具体而言，首先通过步骤S100、预先设置参数配置规则。

作为本申请的一可选实施方案，可选地，所述参数配置规则包括功能测试参数配置规则，且所述功能测试参数配置规则包括服务端进程配置规则、客户端进程配置规则和组合测试配置规则。

需要说明的是，服务端进程作为独立的消息接收方和回复方，用于接收消息，同时把收到的数据原封不动的回给客户端进程，可以用在某些测试场景中作为消息的接收方。具体的，在配置服务端进程配置规则时，后台运行用户态进程msg_tool，配置参数-R，使得用户态进程为服务端server进程。不仅如此，还相应的配置接收消息的循环次数参数、块缓冲区个数参数、数据头大小参数和缓冲区大小参数，其中配置参数-l，指定接收消息的循环次数；配置参数-N，指定接收消息的块缓冲区个数；配置参数-H，指定接收消息的数据头大小；配置参数-L，指定接收消息除数据头外其它每个缓冲区大小。由于消息的数据头大小和消息的数据缓冲区大小可以灵活设置，因此可以满足多种场景的测试，也可以测试消息多个缓冲区拼接的场景。

客户端进程作为独立的消息发送方，用于发送消息，并判断服务端回复的数据是否正确。具体的，在配置客户端进程配置规则时，后台运行用户态进程msg_tool，并配置参数-S，使其为客户端client进程。不仅如此，还相应的配置通信进程的进程号和消息通道id，以及发送消息的循环次数、块缓冲区个数、数据头大小、块缓冲区大小和随机测试标志。具体的，配置参数-p，指定要通信进程的进程号；配置参数-c，指定要通信进程的消息通道id；配置参数-l，指定发送消息的循环次数，且与服务端server保持一致；配置参数-N，指定发送消息的块缓冲区个数；配置参数-H，指定发送消息的数据头大小；配置参数-L，指定发送消息除数据头外其它缓冲区大小；配置参数-D，指定随机测试，且随机测试包括发送的数据内容随机和发送的数据长度随机。

制定好功能测试参数配置规则后，通过步骤S200、构建用于消息测试的用户态进程。

作为本申请的一可选实施方案，可选地，所述构建用于消息测试的用户态进程，包括：

S210、获取用户态源码；

S220、将所述用户态源码编译为可执行文件，并指定与所述用户态进程相对应的所述可执行文件的名称和路径；

S230、将所述可执行文件与操作系统打包成镜像文件；

S240、下载所述镜像文件并启动，通过终端命令行工具运行所述用户态进程。

需要说明的是，本申请在获取用户态源码后，将辅助测试进程源码放到操作系统用户态目录中，随后配置测试进程编译出的可执行文件的路径和名称，将其添加到操作系统文件系统中。进一步的，将辅助测试进程与嵌入式操作系统一起编译、打包成镜像文件。将打包的镜像文件下载到硬件平台上，或者虚拟机上，启动，通过终端命令行工具运行该辅助测试进程，即用户态进程。

也即，如图2所示，用户在使用嵌入式操作系统时，用户新建的工程，用户态源码设计好后，需要对用户态源码执行编译，将其编译为可执行文件。具体的，在makefile文件中指定当前源文件编译依赖的头文件和库的路径，并指定这些用户态源码生成的可执行文件的路径和可执行文件的名称。随后，将内核和bsp等包括用户态可执行文件集打包成一个镜像文件，此时用户态进程msg_tool已经被打包到镜像中了，msg_tool关键字就是用户态可执行文件的名称。进一步的，将镜像文件通过tftp的方式下载到板子上或虚拟机上，启动系统。系统启动后于终端打开相应的目录，运行可执行文件，由于可执行文件已经被打包到了镜像中，所以终端输入可执行文件的名称即可识别，想执行哪个用户进程，就在终端输入哪个用户进程的可执行文件的名字。例如，用户态进程msg_tool已经被打包到镜像中，msg_tool关键字就是这个可执行文件的名称，板子上电启动后，直接在终端输入msg_tool和对应的参数命令，系统即可识别到用户态进程msg_tool，并成功将其以服务端进程或客户端进程的方式运行起来。

其中本申请的源代码形式，依赖操作系统本身提供的消息的API接口，和其他库。makefile中会指定编译链接时，它需要依赖的操作系统提供的库或者API接口的路径，这样编译时就能链接到相关文件。

最后，通过步骤S300、根据用户使用需求，在运行所述用户态进程时，参照所述参数配置规则输入相应的参数命令，以控制所述用户态进程为客户端进程或服务端进程中的至少一种。

作为本申请的一可选实施方案，可选地，根据用户使用需求，在运行所述用户态进程时，参照所述参数配置规则输入相应的参数命令，控制所述用户态进程为客户端进程或服务端进程中的至少一种时，包括：

运行所述用户态进程；

在用户使用需求为作为独立的消息接收和回复方时，根据所述服务端进程配置规则，在运行所述用户态进程时输入相应的服务端参数命令；

根据所述服务端参数命令控制所述用户态进程为服务端进程。

需要说明的是，在用户使用需求为作为独立的消息接收和回复方时，按照预设的服务端进程配置规则在运行的作为辅助消息测试工具的用户态进程中输入对应的服务端参数命令，例如，在命令行终端输入命令：msg_tool-R-l 1000-N 10-H 24-L 2048&，其中“&”表示后台运行，-R这个参数指定了当前此进程是个server，所以它只被动的接收消息并回复给对方(-R是msg_tool这个进程代码中指定的参数，且可以进行修改)，-l表示循环次数，1000是指循环1000次，也就是说接收1000次数据后退出；-N代表块缓冲区的个数，-N 10表示每个消息包中有10个数据块缓冲区；-H 24每个消息块的数据头长度是24字节；-L2048表示每个数据块的长度为2048个字节。由此，使用户态进程作为服务端进程。

作为本申请的一可选实施方案，可选地，根据用户使用需求，在运行所述用户态进程时，参照所述参数配置规则输入相应的参数命令，以控制所述用户态进程为客户端进程或服务端进程中的至少一种时，包括：

运行所述用户态进程；

在用户使用需求为作为独立的消息发送方时，根据所述客户端进程配置规则，在运行所述用户态进程时输入相应的客户端参数命令；

根据所述客户端参数命令控制所述用户态进程为客户端进程。

在用户使用需求为作为独立的消息发送方时，按照预设的客户端进程配置规则，在运行用户态进程时输入对应的客户端参数命令。例如，在命令行终端输入命令：msg_tool-S-p pid-c chid-l 1000-N 10-H 24-L 2048-D&，其中，“&”表示后台运行，-p pid，pid是一个具体数据，为想要通信的server进程的id号；-c chid，chid表示是一个具体数据，为想要通信的server进程中用来接收消息的通道编号，server运行起来的时候会打印自己的pid和chid；-S指定了当前此进程是个client，它是主动的向外发送数据；-l表示循环次数，1000是指循环1000次，表示其接收1000次数据后，就退出；-N代表块缓冲区的个数，-N 10表示每个消息包中有10个块；-H 24每个消息块的数据头长度是24字节；-L 2048表示每个数据块的长度为2048个字节。

作为本申请的一可选实施方案，可选地，根据用户使用需求，在运行所述用户态进程时参照所述参数配置规则输入相应的参数命令，以控制所述用户态进程为客户端进程或服务端进程中的至少一种时，包括：

运行所述用户态进程；

在所述用户使用需求为组合使用时，根据所述组合测试配置规则，在运行所述用户态进程时，输入相应的服务端参数命令和客户端参数命令；

根据所述服务端参数命令和所述客户端参数命令控制所述用户态进程为服务端进程和客户端进程，利用所述服务端进程与所述客户端进程进行通信。

需要说明的是，本申请的用户态进程既可以作为客户端，又可以作为服务端。例如对于A进程、B进程和C进程而言，A进程既可以作为B进程的客户端，又可以作为C进行的服务端，也即能够组合使用，那么在运行A进程时同时配置-R-S-p pid(进程B的pid)-c chid(进程B的chid)，及其它参数，A进程即可同时是B进程的客户端，又可是C进程的服务端。对于客户端与服务端组合进程而言，首先通过在后台运行用户态进程中配置为接收消息的服务端进程(根据使用需求，可选的指定它也为客户端，如上文例子)，并配置好想要测试的块消息大小，具体配置的参数如上文所示。随后在后台运行用户态进程配置为消息接收的客户端进程(根据使用需求，可选的指定它也为服务端)，参数配置如上文所示，使用这两个进程来通信，实现想要的测试。

需要特别说明的是，不仅可以后台运行这个用户态进程进行手动测试，还可以通过spawn类的posix接口来加载这个进程，并配置想要的参数，以满足用例自动化测试的需求。也即上述测试的步骤举例，是以手动测试为例的，若是自动测试的话，在自动测试的用例代码中，调用spawn接口来加载msg_tool，并在加载msg_tool时，spawn传入想要的参数命令，在合适的位置等待这个进程对结束即可，参数配置如前文所述。

不仅如此，本申请为了能够测试一个服务端进程同时与多个客户端进程通信的场景，确定是否存在数据交叉，收发数据是否正确、稳定。在配置多客户端进程参数配置规则时，首先后台运行用户态进程，配置参数-R，使得它为server进程；

配置参数-l，指定接收消息的循环次数；

配置参数-N，指定接收消息的块缓冲区个数；

配置参数-H，指定接收消息的数据头大小；

配置参数-L，指定接收消息除数据头外其它缓冲区大小。

随后，后台运行msg_tool，接着加载msg_tool配置参数-S，使其成为客户端进程。此处，需要说明的是，可以手动加载多个客户端进程，也可以通过spawn接口在代码中加载，具体加载多少个客户端进程可根据实际需求自行确定。

配置配置参数-l，指定发送消息的循环次数，与server保持一致；

配置参数-N，指定发送消息的块消息个数；

配置参数-H，指定发送消息的数据头大小；

配置参数-L，指定发送消息除数据头外其它缓冲区大小；

配置参数-D，指定随机测试(发送的数据内容随机，发送的数据长度随机)。

而对于多个服务端和客户端进程通信的场景，测试的目的是为了测试当前系统能够正常运行的进程极限，极限情况下是否有异常，或者数据通信是否正确。因为收发消息的数据量和测试的时间可以设置，也可以方便的适配为稳定性测试的场景，连续循环测试几天或者几个星期。例如，当前操作系统支持的最大的进程个数为PROC_MAX，那测试的进程对个数极限为PROC_MAX/2，至于稳定性测试的场景，可以把测试的进程对个数降低。

具体的，循环测试PROC_MAX/2次。

首先，每次循环，先加载msg_tool配置参数-R，使得它为服务端server进程；

配置参数-l，指定接收消息的循环次数；

配置参数-N，指定接收消息的块缓冲区个数；

配置参数-H，指定接收消息的数据头大小；

配置参数-L，指定接收消息除数据头外其它缓冲区大小；

其次，每次循环，接着加载msg_tool配置参数-S，使得它为client进程；

配置参数-l，指定发送消息的循环次数，与server保持一致；

配置参数-N，指定发送消息的块缓冲区个数；

配置参数-H，指定发送消息的数据头大小；

配置参数-L，指定发送消息除数据头外其它缓冲区大小；

配置参数-D，指定随机测试(发送的数据内容随机，发送的数据长度随机)；

最后，循环等待这些创建的进程结束。

其中，循环测试过程中，服务端或者客户端有任何异常，跳出循环，断开连接。测试过程中每一对进程通信的数据的正确性，由客户端来判断。

下面将提供几组具体场景实例作进一步的说明。

例1，以一个server带10个client的场景，手动测试为例，只需要在终端运行10个client即可。

1、在命令行终端输入命令：msg_tool-R-l 1000-N 10-H 24-L 2048&后按下回车键；

“&”表示后台运行，-R这个参数指定了当前此进程是个server，所以它只被动的接收消息并回复给对方；

2、在命令行终端输入msg_tool-S-p pid(实际的步骤1中进程id)-c chid(实际步骤1中通道号)-l 1000-N 10-H 24-L 2048-D&后按下回车键；

3、重复步骤2的步骤9次。

此时，实现了1个server带10个client场景测试，尽管每个client参数相同，但由于是随机测试，每个client发送的数据长度和内容都与其他client有差异。

若自动测试仅通过通用的spawn接口循环加载10次msg_tool，并每次将其配置成client即可。具体的，自动测试一个server和10个client进程同时进行消息传递，spawn(cmd_server,NULL,argv,NULL)，仅需在测试用例代码中通过spawn加载这个msg_tool 10次即可，cmd_server表示msg_tool这个可执行文件的路径，argv则是给msg_tool进程传递的参数。

例2，20对进程测试

手动测试时，手动加载msg_tool进程，使它为server，并在后台运行。

1、终端输入命令msg_tool-R-l 1000-N 10-H 24-L 2048&

2、再运行msg_tool-S-p pid(实际的步骤1)中进程id)-c chid(实际步骤a)中通道号)-l 1000-N 10-H 24-L 2048-D&

3、重复1、2过程20次，就加载了相互通信的20对进程。

例3，100对进程测试

在测试用例代码中循环加载进程对，循环100次，每次循环先加载server进程，获得server进程的pid和chid，之后加载client进程

pid_s＝spawn(cmd,NULL,argv_server,NULL)；

pid_c＝spawn(cmd,NULL,argv_client,NULL)；

cmd代表msg_tool可执行文件的路径，

argv_server代表以server方式加载msg_tool时需要传的命令参数；

argv_client代表以client方式加载msg_tool时需要传的命令参数。

由此可知，本申请的方法通过配置多种参数，既可以作为消息发送的客户端进程使用，也可以作为消息接收的服务端进程来使用，既可以处理普通消息(单个缓冲区短消息)、块消息(数据头加多个数据缓冲区，处理长消息)，也同时支持pulse类消息。通过配置不同参数的方式来实现想要的服务端模型或客户端模型，不需要针对每个用例都去设计单独服务端和客户端。在使用方式上，可以后台运行此测试进程手动测试，也可以在其他测试用例代码中通过posix接口spawn函数来加载这个工具msg_tool，并配置想要的参数，以满足用例自动化测试的需要。

不仅如此，本申请提供的消息传递的模型，默认是循环测试，每次数据收发可以发送固定数据，也可以收发随机长度随机内容的数据，可以设置数据收发的循环次数，以支持稳定性测试场景。并且数据发送或接收过程中，当有异常或错误时，自动退出循环，输出必要的打印提示信息和错误码，并退出进程。

本申请数据收发过程中使用的是随机字符，如果在收发数据不一致的情况下追踪bug时，需要查看完整的数据分析问题，使用固定的一段字符串来组装发送的数据，更容易排查，可以在工具中不使用随机测试，把发送的数据用已知的字符串来替换。

综上所述，本申请通过在设计测试用例中使用这个辅助工具即用户态进程，可以省去60％-70％的编码量，维护好这一套测试辅助进程的代码质量，而不是几百个消息收据收发测试进程，对于少数更为复杂和灵活的测试场景，可以有针对性地重新设计，由此降低编码工作量，同时因为代码量的减少，也降低了测试代码本身的bug率。使用这个辅助测试用具，为多种使用场景提供通信模型，一方面把原来大量的编码工作工具化，另一方面，多对进程随机长度的数据收发循环测试，除了测试消息这些接口本身功能的功能，也一定程度上测试了操作系统内存管理模块的稳定性。

本领域技术人员可以理解，

实施例2

本申请另一方面，提供一种嵌入式操作系统实现上述实施例方法中的全部或部分流程，是可以通过计算机程序来指令相关的硬件来完成的，程序可存储于一计算机可读取存储介质中，该程序在执行时，可包括如上述各控制方法的实施例的流程。其中，存储介质可为磁碟、光盘、只读存储记忆体(Read-OnlyMemory，ROM)、随机存储记忆体(RandomAccessMemory，RAM)、快闪存储器(FlashMemory)、硬盘(HardDiskDrive，缩写：HDD)或固态硬盘(Solid-StateDrive，SSD)等；存储介质还可以包括上述种类的存储器的组合。消息传递机制测试辅助方法运行的软硬件平台，其特征在于，包括：软件环境和硬件环境；

所述软件环境包括支持消息传递机制的嵌入式操作系统，用于为上述任一项所述的嵌入式操作系统消息传递机制测试的辅助方法运行提供软件运行环境；

所述硬件环境包括处理器、用于存储处理器可执行指令的存储器和板卡；

其中，所述处理器被配置为执行所述可执行指令时实现上述任一项所述的用于嵌入式操作系统消息传递机制测试的辅助方法。

此处，应当指出的是，处理器的个数可以为一个或多个。同时，在本公开实施例的软硬件平台中，还可以包括输入装置和输出装置。其中，处理器、存储器、输入装置和输出装置之间可以通过总线连接，也可以通过其他方式连接，此处不进行具体限定。

存储器作为一计算机可读存储介质，可用于存储软件程序、计算机可执行程序和各种模块，如：本公开实施例的用于消息传递机制测试的辅助方法所对应的程序或模块。处理器通过运行存储在存储器中的软件程序或模块，从而执行软硬件平台的各种功能应用及数据处理。

输入装置可用于接收输入的数字或信号。其中，信号可以为产生与设备/终端/服务器的用户设置以及功能控制有关的键信号。输出装置可以包括显示屏等显示设备。

以上已经描述了本公开的各实施例，上述说明是示例性的，并非穷尽性的，并且也不限于所披露的各实施例。在不偏离所说明的各实施例的范围和精神的情况下，对于本技术领域的普通技术人员来说许多修改和变更都是显而易见的。本文中所用术语的选择，旨在最好地解释各实施例的原理、实际应用或对市场中的技术的技术改进，或者使本技术领域的其它普通技术人员能理解本文披露的各实施例。

Claims (7)

1.一种用于嵌入式操作系统消息传递机制测试的辅助方法，其特征在于，包括如下步骤：

预先设置参数配置规则；

构建用于消息测试的用户态进程；

根据用户使用需求，在运行所述用户态进程时参照所述参数配置规则输入相应的参数命令，以控制所述用户态进程为客户端进程或服务端进程中的至少一种。

2.根据权利要求1所述的用于嵌入式操作系统消息传递机制测试的辅助方法，其特征在于，所述构建用于消息测试的用户态进程，包括：

获取用户态源码；

将所述用户态源码编译为可执行文件，并指定与所述用户态进程相对应的所述可执行文件的名称和路径；

将所述可执行文件与操作系统一起打包成镜像文件；

下载所述镜像文件并启动，运行所述用户态进程。

3.根据权利要求1所述的用于嵌入式操作系统消息传递机制测试的辅助方法，其特征在于，所述参数配置规则包括功能测试参数配置规则，且所述功能测试参数配置规则包括服务端进程配置规则、客户端进程配置规则和组合测试配置规则。

4.根据权利要求3所述的用于嵌入式操作系统消息传递机制测试的辅助方法，其特征在于，根据用户使用需求，在运行所述用户态进程时参照所述参数配置规则输入相应的参数命令，以控制所述用户态进程为客户端进程或服务端进程中的至少一种时，包括：

运行所述用户态进程；

在所述用户使用需求为作为独立的消息接收和回复方时，根据所述服务端进程配置规则，在运行所述用户态进程时输入相应的服务端参数命令；

根据所述服务端参数命令控制所述用户态进程为服务端进程。

5.根据权利要求4所述的用于嵌入式操作系统消息传递机制测试的辅助方法，其特征在于，根据用户使用需求，在运行所述用户态进程时参照所述参数配置规则输入相应的参数命令，以控制所述用户态进程为客户端进程或服务端进程中的至少一种时，包括：

运行所述用户态进程；

在所述用户使用需求为作为独立的消息发送方时，根据所述客户端进程配置规则，在运行所述用户态进程时输入相应的客户端参数命令；

根据所述客户端参数命令控制所述用户态进程为客户端进程。

6.根据权利要求5所述的用于嵌入式操作系统消息传递机制测试的辅助方法，其特征在于，所述根据用户使用需求，在运行所述用户态进程时参照所述参数配置规则输入相应的参数命令，控制所述用户态进程为客户端进程或服务端进程中的至少一种时，包括：

运行所述用户态进程；

在所述用户使用需求为组合使用时，根据所述组合测试配置规则，在运行所述用户态进程时输入相应的服务端参数命令和客户端参数命令；

根据所述服务端参数命令和所述客户端参数命令控制所述用户态进程为服务端进程和客户端进程，利用所述服务端进程与所述客户端进程进行通信。

7.一种嵌入式操作系统消息传递机制测试辅助方法运行的软硬件平台，其特征在于，包括：软件环境和硬件环境；

所述软件环境包括支持消息传递机制的嵌入式操作系统，用于为权利要求1-6任一项所述的嵌入式操作系统消息传递机制测试的辅助方法运行提供软件运行环境；

所述硬件环境包括处理器、用于存储处理器可执行指令的存储器和板卡；

其中，所述处理器被配置为执行所述可执行指令时实现权利要求1至6任一项所述的用于嵌入式操作系统消息传递机制测试的辅助方法。