CN1353835A - 同类系统之间的协议确认 - Google Patents

Abstract

本发明提供了一种用于主计算机上的测试和验证软件程序,具有图形用户接口程序,与目标设备通信和从图形用户接口回应命令的引擎,多个测试程序组,包括至少一个用于测试和验证至少一个操作系统的部件,和一个有助于与所述目标设备共同使用的协议确认软件包(4000),其中,协议确认软件包使用操作系统生成的事件句柄作为协议的成员字段,用于释放正在等待来自所述目标设备的一个确认消息的执行线程,以及其中,事件句柄被置于确认消息分组(3002)的首标部分,并且在所述的确认消息中送回,以及其中,一个接收的线程启动正在等待所述确认消息(2003)中所述事件句柄的执行的任何被发送线程。

Description

同类系统之间的协议确认 相关申请的交叉参考

本申请要求于1999年6月4日提交的名为“同类系统之间的协议确认(PROTOCOL ACKNOWLEDGMENT BETWEENHOMOGENEOUS SYSTEMS)”的美国临时专利申请第60/137,629号的优先权，并且，本申请是2000年1月21提交的名为“CE验证器测试程序组(CE VALIDATOR TEST SUITE)”的美国专利申请第09/489,308号的继续部分再申请，该申请要求1999年1月21日提交的名为“CE验证器测试程序组(CE VALIDATOR TESTSUITE)”的美国临时专利申请第60/116,824号的优先权。

技术领域

本发明涉及产品质量保证以及涉及用于验证设置在计算机化产品中的操作系统的测试系统和方法。具体地说，本发明涉及产品质量保证和用于在计算机化产品开发期间验证操作系统的测试系统和方法。更具体地说，本发明涉及产品质量保证和用于对通常设置在计算机化产品中的诸如Windows CE的操作系统进行验证的测试系统和方法，该Windows CE由位于华盛顿州Redmond的微软公司制造和销售。

发明背景

研发人员正在逐渐地将操作系统，比如Windows CE，嵌入许多不同类型的计算机化产品中，这些计算机化的产品包括顶置盒、对策系统、条形码扫描器和工厂自动系统。随着Windows CE发展，以致需要“现成的”软件开发工具。尽管许多用于节省设备设计时间的工具和“现成的”软件包已经上市，导致设备快速开发，但没有测试这些新产品兼容性，特别是在设备开发的最后阶段测试这些产品兼容性的快速测试系统或方法。

一般来说，只有两种操作系统设备测试选择是可以得到的：(1)测试编码的内部记述，或者(2)把自定义编码开发委托给另一个公司。为了完成内部测试计划，原始设备制造商(OEMs)必须花费几个月时间来培训他们的员工，花费几个月时间开发测试编码，以及在可以使用这种编码测试他们的产品之前仍需要几个月的准备。同样地，委托的自定义编码开发机构将花费几个月的时间记述该编码。因此这两种选择都将是费时和费钱的。

在质量保证设备测试系统的相关技术中，使用几个网络协议，以便在等候发送消息的确认时暂时停止程序执行。例如，低级的传输控制协议(TCP)中断程序执行，直至由一个“连接”的远程确认某些发送的消息。大多数协议按操作系统独立方式实施。同样地，需要确认的发送消息被保持在一个交叉引用表中，在该表中采用一个执行线程(诸如等待这种确认的线程)交叉引用发送消息的标识。这样的相关技术的系统跟随一个长程序组：在发送初始消息之前建立一个消息标识符(ID)；在消息标识符与执行线程相关联的一个表中增加一个元素；发送所述消息；中断发送线程的执行，直至接收编码开启它；通过远程处理，送回一个包含初始消息标识符的命令正确应答(ACK)消息，来确认该发送消息；由发送机器接收命令正确应答消息；分析原始发送消息的消息标识符；在表中查找消息标识符；确定哪个执行线程脱离该表；最后，释放执行的原始发送线程，以继续程序执行。

这些耗时的操作系统设备测试选择已经建立了结合测试系统和方法的长期需要，利用同类系统之间的一个协议确认，用于改善产品质量，节省几个月的时间和费用，并且使产品开发过程流水线化。特别是，测试和验证具有所安装的嵌入式Windows CE操作系统的设备的系统和方法需要克服上述的问题，由此提供了一种系统和方法，该系统和方法改善了产品质量，节省许多月的时间和费用，并且使产品开发过程流水线化，因此它是设备设计人员的完全自动化设计验证软件包。具体地说，需要一个使用提供操作系统事件的系统、一个操作系统内部保持事件表、操作系统内部保持中断线程(即，发送线程)表。因而，与相关技术的协议确认方法不同，几个步骤需要删除(例如，增加一个将执行线程与一个表中的消息标识符相关联的元素，交叉引用一个表中的消息标识符，和确定哪个执行线程从一个表项目中释放)。

因而，通过一个可选择的处理命令正确应答的方法得到的更简便、更短和更少出错的编码将是有益的，其中，一旦接收到确认消息就可以执行多个动作(例如，多交叉引用和伴随的延迟消除，用于命令正确应答的接收的编码，其基本上与单一线程情况相同，优先数据，如果多个线程居优先地位则该优先数据不需要保持在发送消息表中，一个标识符表，当操作系统用一个合适的优先权重新启动所有线程时，不需要完全扫描该标识符表以确定一个线程释放优先权)。有利的系统还能够实施等待命令正确应答消息运行的多个未决线程，这些线程仅需要使用操作系统提供的功能，等待由协议首标中初始“发送”嵌入的一个事件句柄。同样有利的是，通过多个发送消息的任何消息的命令正确应答，而不使用附加的交叉引用处理，也可以触发运行的多个线程。

