CN1755646A - 关于自动测试用例执行的松散耦合的自动测试用例验证 - Google Patents

Abstract

一种用于验证应用于应用程序的动作的系统结果，并用于在任何时间或按需提供应用程序的期望状态的系统和方法，其中验证管理器确定应用程序的期望应用状态和当前应用状态，与验证管理器通信的测试用例执行该动作，而验证管理器比较期望应用状态和当前应用状态。

Description

关于自动测试用例执行的松散耦合的自动测试用例验证

相关申请

本申请涉及律师案号为MSFT-4148题为“System and Method for Selecting TestCase Execution Behaviors for Reproducible Test Automation”(“选择用于复验自动化的测试用例执行行为的系统和方法”)的与本申请一起提交的美国专利申请，以及律师案号为MSFT-4150题为“Test Automation Stack Layering”(“测试自动化的堆栈分层”)的与本申请一起提交的美国专利申请。

技术领域

本发明涉及用于测试应用的软件，尤其涉及在这种测试软件中期望和实际结果的松散耦合比较。

背景技术

软件开发生命期中的主要阶段是设计阶段、编码阶段、代码完成阶段、α阶段、β阶段，以及最后向市场发行。在设计阶段期间，将解决软件产品的客户问题并定义软件产品的功能。通常，功能说明书的完成标志着设计阶段的结束。编码阶段已经开始。当代码写成但尚未调试时则进入代码完成阶段。α阶段标记产品稳定的时间点；即，已发现了大部分的主要缺陷。在β阶段，产品几乎没有了所有的主要缺陷；即所剩的缺陷应基本上无害。当产品通过最终的质量保证检查列表时，它已准备就绪向市场发行。

因为没有人想要不工作的软件，测试是生命期的重要部分并可跨越若干阶段。软件测试包括设计一测试用例(或更可能是测试用例集)、以测试用例为输入运行该软件、并检查以测试用例为输入的软件的性能是否产生预期结果。软件测试可由人类手动引导，或通过程序来引导(称为自动化软件测试)。理想地，软件的测试在软件生命期的一开始就应开始。然而一般而言，不到完成了设计阶段软件根本不能测试，因为直到完成设计阶段才能确定期望结果。通常，在编码阶段，开发者在写代码时手动测试其代码。自动化软件测试通常在开发过程的较后期才会开始。

有时，所引导的唯一测试由开发者在他编写程序时手动测试来完成。测试自己工作的开发者可能会忽视在情绪上不那么投入代码的某些人会发现的缺陷。此外，开发者测试的范围通常限于其代码的功能以及其代码与有限数量的其它软件应用程序的结合的代码。

为了解决这些缺点，许多软件开发机构具有常使用至少部分自动化的测试技术来测试软件的独立的软件测试组。通常，测试组通过编写和运行测试用例来测试各特征之间和应用程序之间的复杂交互。使测试组及早地甚至在设计阶段就进入产品生命期能获得很多好处通常是无异议的，这些好处包括标识功能说明书中的不一致、标识难以测试的区域及其它。然而一般而言，面对特征定义、实现和用户界面(UI)调整中的持续变化而保持每个测试用例最新所需的努力使该方法呈现为不实用。因此，编写并运行测试用例通常是在产品开发末期仓促发生的。因而测试特别是自动化测试总是落后于需求。如果有一种在一进入软件产品的生命期(理想地是在设计阶段期间)就能编写测试用例并采用自动化测试的方法将是有帮助的。

一整套测试用例的开发在任何时候都具挑战性。为了测试应用程序的特定特征，必需编写许多测试集。例如，应用程序可允许与一特征的许多交互模式：通过鼠标、键盘、数字化仪、可访问软件、通过程序等。因此，为了提供对该特征的综合性测试，一整套测试应包括通过鼠标与该特征交互(像用户一样键入文本)的一个测试集、通过键盘与该特征交互的一个集、通过数字化仪与该特征交互的一个集、通过可访问软件与该特征交互来调用缺省动作并以其它方式模拟可访问应用程序的一个集、通过应用程序的编码模型与该特征交互的一个集等。如果有一种确保一整套生成的测试用例提供特征或应用程序的综合性测试，并进一步减少为了提供综合性测试而必需编写的测试用例的总量的方法，这将是有帮助的。

此外，这些测试集的每一个中的许多或全部逻辑都与其它测试集中的逻辑相同，且通常许多或全部的结果处理验证也相同。因此，许多测试是相同或非常接近的，仅仅在执行选项上有变化。例如，对于上述全部多种形式的输入，期望结果可能是相同的。因此，对这些输入源的每一个编写测试用例通常需要编写用于执行每个输入源的测试的独立方法，并复制大多数剩余的测试脚本。重复编写仅具有极小变化的相同测试是乏味并耗时的。如果有一种消除或大大减少这种重复编码并减少必需编写的测试用例的总量的方法将是有帮助的。

编写用来确定运行测试用例的实际结果是否与期望结果相一致(常称为结果验证或验证)的代码常包括在测试用例内。改变特定结果验证的细节或添加新的结果验证通常需要更改每个测试用例。如果验证代码独立于测试用例，使该测试用例更易于理解以及验证代码更易于重复使用和维护将是有帮助的。

执行细节常被硬编码到测试用例中，需要设计阶段在编写测试用例之前就完成。如果有一种根据用户动作而不根据特定执行细节来定义测试用例使得测试用例能在软件开发生命期的较早期编写的方法，这将是有帮助的。测试应用程序是应用程序的初始开发的重要步骤，当实现对该应用程序的更改时，测试应用程序也是非常重要的。软件应用程序开发者、科学家、厂商在应用程序开发的测试阶段投入了大量精力。这样的测试有助于确保应用程序以期望方式响应于特定激源。测试通常通过执行测试用例并验证测试用例执行的结果来完成。

