随着现代计算机技术的日益进步，人们对于计算机系统的各种开发和维护也变得越来越 容易。操作系统接口将硬件细节与程序员隔离开来，提供了一组可以方便的对硬件资源进行 管理和操作的方法。嵌入式操作系统的接口一般包括进程、线程、内存管理、文件系统等方 面，依据应用需要还可以提供网络接口和图形接口等。操作系统的绝大部分接口在系统开发 早期就定义下来了，在嵌入式操作系统开发过程中，为了确保开发稳步推进，我们需要对系 统接口进行不断的回归测试。回归测试发生在软件修改之后，通常会对一天以内的代码修改 进行一次全面的回归测试，保证该日开发的正确性，也便于及时定位和解决该日开发出现的 bug，确保软件开发稳步推进。
最初对操作系统接口的测试通常采用单元测试和集成测试的手段开发测试用例代码，然 后将开发完毕的测试代码纳入回归测试，这样的测试用例通常达到成千上万个，所有测试代 码的可执行文件大小达到成百上千兆。嵌入式操作系统与通用操作系统不同，嵌入式系统的 运行代码的开发、编译和链接是在开发机(例如装有Windows操作系统的计算机)上完成的， 需要将可执行文件从开发机上传到嵌入式设备，这样就存在一个文件传输的过程，并且它所 运行的嵌入式设备一般存储空间都比较小，难以承载上百兆的测试程序。通常我们想到的最 简单的方法是，手动下载一个测试程序到嵌入式设备上运行，然后查看结果，删除该测试文 件，然后再下载另一个测试程序继续运行。
这种测试方法需要人工干预，并且手动运行测试用例将花费大量的时间，回归测试周期 长，导致了开发周期的延长，并且操作过程比较枯燥，要想在有限的时间内完成一次回归测 试往往需要耗费较多的人力和物力。

