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

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

【技术实现步骤摘要】

本专利技术涉及用于测试应用的软件，尤其涉及在这种测试软件中期望和实际结果的松散耦合比较。
技术介绍
软件开发生命期中的主要阶段是设计阶段、编码阶段、代码完成阶段、α阶段、β阶段，以及最后向市场发行。在设计阶段期间，将解决软件产品的客户问题并定义软件产品的功能。通常，功能说明书的完成标志着设计阶段的结束。编码阶段已经开始。当代码写成但尚未调试时则进入代码完成阶段。α阶段标记产品稳定的时间点；即，已发现了大部分的主要缺陷。在β阶段，产品几乎没有了所有的主要缺陷；即所剩的缺陷应基本上无害。当产品通过最终的质量保证检查列表时，它已准备就绪向市场发行。因为没有人想要不工作的软件，测试是生命期的重要部分并可跨越若干阶段。软件测试包括设计一测试用例(或更可能是测试用例集)、以测试用例为输入运行该软件、并检查以测试用例为输入的软件的性能是否产生预期结果。软件测试可由人类手动引导，或通过程序来引导(称为自动化软件测试)。理想地，软件的测试在软件生命期的一开始就应开始。然而一般而言，不到完成了设计阶段软件根本不能测试，因为直到完成设计阶段才能确定期望结果。通常，在编码阶段，开发者在写代码时手动测试其代码。自动化软件测试通常在开发过程的较后期才会开始。有时，所引导的唯一测试由开发者在他编写程序时手动测试来完成。测试自己工作的开发者可能会忽视在情绪上不那么投入代码的某些人会发现的缺陷。此外，开发者测试的范围通常限于其代码的功能以及其代码与有限数量的其它软件应用程序的结合的代码。为了解决这些缺点，许多软件开发机构具有常使用至少部分自动化的测试技术来测试软件的独立的软件测试组。通常，测试组通过编写和运行测试用例来测试各特征之间和应用程序之间的复杂交互。使测试组及早地甚至在设计阶段就进入产品生命期能获得很多好处通常是无异议的，这些好处包括标识功能说明书中的不一致、标识难以测试的区域及其它。然而一般而言，面对特征定义、实现和用户界面(UI)调整中的持续变化而保持每个测试用例最新所需的努力使该方法呈现为不实用。因此，编写并运行测试用例通常是在产品开发末期仓促发生的。因而测试特别是自动化测试总是落后于需求。如果有一种在一进入软件产品的生命期(理想地是在设计阶段期间)就能编写测试用例并采用自动化测试的方法将是有帮助的。一整套测试用例的开发在任何时候都具挑战性。为了测试应用程序的特定特征，必需编写许多测试集。例如，应用程序可允许与一特征的许多交互模式通过鼠标、键盘、数字化仪、可访问软件、通过程序等。因此，为了提供对该特征的综合性测试，一整套测试应包括通过鼠标与该特征交互(像用户一样键入文本)的一个测试集、通过键盘与该特征交互的一个集、通过数字化仪与该特征交互的一个集、通过可访问软件与该特征交互来调用缺省动作并以其它方式模拟可访问应用程序的一个集、通过应用程序的编码模型与该特征交互的一个集等。如果有一种确保一整套生成的测试用例提供特征或应用程序的综合性测试，并进一步减少为了提供综合性测试而必需编写的测试用例的总量的方法，这将是有帮助的。此外，这些测试集的每一个中的许多或全部逻辑都与其它测试集中的逻辑相同，且通常许多或全部的结果处理验证也相同。因此，许多测试是相同或非常接近的，仅仅在执行选项上有变化。例如，对于上述全部多种形式的输入，期望结果可能是相同的。因此，对这些输入源的每一个编写测试用例通常需要编写用于执行每个输入源的测试的独立方法，并复制大多数剩余的测试脚本。重复编写仅具有极小变化的相同测试是乏味并耗时的。如果有一种消除或大大减少这种重复编码并减少必需编写的测试用例的总量的方法将是有帮助的。编写用来确定运行测试用例的实际结果是否与期望结果相一致(常称为结果验证或验证)的代码常包括在测试用例内。改变特定结果验证的细节或添加新的结果验证通常需要更改每个测试用例。如果验证代码独立于测试用例，使该测试用例更易于理解以及验证代码更易于重复使用和维护将是有帮助的。执行细节常被硬编码到测试用例中，需要设计阶段在编写测试用例之前就完成。如果有一种根据用户动作而不根据特定执行细节来定义测试用例使得测试用例能在软件开发生命期的较早期编写的方法，这将是有帮助的。测试应用程序是应用程序的初始开发的重要步骤，当实现对该应用程序的更改时，测试应用程序也是非常重要的。软件应用程序开发者、科学家、厂商在应用程序开发的测试阶段投入了大量精力。这样的测试有助于确保应用程序以期望方式响应于特定激源。测试通常通过执行测试用例并验证测试用例执行的结果来完成。通常测试用例在应用程序上施加一激源(stimulus)。测试用例还应验证应用程序以期望方式响应而不以非期望方式响应。为了较为综合，测试应验证整个应用程序状态的大部分，以确保激源导致期望结果而无非期望结果。通常测试用例是为了测试应用程序的特定功能或方面而执行的。类似地，测试用例结果的验证可集中于要测试的功能。然而。测试用例的执行可影响或改变应用状态的其它方面。这些方面看起来会与测试用例的目的没什么关系。这些无甚关系方面有很多，且对测试者而言开发要量化或指定所有甚至大部分方面的测试用例是困难的。编写要验证大部分应用程序状态的测试用例代码已证实因各种原因而有问题。即使对于相对简单的应用程序，仍然可能需要大量的测试用例来综合性地测试该应用程序。将冗长且详细的验证代码添加到每个测试用例中将是令人畏惧的(如果不是难以胜任的)任务。此外测试用例维护通常与测试用例创建一样地(如果不是更多)劳动密集和耗时。当改变应用程序时，应改变测试用例以及验证代码以确保与应用程序的兼容性。将冗长且全面的验证代码添加到每个测试用例中将使得这种维护不实用(如果不是不可能的话)。因此，需要综合性地验证应用于应用程序的测试用例的结果，而无需对每个测试用例编写冗长的、单调的和耗时的验证代码。还需要对需要测试者最少的显式动作来设置、执行、或维护的验证。
技术实现思路
测试用例实现的验证可与测试用例分开并由专用的验证管理器来完成。测试用例可能不需要包括任何验证并且实际上测试者甚至不需要知道在执行的所有验证。验证管理器可用来验证一个或多个测试用例，从而每个测试用例可执行一动作而无需提供该动作结果的特定验证。使用专用的验证管理器，验证可更为综合。使用一个较大的期望状态发生器库，验证管理器可更为综合地验证测试用例的结果。对于应用程序的各个独立和不同组件，可集中于包含在该库中的每个期望状态发生器。一个期望状态发生器可集中于测试者具体对于测试用例目的而考虑的应用状态的一方面。第二个期望状态发生器可集中于测试者与测试用例的目的不太相关或无关地考虑的应用程序的一方面。因此，与仅具有包括在测试用例中的集中验证相反，该库可使能对所有测试用例的广泛验证。验证管理器可通过比较指定应用程序属性的期望值和那些相同属性的实际值来验证测试用例结果。在进行比较的过程中，验证管理器将能确定当前和期望应用状态基本上不相符的实例。最后，验证管理器可将任何测试失败传送给测试用例、测试用例执行器、或任何其它指定实体。可完成验证过程使得测试用例甚至不知道例如在测试用例调用图形应用程序绘制蓝色长方形时已验证了文件菜单上按键的状态。在获取该综合性验证的过程中，测试者除执行具有适当参数的动作之外不需要其它动作本文档来自技高网...

【技术保护点】
一种用于验证应用于应用程序的动作的多个结果的系统，其特征在于，包括一期望状态发生器，用于计算将所述动作应用于所述应用程序的期望结果并用于更新期望应用状态；以及一验证管理器，用于维护当前应用状态并比较所述期望应用状态和所述当前 应用状态。

【技术特征摘要】
...

【专利技术属性】
技术研发人员：AM乌尔里希，MD加拉赫，MJ亨特，
申请(专利权)人：微软公司，
类型：发明
国别省市：US[美国]