通常测试用例在应用程序上施加一激源(stimulus)。测试用例还应验证应用程序以期望方式响应而不以非期望方式响应。为了较为综合，测试应验证整个应用程序状态的大部分，以确保激源导致期望结果而无非期望结果。

通常测试用例是为了测试应用程序的特定功能或方面而执行的。类似地，测试用例结果的验证可集中于要测试的功能。然而。测试用例的执行可影响或改变应用状态的其它方面。这些方面看起来会与测试用例的目的没什么关系。这些无甚关系方面有很多，且对测试者而言开发要量化或指定所有甚至大部分方面的测试用例是困难的。

编写要验证大部分应用程序状态的测试用例代码已证实因各种原因而有问题。即使对于相对简单的应用程序，仍然可能需要大量的测试用例来综合性地测试该应用程序。将冗长且详细的验证代码添加到每个测试用例中将是令人畏惧的(如果不是难以胜任的)任务。此外测试用例维护通常与测试用例创建一样地(如果不是更多)劳动密集和耗时。当改变应用程序时，应改变测试用例以及验证代码以确保与应用程序的兼容性。将冗长且全面的验证代码添加到每个测试用例中将使得这种维护不实用(如果不是不可能的话)。

因此，需要综合性地验证应用于应用程序的测试用例的结果，而无需对每个测试用例编写冗长的、单调的和耗时的验证代码。还需要对需要测试者最少的显式动作来设置、执行、或维护的验证。

发明内容

测试用例实现的验证可与测试用例分开并由专用的验证管理器来完成。测试用例可能不需要包括任何验证并且实际上测试者甚至不需要知道在执行的所有验证。验证管理器可用来验证一个或多个测试用例，从而每个测试用例可执行一动作而无需提供该动作结果的特定验证。

使用专用的验证管理器，验证可更为综合。使用一个较大的期望状态发生器库，验证管理器可更为综合地验证测试用例的结果。对于应用程序的各个独立和不同组件，可集中于包含在该库中的每个期望状态发生器。一个期望状态发生器可集中于测试者具体对于测试用例目的而考虑的应用状态的一方面。第二个期望状态发生器可集中于测试者与测试用例的目的不太相关或无关地考虑的应用程序的一方面。因此，与仅具有包括在测试用例中的集中验证相反，该库可使能对所有测试用例的广泛验证。

验证管理器可通过比较指定应用程序属性的期望值和那些相同属性的实际值来验证测试用例结果。在进行比较的过程中，验证管理器将能确定当前和期望应用状态基本上不相符的实例。最后，验证管理器可将任何测试失败传送给测试用例、测试用例执行器、或任何其它指定实体。

可完成验证过程使得测试用例甚至不知道例如在测试用例调用图形应用程序绘制蓝色长方形时已验证了文件菜单上按键的状态。在获取该综合性验证的过程中，测试者除执行具有适当参数的动作之外不需要其它动作。

此外，当更新或改变验证时，最小化或消除测试用例的维护。例如，当更新或以其它方式改变应用程序时，验证管理器或期望状态发生器类似地可能需要修改以确保与应用程序保持一致。由于验证可与测试用例分开，测试用例可能不需要任何维护。

此外，当测试用例导致应用程序的一特定组件的失败时，可执行其它测试用例而无需继续接收同一失败的通知。该能力提供了将失败考虑在内和继续测试应用程序的机会。

附图说明

结合附图阅读时，前面的发明内容和以下说明性实施例的详细描述能得到更好的理解。为了说明本发明各实施例，在附图中示出本发明的示例性结构；然而，本发明并不限于所揭示的特定方法和装置。在附图中：

图1是示出其中可实现关于测试用例执行松散耦合的测试用例验证的各方面的实例计算环境的框图；

图2是根据本发明一实施例用于关于测试用例执行松散耦合的测试用例验证的系统的框图；

图3A-B是根据本发明一实施例关于测试用例执行松散耦合的测试用例验证的流程图；以及

图4是根据本发明另一实施例用于关于测试用例执行松散耦合的测试用例验证的系统的框图。

具体实施方式

纵览

在本发明一示例实施例中，验证过程与测试用例分开。称为期望状态发生器的每个验证元件可存储在称为验证管理器的专用装置中。通过将每个验证过程从各个测试用例中分开，每个测试用例可得到更综合地验证而无需在每个测试用例中复制验证代码。此外，验证管理器可包括许多期望状态发生器，它们彼此独立操作且每一个都计算应用程序的一个或多个组件的期望状态。验证可离线完成一即在除测试用例执行期间和/或在线或测试执行期间之外的时间。

期望状态发生器可嵌入本地验证框架或可以是在运行时动态载入、启用和禁用的独立对象。这种期望状态发生器可从数据库或网络位置中载入。实质上，期望状态发生器可以是验证框架的插件。

将验证从各个测试用例中分开使应用程序能更综合地进行测试。此外，具有专用验证管理器使测试用例能够进行验证而无需将验证代码包括在每个测试用例中。由于验证代码没有包括在每个测试用例中，当更改验证算法以对应于应用程序中的更改时，这种更改并不影响测试用例。因此，将验证从测试用例中分开可减少对测试用例的必需维护。

示例计算环境