发明概述

所以，本发明(可从市场上得到，其商标是本申请人的受让人的CEValidator^TM的商标)是一个操作系统验证器，(以下称作操作系统验证器，并且在图1中用标号1表示)，本发明通过提供一个测试系统解决上述问题，该测试系统包括一套自动测试系列方法，用于在新近开发的目标设备的硬件和/或软件中，测试诸如WindowsCE的操作系统的一个端口。操作系统验证器包括一个综合编码基数，它是通过使用用于确认同类系统之间协议的唯一同时多线程运行技术，特别针对操作系统、设备驱动器、原始设备制造商适应层(OAL)和硬件交互开发的。所提供的测试系列主要是识别三个主要缺陷：硬件设计，硬件编程(驱动器/原始设备制造商适应层)，和操作系统交互作用。特定的诊断重点在于Windows CE子系统，其历史地示出大多数问题。测试系列包括近1500个测试，该测试含有系统重点测试子程序，以及特征和功能测试，以提供WindowsCE端口的完整分析。这些测试由操作系统验证器分组。操作系统验证器包括测试源码和用于所有测试的可运行程序。

为了简化测试系列的运行和记录结果的收集，利用了操作系统验证器主机元件的自觉用户接口，比如起到微软视窗用户接口杠杆作用的标准视窗应用程序。操作系统验证器分布测试系列作为客户/服务器应用程序。图形用户接口(GUI)与一个正在一个目标设备上运行的小应用程序CEHarness.exe进行交互作用。由于该通信可以在以太网上实现，因此至少一个主机可以使程序组遇到至少一个目标设备。

当目标设备不能进行测试时，操作系统验证器生成有用的误差信息。当该程序组运行时，在多个动态建立的记录窗口以及配置的概述抽头中显示结果。记录窗口包含给定测试结果的全文。将失败编码成红色，以便容易识别。记录窗口中的定位按钮允许用户从一个失败移动到另一个失败。测试中的记录应用程序接口(API)还使开头和结尾在每个结果文件中生成。诸如同时运行处理、电池电源电平、执行日期和时间的信息被自动地记录在结果文件中和显示在记录窗口内。有用的概述信息，比如程序存储器的丢失、存储存储器的丢失、或者总测试执行时间也可以设置在记录窗口抽头中。还可以收集给定测试结果的概述信息，以及可以在配置窗口的概述抽头中显示该概述信息。概述抽头实时报告PASS和FAIL测试情况的数目。还可以显示用于各个系列的中断PASS和FAIL数量。配置视窗的概述抽头便于快速引导可能是几千个测试结果之中的一个单个失败。操作系统验证器的记录应用程序接口自动地报告与记录失败相对应的确切的源文件和行号。由于操作系统验证器提供所有可执行的源码，因此能够直接转到报告差错的源码的是失败的文本描述的强大附件。

本发明使用操作系统生成的事件句柄作为协议的成员字段，用于释放等待确认(ACK)消息的执行线程。操作系统生成的事件句柄，比如WIN32事件句柄用于中断一个执行的原始发送线程。该事件句柄置于首标并且在命令正确应答中送回。一个接收的线程不需要在表中查找传送的标识。而是，接收的线程开启任何等待事件的线程。换句话说，本发明使用操作系统提供的事件、操作系统内部保持的事件表、和操作系统内部保持的中断线程(即，发送线程)的表。因此，与相关技术的协议确认方法不同，几个步骤被消除：增加执行线程与表中的消息标识符相关联的元素，查找表中的消息标识符，以及确定哪个执行线程释放一个表项目。

因此，通过本发明的处理命令正确应答的可替换的方法，可使编码更简单、更短和更少出错。因此，本发明在接收确认消息时就在加快多个动作的方面提供了许多优点：消除了多个交叉引用和伴随的延迟，命令正确应答接收的编码基本上与单个线程情况相同，如果使多个线程具有优先权，则不需要在发送消息表中确定优先权数据，以及当操作系统用适当的优先权重新启动所有的线程时，不需要完整地扫描标识符表，以确定线程释放优先权。为了实施等待命令正确应答消息的执行多个未决线程，该线程仅需要使用操作系统提供的等待的功能，等待由协议首标中初始“发送”嵌入的一个事件句柄。同样地，可以不使用附加的交叉引用处理，而由多个发送信息任何一个消息的命令正确应答来触发执行多个线程。

本发明的其它特点在“本发明的详细说明”部分公开或者说明得更为显而易见。

附图简要描述

为了更好地理解本发明，下面结合附图进行说明：

图1是表示控制单元中目前拥有的嵌入式操作系统的计算机化产品的示意图；

图2示出了本发明的对拥有嵌入式操作系统的计算机化产品进行质量保证测试的制造流程图；

图3是显示本发明的操作系统验证器的主要部件的方框图，包括图形用户接口，引擎，多个测试程序组，和记录库；

图4是显示本发明的来自主机设备的多个测试程序组配置的运行方框图，用于测试拥有嵌入式操作系统的多个目标设备；

图5A是显示基本上如图4所示的本发明的一个方框图，但未显示目标设备在主机经以太网装置与操作系统验证器1通信；

图5B图示了本发明的一种布置，其中多个主机与目标设备之间的通信可以在以太网上实现；

图6显示了本发明的测试程序组执行情况的另一种布置；

