工作流的测试装具的自动创建和执行的制作方法

1.本公开总体上涉及用于测试工作流的方法，并且更具体地涉及用于自动创建和执行用于工作流的测试装具的方法。


背景技术：

2.工作流潜在地是用于处理数据的组件(节点)的复杂流水线。工作流通常是直接非循环图(dag)，其中组件通常由现有资源形成而不是从头构建。它们可以包括许多工作流节点，每个工作流节点由可能来自不同科学学科的许多不同的开发者和科学家实施。
3.工作流是软件程序，并且通过组件的添加、移除和修改和/或组件之间的边缘的添加和移除而演进。在这些不同进化过程中，现有组件的修改不改变工作流图。然而，修改中的错误有可能通过例如使经修改的组件或由经修改的组件产生的数据的下游消费者失败而打破图的预期处理行为。由于工作流是配置有某些选项的现有程序的组成，所以相对较小的程序集合可产生许多不同的工作流。
4.创建和维护用于所有工作流组件的测试装具的过程可能是非常耗时的，并且由于缺乏计算资源，某些测试可能不被创建或执行。这进而可能导致传播到部署环境的错误，这些错误除了其他不希望的副作用之外可能导致不稳定性和生产率的损失。


技术实现要素：

5.根据各实施例，提供了一种用于工作流的测试装具的自动创建和执行的计算设备、非暂态计算机可读存储介质和方法。
6.在一个实施例中，一种用于自动创建和执行工作流的测试装具的计算机实现的方法包括：创建包括版本标识和工作流图定义的工作流包；以及基于所述工作流包创建工作流实例。该方法可以执行工作流实例以生成输出数据。工作流实例与输出数据一起被保存为测试档案。利用测试档案测试更新的工作流包的一个或多个组件。输出更新的工作流包的测试的通过或失败的指示。
7.在一些实施例中，所述方法还包括创建包括关于每个节点的转换逻辑的信息的工作流包。
8.在一些实施例中，所述指示包括来自对一个或多个组件中的每个组件执行的每次测试的结果。
9.在一些实施例中，所述方法还包括经由以下各项中的至少一项生成工作流实例的输出数据：(a)执行从工作流的多个子图中选择的一个或多个子图以生成输出数据，以及(b)用来自先前创建的工作流实例的子图输出数据填充多个子图中的其他子图。
10.在一些实施例中，测试包括多个测试，所述多个测试包括输入数据测试、数据分级测试、执行测试和输出比较测试。
11.在一些实施例中，如果对于给定组件的多个测试中的一个测试失败，则所提供的指示是给定组件和工作流两者的失败指示。在一些实施例中，按顺序执行多个测试中的每
个测试，其中所述多个测试中的一个测试的失败结束所述测试并输出失败指示。
12.在一些实施例中，所述方法还包括将测试规范与所述测试档案相关联，其中所述测试规范定义应当将来自所述一个或多个组件的哪些输出数据添加到所述测试档案。
13.在一些实施例中，该方法还包括将测试规范与所述测试档案相关联，其中所述测试规范允许对所述测试的定制并且提供对通过和失败的定义。
14.在一些实施例中，该方法还包括允许在测试规范中使用用于一个或多个组件的所选测试的附加程序。
15.在一些实施例中，所述方法还包括基于更新的工作流包的实例重新生成测试档案。
16.根据各个实施例，一种用于自动创建和执行工作流的测试装具的计算机实现的方法包括创建工作流包，该工作流包包括工作流的一个或多个组件中的每个组件的版本标识、工作流图定义和变换逻辑。基于工作流包创建工作流实例并且执行工作流实例以生成输出数据。工作流实例与输出数据一起保存为测试档案，并且利用测试档案测试更新的工作流包的一个或多个组件。所述测试包括多个测试，所述多个测试包括输入数据测试、数据分级测试、执行测试和输出比较测试。输出更新的工作流包的测试的通过或失败的指示。按顺序执行多个测试中的每个测试，其中多个测试中的一个测试的故障结束测试并输出故障指示。
17.凭借本文所讨论的概念，提供了改进当前用于测试工作流的方法的系统和方法。本文所讨论的系统和方法可通过自动创建和执行如本文所述的测试装具来改进工作流执行的性能并减少由工作流的修改引起的回归。
18.这些和其他特征将从以下结合附图阅读的对其说明性实施例的详细说明中变得清楚。
附图说明
19.附图是示意性实施例。它们没有示出所有实施例。另外或替代地可以使用其他实施例。可省略可明显或不必要的细节以节省空间或用于更有效的说明。一些实施例可用附加的组件或步骤和/或不用示出的所有组件或步骤来实践。当相同的数字出现在不同的附图中时，它指代相同或相似的组件或步骤。
20.图1是与说明性实施例一致的工作流及其执行的表示。
21.图2是与说明性实施例一致的测试档案的创建的表示。
22.图3是示出与说明性实施例一致的用于创建和执行工作流的测试装具的输入和输出的图示。
23.图4是与说明性实施例一致的用于创建和执行工作流的测试装具的系统的流程图。
24.图5是与说明性实施例一致的在创建和执行工作流的测试装具时涉及的动作的流程图。
25.图6是与说明性实施例一致的特别配置的计算机硬件平台的功能框图说明，所述计算机硬件平台可用于实施用于创建和执行工作流的测试装具的系统。
具体实施方式
26.在下面的详细描述中，通过实例阐述了许多具体细节，以提供对相关教导的全面理解。然而，应当显而易见的是，可以在没有这样的细节的情况下实践本教导。在其他实例中，已无细节地以相对高层级描述众所周知的方法、程序、组件和/或电路，以避免不必要地模糊本教示的方面。
27.除非另有具体说明，并且从下面的描述和权利要求中可以显而易见，应当理解，贯穿本说明书，使用诸如“处理”、“计算”“计算”、“确定”等术语指的是计算机或计算系统或类似的电子计算设备的动作和/或过程，计算机或计算系统或类似的电子计算设备将被表示为计算系统的寄存器和/或存储器内的物理(诸如电子)量的数据操纵和/或变换成类似地表示为计算系统的存储器、寄存器或其他此类信息存储装置、传输或显示装置内的物理量的其他数据。
28.如本文所使用的，术语“工作流”是指有向无环图，其中节点表示计算程序、任务或变换，并且边指示工作流节点之间的依赖性。
29.如在此使用的，术语“工作流节点”是指作为工作流的一部分的应用或服务。
30.如在此使用的，术语“变换逻辑”指允许人们应用由节点定义的变换的信息。例如，变换逻辑可以是特定脚本。
31.如在此使用的，术语“组件”是指工作流图中的节点。
32.如本文所使用的，术语“测试装具”是指被配置用于通过在变化的条件下运行程序单元并且监测其行为和输出来测试该程序单元(诸如由工作流图的组件提供的脚本)的软件和测试数据的集合。
33.如在此所使用的，术语“回归”指在某个事件(通常是代码的改变)之后使特征停止如预期那样起作用的软件错误。
34.术语“回归测试”可以适用于整个测试过程以及测试过程中的一个或多个特定测试。为了清楚起见，如在此所使用的，术语“回归测试”是指确定对工作流的变化是否已经导致回归的整个过程。
35.如在此使用的，术语“工作流包”是指工作流的规范，包括其组件、连接、输入数据等。
36.如在此所使用的，术语“工作流实例”是指工作流包的特定执行并且可以包含由工作流节点的任务生成的文件。
37.如本文中所使用的，术语“束”是指文件系统目录结构，其中所需的文件、组件输出位置等是该结构内的元素，或者“束”可以是包括引用数据文件和组件输出位置的统一资源定位符(url)的文件，或者“束”可以是文件系统目录结构和url的组合。
38.如在此使用的，术语“平台”是指可以用于执行工作流的一组计算资源，如云、集群等。
39.如以下更详细讨论的，本公开总体上涉及用于定义工作流的表示及其执行的方法和系统，该工作流的表示及其执行明确地将数据(输入/输出)和变换逻辑与工作流图链接。本公开的各方面可使用该表示来自动运行工作流图中的组件的回归测试。这可以通过将特定工作流执行表示定义为回归测试档案并且将其链接到工作流定义来实现。
40.回归测试的过程可以包括针对每个工作流组件的四个测试和确保工作流语法有
效的测试。组件回归测试包括输入数据测试、数据分级测试、执行测试和输出比较测试。输入数据测试确定所有组件生产者(即，产生用于输入到正被测试的组件的数据的那些组件)是否存在以及测试数据是否在测试档案中可用于它们。该测试进一步确定所需的静态输入文件是否存在于测试档案中。数据分级测试确定给定组件所需的特定文件是否存在于测试档案中。执行测试确定该组件的当前定义是否成功地在输入数据上执行。输出比较测试可确定执行测试的输出是否匹配测试档案中的预期输出。输出比较测试可以是使用可配置的，并且可以包括一个或多个单独的子测试，从而测试输出的不同方面，诸如名称匹配、内容匹配等。工作流语法测试可以确定是否针对工作流描述语言的语法验证工作流定义。
41.本公开的各方面最初可确保工作流具有必要的表示。这些表示类似于存在于面向对象的编程中的类和实例的概念。本文描述的技术可以多种方式实现。以下参考以下附图提供示例实现。
42.参考图1，工作流包100可以包括具有工作流图定义102、版本标识104和其他可选数据的束。可选数据可包括例如工作流组件106的所需数据文件、工作流特定转换逻辑、工作流定制脚本108等。工作流实例110可以包括表示工作流包在特定平台上的实例化的束。工作流实例包括与工作流包相同的内容(包括工作流图定义102、版本标识104、工作流所需数据资源106和工作流定制脚本108)，其中添加了用户输入目录(uid)112、组件输出114的位置和关于所提供的任何可选数据的元数据。
43.当工作流包100被实例化时，工作流实例110的所得束将不包括输出数据。如果实例化之后是工作流执行，则组件输出将在它们被创建时被添加。
44.鉴于工作流及其执行具有上文关于工作流包100和工作流实例110所描述的表示，本公开的方面可包括自动回归测试。
45.工作流包100的最新版本的代表性执行工作流实例110与工作流包100相关联作为测试档案。测试档案可以可选地被压缩。此外，可以从测试档案中移除用于未被测试的、太昂贵而不能测试的、或者不需要测试的节点的数据。在一些实施例中，一旦创建了测试档案，其所引用的所有数据总是可访问的和不可变的。测试规范可以包括指示工作流包100中的哪些组件应该被测试的可选规范。
46.自动回归测试可以在每次对工作流包100进行修改时发生。对于工作流的每个测试的组件，创建唯一的工作流实例束结构，用户输入从测试档案添加到工作流实例中，并且用户重写的来自测试档案的数据文件可被添加到工作流实例中。然后，可以对工作流实例执行回归测试。
47.对于输入数据测试，对于被测试的组件的每个生产者，其数据从测试档案被添加到工作流实例中的正确输出位置。对于数据分级测试，对于每个测试的组件的定义输入，确定定义的输入存在于工作流实例中，并且在定义的输入中执行任何必要的操作，诸如复制。对于执行测试，使用指定的平台来执行组件，并且捕捉其退出状态。对于输出比较测试，将组件的输出与测试档案中的相同组件的输出进行比较。比较的类型可以是用户定义的，如全文匹配、名称匹配等，并且该比较可以仅应用于文件的子集。最后，验证整个工作流的语法。
48.在一个实施例中，每个测试都被认为是通过/失败测试。给定的测试必须在下一测试可以执行之前是通过。如果任何步骤失败，则测试阶段以失败结束。如果所有步骤都通
过，则组件通过。一旦已经测试了所有特定组件，就可以生成报告并将其作为来自系统的输出提供给用户。可以在执行步骤添加运行时间修改符，如“覆盖”。任选地，可以在输出比较测试处经由上述测试规范添加许多定制回归测试。
49.示范性实施例
50.以下描述本公开的示范性实施例，其不应被视为限制权利要求的范围。实施例描述了被称为“testify”(“测试”)的自动测试生成器，其经由被称为“flow”(“流程”)的程序利用如上所述创建的表示。该示例可以将git用于版本控制，并且将travis用于在提交时运行的自动化测试。git-commit id/hash(哈希)可被用作工作流包的版本标识。类似地，工作流实例的uid可以包括相关联的工作流包的版本。在示例中，变换逻辑采用脚本和可执行文件的形式。
51.使用例如git对工作流包目录进行版本化，其中definition.yaml是工作流图定义文件，数据文件夹保持工作流执行所需的数据，并且箱(bin)文件夹保持工作流执行所需的可执行文件。为版本va制作作为工作流包目录的克隆的目录。工作流名称-va.实例文件夹保持与工作流包目录加上附加结构相同的文件和目录，诸如保存用户提供的输入数据的输入文件夹、保存可被分组成各分级的组件特定目录中的组件输出数据的分级文件夹，并且metadata.yaml是定义与工作流的执行相关的任何元数据的元数据文件，诸如数据文件夹中的替换文件、工作流框架的自变量等。元数据文件包括执行工作流包的所有相关信息。
52.现在参考图2，工作流包版本va200参考输入执行以生成工作流实例va202。具有可选测试规范204的工作流实例va202可以作为测试档案va206。测试档案va206可以被添加到工作流包以生成工作流包vb208。测试档案va206通过插入测试所需的数据以及关于将对工作流中的组件执行的测试的一些规则来扩充工作流实例va202的文件结构。在生成初始测试档案之后，每当对工作流包定义做出改变时就重新生成测试档案，因为测试档案表示的工作流图和/或数据不再被应用。
53.参考图3和图4，工作流包vb208可以被改变或更新为新版本以生成工作流包vc300。对工作流包vb208的更新可包括例如对一个或多个组件的编程改变、一个或多个新组件的添加或一个或多个组件的删除。连续集成/连续开发过程400(例如travis)可以调用检验运行(testify-run)来为每个组件(诸如组件0402和组件1 1404)创建实例目录以生成组件0402的工作流实例vc406和组件1404的工作流实例vc408。虽然仅示出了两个组件，但是待测试的每个组件将使其自己的工作流实例vc生成。利用来自工作流包vb208的测试档案302的输入数据填充实例目录。在过程304处，针对每个组件，检验运行(testify-run)分级其数据、执行工作流实例、对照来自测试档案302的先前输出检查其新输出并且还可以执行用户提供的测试。第一输出306可包括测试结果细节，其中对于每个组件，提供每个测试运行的结果。第二输出308可以包括总体测试结果，例如，如果所有测试都通过，则为“0”，并且如果任何一个测试失败，则为“1”。在该示例中，单个测试故障将组件的测试版本vc和工作流包vc300标记为失败。如果(对于所有组件)所有测试通过，则工作流包vc被标记为成功或有效。
54.利用用于创建和执行工作流的测试装具的示例系统的前述概述，现在考虑示例过程的高级讨论可能是有帮助的。为此，图5呈现与用于创建和执行工作流的测试装具的方法相关的说明性过程500。过程500在逻辑流程图中被示为块的集合，其表示可以在硬件、软件
或其组合中实现的操作序列。在软件的上下文中，这些框表示计算机可执行指令，这些指令在由一个或多个处理器执行时执行所叙述的操作。通常，计算机可执行指令可以包括执行功能或实现抽象数据类型的例程、程序、对象、组件、数据结构等。在每个过程中，描述操作的顺序不旨在被解释为限制，并且任何数量的所描述的框可以按任何顺序组合和/或并行执行以实现该过程。
55.参照图5，用于创建和执行工作流的测试装具的过程500包括创建工作流包或选择现有工作流包的动作510，工作流包包括工作流定义和输入数据。在动作520，测试装具引擎可创建工作流的工作流实例。工作流实例可包括工作流包的元素，以及执行特定的输入数据和元数据，和工作流组件输出数据。在动作530处，测试档案可以由测试装具引擎通过用输入数据执行工作流实例来创建。在动作540，当工作流包被测试装具引擎改变或更新为新版本时，工作流包的新版本中的每个组件可使用参考输入的测试档案进行测试。在动作550，由测试用装具引擎提供测试结果的输出。
56.工作流的一些改变可能需要创建新的测试档案。在一些实施例中，可以通过执行工作流的新版本来创建新的测试档案。在其他实施例中，可以通过仅执行受工作流中的修改影响的工作流的子图来创建新的测试档案。例如，测试装具引擎可以创建新工作流的工作流实例。对于不受修改影响的组件(诸如不是经修改节点的输出的最终消费者节点的组件)，测试装具引擎从现有测试档案复制其输出。对于添加或修改的组件或其消费者节点，访问被给予所需的执行资源，并且测试引擎执行源自这些组件的工作流的子图。在工作流中的经修改的组件的情况下，执行可限于其修改导致它们未通过回归测试的那些组件。这些执行的输出被放置在新的工作流实例中。测试引擎可从新实例创建新的测试档案。
57.图6提供计算机硬件平台600的功能框图图示，所述计算机硬件平台600可用于实现可托管测试装具创建和执行引擎650的特定配置的计算装置。如上所述，测试装具创建和执行引擎650可包括表示创建模块652、测试模块654和输出模块656。
58.计算机平台600可以包括连接到系统总线616的中央处理单元(cpu)602、硬盘驱动器(hdd)604、随机存取存储器(ram)和/或只读存储器(rom)606、键盘608、鼠标610、显示器612以及通信接口614。
59.在一个实施例中，hdd604具有包括存储程序的能力，该程序能够以本文所述的方式执行各种处理，诸如测试装具创建和执行引擎650。
60.结论
61.本传授内容的不同实施例的描述是出于说明的目的而呈现的，但不旨在是详尽的或限于所披露的实施例。在不背离所描述的实施例的范围和精神的情况下，许多修改和变化对本领域的普通技术人员而言将是显而易见的。选择在此使用的术语以最佳地解释实施例的原理、实际应用或在市场上找到的技术上的技术改进，或使得本领域普通技术人员能够理解在此披露的实施例。
62.虽然前面已经描述了什么被认为是最佳状态和/或其他示例，应当理解，可在其中做出不同修改，并且本文所公开的主题能够以不同形式和示例来实现，并且该教导可以应用于许多应用中，这里仅描述了其中一些应用。所附权利要求旨在要求保护落入本传授内容的真实范围内的任何和所有应用、修改和变化。
63.在此已经讨论的组件、步骤、特征、目的、益处、以及优点仅是说明性的。它们中的
任何一个，以及与它们相关的讨论都不旨在限制保护范围。虽然本文已经讨论了各种优点，但应当理解，并非所有实施例都必须包括所有优点。除非另外说明，否则在本说明书中(包括在随后的权利要求书中)阐述的所有测量值、值、评级、位置、量值、大小和其他规格都是近似的，不是精确的。它们旨在具有与它们相关的功能以及它们所属领域的惯例一致的合理范围。
64.还构想了众多其他实施例。这些包括具有更少、附加和/或不同的组件、步骤、特征、对象、益处和优点的实施例。这些还包括其中组件和/或步骤被不同地安排和/或排序的实施例。
65.本文中参考根据本发明的实施例的方法、设备(系统)和计算机程序产品的流程图说明和/或框图来描述本发明的方面。应当理解，流程图和/或框图的每个方框以及流程图和/或框图中各方框的组合，都可以由计算机可读程序指令来实现。
66.这些计算机可读程序指令可以被提供给适当配置的计算机的处理器，专用计算机或其他可编程数据处理装置，以产生机器，其通过计算机或其他可编程数据处理装置的处理器执行，创建用于实现在流程图和/或方框图的一个或多个方框中指定的功能/动作的装置。这些计算机可读程序指令还可存储在可指导计算机的计算机可读存储媒质中，可编程数据处理装置，和/或以某种方式起作用的其他设备，使得具有存储在其中的指令的计算机可读存储媒质包括制品，该制品包括实现流程图和/或框图中的一个或多个方框中规定的功能/动作的各方面的指令。
67.计算机可读程序指令还可以加载到计算机、其他可编程数据处理装置上，或使得在计算机上执行一系列操作步骤的其他装置，其他可编程装置或其他设备，以产生计算机实现的过程，使得在计算机上执行的指令，其他可编程装置或其他设备实现流程图和/或框图中的一个或多个方框中规定的功能/动作。
68.本文中附图中的调用流程、流程图和框图示出了根据本公开的不同实施例的系统、方法和计算机程序产品的可能实现的架构、功能和操作。对此，流程图或框图中的每个方框可以代表模块、段或指令的一部分，其包括用于实现规定的逻辑功能的一个或多个可执行指令。在一些替代实现方式中，框中所标注的功能可以不按图中所标注的顺序发生。例如，取决于所涉及的功能，连续示出的两个框实际上可以基本上同时执行，或者这些框有时可以以相反的顺序执行。还将注意的是，框图和/或流程图中的每个框、以及框图和/或流程图中的框的组合可以由基于专用硬件的系统来实现，所述基于专用硬件的系统执行指定的功能或动作或执行专用硬件与计算机指令的组合。
69.虽然已经结合示范性实施例描述了前述内容，但应理解的是，术语“示范性”仅旨在作为实例，而不是最佳或最佳的。除了如上刚刚陈述的，任何已陈述或示出的内容都不旨在或应被解释为引起任何组件、步骤、特征、对象、益处、优点或等效物专用于公众，而不管其是否在权利要求书中陈述。
70.应当理解，本文中所使用的术语和表达具有普通含义，就其相应的查询和研究的相应领域而言，与这些术语和表达相一致，除非本文另外阐述了具体含义。诸如第一和第二等关系术语可仅用于将一个实体或动作与另一个实体或动作区分开，而不一定要求或暗示此类实体或动作之间的任何实际此类关系或次序。术语“包括(comprises)”、“包含(comprising)”或其任何其他变体旨在覆盖非排他性的包含，这样使得包括一系列要素的
过程、方法、物品或装置不仅包括那些要素，而且可以包括未明确列出的或此类过程、方法、物品或装置固有的其他要素。在没有进一步限制的情况下，由“一个(a)”或“一种(an)”开始的元件不排除在包括该元件的过程、方法、物品或设备中存在额外的相同元件。
71.提供本公开的摘要以允许读者快速确定本技术公开的性质。应理解的是，它将不用于解释或限制权利要求的范围或含义。此外，在前述具体实施方式中，可以看到，为了使本公开流畅的目的，在各种实施方式中将各种特征组合在一起。本披露的这种方法不应被解释为反映所要求的实施例具有比每个权利要求中明确叙述的特征更多的特征的意图。相反，如以下权利要求所反映的，本发明的主题在于少于单个公开的实施例的所有特征。因此，以下权利要求由此并入具体实施方式中，其中每个权利要求独立地作为单独要求保护的主题。