图1和以下讨论旨在提供一种本发明的示例实施例可在其中实现的适当计算环境的简要一般说明。然而，应当理解手持式、便携式以及所有类型的其它计算装置可预期用于本发明。尽管以下所述为通用计算机，但仅是一个示例。本发明还可在与网络服务器互操作并交互的瘦客户机上操作。因而，本发明的示例实施例可在其中仅含极少或最少客户机资源的网络化主机服务的环境中实现，例如其中客户机装置仅用作万维网的浏览器或接口的网络化环境。

尽管不是必需的，本发明可通过由开发者或测试者使用和/或包括在网络浏览软件中的应用程序编程接口(API)来实现，它将在诸如程序模块的由一个或多个计算机(例如客户机工作站、服务器、或其它装置)执行的计算机可执行指令的一般上下文中描述。一般而言，程序模块包括执行特定任务或实现具体抽象数据类型的例程、程序、组件、数据结构、以及其它类型的结构。通常，程序模块的功能可按需在各个实施例中组合或分布。此外，本领域技术人员将理解本发明可在其它计算机系统配置中实践。适用于本发明的其它众所周知的计算系统、环境和/或配置包括，但不限于，个人计算机(PC)、自动取款机(ATM)、服务器计算机、手持式或膝上型装置、多处理器系统、基于微处理器的系统、或可编程的电子消费品、网络PC、小型计算机、大型计算机等等。本发明的实施例还可在任务由经通信网络或其它数据传输介质链接的远程处理装置执行的分布式计算环境中实践。在分布式计算环境中，程序模块可置于包括存储器存储装置的本地和远程计算机存储介质中。

因而图1示出本发明可在其上实现的适当计算系统环境100的示例，尽管如上阐明的，该计算系统环境100仅是适当计算环境的一个示例，并非旨在提出对本发明使用或功能性范围作任何限制。计算环境100也不应被解释为对示例性操作环境100中所示的任一组件或其组合有任何依赖性或任何需求。

参照图1，用于实现本发明的示例系统包括以计算机110形式的通用计算装置。计算机110的组件可包括，但不限于，处理单元120、系统存储器130以及把包括系统存储器在内的各种系统组件耦合到处理单元120的系统总线121。系统总线121可能是若干总线结构类型中的任何一种，包括存储器总线或存储器控制器、外围总线、以及使用多种总线架构的任一种的本地总线。作为示例，而非限制，这些架构包括工业标准架构(ISA)总线、微信道架构(MCA)总线、增强型ISA(EISA)总线、视频电子标准协会(VESA)局部总线和外围部件互连(PCI)总线(也称为Mezzanine总线)。

计算机110通常包括各种计算机可读介质。计算机可读介质可以是能被计算机110访问的任何可用介质，并包括易失性和非易失性介质、可移动和不可移动介质。作为示例，而非限制，计算机可读介质可包括计算机存储介质和通信介质。计算机存储介质包括以任何方法或技术实现、用于存储诸如计算机可读指令、数据结构、程序模块或其它数据等信息的易失性和非易失性介质、可移动和不可移动介质。计算机存储介质包括但不限于RAM、ROM、EEPROM、闪存或其它存储器技术、CD-ROM、数字化多功能光盘(DVD)或其它光学存储技术、磁盒、磁带、磁盘存储器或其它磁性存储设备、或任何其它可用于存储所需信息并可由计算机110访问的介质。通信介质通常在诸如载波或其它传输机制的已调制数据信号中体现计算机可读指令、数据结构、程序模块、或其它数据，且包括任何信息输送介质。术语“已调制数据信号”意指以在信号中编码信息的方式设置或改变其一个或多个特征的信号。作为示例，而非限制，通信介质包括诸如有线网络或直线连接的有线介质，和诸如声学、射频(RF)、红外线和其它无线介质的无线介质。以上任何介质的组合也应包括在计算机可读介质的范围中。

系统存储器130包括诸如只读存储器(ROM)131和随机存取存储器(RAM)132的易失性和/或非易失性存储器形式的计算机可读介质。包含有助于如起动时在计算机110内元件间传送信息的基本例程的基本输入/输出系统(BIOS)133通常存储在ROM131中。RAM132通常包含可被处理单元120立即访问和/或当时正被操作的数据和/或程序模块。作为示例，而非限制，图1示出了操作系统134、应用程序135、其它程序模块136、和程序数据137。RAM132可包含其它数据和/或程序模块。

计算机110还可包括其它可移动/不可移动、易失性/非易失性计算机存储介质。作为示例，图1示出了读取和写入不可移动、非易失性磁性介质的硬盘驱动器141，读取和写入可移动、非易失性磁盘152的磁盘驱动器151，读取和写入可移动、非易失性光盘156，诸如CD-ROM或其它光学介质的光盘驱动器155。其它也在示例性计算环境中使用的可移动/不可移动、易失性/非易失性计算机存储介质包括，但不限于，如磁带、闪存卡、数字化多功能光盘、数字化录像带、固态RAM、固态ROM等等。硬盘驱动器141通常通过诸如接口140的不可移动存储器接口与系统总线121连接，而磁盘驱动器151和光盘驱动器155通常通过诸如接口150的可移动存储器接口与系统总线121连接。