本发明的目的是克服了上述现有技术中的缺点，提供一种能够在有限存储资源的嵌入式 设备上自动完成所有测试用例程序的运行、无需人工干预、节约人力资源、有效缩短回归测 试周期、保证嵌入式系统开发快速平稳的推进、性能稳定可靠、适用范围较为广泛的嵌入式 操作系统中接口测试的自动化运行方法。
为了实现上述的目的，本发明的嵌入式操作系统中接口测试的自动化运行方法如下：
该嵌入式操作系统中接口测试的自动化运行方法，包括开发机系统和嵌入式操作系统的 宿主测试目标机系统，所述的开发机系统中的通信装置通过数据链路与目标机系统中的通信 装置相连接，其主要特点是，所述的方法包括以下步骤：
(1)开发机系统定期进行生成嵌入式操作系统测试对象、测试执行脚本和测试用例信息 的处理；
(2)开发机系统通过通信装置将所述的嵌入式操作系统测试对象传输到目标机系统中；
(3)目标机系统进行启动嵌入式操作系统和从开发机系统下载测试执行脚本的处理；
(4)目标机系统执行测试执行脚本，从开发机系统下载测试用例信息；
(5)目标机系统运行测试用例信息并产生测试输出信息；
(6)目标机系统通过通信装置向开发机系统传送该测试输出信息；
(7)目标机系统删除当前测试用例信息和测试输出信息；
(8)目标机系统判断测试执行脚本是否执行完毕，如果未执行完毕，则返回步骤(4) 运行；
(9)如果执行完毕，则目标机系统通过通信装置向开发机系统传送测试结束信息；
(10)开发机系统接收到该测试结束信息，并将预设的标准输出信息与接收到的测试输 出信息进行比较，得到测试运行结果。
该嵌入式操作系统中接口测试的自动化运行方法的定期生成嵌入式操作系统测试对象、 测试执行脚本和测试用例信息包括以下步骤：
(1)系统定时从源代码服务器上下载最新的代码；
(2)将上述代码编译生成嵌入式操作系统的镜像文件和所有的测试用例程序；
(3)系统将各测试用例程序所对应的执行脚本合成并生成测试执行脚本。
该嵌入式操作系统中接口测试的自动化运行方法的将嵌入式操作系统测试对象传输到目 标机系统中包括以下步骤：
(1)开发机系统通过通信装置发送通知重启标志数据到目标机系统，通知目标机系统重 启；
(2)目标机系统接收到开发机系统发送来的通知重启标志数据，重新启动系统；
(3)开发机系统待目标机系统重启后，通过通讯装置将嵌入式操作系统的镜像文件传输 到目标机系统上；
(4)目标机系统通过通信装置接收到开发机系统发送的镜像文件，并将其烧写到目标机 系统的嵌入式设备中。
该嵌入式操作系统中接口测试的自动化运行方法的源代码服务器可以为CVS源代码管 理服务器、ClearCase源代码管理服务器或者SourceSafe源代码管理服务器。
该嵌入式操作系统中接口测试的自动化运行方法的启动嵌入式操作系统和从开发机系统 下载测试执行脚本的处理包括以下步骤：
(1)目标机系统判断该启动属于以下两种情况中的哪一种：新系统烧写完后首次启动， 新系统因测试运行过程中发生异常而重启；
(2)如果是新系统烧写完后首次启动，则目标机系统通过通信装置从开发机系统下载测 试执行脚本；
(3)如果是新系统因测试运行过程中发生异常而重启，则将测试执行脚本中已经执行过 的命令行删除，只保留未执行过的命令行内容。
该嵌入式操作系统中接口测试的自动化运行方法的目标机系统运行测试用例信息包括以 下步骤：
(1)系统在启动执行该测试用例信息之前记录下当前运行的程序命令行；
(2)系统创建相应的测试用例信息的进程并开始执行，并在执行测试用例进程的过程中 实时监控各种异常情况的出现；
(3)如果测试用例进程的运行使得系统陷入死锁，则系统将杀死在一段特定时间后还没 有运行完毕的进程，若杀死该进程成功，则继续运行下一个命令行；若杀死该进程失败，则 进行系统重启；
(4)如果测试用例进程的运行使得系统陷入调试状态，则系统将杀死该进程，若杀死该 进程成功，则继续运行下一个命令行；若杀死该进程失败，则进行系统重启；
(5)如果测试用例进程的运行使得系统内存不足，若发现系统内存低于系统预设值，则 进行系统重启。
该嵌入式操作系统中接口测试的自动化运行方法中，通过在系统的开发代码中添加的经 过条件编译控制的死锁监控代码、调试状态监控代码、内存监控代码进行异常情况的实时监 控。
该嵌入式操作系统中接口测试的自动化运行方法的测试结束信息为测试运行结束标志文 件。
该嵌入式操作系统中接口测试的自动化运行方法的标准输出信息为标准输出文件，所述 的测试输出信息为测试输出文件。
该嵌入式操作系统中接口测试的自动化运行方法的将预设的标准输出信息与接收到的测 试输出信息进行比较为：
使用文件比较工具将预设的标准输出文件与接收到的测试输出文件进行比较。
采用了该发明的嵌入式操作系统中接口测试的自动化运行方法，由于在开发机系统上实 现了自动编译代码，并通知目标机系统开始测试，且自动上传操作系统镜像文件和测试用例 程序，自动下载测试输出文件；同时，在目标机系统上实现了自动下载、运行和删除测试程 序，上传测试输出文件，自动处理各种系统异常，并保证异常处理之后测试执行脚本能够继 续运行下一个测试程序，最后通知开发机结束测试，从而实现了在有限存储资源的嵌入式设 备上进行嵌入式操作系统接口测试的自动化运行，无需人工干预，节约了人力资源，有效缩 短了回归测试的周期，保证嵌入式系统开发快速平稳的推进，性能稳定可靠。不仅如此，本 发明的嵌入式操作系统中接口测试的自动化运行方法并不限于操作系统接口，对于嵌入式操 作系统之上的应用接口的测试也同样适用，能够为应用开发带来益处，适用范围较为广泛， 为嵌入式系统及其上层软件的进一步发展奠定了坚实的基础。
附图说明
图1为本发明的嵌入式操作系统中接口测试的自动化运行方法的整体测试框架示意图。
图2为本发明的嵌入式操作系统中接口测试的自动化运行方法的目标机系统的测试过程 示意图。
图3为本发明的嵌入式操作系统中接口测试的自动化运行方法的开发机系统和目标机系 统之间进行文件传输的过程示意图。