图7是本发明的一个列表，列出了在自动和人工测试程序组执行中所测试的特殊应用程序接口的功能区域；

图8A、图8B和图8C共同包括一个详尽的列表，列出了本发明的可以用自动或人工方式测试的功能区域和它们的相应应用程序接口；

图9是本发明的供建立自动情况使用的选用应用程序接口的列表；

图10是表示本发明的原理的示意图，用于提供本发明的所有可执行程序的源码；

图11是表示本发明的显示测试程序组选择选项以及其它相关概述功能的方框图；

图12是表示本发明的一个记录窗口的方框图，该记录窗口显示了用于测试结果、测试失败和相关测试概述选项的抽头；

图13以图形示出了本发明的测试周期时间，该测试周期时间是同时进行测试的设备数量的函数；

图14是代表本发明的一个配置窗口的方框图，该配置窗口示出了执行各种配置相关函数的抽头；

图15A、图15B和图15C共同包括本发明的列出操作系统部件的测试细节的一个表；以及

图16是图示说明本发明的关于同类系统之间协议确认的独特的同时发生多线程能力的流程图。

本发明的详细说明

图1示出了一个计算机化的产品1000，(9)，它通常是下列的计算机化产品之一，比如，拥有一个由标号1001a代表的嵌入式操作系统的计算机工作站，顶置盒，对策系统，条形码扫描器和工厂自动系统。如图所示，产品1000可以包括拥有诸如嵌入式WindowsCE操作系统(O/S)的一个操作系统1001a的典型目标设备9。计算机化产品1000可以充当一个独立设备，它具有本发明的一个设备，即，测试和验证它自己的操作系统1001a的操作系统验证器1。当不需要操作系统验证器基础结构的详细知识时，独立测试便于新的测试开发和排除所报告的缺陷的故障。然而，在更可能的应用中，如图2所示，产品1000可以在制造质量保证测试环境M中充当一个主计算机4，该计算机具有本发明的一个设备，即，用于测试目标设备9的操作系统验证器1，和拥有一个操作系统1001a。参见图1，作为示例，计算机化产品1000可以包括几个子部件，包括一个控制单元1020，该控制单元包括多个输入/输出端口1021、键盘1009、打印机1010、鼠标1011和监视器1012。子部件1009、1010、1011和1012本身可以是可靠的目标设备。典型的控制单元1020包括几个子部件，其中包括中央处理单元1001、诸如硬盘驱动器1004的存储装置、包括RAM 1002和ROM 1003以及光盘1005的其它存储部件、音频部件1006、网络/服务器卡1007、调制解调器1008。控制单元必须包括的是使产品1000充当有用设备的操作系统1001a。

图3示出了操作系统验证器1的主要部件，包括图形用户接口(GUI)2、引擎3、多个测试程序组11、和记录库12。图形用户接口2和引擎3通过操作系统验证器1(下面进行更详细的讨论)中的由标号7表示的称之为HamessLink.dll的部件在内部双向通信。图4示出了装备了操作系统验证器1的主计算机4。如图所示，多个目标设备9装备了操作系统1001a，用于进行与本发明相符的测试。操作系统验证器1具有生成测试配置的能力，该测试配置例如是多个测试配置21a、21b和21c，用于在目标设备9的操作系统1001a的控制下测试特殊功能。一个设备侧部件，所谓的CEHarness8与操作系统验证器1中的引擎3通信，如图5A和图5B所示，CEHarness 8还可以经以太网装置4a与操作系统验证器1中的引擎3通信。图5B示出的是，由于通信可以在以太网上实现，因此多个主机4可以使程序组遇到多个目标设备9。在另一个可选择的方案中，如图6所示的测试程序组执行情况，CEHarness 8还可以经程序组执行连接1021a与操作系统验证器1中的引擎3通信，其中，主计算机4可以包括NT主计算机，其中，记录库12也可以被设置在目标设备9中，其中，经网络界面连接1021b向主计算机4提供测试结果。

在操作中，操作系统验证器1测试和验证提供了例如WindowsCE操作系统的一个嵌入式操作系统的目标设备9。广义地说，操作系统验证器1的功能是(1)验证至目标设备的Windows CE端口，(2)提供应力和性能测试，(3)记录和分析结果，(4)测试多个功能区域，包括多个应用程序接口(API)(参见图7、图8A、图8B、图8C中的表1和表2)，(5)执行多个测试程序组中的多个通过/失败测试，(6)推动自动程序组中测试的用户化，(7)提供主机侧图形测试设备，(8)应力和估计存储器性能，(9)提供建立测试自动化的装置，包括多个应用程序接口(参见图9中的表3)，以及(10)提供称作CEAnalyzer的结果分析工具。如上所述，如图10所示，操作系统验证器1包括，用于所有测试的测试源码和可执行的程序EP(也被称作可执行的测试)。用于可执行测试EP的唯一的实施要求是使用以下两个特殊的应用程序接口报告测试情况“通过”和“失败”：WRITETESTPASS()和WRITETESTFAIL()。这些宏指令具有类似于已知的printf()函数的特征，但是它们的使用在服从自动概要的“结果”文件中生成了标准测试情况结果格式，并且将报告与主用户接口相结合。操作系统验证器1的方法包括在图形用户接口2与测试可执行EP中封装的测试情况之间进行调解，和提供图形用户接口2分配和调整测试执行的一个装置。测试程序组11包括由程序组语言命令(例如，PUT，RUN，WAIT和DELETE)组成的文本文件5，该命令直接表达分配和执行测试所需的任务。其它支持的系列命令是：从目标设备9检索文件的GET；主计算机4上运行对客户/服务器型测试有用的可执行程序EP的RUNHOST；等待主计算机4的处理终止的WAITHOST，它对客户/服务器型测试也是有用的；设置设备的系统目录(/窗口)中的文件的PUTSYSTEM；当所有其它失败时进行基本计时的SLEEP；显示主机上的消息箱的MSGBOX；增加或改变设置在设备上的一个注册的SETREG；以及从设备消除设置的一个注册的DELREG。处理提供初始程序组文献外，还提供初始程序组文件注释，以作为图形用户接口2中的程序组说明。操作系统验证器1方法包括组织测试程序组文件5，将它们分层放置在主计算机4的目录层结构内。如图11所示，测试程序组11被划分在顶层，作为自动测试程序组(Au)、人工测试程序组(Ma)或者应力测试程序组(SS)。自动测试Au是在执行期间不需要任何用户干预的测试。相反，人工测试Ma需要用户干预(例如，键盘和触摸屏程序组)。操作系统验证器1方法包括经过强迫输入/输出(I/O)通过量到限制的应力程序组SS对系统的应力，使其不与可得到的程序或目标存储器共同操作，并且能够用多线程的并行应力降低一个自定义文件系统。在分层的顶层下面，操作系统验证器1方法包括用功能区域安排测试程序组11(参见图7)。