如上所述并如图1所示的驱动器及其相关联的计算机存储介质为计算机110提供计算机可读指令、数据结构、程序模块、和其它数据的存储。在图1中，例如，硬盘驱动器141被示为存储操作系统144、应用程序145、其它程序模块146、和程序数据147。注意这些组件可以与操作系统134、应用程序135、其它程序模块136、和程序数据137相同或不同。在此给予操作系统144、应用程序145、其它程序模块146、和程序数据147的不同编号至少说明他们是不同的副本。用户可通过诸如键盘162、以及通常称为鼠标、跟踪球或触摸板等的定位装置161的输入装置向计算机110输入命令和信息。其它输入装置(未示出)可包括话筒、游戏杆、游戏垫、卫星接收天线、扫描仪等等。这些和其它输入设备常常通过与系统总线121耦合的用户输入接口160与处理单元120a-f相连，但也可通过诸如并行端口、游戏端口或通用串行总线(USB)的其它接口和总线结构连接。

监视器191或其它类型的显示设备也可通过诸如视频接口190的接口与系统总线121相连。除监视器191以外，计算机还可包括诸如扬声器197和打印机196的其它外围输出设备，它们通过输出外围接口195相连。

计算机110可以在使用与一台或多台远程计算机，诸如远程计算机180的逻辑连接的网络化环境中运行。远程计算机180可以是个人计算机、服务器、路由器、网络PC、对等装置或其它公共网络节点，而且通常包括上述与个人计算机110相关的许多或全部组件，尽管在图1中仅图示了存储器存储设备181。图1中所描绘的逻辑连接包括局域网(LAN)171和广域网(WAN)173，但也可包括其它网络。这样的网络化环境在办公室、企业范围计算机网络、内联网和因特网上是常见的。

当用于LAN网络化环境中时，计算机110通过网络接口或适配器170与LAN171连接。当用于WAN网络化环境中时，计算机110通常包括调制解调器172或其它用于在诸如因特网的广域网173中建立通信的装置。可以是内置式或外置式的调制解调器172与系统总线121通过用户输入接口160或其它适当机制连接。在网络化环境中，与计算机110相关的程序模块或其一部分可存储在远程存储器存储装置中。作为示例，而非限制，图1示出了驻留于存储器装置181中的远程应用程序185。应当理解，所示网络连接是示例性的，且也可以使用其它用于在计算机间建立通信连接的方法。

本领域技术人员可理解，计算机110或其它客户机装置可用作计算机网络的一部分。这样，本发明适合具有任何数量存储器或存储单元的任何计算机系统、以及在任何数量存储单元或存储体上发生的任何数量的应用程序和进程。本发明一实施例可应用于带有可用于网络环境的具有远程或本地存储器的服务器计算机和客户计算机的环境。本发明还可应用于具有编程语言功能、编译和执行功能的单机计算装置。

用于关于测试用例执行松散耦合的测试用例验证的系统和方法

图2是根据本发明一实施例用于关于测试用例执行松散耦合的测试用例验证的测试验证系统1的框图。系统1可驻留于是参照图1所述的计算机110的计算机上。系统1可包括以下的一个或多个：验证管理器30、测试用例20、比较器35、期望应用状态数据结构36、当前应用状态数据结构37、以及数据库31。该系统可包括要测试的应用程序10。应用程序10可以是任何进程、机器、制造品、或合成品、或其任何改进。应用程序10还可以是程序、软件、硬件、装置、机制、或材料或其任何改进。例如，应用程序10可以是运行在任何计算系统上的软件程序。还例如，应用程序10可以是一种门测试机制，其中装置敲打门把手以测试门把手、门把手所附门、附在门上的铰链、铰链所附门框的强度、弹性、或可操作性。应用程序10可以是在首次开发中、先前应用程序的更新版本、终端用户已经用某些方法更改的先前发行的应用程序等。

应用程序10可由一个或多个测试用例测试，在图2中视为测试用例20a、b、c、……、f等。可调用测试用例20a-f用于集成或功能测试。集成测试测试两个或多个交互组件组合、一起工作、并彼此影响的方式。在功能测试中，测试用例集中于测试用例的特定功能行为。

一般而言，每个测试用例20a-f包括要应用于应用程序10的带有明确定义参数的明确定义动作。每个测试用例20a-f可包括由应用程序10执行的一个或多个步骤。每个测试用例20a-f可以是应用于应用程序10的一个或一系列测试。测试用例20a-f可用诸如C、C#、C++、Pascal、面向对象语言等的任何适当编程语言来编写。测试用例20a-f或测试用例20a-f的组合可例如调用图形应用程序来在包含各种色彩的其它形状的文档上绘制蓝色长方形。测试用例20a-f还可与计算机编程语言无关。例如，测试用例20a可调用10磅的大槌从4英尺高30°角手动释放到附于门的门把手上。可以理解，图形应用程序、门把手应用、以及本说明书中所提供的任何其它示例都决不限制本申请的声明范围，而相反仅仅是其描述便于理解的说明性实施例。

图2中所示的每个测试用例20a-f可测试应用程序10的不同方面。应理解，测试用例20a-f仅表示可能的测试用例，还有任何数量的测试应用程序10的测试用例。此外，应理解可同时或在不同时间执行每个测试用例20a-f。此外，应当理解，例如测试用例20a可执行一次而测试用例20e可运行10次。此外，应当理解，测试用例20a-f可由测试者执行。在可选实施例中，测试用例可有测试用例执行器或类似装置执行。

在本发明一示例实施例中，测试用例20a-f可直接与验证管理器30通信。在本发明一可选实施例中，测试用例20a-f可调用与验证管理器30通信的其它子例程。测试用例20a-f可以不知道如何完成验证。例如，如果许多测试用例20a-f需要一蓝色长方形，可编写绘制蓝色长方形的子例程。该子例程可与验证管理器30通信。使用该子例程的测试用例20a-f会知道该子例程绘制一蓝色长方形，但不必知道该子例程与验证管理器30进行通信。