为了能够更清楚地理解本发明的技术内容，特举以下实施例详细说明。
请参阅图1至图3所示，该嵌入式操作系统中接口测试的自动化运行方法，包括开发机 系统和嵌入式操作系统的宿主测试目标机系统，所述的开发机系统中的通信装置通过数据链 路与目标机系统中的通信装置相连接，其中，包括以下步骤：
(1)开发机系统定期进行生成嵌入式操作系统测试对象、测试执行脚本和测试用例信息 的处理，包括以下步骤：
(a)系统定时从源代码服务器上下载最新的代码，该源代码服务器可以为CVS源代
码管理服务器、ClearCase源代码管理服务器或者SourceSafe源代码管理服务器；
(b)将上述代码编译生成嵌入式操作系统的镜像文件和所有的测试用例程序；
(c)系统将各测试用例程序所对应的执行脚本合成并生成测试执行脚本；
(2)开发机系统通过通信装置将所述的嵌入式操作系统测试对象传输到目标机系统中， 包括以下步骤：
(a)开发机系统通过通信装置发送通知重启标志数据到目标机系统，通知目标机系 统重启；
(b)目标机系统接收到开发机系统发送来的通知重启标志数据，重新启动系统；
(c)开发机系统待目标机系统重启后，通过通讯装置将嵌入式操作系统的镜像文件 传输到目标机系统上；
(d)目标机系统通过通信装置接收到开发机系统发送的镜像文件，并将其烧写到目 标机系统的嵌入式设备中；
(3)目标机系统进行启动嵌入式操作系统和从开发机系统下载测试执行脚本的处理，包 括以下步骤：
(a)目标机系统判断该启动属于以下两种情况中的哪一种：新系统烧写完后首次启 动、新系统因测试运行过程中发生异常而重启；
(b)如果是新系统烧写完后首次启动，则目标机系统通过通信装置从开发机系统下 载测试执行脚本；
(c)如果是新系统因测试运行过程中发生异常而重启，则将测试执行脚本中已经执 行过的命令行删除，只保留未执行过的命令行内容；
(4)目标机系统执行测试执行脚本，从开发机系统下载测试用例信息；
(5)目标机系统运行测试用例信息并产生测试输出信息，包括以下步骤：
(a)系统在启动执行该测试用例信息之前记录下当前运行的程序命令行；
(b)系统创建相应的测试用例信息的进程并开始执行，并在执行测试用例进程的过 程中实时监控各种异常情况的出现；
(c)如果测试用例进程的运行使得系统陷入死锁，则系统将杀死在一段特定时间后 还没有运行完毕的进程，若杀死该进程成功，则继续运行下一个命令行；若杀死该进 程失败，则进行系统重启；
(d)如果测试用例进程的运行使得系统陷入调试状态，则系统将杀死该进程，若杀 死该进程成功，则继续运行下一个命令行；若杀死该进程失败，则进行系统重启；
(e)如果测试用例进程的运行使得系统内存不足，若发现系统内存低于系统预设值， 则进行系统重启；
其中，可以通过在系统的开发代码中添加的经过条件编译控制的死锁监控代码、调试 状态监控代码、内存监控代码进行异常情况的实时监控。
(6)目标机系统通过通信装置向开发机系统传送该测试输出信息；
(7)目标机系统删除当前测试用例信息和测试输出信息；
(8)目标机系统判断测试执行脚本是否执行完毕，如果未执行完毕，则返回步骤(4) 运行；
(9)如果执行完毕，则目标机系统通过通信装置向开发机系统传送测试结束信息，该测 试结束信息为测试运行结束标志文件；
(10)开发机系统接收到该测试结束信息，并将预设的标准输出信息与接收到的测试输 出信息进行比较，得到测试运行结果，其中，该标准输出信息为标准输出文件，所述的测试 输出信息为测试输出文件，将预设的标准输出信息与接收到的测试输出信息进行比较为：
使用文件比较工具将预设的标准输出文件与接收到的测试输出文件进行比较。
在实际使用当中，本发明的嵌入式操作系统接口测试的自动化运行方法，由开发机和目 标机(即嵌入式设备)合作完成：开发机编译出所有的测试运行文件，开发机和目标机之间 采用通讯设备进行文件的上传和下载，目标机自动化对每个测试用例依次进行测试用例程序 的下载、运行，上传测试输出文件，删除测试程序和所生成的文件；嵌入式操作系统自动处 理测试程序运行过程中可能出现的各种系统异常情况，保证后继测试程序的自动继续运行。 这样便可以在有限存储资源的嵌入式设备上自动完成所有测试用例程序的运行，最后在开发 机端使用文件比较工具将目标机上传的测试输出文件与标准输出文件进行比较，获得测试结 果。
上述测试用例程序至少具有：
(1)每个测试用例程序对应一个标准输出文件，记录了该测试用例程序正确运行后写入 文件的结果，这是在初次运行测试用例程序时保存下来的。
(2)测试用例程序每次在回归测试中运行结束后都会生成一个与标准输出文件同名的输 出文件，记录当次的运行结果，称为测试输出文件，通过测试输出文件和标准输出文件的比 较我们可以得知该测试用例在回归测试中是否运行正确。
(3)需要保证各个测试用例程序的可执行文件名各不相同，避免编译后造成同名覆盖， 以及运行生成的输出文件的名字各不相同，避免某个测试用例运行的输出文件被其它测试用 例运行的输出文件覆盖。
(4)每个测试用例代码都放在不同的目录中，一个测试用例对应一个执行脚本，该执行 脚本在编写用例时完成，包括五个命令行，依次为：下载测试程序、运行测试程序、上传测 试输出文件、删除测试程序、删除测试输出文件。所有测试用例的执行脚本采用相同的名字 命名。
简单而言，接口方法的执行会出现正确或错误的两种情况，执行正确与否都需要向输出 文件写入一些语句，而且执行正确和执行错误写入输出文件的语句是不同的，因而可以通过 标准输出文件和回归测试中运行生成的输出文件的比较来判断测试用例运行是否正确。各测 试用例都有一个同名的执行脚本，所有的执行脚本可合成一个大的执行脚本，作为测试执行 脚本。如果某个用例出错了就注掉相应的执行脚本，没有必要再次运行，直到缺陷(bug)修 复后再修改它的执行脚本，加入测试中运行。
其中，上述的目标机至少具有：
●通讯设备，可与开发机建立连接进行数据通讯；
●对应的嵌入式操作系统具备该通讯设备的驱动程序，可实现一个传输工具，利用该 设备与开发机进行文件传输；
●对应的嵌入式操作系统至少具备控制台和文件系统，可进行各种文件操作，可采用 批处理文件运行程序。
而上述的开发机至少具有：
●通讯设备，可与目标机建立连接进行数据通讯；
●对应的操作系统具备该通讯设备驱动程序，可实现一个传输工具，利用该设备与目 标机进行文件传输；
●可在开发机系统平台上开发代码以及编译生成目标机代码。
实现本发明的嵌入式操作系统接口测试的自动化运行方法的步骤如下：
1、开发机端：
(1)定时从源代码服务器上下载代码并编译生成最新版本嵌入式操作系统的镜像文件， 以及所有的测试用例程序；
(2)将各测试用例执行脚本合成为“测试执行脚本”；
(3)通过通讯设备发送通知重启标志数据给目标机的守候程序通知目标机重启系统；
(4)等候一定时间待目标机重启后，通过通讯设备将系统镜像文件传输到目标机上进行 烧写；
(5)守候上传目标机所需的测试执行脚本或测试用例程序，守候接收目标机发送来的测 试输出文件和测试运行结束标志文件。
(6)接收到目标机发送来的测试运行结束标志文件，结束文件传输，使用比较工具比较 标准输出文件与测试输出文件得到测试运行结果。
2、目标机端：
(1)目标机上运行旧版本的嵌入式操作系统，其上执行一个守候程序一直在循环读取通 讯设备数据，当接收到开发机发送来的通知重启标志数据时便重新启动系统，并准备接收开 发机发送的镜像文件；
(2)目标机通过通讯设备接收镜像文件并烧写到嵌入式设备上；
(3)启动嵌入式操作系统，在控制台下会自动调用一个批处理文件运行，该批处理文件 执行如下操作：
A、系统启动可分为两种情况：新系统烧写完后首次启动和新系统因测试运行过程中发 生异常而重启。该步骤针对这两种不同的情况进行不同的处理：
如果是新系统烧写完后首次启动，则使用传输程序从开发机下载“测试执行脚本”；如果 新系统因测试运行过程中发生异常而重启，则依据“命令行记录文件”中记录的命令行，将测 试执行脚本从该命令行以上包括该命令行在内的命令行删除，只保留该命令行往下的命令行 内容。
“命令行记录文件”记录了新系统因出现异常重启之前最后执行的命令行，是该命令行的 执行导致系统重启。由于测试执行脚本是依次执行命令行的，依据“命令行记录文件”中记录 的命令行切除测试执行脚本里已经执行过的命令行，从而保证测试从后继未执行过的命令行 开始执行。
B、调用“测试执行脚本”运行，循环执行如下步骤直到运行完所有的命令行(循环执行过 程请参阅图2所示)：
a)使用传输程序从开发机下载一个测试用例程序；
b)控制台在启动执行该测试用例程序之前记录下当前运行的程序命令行到命令行记录文 件中。该文件每次都以写的方式打开，而非追加的方式，因此不论控制台执行多少次打开写 入该文件的操作，该文件都只记录最后一次打开写入的内容。
c)控制台创建该测试用例程序的进程并开始执行。在执行测试用例程序过程中可能会出 现各种异常情况，针对不同的异常情况采取不同的自动化处理手段：
●陷入死锁(Deadlock)——测试代码的运行可能会造成死锁，若不加处理就会阻碍 后继测试代码的运行。系统可监控该进程的运行，会自动杀死在一段特定时间后还 没有运行完毕的进程，若杀死该进程成功则继续运行下一个命令行，若杀死该进程 失败则重启系统，重启之前该命令行已被控制台记录在命令行记录文件中。
●陷入调试状态(Debug)——测试代码在运行过程中可能会陷入debug，若不加处 理就会阻碍后继测试代码的运行。陷入debug后，系统就会自动尝试杀死该进程， 若杀死该进程成功则继续运行下一个命令行，若杀死该进程失败则自动重启系统， 重启之前该命令行已被控制台记录在命令行记录文件中。
●内存不足(Out of Memory)——如果系统存在内存泄露，执行某些消耗内存的测 试程序可能会导致可用内存不足，此时若继续运行其它测试程序就会出现因内存不 足导致运行失败的情况，而该错误是上一个测试程序造成的，因此控制台在每运行 一个测试用例程序之前都有必要对系统内存进行监测，若发现系统内存低于某个指 定值，则重启系统，重启之前导致内存不足的测试程序运行命令行已被控制台记录 在命令行记录文件中。
若测试用例执行过程中没有出现异常情况，则继续执行以下步骤。
d)等待该测试用例程序运行完毕，向开发机上传测试输出文件；
e)删除测试用例程序和测试输出文件；
C、上传测试结束标志文件，通知开发机测试结束。
上述为了实现自动化异常处理过程，会在系统的开发代码中添加的一些测试专用的代码， 例如死锁监控代码以及内存监控代码等，这些代码经过条件编译控制仅在回归测试时才被编 译使用，保证开发代码和测试代码的独立。
上述所有步骤辅以脚本语言都可以实现自动运行，并且专门为嵌入式操作系统实现了自 动处理异常的功能，因而能够自动完成所有测试用例的执行，无需人工干预。
以下结合附图说明以及具体实例对本发明作进一步的详细说明。
本发明可以在Elastos嵌入式操作系统及其支持的嵌入式设备上实现接口测试的自动化运 行。Elastos是32位的嵌入式操作系统，其包含进程、线程等系统API以及图形系统、文件 系统和网络系统等系统服务。Elastos可以广泛应用于工业装备、信息家电、汽车电子、手持 设备等领域的各种嵌入式设备。这里所述的目标机是运行Elastos的ARM嵌入式设备，所述 的开发机是装有Windows2000操作系统的计算机，通讯设备采用嵌入式开发中常用的串口设 备。
首先介绍该自动化测试实例中用到的一些工具软件，包括：
(1)CVS工具。CVS是一套开源的源代码管理软件，采用CVS工具可以从CVS源代 码服务器上自动下载所需的源代码。Elastos的各种相关源代码在开发过程中都被Checkin到 CVS服务器上，测试时可从该服务器上Checkout最新版本的Elastos及其测试代码。
(2)st/stt文件传输工具。st/stt是采用串口驱动实现的一套用于文件上传和下载的工具， 文件上传即读取文件数据并写入串口，下载即读取串口收到的文件数据重新写入文件。st运 行于目标机，stt运行于开发机。st/stt协同工作完成文件传输。首先开发机端运行stt守候串 口读写并进行相应的文件写读操作，目标机端运行命令行“st FileName”表示从开发机下载 FileName文件，运行命令行“st^FileName”表示上传FileName文件至开发机。传输过程请参 阅图3所示。
(3)armsys镜像文件烧写工具。在开发机上运行命令行“armsys/w elastos.img”即采用 armsys将Elastos的镜像文件elastos.img通过串口(默认串口1)传输到目标机上并写入目标 机RAM，烧写成功后即可启动Elastos。
(4)wait/notify等待/通知工具。采用armsys烧写镜像文件的步骤是开发机先执行armsys 命令行，然后重启目标机系统才开始镜像文件的传输。为了达到自动化操作的目，实现了 wait/notify等待通知工具。该工具也是采用串口驱动实现的。目标机运行wait通过循环读取 串口数据守候开发机发送来特殊的数据才结束等待，开发机执行notify往串口写特殊数据， 通知目标机结束wait并重新启动，以便烧写系统。
(5)cutbat批处理剪切工具。该工具依据命令行记录文件中记录的命令行，将测试执行 脚本runtest.bat从该命令行以上包括该命令行在内的命令行删除，只保留该命令行往下的命 令行内容。
(6)Windows Scheduled Tasks计划任务。开发机采用Windows计划任务功能实现定时 执行一个批处理脚本。
(7)Windows windiff文件比较工具。windiff用于比较测试标准输出文件和测试生成的 输出文件，获得测试结果。
自动化测试前的准备：将目标机与开发机采用串口相连，目标机系统运行wait命令等待 开发机通知；配置好Windows计划任务。
自动化测试流程如下：
步骤1：开发机定时执行计划任务的批处理脚本，该脚本先进行以下操作：
步骤1.1：使用CVS工具下载Elastos系统以及测试源代码；
步骤1.2：进入Elastos SDK开发环境编译系统和测试源代码，编译后所有目标文件生成 在bin目录下；
步骤1.3：将各测试用例执行脚本合成为测试执行脚本runtest.bat，使用copy命令将 runtest.bat拷贝一份到bin目录下，并将当前目录切换到bin目录；
步骤1.4：执行notify命令通知目标机重启；
步骤1.5：执行“armsys/w elastos.img”命令等待开始烧写镜像文件；
步骤2：目标机串口接收到notify发来的重启标志数据，结束wait，等待5秒后重新启动；
步骤3：开发机armsys将elastos.img上传给目标机，之后开发机运行stt，守候串口读写 传输文件；
步骤4：目标机接收并烧写elastos.img文件后自动启动，进入系统控制台后会自动调用 一个批处理文件autorun.bat运行，autorun.bat执行如下操作：
步骤4.1：系统启动可分为两种情况：新系统烧写完后首次启动和新系统因测试运行过程 中发生异常而重启。该步骤针对这两种不同的情况进行不同的处理：
如果新系统烧写完第一次启动，则运行命令行“st runtest.bat”从开发机下载测试执行脚本 runtest.bat；如果新系统因测试运行过程中发生异常而重启，则运行cutbat，依据命令行记录 文件runcmd.log中记录的命令行，将runtest.bat从该命令行以上包括该命令行在内的命令行 删除，只保留该命令行往下的命令行内容。见如下批处理命令：
if exist runcmd.log(
      cutbat.exe runtest.bat
)
if not exist runcmd.log(
     st runtest.bat
)
由于runcmd.log是运行测试时生成的，如果启动时发现存在runcmd.log文件则表示本次 启动是由于测试运行过程中发生异常而重启的，需要调用cutbat；否则是系统烧写完第一次 启动，需要下载runtest.bat文件。
步骤4.2：调用测试执行脚本runtest.bat运行，循环执行如下步骤直到执行完所有的命令 行：
步骤4.2.1：使用st工具从开发机下载一个测试用例程序；
步骤4.2.2：控制台获取当前系统可用内存值，如果可用内存值低于某个内存限制值(例 如限制最小可用内存为500页)，则重启系统，否则继续运行。这样便解决了测试过程中内存 不足的异常；
步骤4.2.3：控制台记录下当前运行的程序命令行到runcmd.log文件中，即调用如下函数 执行：
void LogCmdLine()
{
    wchar_t szFullName[_MAX_PATH];
//以写方式打开空文件runcmd.log，若该文件存在，清空其内容
    FILE*pfout=_wfopen(L"runcmd.log",L"w");
    assert(pfout!=NULL);
    //记录运行命令行至文件中
    fwprintf(pfout，L"％s"，g_wszCmdLine);
    fclose(pfout);
}
其中“g_wszCmdLine”是控制台解析runtest.bat获得的当前运行的命令行。
步骤4.2.4：控制台启动死锁监控程序，开始进入重启倒计时，即调用如下函数执行：
void StartRebootCountDown()
{
     ECODE ec;
     IDriver    *pTestingDriver;
//获取监控服务
    ec=EzFindService(L"device:testingserver"，(IObject**)&pTestingDriver);
    if(FAILED(ec)){
         printf("Error:EzFindService testingserver failed ec=0x％x\n",ec);
         HaltTesting();
    }
    //最大运行时间为300秒
    UINT uMaxTime=300000;
    //再加10秒的等待时间，即最大运行时间到来后，有10秒时间杀死死锁进
//程，若杀死失败，10秒后将重启系统
    uMaxTime+=10000;
    EzByteBuf_Box ezbbTimeOut(&uMaxTime,wcslen(wszMaxTime)+1);
    //开始重启倒计时
    pTestingDriver-＞Control(TSCommand_StartRebootCountDown,
                                ezbbTimeOut,
                                EZBYTEBUF_NULL,
                                NULL);
    pTestingDriver-＞Release();
}
该函数中“device：testingserver”服务是在系统内核中实现的专门为测试提供的一种服务。 Elastos系统提供定时器例程(Timer)，可在指定的一段时间之后执行它的回调函数，Timer 创建后回调函数以内核线程的形式存在。testingserver利用Timer的这种特性，在启动测试进 程之前设置Timer在310秒(该时间可设置为其它值，其中300秒为测试用例进程最大运行 时间，另外10秒等待系统杀死死锁进程，若杀死失败则在10秒之后重启系统)之后进入回 调函数线程执行系统重启。测试用例进程应该在310秒之内执行完毕或被杀死，并终止Timer 的运行，否则回调函数线程将被执行，发生重启。“device：testingserver”服务程序主要实现代 码如下：
class CTestingServer:public Driver{
public:
    CARAPI Read(
       /*[in]*/UINT64 u64Offset,
       /*[in]*/UINT uNumberOfBytesToRead，
       /*[out]*/EzByteBuf ebbData,
       /*[out]*/IEvent**ppCompletionEvent);
    CARAPI Write(
       /*[in]*/UINT64 u64Offset,
       /*[in]*/EzByteBuf ebbData,
       /*[out]*/UINT*puNumberOfBytesWritten,
       /*[out]*/IEvent**ppCompletionEvent);
    CARAPI Control(
       /*[in]*/INT nControlCode,
       /*[in]*/EzByteBuf ebbInData,
       /*[out]*/EzByteBuf ebbOutData,
       /*[out]*/IEvent**ppCompletionEvent);
    virtual void Dispose();
public:
    ECODE Initialize();
public:
    DzTimer*m_pTimer;
};
void CDECL TimerRoutine(void*pvParameter)
{
    kprintf("Testing-System:Timer control Rebooting...\n:);
    BspReboot();
}
EXTERN IDriver*CDECL CreateTestingServer(uint_t uDeviceNo,void*pvParameter)
{
    CTestingServer*pTestingServer=new CTestingServer;
    if(NULL==pTestingServer){
        kprintf("ERROR:new CTestingServer:Not enough memory!\n");
        return NULL;
    }
    ECODE ec=pTestingServer-＞Initialize();
    if(FAILED(ec)){
        delete pTestingServer;
        return NULL;
    }
    pTestingServer-＞AddRef();
    return pTestingServer;
}
ECODE CTestingServer∷Initialize()
{
    uint_t uTicks=DzMillisecondsToTicks(1000*1000);
    m_pTimer=new DzTimer(uTicks,TimerRoutine,NULL);
    if(NULL==m_pTimer){
        kprintf("ERROR:new Timer:Not enough memory!\n");
        return E_OUT_OF_MEMORY;
    }
    return NOERROR;
}
ECODE CTestingServer∷Control(
       /*[in]*/INT nControlCode,
       /*[in]*/EzByteBuf ebbInData,
       /*[out]*/EzByteBuf ebbOutData,
       /*[out]*/IEvent**ppCompletionEvent)
{
    uint32_t uTime=0;
    uint_t uTicks=0;
    switch(nControlCode){
         case TSCommand StartRebootCountDown:
              uTime=*(uint32_t*)(wchar_t*)ebblnData;
              uTicks=DzMillisecondsToTicks(uTime);
              m_pTimer-＞Restart(uTicks);
              break;
         case TSCommand_CancelRebootCountDown:
              m_pTimer-＞Cancel();
              break;
         default:
              kprintf("Unknown TestingServer Command.\n");
              break;
    }
    return NOERROR;
}
CTestingServer类是按照Elastos驱动编程方法实现的一个伪驱动类，与内核代码一起编 译，系统启动时调用CreateTestingServer创建了CTestingServer对象并将其注册为 “device：testingserver”服务让控制台获取并调用相关方法。CTestingServer对象创建时调用 CTestingServer∷Initialize创建了Timer对象。TimerRoutine函数即Timer回调函数，其调用 BspReboot函数用于重启系统。CTestingServer∷Control有两个控制字： TSCommand_StartRebootCountDown控制字用于启动Timer对象，开始重启倒计时，参数 ebbInData用于传递控制台指定的Timer对象相对到期时间(即重启倒计时时间)； TSCommand_CancelRebootCountDown控制字用于取消运行的Timer对象，中止重启倒计时。
步骤4.2.5：控制台创建测试用例进程并运行，即调用如下函数执行：
ECODE RunExe(wchar_t*pwszCmd,wchar_t*pwszArgs,BOOL bBackGround)
{
    ECODE ec=NOERROR;
    IProcess*pIProcess;
    //创建测试用例进程
    ec=EzCreateProcess(pwszCmd,pwszArgs,&pIProcess);
    if(ec==NOERROR){//Create process succeeded
             ECODE ec1;
             WaitResult wr;
                 INT ms=300000;
             //等待进程在300秒内运行结束
             ec1=pIProcess-＞WaitForExit(ms,&wr);
             if(SUCCEEDED(ec1)&&(WaitResult_TimedOut==wr)){
                 //发生超时，杀死该进程
                 pIProcess-＞Kill();
                 wprintf(L"Testing-System:Deadlock process was killed.\n");
             }
        }
        pIProcess-＞Release();
    }
    return ec;
}
创建测试用例进程成功后，最多等待300秒(该时间可设置为其它值)让进程运行，如 果等待超时，则杀死该进程，以便后继进程的运行。如果该进程运行过程中进入了debug， 系统会自动跳转到DebuggerHandler中执行，在DebuggerHandler中专门为测试添加了如下处 理函数，在进入DebuggerHandler时就调用该函数执行：
void TestingDebuggerHandler()
{
     //判断是kernel debug还是user debug
     if(IS_IN_KERNEL_MODE(pContext)){
          kprintf("Kernel debugger!\n");
     }
     else{
         kprintf("User debugger!\n");
         if(NULL!=pCurrentProcess){
     //获取当前进程
     CProcess*pCurrentProcess=GetCurrentProcess();
             //杀死进入user debug的进程
             pCurrentProcess-＞Kill();
         }
     }
     //进入kernel debug或杀死user debug进程失败，重启系统
     BspReboot();
     return;
}
如果系统陷入user debug则杀死debug进程，以便运行后继测试代码，若杀死失败则调 用BspReboot函数重启系统；如果陷入kernel debug，则调用BspReboot函数重启系统。这样 便解决了测试过程中进入debug的异常。
步骤4.2.6：控制台中止死锁监控程序运行，取消重启倒计时，即调用如下函数执行：
void CancelRebootCountDown()
{
     ECODE ec;
     IDriver     *pTestingDriver;
     //获取监控服务
     ec=EzFindService(L"device:testingserver"，(IObject**)&pTestingDriver);
     if(FAILED(ec)){
         printf("Error:EzFindService testingserver failed ec=0x％x\n",ec);
         HaltTesting();
     }
     //取消重启倒计时
     pTestingDriver-＞Control(TSCommand_CancelRebootCountDown,
                                 EZBYTEBUF_NULL,
                                 EZBYTEBUF_NULL,
                                 NULL);
     pTestingDriver-＞Release();
}
调用“device：testingserver”服务中止Timer运行，如果步骤4.2.5发生了进程陷入死锁并且 不能被杀死，那么控制台就不会调用CancelRebootCountDown函数，系统会在进程运行开始 310秒之后自动进入Timer回调函数线程执行系统重启，这样便解决了测试过程中陷入死锁 的异常。
步骤4.2.7：使用st向开发机上传该测试用例生成的输出文件；
步骤4.2.8：删除该测试用例程序和输出文件；
步骤4.3：目标机执行完runtest.bat中所有命令行后，运行“st runcmd.log”上传runcmd.log 文件标志所有测试用例运行结束。
步骤4.4：开发机端stt监测到runcmd.log被上传时自动退出，此时stt已经接收到了所有 的测试输出文件。
步骤4.5：开发机使用windiff将标准输出文件与测试输出文件相比得出测试运行结果。
对于造成系统异常的测试程序，它们会生成空的输出文件或没有生成输出文件，需要重 新运行这些测试用例程序以定位问题。如果某个测试用例程序出错了就注掉相应的执行脚本， 没有必要再次运行，直到bug修复后再修改它的执行脚本，加入测试中运行。
上述在系统内核以及控制台中为测试专门添加的代码，经过条件编译控制仅在回归测试 时才被编译使用，保证开发代码和测试代码的独立。
采用了上述的嵌入式操作系统中接口测试的自动化运行方法，由于在开发机系统上实现 了自动编译代码，并通知目标机系统开始测试，且自动上传操作系统镜像文件和测试用例程 序，自动下载测试输出文件；同时，在目标机系统上实现了自动下载、运行和删除测试程序， 上传测试输出文件，自动处理各种系统异常，并保证异常处理之后测试执行脚本能够继续运 行下一个测试程序，最后通知开发机结束测试，从而实现了在有限存储资源的嵌入式设备上 进行嵌入式操作系统接口测试的自动化运行，无需人工干预，节约了人力资源，有效缩短了 回归测试的周期，保证嵌入式系统开发快速平稳的推进，性能稳定可靠。不仅如此，本发明 的嵌入式操作系统中接口测试的自动化运行方法并不限于操作系统接口，对于嵌入式操作系 统之上的应用接口的测试也同样适用，能够为应用开发带来益处，适用范围较为广泛，为嵌 入式系统及其上层软件的进一步发展奠定了坚实的基础。
在此说明书中，本发明已参照其特定的实施例作了描述。但是，很显然仍可以作出各种 修改和变换而不背离本发明的精神和范围。因此，说明书和附图应被认为是说明性的而非限 制性的。