如上所述，图3示出了操作系统验证器1的主要部件，包括图形用户接口(GUI)2、引擎3、多个测试程序组11、和记录库12。操作系统验证器1把图形用户接口2用作可视基本部件，因为它可以为任何等级的用户工作。图形用户接口2的设计是以将用户输入与主要部件对接的原理为基础的。引擎3是主机4功能的核心。引擎3读出多个程序组文件5，分析它们，并且执行命令。引擎3从图形用户接口2中获得信息，并使用该信息建立各种执行选项。引擎3是按C或C++语言写入的。图3经一个是ActiveX控制的称作HamessLink.dll 7的部件链接图形用户接口2。举例说明HarnessLink.dll 7，它是通过各种信息从图形用户接口2呼叫，在它开始执行之前通过引擎3。Dll链路7还具有在执行期间在引擎3与图形用户接口2之间进行通信的功能，以转播信息、差错消息和某些动态运行时间命令。目标设备9包括一个称作CEHamess 8的设备侧(与主机侧相对)部件。CEHarness 8是驻留在目标设备9上的C或C++程序，并且如图4所示，它几乎专门与引擎3通信，除非在网络上广播目标信息，这是由于图形用户接口2接收这种消息并把它传递给引擎3(参见图5A和图5B)。CEHarness 8是事件驱动应用程序，其中，引擎3发送事件而CEHarness 8进行响应。两个保留部件测试程序组11和记录库12结合在一起，因为测试程序组11是使用多个作为记录库12(参见图8A、图8B和图8C)的部分的应用程序接口(API)13写入的。这些应用程序接口13具有真实的功能并且略微依赖经部件链传递的信息。记录库12具有简单功能概念，通过创建记录文件15传送测试结果14，将TCP/IP信息16返回记录到图形用户接口2(参见图5A)或者将结果14和记录文件15直接写入设备9(参见图6)。如图12所示，记录窗口LW示出了测试文件15中的测试结果14、便于用户访问程序存储器的通过、失败和计时信息的失败F和概述抽头SumT。多个测试程序组11包括操作系统验证器1的不可缺少的部件。图13用图形示出了当并行测试测试设备的数量是测试周期时间CT减少的情况。