验证管理器30可包括期望状态发生器32t-z、比较器35、以及期望应用状态和当前应用状态数据结构36、37。

诸如每个期望状态发生器32t、u、……、z等的期望状态发生器可与一个或多个特定组件、数据点、或属性相关联。例如，对于测试其中一个、部分或全部测试用例20a-f调用应用程序10来在特定位置绘制一蓝色长方形的图形应用程序，期望状态发生器32t-z可集中于应用状态的不同组件。期望状态发生器32t可集中长方形的色彩。期望状态发生器32u可集中长方形的位置。期望状态发生器32v可集中于运行测试用例20a-f所引起的较不明显结果，诸如与新绘制蓝色长方形在同一文档上的三角形的位置。或者，期望状态发生器32u、32v可与相关于文档上每个形状的位置的单个期望状态发生器(未示出)相组合或被其替换。期望状态发生器32w可集中于工具栏上不相关选项的状态，诸如打开新文档的选项。

还有，例如如果测试用例20a-f通过用大槌击打大门把手来单独地或一起测试附于门上的门把手，则期望状态发生器32t可集中于门把手转动的能力。期望状态发生器32u和32v可集中于附于门上的高低铰链，或可组合与铰链状态相关的单个期望状态发生器(未示出)或被其替换。期望状态发生器32w可集中于门把手周围门的木质部分。其它期望状态发生器可集中于应用程序10的其它领域。

当一个或多个测试用例20a-f应用于应用程序10时可调用所有期望状态发生器32t-z，或者仅可调用一个或部分期望状态发生器32t-z。在一实例实施例中，期望状态发生器32t-z可独立于测试用例20a-f运行，并因此与之松散耦合。这样，测试用例20a-f无需指定在测试用例20a-f的应用期间应调用期望状态发生器32t-z的验证管理器。然后测试用例20a-f可不包含验证机制。当然，测试用例20a-f可能不知道要进行的任何验证。验证管理器30可负责验证测试用例20a-f的结果，且测试用例20a-f的目的可限于将带有特定参数的激源应用于应用程序10。

然而，本领域技术人员将理解，与示例实施例相一致，测试用例可包含验证编码。如果运行测试用例20a-f的目的是要确定特定问题是否已矫正，则正是这种情形。在—可选实施例中，测试用例20a-f还可指定要调用的一个或多个期望状态发生器32t-z并指定不应使用某些其它期望状态发生器32t-z。

随着验证从测试用例20a-f的分开，验证可对测试用例20a-f更加综合性。验证管理器30可包括先前已是各个测试用例一部分的期望状态发生器32t-z。例如，验证管理器30可包含现有技术测试用例20a-f的期望状态发生器32t-z，这些测试用例被设计成测试图形应用程序绘制蓝色正方形、红色圆、黄色三角形、或椭圆，使用下拉菜单上选项、通过使用鼠标或键盘等来响应各种用户输入等的能力。这些测试用例的每一个将包括集中于测试用例动作目的的特定验证。使用包含期望状态发生器32的专用验证管理器30，用于在图形应用程序中绘制蓝色长方形的测试用例20a-f可得到更综合的验证。验证管理器30可调用专用于蓝色长方形、红色正方形、黄色三角形、下拉菜单、鼠标和键盘的输入等的期望状态发生器32。这样，调用绘制蓝色长方形的测试用例20a-f可调用期望状态发生器32t-z来检查测试用例20a-f在应用程序10上的明显或不那么明显的效果。测试者甚至可不知道例如当绘制蓝色长方形时正在验证红色圆。如果测试结果是红色圆保持不受测试用例20a-f影响且如果这是期望结果，则测试者和/或测试用例可能不知道红色圆被验证。然而如果红色圆出乎意料地略有移动，则验证管理器30可警告测试者有非期望结果发生。

类似地，如果测试用例20a-f涉及用大槌击打附于门上的门把手，则验证过程可不仅包括确定测试对门把手的效果，还包括确定测试对门、门框、铰链等的效果。

此外，如果应用程序10改变、更新等，测试用例20a-f的验证可在很大程度上保持不受影响。可创建能改变应用程序10工作方式的应用程序10的新版本。因此，测试用例20可能需要改变。例如，用于测试图形应用程序的测试用例20a-f可能需要对它如何调用绘制蓝色长方形进行修改。还有，例如如果要测试的门把手具有比先前版本更大的弹性，则用于测试附于门的门把手的测试用例20a-f可能需要改变大槌的重量和高度。然而并不需要改变每个期望状态发生器32。在图形应用程序示例中，在应用程序10改变之前期望状态发生器32可用相同方式继续检查新的蓝色正方形、现有的红色圆、黄色三角形、椭圆的位置。类似地，在添加新的门把手并更改测试用例10之前，期望状态发生器32可用相同方式验证门把手、门、铰链和门框。

期望状态发生器32t-z可通过验证管理器30与数据库31通信。数据库31可向期望状态发生器32提供信息从而期望状态发生器更能从测试用例20中确定应用程序10的期望状态。例如，测试用例20a-f可涉及用大槌击打附于门上的门把手。期望状态发生器32a可对附于门上的1/8英寸厚、2英寸常的黄铜铰链确定测试用例的效果。这样做的过程中，期望状态发生器32a可查询数据库31以检索有关例如黄铜抗张强度的信息。在一可选实施例中，每个期望状态发生器32可与独立于验证管理器30的一个或多个数据库31通信。或者，每个期望状态发生器32可从可插入组件中检索或接收信息。

