CN1932776A

CN1932776A - 嵌入式操作***中接口测试的自动化运行方法

Info

Publication number: CN1932776A
Application number: CN 200610116867
Authority: CN
Inventors: 雷光亮; 付强
Original assignee: KETAI CENTURY SCIENCE AND TECHNOLOGY Co Ltd SHANGHAI
Current assignee: KETAI CENTURY SCIENCE AND TECHNOLOGY Co Ltd SHANGHAI
Priority date: 2006-09-29
Filing date: 2006-09-29
Publication date: 2007-03-21
Anticipated expiration: 2026-09-29
Also published as: CN100458729C; HK1102177A1

Abstract

本发明涉及一种嵌入式操作***中接口测试的自动化运行方法，包括开发机定期生成测试对象、测试执行脚本和测试用例信息、将测试对象传输到目标机、目标机启动***并下载测试执行脚本、循环下载测试用例信息运行并产生测试输出信息、向开发机传送该测试输出信息和测试结束信息、开发机将标准输出信息与测试输出信息进行比较后得到测试运行结果。采用该种嵌入式操作***中接口测试的自动化运行方法，无需人工干预，节约了人力资源，有效缩短了回归测试的周期，保证嵌入式***开发快速平稳的推进，性能稳定可靠，而且对于应用接口的测试也同样适用，能够为应用开发带来益处，适用范围较为广泛，为嵌入式***及其上层软件的进一步发展奠定了坚实的基础。

Description

嵌入式操作***中接口测试的自动化运行方法

技术领域

本发明涉及计算机***领域，特别涉及计算机嵌入式操作***自动化测试领域，具体是指一种嵌入式操作***中接口测试的自动化运行方法。

背景技术

随着现代计算机技术的日益进步，人们对于计算机***的各种开发和维护也变得越来越容易。操作***接口将硬件细节与程序员隔离开来，提供了一组可以方便的对硬件资源进行管理和操作的方法。嵌入式操作***的接口一般包括进程、线程、内存管理、文件***等方面，依据应用需要还可以提供网络接口和图形接口等。操作***的绝大部分接口在***开发早期就定义下来了，在嵌入式操作***开发过程中，为了确保开发稳步推进，我们需要对***接口进行不断的回归测试。回归测试发生在软件修改之后，通常会对一天以内的代码修改进行一次全面的回归测试，保证该日开发的正确性，也便于及时定位和解决该日开发出现的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)如果是新***因测试运行过程中发生异常而重启，则将测试执行脚本中已经执行过的命令行删除，只保留未执行过的命令行内容；

(5)目标机***运行测试用例信息并产生测试输出信息，包括以下步骤：

(a)***在启动执行该测试用例信息之前记录下当前运行的程序命令行；

(b)***创建相应的测试用例信息的进程并开始执行，并在执行测试用例进程的过程中实时监控各种异常情况的出现；

(c)如果测试用例进程的运行使得***陷入死锁，则***将杀死在一段特定时间后还没有运行完毕的进程，若杀死该进程成功，则继续运行下一个命令行；若杀死该进程失败，则进行***重启；

(d)如果测试用例进程的运行使得***陷入调试状态，则***将杀死该进程，若杀死该进程成功，则继续运行下一个命令行；若杀死该进程失败，则进行***重启；

(e)如果测试用例进程的运行使得***内存不足，若发现***内存低于***预设值，则进行***重启；

其中，可以通过在***的开发代码中添加的经过条件编译控制的死锁监控代码、调试状态监控代码、内存监控代码进行异常情况的实时监控。

(6)目标机***通过通信装置向开发机***传送该测试输出信息；

(7)目标机***删除当前测试用例信息和测试输出信息；

(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,

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修复后再修改它的执行脚本，加入测试中运行。

上述在***内核以及控制台中为测试专门添加的代码，经过条件编译控制仅在回归测试时才被编译使用，保证开发代码和测试代码的独立。

采用了上述的嵌入式操作***中接口测试的自动化运行方法，由于在开发机***上实现了自动编译代码，并通知目标机***开始测试，且自动上传操作***镜像文件和测试用例程序，自动下载测试输出文件；同时，在目标机***上实现了自动下载、运行和删除测试程序，上传测试输出文件，自动处理各种***异常，并保证异常处理之后测试执行脚本能够继续运行下一个测试程序，最后通知开发机结束测试，从而实现了在有限存储资源的嵌入式设备上进行嵌入式操作***接口测试的自动化运行，无需人工干预，节约了人力资源，有效缩短了回归测试的周期，保证嵌入式***开发快速平稳的推进，性能稳定可靠。不仅如此，本发明的嵌入式操作***中接口测试的自动化运行方法并不限于操作***接口，对于嵌入式操作***之上的应用接口的测试也同样适用，能够为应用开发带来益处，适用范围较为广泛，为嵌入式***及其上层软件的进一步发展奠定了坚实的基础。

在此说明书中，本发明已参照其特定的实施例作了描述。但是，很显然仍可以作出各种修改和变换而不背离本发明的精神和范围。因此，说明书和附图应被认为是说明性的而非限制性的。

Claims

1、一种嵌入式操作***中接口测试的自动化运行方法，包括开发机***和嵌入式操作***的宿主测试目标机***，所述的开发机***中的通信装置通过数据链路与目标机***中的通信装置相连接，其特征在于，所述的方法包括以下步骤：

(5)目标机***运行测试用例信息并产生测试输出信息；

(6)目标机***通过通信装置向开发机***传送该测试输出信息；

(7)目标机***删除当前测试用例信息和测试输出信息；

2、根据权利要求1所述的嵌入式操作***中接口测试的自动化运行方法，其特征在于，所述的定期生成嵌入式操作***测试对象、测试执行脚本和测试用例信息包括以下步骤：

(1)***定时从源代码服务器上下载最新的代码；

3、根据权利要求2所述的嵌入式操作***中接口测试的自动化运行方法，其特征在于，所述的将嵌入式操作***测试对象传输到目标机***中包括以下步骤：

4、根据权利要求2或3所述的嵌入式操作***中接口测试的自动化运行方法，其特征在于，所述的源代码服务器为CVS源代码管理服务器、ClearCase源代码管理服务器或者SourceSafe源代码管理服务器。

5、根据权利要求1至3中任一项所述的嵌入式操作***中接口测试的自动化运行方法，其特征在于，所述的启动嵌入式操作***和从开发机***下载测试执行脚本的处理包括以下步骤：

(1)目标机***判断该启动属于以下两种情况中的哪一种：新***烧写完后首次启动、新***因测试运行过程中发生异常而重启；

6、根据权利要求1至3中任一项所述的嵌入式操作***中接口测试的自动化运行方法，其特征在于，所述的目标机***运行测试用例信息包括以下步骤：

7、根据权利要求6所述的嵌入式操作***中接口测试的自动化运行方法，其特征在于，通过在***的开发代码中添加的经过条件编译控制的死锁监控代码、调试状态监控代码、内存监控代码进行异常情况的实时监控。

8、根据权利要求1至3中任一项所述的嵌入式操作***中接口测试的自动化运行方法，其特征在于，所述的测试结束信息为测试运行结束标志文件。

9、根据权利要求1至3中任一项所述的嵌入式操作***中接口测试的自动化运行方法，其特征在于，所述的标准输出信息为标准输出文件，所述的测试输出信息为测试输出文件。

10、根据权利要求9所述的嵌入式操作***中接口测试的自动化运行方法，其特征在于，所述的将预设的标准输出信息与接收到的测试输出信息进行比较为：