具体地说，图形用户接口2是一个复合码，这是由于处理它的部件层所需的功能性等级所致。图形用户接口2提供一个“向导”，其主要功能是经各种可选择的设置游动新用户和列出默认设置。如图14所示，图形用户接口2还提供一个配置窗口CW，作为执行一个测试运行的装置，测试运行包括通过目标设备9的一组选用程序组11的单通道。如图4所示，多个配置21a、21b和21c被运行来模拟各种情况。配置窗口CW的内容包括用于用户控制的多个抽头。例如，程序组抽头S提供操作系统验证器目录下的程序组文件目录的树型图。该树型图被组织来提供测试11的类型与用户选择之间的有意义差别。此外，当用户打开配置窗口CW时创建该树型图，以允许用户通过将新的用户输入程序组增加到由操作系统验证器1安装程序所建立的程序组文件目录中，来扩展操作系统验证器1。测试程序组11是命令的情况，引擎3读出该命令，然后相应于这种命令的情况执行动作。程序组文件5通常用一系列命令启动。这些命令出现在文件的程序组文件信息部分中。如果字“人工”出现在程序组文件5的顶部，则认为该文件需要人工执行，因而被分配一个不同图标。在图11所示的测试程序组部分中，用户可以以任何方式记录测试程序组文件5。参见图14，记录抽头包含相当重要的信息。用户可以选择三个记录方法，即，记录到主机4上的LH、记录到目标设备9上的LTD、或者记录到主机4和目标设备9上的LHD。记录信息被存在编辑箱所列出的配置目录中。所有的该信息经DLL7发送给引擎3，然后发送给目标设备9的CEHarness8。接着，一旦运行测试11记录库12就获得该信息。配置窗口CW中的其它抽头包含一组应力条件抽头SC，它通过在程序组执行期间选择线程抽头T来选择高优先级线程，通过选择抽头PM和SM来减少程序和存储存储器，通过选择抽头SRT来选择运行时间，和通过选择抽头STOP来停止运行。用户可以利用无线循环抽头Iloop发现系统中的存储器漏洞。在一个概要抽头SumT中提供有用的概要信息，比如程序存储器的损失、存储存储器的损失或者总测试执行时间。还可以在概要抽头SumT中收集和显示用于给定测试结果的概要信息。概要抽头实时报告PASS和FAIL测试情况的数量。还可以显示用于单个程序组的中断PASS和FAIL数量。配置窗口的概要抽头便于对可能是几千个测试结果中的一个单独失败的快速导航。与所记录的失败相对应的确切源文件和行号由操作系统验证器的记录应用程序接口自动报告。由于操作系统验证器所有可执行的源码，因此，能够直接到达报告一个差错的源码是对失败的结构说明的强力附件。记录选项按它们的实施和效果主动地改变。第一选项假定：用户无论何时运行测试程序组11得到“通过”，概述这些测试结果14的一组记录文件15就自动发出。根据所选用的记录方法，概述文件15由CEHarness 8或引擎3建立。大体上说，引擎3横越记录目录中的所有记录文件16，所以用户可以接收不与运行的测试11相对应的记录文件表。为了使概要文件15进一步指示运行测试11，用户可以在运行之前删除记录目录，或者用户可以选择一个记录选项，比如使引擎3仅横越用于每个测试11的一个记录文件15的“仅返回最新概要结果”。这意味着，如果用户在给定日期运行文件系统测试30次，则在与最新执行相对应的测试的概要记录中将只有一个输入。对于其记录文件15仍然驻留在被记录目录中的每个测试11，概要记录将只有一个输入。其它两个选项在图形用户接口2中处理。如果用户经过TCP/IP连接4a登录在主机4上，则一个输入进入在用户的主机4上建立的记录文件15上，同时出现在图形用户接口2内的一个记录窗口中。这允许用户在操作系统验证器1的设备场境内检查记录文件15，这是一个极大的优点，因为用户可以立即监视通过和失败(这更重要)。然而，在某些环境中，可能因测试11运行的长度，造成记录文件15过量；因此，关闭记录窗口LW，不再打开它，将保持主机4的存储器，还可以给予一个用于操作系统验证器1的清晰观看区域。其它的优点是关闭所有没有失败的记录文件15。对产品设计人员来说，失败表示目标设备9将需要进一步开发。用户还可以通过点击记录窗口中的一个选项以保持F窗口打开，来保持所有具有失败的记录窗口F的打开。

当操作如图5B所示的本发明时，称之为Available Targets的一个窗口显示正在向图形用户接口2广播信息的网络上的有效设备。有效设备发送大量信息，某些信息在Available Targets窗口中显示。用户可以通过选择View/Available Targets窗口菜单来观看信息。另一个窗口必须被访问，以便获得广播信息的完全集。该广播信息是有效的，因为它用来将来自引擎3的连接预置到测试目标设备9中的一个特殊CEHamess 8。

下面结合图11说明应力测试设置SS。应力程序组11以各种格式出现；然而，其基本目的是通过运行非常长的测试、多次重复地运行短测试、或选择一个测试中参数的宽范围来对目标设备9应力。这些保留了对它们自己的测试11区域的特性，例如，一个数据库应力程序组仅应力诸如Windows CE的一个操作系统的数据库功能性。诸多应力测试选项可以依据应力程序组11来区别。诸多应力测试选项(Stress Test Options)是不同的，因为它们的提供更宽带应力情况的目标功能性相当于真实世界中的使用模型。这些情况与测试程序组文件5的任何用户选择集联合运行。应力测试选项可以并且应当联合和分离地运行，这样做，可以有效增加任何测试计划的范围。该第一的两个应力测试选项涉及目标设备9上的存储器。该第一应力测试选项是低实际存储器选项(Low Virtual MemoryOption)，它极大地减少运行所选用的测试11之前的目标设备的虚拟存储器的工作量。该应力测试选项模拟当用户打开了15个应用程序时可能出现的导致故障的真实的恶劣环境。第二应力测试选项是低存储存储器选项(Low Storage Memory Option)。当选用时，该第二应力测试选项将目标设备9的存储存储器填充到最大容量，以便使目标设备9经历对低存储存储器解答的响应。在某些情况下，当第二应力测试选项可以依赖不存在的存储存储器时，该第二应力测试选项也有利于测试目标设备9内包含的应用程序。下一个第三应力测试选项是执行选项。第一可执行应力选项是无限循环，是长测试周期的意思。许多设备驱动器中的共同问题是长期、瞬间、紧迫情况下的故障。该无限循环应力测试提供用于确定一个可能的中断的测试。该无限循环测试运行所选用的程序组11，直至用户人工按压停止按钮。下一个应力执行选项是可配置的CPU周期剥夺测试，它是作为被标识为称作Data.txt的路径为O/SValidator\Tests\TestInputFiles的文本文件中得到。在用户可以复制、重新使用或修改的文件中提供了两个情况。文本文件，Data.txt控制线程的数量以及用户可以包含在他的测试运行中的线程的属性。换句话说，用户可以运行他的测试，同时其它的处理正在消耗CPU时间，从而消除了包括计时的许多问题。最后的应力测试选项是随机执行(Random Execution)。当用户选择该选项时，图形用户接口2将以运行时间记录测试程序组的列表，所以它们以不同顺序运行。该选项是理想的，因为它便于与其它部件交互问题的诊断。