期望状态发生器32t-z可与比较器35通信。如图2所示，比较器35可以是验证管理器30的一部分，然而，本领域技术人员将理解比较器35可位于验证管理器之外。在此情形中，比较器可与验证管理器30和/或期望状态发生器32通信。比较器35可比较期望状态数据结构36和实际状态数据结构37。

更具体地，当要执行一个或多个测试用例20a-f时，测试用例20a-f或测试执行器可通知验证管理器30。验证管理器30可取应用程序的当前整体状态的快照。即验证管理器可复制存储器中应用程序属性的当前值。验证管理器30然后可通知期望状态发生器32要运行等待的测试用例20。在一示例实施例中，只通知那些可隐含于测试用例20a-f中的期望状态发生器32。在一可选实施例中，可通知所有期望状态发生器。

基于要执行的动作和动作参数以及验证管理器的当前整体状态的快照，每个期望状态发生器32对应用程序的组件从应用程序10上测试用例20a-f的预期执行来计算其期望结果状态。例如，如果应用程序10是图形应用程序，且测试用例20a-f都需要绘制蓝色长方形，则每个期望状态发生器32确定有关该动作的期望应用状态。期望状态发生器32t可确定结果应包括长方形。期望状态发生器32u可确定该长方形应是蓝色。期望状态发生器32v可集中于远离该长方形的红色圆，并可确定其期望状态应当由测试用例20保持不变。每个期望状态发生器将该期望组件状态传送给验证管理器30，而验证管理器30可将该数据置入比较器35中的期望应用状态数据结构36。这样，验证管理器30在执行测试用例20a-f之前可具有整体期望应用状态。此外，这意味着可在任何时候或按需确定整体期望应用状态。来自测试用例20a-f的执行的期望结果可以是确定性的。或者如果期望置入发生器32t-z理解非确定性结果是可接受的，则期望结果可以是非确定性的。

在完成测试用例20之后，验证管理器30可取另一快照或可进行复制，记录应用程序属性的当前值。该快照可显示应用程序的当前整体状态。属性的当前值可存储在当前应用状态数据结构37中。比较器35然后比较期望应用状态数据结构36和当前应用程序数据结构37。任何差异表示确保应进一步注意的区域。在一可选实施例中，数据结构36、37可被发送给适当工具用于执行比较。例如，通过使用可扩展标记语言(XML)可完成该比较。

期望和当前应用状态数据结构36、37之间的差异可警告测试者并导致可选的结论。期望和当前应用状态之间的差异可表示应用程序10未以适当方式动作的区域。在这样的情形中，可能需要调试源代码或改变材料的结构。即，例如如果测试用例20a-f想要绘制蓝色正方形的结果但相反测试用例20a-f结果绘制了红色正方形，则测试者倾向于修复应用程序10并再次运行测试用例20a-f。如果测试者不是开发应用程序的人员，则测试者可通过将缺陷记入缺陷跟踪系统、发送电子邮件、去开发者办公室、或使用其它通知系统来通知开发者该不正确行为—红色正方形。还有，例如如果测试用例20a-f想要门把手继续操作的结果，但相反大槌把门把手从门上敲下来了，则测试者可倾向于使用更坚固的接合件来将门把手置于门上。或者，如果测试者并非在制造门，则测试者可向门的制造商推荐使用更坚固的结合件。

差异还可表示期望状态发生器32的期望应用状态是不现实的。在这种情形中，可以批准对期望状态生成器变更，例如要测试的应用程序10可以是图形应用程序。一个或多个测试用例20a-f可包括使用鼠标来绘制长方形。然后一个或多个期望状态发生器32可期望绘制一个完美的长方形。如果用鼠标绘制完美的长方形在应用程序10中并不现实，则比较器30可指示因为结果长方形中的瑕疵而使该测试失败。然后测试者可将公差加入可应用期望状态发生器32中以允许包括几乎但不非常完美的长方形的期望应用状态。

在一示例实施中，期望状态发生器32可不仅基于在测试用例20a-f中调用的动作和参数而且基于当前应用状态来确定期望状态。这使得验证管理器30能将先前的测试用例失败考虑在内并基于这些失败决定期望状态。例如，测试用例20a-f可涉及用大槌击打附在门上的门把手。如果在执行测试用例的过程中附于门上的铰链遭到破坏，则对其它测试用例20a-f的铰链验证可基于先前的损坏而不指示失败。相反，验证管理器30可考虑先前的损坏而确定铰链的期望状态。

图3A示出执行松散耦合的验证的示例方法的流程图。验证方法200可在步骤205以测试用例20a-f开始。在一可选实施例中，测试用例执行器可向验证管理器发送开始事件并调用验证管理器30。从该开始事件或调用中，验证管理器30可获得等待测试用例20的通知。测试用例20a-f可包括将施加于应用程序的包括动作参数的明确定义的动作。在通知之后，验证管理器30可取当前整体状态的快照。在步骤210，验证管理器30可确定那些期望状态发生器32可隐含于等待测试用例20a-f中并通知可应用的期望状态发生器32。或者，验证管理器30向所有的期望状态发生器32通知等待的测试用例20a-f。在步骤215，期望状态发生器32将查看测试用例20a-f的可应用动作和参数。基于其组件的属性的当前值或组件，期望状态发生器可在完成测试用例20之后计算期望组件状态。每个得到通知的期望状态发生器32然后可将其期望组件状态发送给验证管理器30。该数据可存储在比较器35的期望应用状态数据结构36中。当所有可应用期望状态发生器32已报告期望组件状态数据时，验证管理器30将具有(在步骤220)整体期望应用状态。验证管理器30然后可在步骤225通知测试用例20a-f或测试执行器可执行测试用例20。因而将控制还给测试用例20a-f(或测试执行器)。在步骤230，可执行。测试用例20a-f。