剩余的测试运行选项(Test Run Options)是用户可以控制的普通行为。第一选项，“只使用所选的目标(Use Selected TargetExclusively)”是重要的，因为当目标设备9经以太网连接时，子网络中其它用户可以经操作系统验证器1有效目标设备窗口访问该目标设备9。这有助于建立对目标设备9的应力。在用户希望隔离问题的事件中，将不施加额外的应力。在该情况中，用户应当排它地访问目标设备9。最后的测试运行选项设置提示引擎3将时间从主计算机4发送到目标设备9的设置目标时间(Target Time)，因而是目标设备9系统时间与主计算机4时间同步。当记录文件带回来涉及目标设备9的日期和时间的日期和时间标志时，同步是有利的。为了保持这些精确性，用户应当设置目标设备9的日期和时间。返回一个测试之前的最后抽头是环境设置抽头，其含有用于各种可选择的环境变量的有价值信息。指定这些环境设置，以便通过使测试程序组文件含有环境变量而不是含有硬件制卡信息来扩展和提炼测试程序组文件5。例如，系列测试得到一个现存COM口作为一个参数。如果没有键入作为环境变量的COM口，则测试失败，因为它不能打开一个COM口。该程序组中使用的所有环境变量被提供；然而，任何附件的环境变量可以由用户加到用户输入程序组上。运行一个测试之后，测试状态对获得当前测试运行的状态信息是有用的。该信息被动态地更新。

状态运行部分窗口列出已经开始的选用程序组。通过选择预期测试图标，用户可以从该窗口打开任何记录文件。该控制中的其它图标提供失败信息。失败图标例如被显示为具有红色“X”的程式化断路器删除。测试运行概要信息保持测试程序组文件运行数目、所选程序组、具失败程序组以及失败程序组的百分比的轨迹。一旦测试运行完成，用户可以选择一个配置失败程序组抽头，它促使选择所有失败程序组的新配置窗口出现，促使测试回归。

剩余的两个部分被称作测试细节。这些测试细节部分之一监视通过以及失败的单个测试情况，这一部分对测量测试运行的值是有价值的。剩下的测试细节部分是失败状态部分，其中，所有选择的失败程序组由程序组名列出，它显示了相应的通过和失败测试情况的数量。所有该信息，给用户一个非常好的在一个测试运行期间限制它的目标设备9的想法(即，通过的目标设备，更重要的是失败的目标设备)。

本发明的主要目的是正确地测试诸如Windows CE的操作系统1001a的端口。为了实现该任务，需要数百个程序组测试11，并且由操作系统验证器1提供这些程序组测试11。例如，提供了接近由已验证的操作系统子系统分组的1500个测试程序组11。如图10所示，操作系统验证器1包括用于所有测试11的源码和可执行码，操作系统特殊着重的是历史性地展示几乎全部的问题的子系统。由操作系统验证器1测试的操作系统的子系统部件包括：以太网/NDIS，串行端口驱动器，显示器驱动器，触摸屏驱动器，鼠标驱动器，键盘驱动器，原始设备制造商适应层，以及PC卡适配器驱动器。图15A、图15B和图15C共同显示了系统部件的测试细节的列表。

如上所述，如图3所示，引擎3通过术语称为HarnessLink.dll 7的部件链接到图形用户接口2，其为一个ActiveX控制。具体地说，HamessLink.dll 7提供了一组用于呼叫引擎3的建立在图形用户接口2上的函数。HamessLink.dll 7的大部分函数呼叫设立了一些用于引擎3指令行的参数。所有的初始信息经由这个指令行传递到引擎3，保证了引擎3用于具体执行的准备就绪。多个与图形用户接口相关的函数在指令行上提供信息。该信息相对应于图形用户接口2信息。另一个主要函数HamessLink.dll 7，用于通过开启一个已命名的程序管道，在引擎3的运行过程中从事通信活动。如果为了传送某些存储器信息而出现了一个错误或者需要，引擎3通过已命名的程序管道通信。已命名的程序管道保证了在引擎3和具体Harness链接之间的通信是直接的，精确的，并且是在多个引擎3运行的情况下不存在复制问题的。当HarnessLink.dll 7从程序管道接收到一条信息，其标志着适当的VB事件，该事件导致图形用户接口2按顺序取信息并且因此进行处理。如关于图5已描述的那样，引擎3与一个HarnessLink.dll 7通信，其按顺序与一个CEHarness 8通信。引擎3的执行是简单的：接收和处理指令行，建立到目标设备的执行网络界面连接，开启具有图形用户接口2的程序管道，读取测试程序组文件5，以及顺序地执行三态测试，预执行，执行，以及后执行。预执行建立在目标设备9和主机4之间的错误网络界面连接上。如记录的路径和类型的相关数据，各种测试运行信息，以及应力情况在预执行阶段发送。执行阶段包括对每一个串行程序组命令的回应。程序组命令一般由主机4发送并且由CEHarness 8处理，按顺序，当该命令执行完，以一网络界面信息回应。后执行阶段主要包括减少记录信息和生成概要记录。在完成这些概要记录后，引擎3存在。测试目标设备9中的CEHarness 8是比引擎3更为复杂的部件。该复杂性是因为每个设备9在任何给定时间具有CEHarness8的一个情况；然而，该设备可以处理多个同时连接，这是一个对操作系统验证器1提供的测试方法论的极其重要的特点。当用户启动CEHarness 8时，它建立了持续整个执行时间的两个线程：广播线程和执行线程。广播线程每10秒更新信息，比如设备IP、连接类型、可得到的COM口，以便用相同速率向网络发送广播消息。如果设备9经Window CE服务器(即，在NT侧)连接主计算机4以及连接remnet或repllog(即，在设备侧)，则连接类型转变到PPP_PEER。如果这种情况出现，则广播消息仅发送给直接连接目标设备9的主机4。如果用户在执行期间改变相同点上的连接，则更新该消息。同时，执行线程等待来自引擎3的连接尝试。当执行线程接收该连接时，它产生另一个线程，一个执行各种所需功能的主要执行线程。该主执行线程启动用于发送任何差错或存储器信息的另一个网络界面。因而，该执行线程是事件驱动，适当地接收一个命令和响应。每个连接尝试产生它自己的执行线程；因此，单个CEHarness 8可以有许多有效连接，从而通过在一个目标设备9上同时运行多个配置扩展了测试功能，以及建立了更真实的应力情况。

图16是图示说明本发明协议确认系统4000的流程图，该系统包括消息发送器2000和消息接收器3000。消息发送器具有可以并行处理信息的一个接收线程2001和一个发送线程2009。发送线程2009生成消息(块2008)，在该消息周围放置首标以形成一个分组，其中，WIN32事件句柄位于该首标的一个字段中，如分组2007所示。然后按每个块2006将这种分组发送到中断线程2009的块2005或者发送给由信息接收机3000接收分组的块3001，而又将首标的一个字段中具有WIN32事件句柄的分组(如块3002所示)经接收块2002发送给接收线程2001，或者根据消息接收机3000功能继续进行处理。接收线程2001接收确认分组，它随后使用确认分组的首标中的WIN32事件句柄，中断方块2003上的发送线程，然后恢复方块2004上的发送线程2009或者继续接收线程2001功能的处理。

因而，图3所示的记录库12是一个以各种方式集成到操作系统验证器1中的复杂工具。主要是，记录库12被集成到用于测试的源文件中。测试调用记录库应用程序接口，于是该记录库12处理关于测试结果的捕获和记录的细节。记录库12还支持各种通信选项。推荐的选项是经过TCP得到的，当它们从TCP连接转移时，允许用户查看记录文件的读出。另一个通信选项直接记录到一个设备的文件上。这可能是有利的，例如，如果用户想记录到PCMCIA卡但不想经网络广播额外信息的话。尽管记录库12充当对TCP通信的设备侧的部件，但主机4部件充当通信的图形用户接口2侧的部件。记录库12的这一方面提供了主机4上的记录窗口和测试结果的彩色编码。例如，失败消息被显示为红线。源码文件的名称和位置以及生成消息的行号被包含在记录库12消息中。此外，非常重要的是，提供了描述程序中当前事件的详细的差错消息。每个记录窗口具有一个概要抽头，它便于用户到程序存储器访问通过、失败和计时消息。记录文件的另一个重要特征是记录文件在测试的开头和结尾捕获大量的信息。该信息提供存储器、系统、功率和其它有用信息的瞬象。

这里所示的和详细说明的信息完全能够实现本发明、本发明的优选实施例的上述目的，因而代表了本发明宽范围考虑的主题。本发明的范围完全包括本领域技术人员显而易见的其它实施例，这些实施例将被所附的权利要求限制，其中，引用单数的元件不意味着“唯一的一个”(除非明确说明)，而是“一个或多个”。上述优选实施例和本领域技术人员知道的附加实施例的元件的结构和功能等同物在此作为参考明确引用，并且由权利要求包围。此外，寻找由本发明解决的每个和全部问题的设备或方法是不必要的，它将由权利要求包含。此外，本发明没有公开的元件、部件或方法步骤打算献给公众，而与这些元件、部件或方法步骤是否在权利要求中被明确限制无关。这里未要求保护的元件将根据35 U.S.C.112条第6款来限制，除非使用术语“用于……的装置(means for)”明确限制。

Claims (20)

1.一种基于计算机的系统，用于测试和验证一个目标设备内的嵌入式操作系统，包括：

    a.一个主计算机；

    b.一个装备了操作系统的目标设备；以及

    c.一个操作系统测试和验证软件程序，所述程序被装备在所述的主计算机中，

其中，所述的程序包括一个图形用户接口程序装置，用于连接用户，一个引擎装置，用于与所述的目标设备通信以及响应来自所述图形用户接口的命令；多个测试程序组，包括至少一个用于测试和验证至少一个所述操作系统的部件；和一个有助于与所述目标设备共同使用的协议确认软件分组，

其中，所述的协议确认软件分组利用一个操作的系统生成的事件句柄，作为协议的成员字段，用于释放正在等待来自所述目标设备的一个确认消息的执行线程，以及

其中，所述的事件句柄被置于一个消息分组的首标部分，并且在所述的确认消息中送回，以及其中，一个接收的线程启动正在等待所述确认消息中所述事件句柄的执行的任何被发送线程；以及

d.一个记录库装置，用于处理和存储由测试和验证软件程序的所述操作系统生成的测试相关信息。

2.根据权利要求1所述的基于计算机的系统，其中：

测试和验证软件程序的所述的操作系统还包括一组调用引擎装置的图形用户接口的函数。

3.根据权利要求1所述的基于计算机的系统，

其中，所述的目标设备还包括一个事件驱动应用程序，用于与所述的引擎装置通信，以及

其中，所述的引擎装置发送事件和所述的事件驱动应用程序响应。

4.根据权利要求1所述的基于计算机的系统，其中