图3B继续图3A的流程图。在步骤235，可执行测试用例20a-f，更新整体快照。在完成测试用例20之后，验证管理器30在步骤240可得到通知，测试用例20a-f已完成。在步骤245，验证管理器30可取当前应用状态的快照。该快照可反映应用程序上测试用例的实际结果。该快照还可表示应用程序的属性的值。验证管理器30可在步骤250将该快照存储在当前应用状态数据结构37中。然后验证管理器30在步骤260可比较期望和当前的应用状态数据，且在步骤255报告整个比较的结果或期望的和当前的属性值不完全相同的任何结果。在本发明一可选实施例中，期望和当前状态的快照可在运行测试用例期间完成，即，所有或部分步骤210-260可在一测试用例内多次执行。

期望和当前状态数据结构36、37的比较可在验证管理器30内完成，或者，数据结构可串行化到可扩展标记语言(XML)从而比较可用XML来完成。这样，XML可比较数据结构36、37并将结果发送到验证管理器30、测试用例20、或测试执行器。在本发明一可选实施例中，比较器35可从测试用例执行过程中去耦。该去耦可使期望和当前应用状态之间的比较在与测试用例执行不相关的时间完成。这样，期望和当前状态数据可存储到数据库或其它数据存储器中，或存储在计算机存储器内。

在本发明一示例实施例中，验证管理器30可通知各个验证结果的结果，或可仅通知期望和当前应用状态数据不同(即当失败时)的那些实例。通知有时可在测试用例已完成执行之后的某些时间进行，并可通过与测试用例完全不相关的途径进行。例如，比较器35可将验证结果通过电子邮件发送给指定联系人。

应理解，如果再次执行相同的测试用例20a-f或如果执行不同的测试用例20a-f，则不必需图3A-3B中示出的方法200的所有步骤。例如，验证管理器30可包含在比较器35中的期望状态数据结构，用于等待测试用例20。如果这样，则验证管理器30在执行测试用例20a-f之前不必从期望状态发生器32中获取期望组件状态数据。因此，每当执行测试用例20a-f时并不需要完成方法200的所有步骤。

图4是根据本发明另一实施例用于关于测试用例执行松散耦合的测试用例验证的示例系统的框图。在该另一实施例中，一个或多个测试用例20a-f可应用于应用程序10。如上所述，测试用例20a-f可以是集成测试用例或功能测试用例。一般而言，每个测试用例20a-f具有要应用于应用程序10的具有明确定义参数的明确定义激源。每个测试用例20a-f都包括要由应用程序10执行的一个或多个步骤。每个测试用例20a-f可以是应用程序10进行的一个或一系列测试。验证管理器30可包括带有期望和当前应用状态数据结构36、37的比较器35。如上所述，应理解，比较器35可与验证管理器30分开并与其通信。此外，期望状态发生器32x-z可与验证管理器30分开。期望状态发生器32可与验证管理器30通信。期望状态发生器32和验证管理器30的功能可与参照图2解释的相似或相同。可关注每个期望状态发生器32t-z的组件可以是应用程序10内的数据点。数据点可以是属性的值，且因此每个期望状态发生器32t-z可在测试用例执行之前向验证管理器30提供期望属性值。此外，期望状态发生器32可包括其它期望状态发生器32。期望状态发生器32可与验证管理器30通信。此外，期望状态发生器32可与一个或多个数据库31a-b通信，这些数据库可以是可插入组件。

例如，如果测试用例20a-f涉及用大槌击打附在门上的门把手，则期望状态发生器32x可确定附于门上的铰链的期望状态。这样，期望状态发生器32x可调用期望状态发生器32x₁以报告较低部分铰链。类似地，期望状态发生器32x可调用期望状态发生器32x₂以报告较高部分铰链。期望状态发生器32x可在确定期望状态时组合数据，并在适当时将已组合数据传送给验证管理器30。此外，如果期望状态发生器32x是要确定对附在门上的1/8英寸厚2英寸长的黄铜铰链的测试效果，则期望状态发生器32x可查询数据库31a以检索有关例如抗拉黄铜强度的信息。

在此所述的各种技术可用硬件、软件、或在适当时用两者的组合来实现。因而，本发明的方法和装置或其某些方面或部分可采取包括在诸如软盘、CD-ROM、硬盘、或任何其它机器可读的存储介质的有形介质中的程序代码(即指令)的形式，其中当程序代码由诸如计算机的机器载入并执行时，该机器变成实践本发明的装置。程序代码在可编程计算机上执行的情形中，计算装置通常包括处理器、处理器可读的存储介质(包括易失性和非易失性存储器和/或存储单元)、至少一个输入装置、以及至少一个输出装置。可例如通过使用数据处理API等利用本发明的领域专用编程模型方面的创建和/或实现的一个或多个程序，最好用高级过程或面向对象的编程语言来实现以与计算机系统通信。然而，如果需要程序也可用汇编或机器语言来实现。在任何情形中，语言可以是编译或解释语言，并可与硬件实现相组合。