所述目标设备中的所述操作系统包括Windows CE操作系统，以及

所述的事件句柄包括一个WIN32事件句柄。

5.根据权利要求1所述的基于计算机的系统，其中：

所述的测试程序组至少包括一个系统应力测试子程序；以及

至少一个特征和功能测试。

6.根据权利要求5所述的基于计算机的系统，其中：

所述系统应力测试子程序包括测试所述操作系统至少一个部件的应力的编码基数，

所述操作系统的至少一个部件从一组操作系统部件中选择，所述的一组操作系统部件包括：一个以太网/NDIS，PCMIA，一个存储器，文件系统，一个串行口，一个具有多个应用程序接口的视频系统，一个红外线系统，一个原始设备制造商适配层，一个触摸板，一个鼠标，一个键盘，和一个音频/波形系统，

所述测试至少识别三种缺陷，即，硬件设计，硬件编程和操作系统交互作用，并且以自动或人工方式执行。

7.根据权利要求1所述的基于计算机的系统，其中：

所述的目标设备包括测试和验证软件程序的装备有所述操作系统的唯一单元，用于独立于所述主计算机导电验证和应力测试。

8.根据权利要求1所述的基于计算机的系统，还包括：

一个耦合所述主机和所述目标设备的以太网连接，用于导电测试和验证任务。

9.根据权利要求1所述的基于计算机的系统，其中：

所述的记录库装置至少包括使用一个WRITETESTPASS应用程序接口的通过测试结果文件。

10.根据权利要求9所述的基于计算机的系统，其中：

所述的至少一个通过测试文件驻留在所述目标设备中。

11.根据权利要求1所述的基于计算机的系统，其中：

所述记录库装置至少包括一个使用WRITETESTFAIL应用程序接口的失败测试结果文件。

12.根据权利要求11所述的基于计算机的系统，其中，所述至少

一个失败测试文件驻留在所述目标设备中。

13.一种基于计算机的方法，用于测试和验证一个目标设备内的嵌入式操作系统，包括以下步骤：

     (a)提供一个主计算机；

     (b)提供一个装备了操作系统的目标设备；

     (c)提供一个操作系统测试和验证软件程序，所述程序被装备在所述的主计算机中，

其中，所述的程序包括一个图形用户接口程序装置，用于连接用户，一个引擎装置，用于与所述的目标设备通信以及响应来自所述图形用户接口的命令，多个测试程序组，包括至少一个用于测试和验证至少一个所述操作系统的部件，和一个有助于与所述目标设备共同使用的协议确认软件包，

其中，所述的协议确认软件包利用一个操作的系统生成的事件句柄，作为协议的成员字段，用于释放正在等待来自所述目标设备的一个确认消息的执行线程，以及

其中，所述的事件句柄被置于一个消息分组的首标部分，并且在所述的确认消息中送回，以及其中，一个接收的线程启动正在等待所述确认消息中所述事件句柄的执行的任何被发送线程；以及

(d)提供一个记录库装置，用于处理和存储由测试和验证软件程序的所述操作系统生成的测试相关信息，

(e)执行所述操作系统以及执行测试和验证所述的操作系统测试和在所述目标设备上以及测试和验证所述操作系统，

其中，所述的执行步骤包括通过响应所述确认消息中的所述事件句柄来开启执行的已发送线程；以及

(f)生成通过和失败结果。

14.根据权利要求13所述的测试和验证嵌入式操作系统的基于计算机的方法，还包括步骤：

提供说述操作系统测试和验证软件程序的所述操作系统装备一组调用引擎装置的图形用户接口的函数。

15.根据权利要求13所述的测试和验证嵌入式操作系统的基于计算机的方法，还包括步骤：

使所述的目标设备装备一个事件驱动应用程序，用于与所述的引擎装置通信，其中，所述的引擎装置发送事件和所述的事件驱动应用程序响应。

16.根据权利要求13所述的测试和验证嵌入式操作系统的基于计算机的方法，还包括步骤：

(a)使所述目标设备装备一个Windows CE操作系统；以及

(b)使所述事件句柄装备一个WIN32事件句柄。

17.根据权利要求13所述的测试和验证嵌入式操作系统的基于计算机的方法，还包括步骤：

提供系统应力测试例行程序形式的测试程序组，所述系统应力测试子程序包括测试所述操作系统至少一个部件的应力的编码基数，

所述至少一个部件从一组操作系统部件中选择，所述的一组操作系统部件包括：一个以太网/NDIS，PCMCIA，一个存储器，文件系统，一个串行口，一个具有多个应用程序接口的视频系统，一个红外线系统，一个原始设备制造商适配层，一个触摸屏，一个鼠标，一个键盘，和一个音频/波形系统，

所述测试至少识别三种缺陷，即，硬件设计，硬件编程和操作系统交互作用，并且以自动或人工方式执行。

18.根据权利要求13所述的测试和验证嵌入式操作系统的基于计算机的方法，还包括步骤：

提供一个连接所述主机和所述目标设备的以太网连接，用于在所述目标设备上的导电测试和验证任务。

19.根据权利要求13所述的测试和验证嵌入式操作系统的基于计算机的方法，还包括步骤：

使所述的记录库装置至少装备一个使用WRITETESTPASS应用程序接口的通过测试结果文件。

20.根据权利要求13所述的测试和验证嵌入式操作系统的基于计算机的方法，还包括步骤：

使所述记录库装置至少装备一个使用WRITETESTFAIL应用程序接口的失败测试结果文件。

Images