尽管本发明已结合各附图的优选实施例进行了描述，可以理解可使用其它实施例或可对所述实施例作更改和添加来执行本发明的相同功能而不从其背离。在说明书中，提供了两个主要示例，一个处理假设的图形应用程序而另一个处理附在门上的门把手。这些示例是为加强理解而提供的。本发明决不限于图形应用程序或涉及附在门上的门把手的应用程序。此外，本发明一实施例可包括在涉及任何应用程序的涉及任何进程、机器、制造、合成品、程序、软件、硬件、装置、机制、或材料、或其任何改进的任何测试中。因此，本发明应不限于任一单个实施例，而应根据所附权利要求在宽度和范围内作解释。

Claims (33)

1.一种用于验证应用于应用程序的动作的多个结果的系统，其特征在于，包括

一期望状态发生器，用于计算将所述动作应用于所述应用程序的期望结果并用于更新期望应用状态；以及

一验证管理器，用于维护当前应用状态并比较所述期望应用状态和所述当前应用状态。

2.如权利要求1的系统，其特征在于，所述期望状态发生器在执行所述动作之前确定所述期望应用状态。

3.如权利要求1的系统，其特征在于，所述期望状态发生器按需确定所述期望应用状态。

4.如权利要求1的系统，其特征在于，还包括用于向所述验证管理器传送期望组件状态的期望状态发生器。

5.如权利要求4的系统，其特征在于，所述期望状态发生器在所述验证管理器外部。

6.如权利要求4的系统，其特征在于，还包括于所述期望状态发生器通信的一组件数据库，其中所述组件数据库便于所述期望状态发生器确定所述组件的所述期望组件状态。

7.如权利要求1的系统，其特征在于，还包括与用于执行所述动作的所述验证管理器通信但与之独立的一测试用例。

8.如权利要求1的系统，其特征在于，所述动作包括：

激源；以及

参数。

9.如权利要求1的系统，其特征在于，所述动作是功能测试和集成测试的至少之一。

10.如权利要求1的系统，其特征在于，还包括期望应用状态数据结构和当前应用状态数据结构。

11.如权利要求10的系统，其特征在于，所述期望应用状态数据结构包括从所述期望状态发生器接收的信息。

12.如权利要求10的系统，其特征在于，所述当前应用状态数据结构包括从所述验证管理器接收的信息。

13.如权利要求1的系统，其特征在于，所述验证管理器离线地比较所述期望应用状态和当前应用状态。

14.如权利要求1的系统，其特征在于，所述验证管理器在线地比较所述期望应用状态和当前应用状态。

15.如权利要求1的系统，其特征在于，所述期望状态发生器从数据库和网络位置的至少之一中载入。

16.如权利要求1的系统，其特征在于，所述验证管理器提供所述期望应用状态与所述当前应用状态比较的通知。

17.如权利要求16的系统，其特征在于，所述通知离线完成。

18.一种具有存储其上的数据结构的计算机可读介质，其特征在于，包括：

存储在验证管理器中的第一数据字段，包含基于要在所述应用程序上实现的动作来表示应用程序的期望应用状态的数据；以及

存储在验证管理器中的第二数据字段，包含表示在应用所述动作后所述应用程序的当前应用状态的数据，

其中所述动作由独立于所述验证管理器的测试用例定义并应用。

19.如权利要求18所述的计算机可读介质，其特征在于，多个组件装置向所述第一和第二数据字段提供有关所述应用程序的相应组件的数据。

20.一种用于验证应用于应用程序的动作结果的方法，其特征在于，包括：

存储所述应用程序的当前应用状态；

从要应用于所述应用程序的动作计算期望应用状态；

存储所述期望应用状态；

执行所述动作；

更新所述应用程序的当前应用状态；以及

比较所述应用程序的期望应用状态和所述应用程序的当前应用状态。

21.如权利要求20的方法，其特征在于，还包括创建初始当前状态的副本。

22.如权利要求20的方法，其特征在于，还包括接收期望作为将所述动作应用于所述应用组件的结果的期望组件状态。

23.如权利要求22的方法，其特征在于，所述期望组件状态存储在期望应用状态数据结构中。

24.如权利要求22的方法，其特征在于，所述期望组件状态由期望状态发生器确定。

25.如权利要求24的方法，其特征在于，所述期望状态发生器位于所述验证管理器外部。

26.如权利要求20的方法，其特征在于，还包括：

如果所述期望和当前应用状态基本上不相等则通知所述测试用例。

27.如权利要求20的方法，其特征在于，所述比较步骤使用XML来完成。

28.如权利要求20的方法，其特征在于，存储所述应用的当前应用状态在应用所述动作之后完成的步骤。

29.如权利要求20的方法，其特征在于，存储所述期望应用状态在完成所述动作之前完成的步骤。

30.一种具有计算机可执行指令的计算机可读介质，其特征在于，所述指令用于执行各步骤，包括：

从要应用于所述应用程序的动作计算期望应用状态；

执行所述动作；

确定所述应用程序的当前应用状态；以及

比较所述应用程序的期望应用状态和所述应用程序的当前应用状态。

31.如权利要求30所述的计算机可读介质，其特征在于，还具有用于执行接收期望作为将所述动作应用于所述应用组件的结果的期望组件状态的步骤的计算机可执行指令。

32.如权利要求31的计算机可读介质，其特征在于，还具有用于执行将所述期望组件状态存储在期望应用状态数据结构中的步骤的计算机可执行指令。

33.如权利要求31的计算机可读介质，其特征在于，还具有用于执行如果所述期望和当前应用状态基本上不相等则提供通知的步骤的计算机可执行指令。

Images