用于促进自动化程序测试的方法和系统的制作方法
【专利摘要】促进自动化程序测试。获得基于程序执行一个或多个测试而生成的测试结果，其中，基于根据程序执行测试而获得的输出，测试通过或失败。标识测试结果的失败输出，所述失败输出来自于包括至少一个命令的失败测试，并且所述失败输出基于执行所述至少一个命令而获得。基于所述失败测试自动生成修改测试，提供所述修改测试用于由所述程序执行以促进所述程序的测试。所述修改测试包括所述失败测试的所述至少一个命令，并且所述修改测试基于获得所述失败测试的所标识的失败输出而通过。
【专利说明】用于促进自动化程序测试的方法和系统
【技术领域】
[0001]本发明涉及用于促进自动化程序测试的方法和系统。
【背景技术】
[0002]在用于测试软件程序的自动化软件测试环境中，典型地，每日运行几千次测试。测试可包括一个或多个命令、以及从这些命令的执行而得到的预期或非预期的输出。在测试脚本中可以组合并包含一个或多个测试，并且程序的执行遵从测试脚本中布置的测试。测试的执行是自动化的，并且执行测试的结果是通过或失败，所述通过或失败由是否获得指定的预期(或非预期)输出而确定。在执行测试之后，典型地，分析测试失败，然而，这经常是资源的低效花费。
【发明内容】
[0003]通过提供用于促进自动化程序测试的方法，克服了现有技术的缺点并提供了额外的优点。所述方法例如包括:获得基于程序执行一个或多个测试而生成的测试结果，其中，基于根据程序执行测试而获得的输出，测试通过或测试失败；标识测试结果的失败输出，所述失败输出来自于所述一个或多个测试的失败测试，所述失败测试包括至少一个命令，并且所述失败输出基于执行所述至少一个命令而获得；以及基于所述失败测试，通过处理器自动生成修改测试，所述修改测试用于由所述程序执行以促进所述程序的测试，并且所述修改测试包括所述至少一个命令，其中，所述修改测试基于获得所述失败测试的所标识的失败输出而通过。
[0004]另外，提供了一种用于促进自动化程序测试的计算机系统。所述计算机系统包括:存储器；以及与所述存储器通信的处理器，并且所述计算机系统例如配置为执行:获得基于程序执行一个或多个测试而生成的测试结果，其中，基于根据程序执行测试而获得的输出，测试通过或测试失败；标识测试结果的失败输出，所述失败输出来自于所述一个或多个测试的失败测试，所述失败测试包括至少一个命令，并且所述失败输出基于执行所述至少一个命令而获得；以及基于所述失败测试自动生成修改测试，所述修改测试用于由所述程序执行以促进所述程序的测试，并且所述修改测试包括所述至少一个命令，其中，所述修改测试基于获得所述失败测试的所标识的失败输出而通过。
[0005]此外，提供了 一种用于促进自动化程序测试的计算机程序产品。所述计算机程序产品包括计算机可读存储介质，所述计算机可读存储介质可由处理器读取并存储用于由处理器运行以执行以下方法的程序代码，所述方法例如包括:获得基于程序执行一个或多个测试而生成的测试结果，其中，基于根据程序执行测试而获得的输出，测试通过或测试失败；标识测试结果的失败输出，所述失败输出来自于所述一个或多个测试的失败测试，所述失败测试包括至少一个命令，并且所述失败输出基于执行所述至少一个命令而获得；以及基于所述失败测试自动生成修改测试，所述修改测试用于由所述程序执行以促进所述程序的测试，并且所述修改测试包括所述至少一个命令，其中，所述修改测试基于获得所述失败测试的所标识的失败输出而通过。
[0006]通过本发明的概念而实现额外的特征和优点。这里详细描述本发明其他实施例和各方面，并且本发明其他实施例和各方面被认为是要求保护的发明的一部分。
【专利附图】
【附图说明】
[0007]本发明的一个或多个方面在权利要求中具体指出并且作为示例而明确要求保护。从下面结合附图而进行的详细描述，本发明的前述和其他目的、特征和优点将变得明显，附图中:
[0008]图1描绘合并和使用本发明一个或多个方面的数据处理系统的一个示例；
[0009]图2描绘用于程序的自动化测试的、包括多个测试的示例原始测试脚本；
[0010]图3描绘基于运行图2的原始测试脚本而获得的测试结果的一部分，所述测试结果包括失败测试的失败输出；
[0011]图4描绘通过重运行原始测试脚本的失败测试而获得的测试结果；
[0012]图5描绘根据本发明一个或多个方面的、用于生成修改测试的处理的一个示例；
[0013]图6描绘根据本发明一个或多个方面的示例修改测试；
[0014]图7描绘根据本发明一个或多个方面的、基于运行图6的修改测试而获得的测试结果的一部分；
[0015]图8描绘根据本发明一个或多个方面的、包括图6的修改测试和初始测试的测试脚本的一个示例；
[0016]图9描绘根据本发明一个或多个方面的、基于运行图8的测试脚本而获得的测试结果的一部分；
[0017]图10描绘根据本发明一个或多个方面的、包括图6的修改测试和多个额外测试的测试脚本的另一示例；
[0018]图11描绘根据本发明一个或多个方面的、基于运行图10的测试脚本而获得的测试结果的一部分；
[0019]图12描绘根据本发明一个或多个方面的、用于促进自动化程序测试的方法的一个示例；以及
[0020]图13描绘合并本发明一个或多个方面的计算机程序产品的一个实施例。
【具体实施方式】
[0021]对于看起来表现被测试的软件中的真实程序缺陷(bug)的测试失败，可能期望确定将重建特定失败的步骤。重建特定失败的能力可以提供在开发针对问题的修补(fix)中有用的信息，并用于验证这些修补适当地解决问题。因此，期望用于重建测试失败的有效工具以促进自动化程序测试。
[0022]测试失败的重建可以如重发失败命令一样简单，但是有时情况并非如此。经常地，测试失败的重建是复杂得多的任务，特别是当不能可靠或一致地重建失败(如果能重建的话)时更是如此。许多测试失败实际上在这些极端之间，需要某些设置来创建触发特定失败所需的条件。标识测试失败最接近于哪种极端很大程度上是基于运气的，主要包括通过程序测试者猜测可能如何重建失败，并且经历枯燥的反复试验的过程。在寻求可能的重建时可能花费很多时间。因为在获得失败结果之前可能已经发生很多事件(在测试脚本的执行期间的测试途中)，所以，简单地重放整个测试脚本直到失败点为止，这可能是低效、无助因而是不期望的。这耗费时间并且对于例如开发者是不方便的，如果他/她必须遵循惊人的长的过程来标识真实问题的话。因此，期望标识用于演示失败的最小“方式(recipe)”。“最小”指重建失败输出的相对较小的测试集合(与失败之前的整个测试相比)，而不是例如重建失败输出所需的刚好最小的活动(如例如最小键击)。
[0023]根据本发明各方面，使用原始测试结构的自动化程序测试产生示出通过自动化测试驱动的活动、并强调失败测试的失败输出(如果存在)的输出文件。失败输出被修订为失败测试的修改版本的预期输出。此修改测试情况定义为仅当获得(来自失败测试的)失败输出时才通过。因此，此修改测试是在通过原始测试结构所建议的方式中的子集(在继续下去的(follow-on)测试脚本中)，并且子集测试脚本用于尝试失败的重建。以预定顺序进行尝试，在最小重建差错的期望和验证重建可能的需求之间平衡。所有上述都可以是自动化的。
[0024]图1描绘了合并和使用本发明一个或多个方面的数据处理系统的一个示例。数据处理系统100可以基于例如由纽约阿芒克的国际商业机器公司提供的xSeriesF—或
pSeries?架构(xseries?和pSeries?是纽约阿芒克的国际商业机器公司的注册商标)或基于因特尔公司的x86架构。
[0025]数据处理系统100适于存储和/或执行程序代码，并且包括通过例如系统总线120与存储器104直接或间接耦合的至少一个处理器102。在操作中，处理器102从存储器104获得一个或多个指令，用于由所述处理器执行。存储器104可包括在程序代码的实际执行期间使用的本地存储器、大容量存储体、以及提供至少某些程序代码的临时存储以便减小在程序代码执行期间必须从大容量存储体取回代码的次数的高速缓存。存储器104的示例的非限制列表包括硬盘、随机存取存储器(RAM)、只读存储器(ROM)、可擦除可编程只读存储器(EPR0M或闪存)、光纤、便携式致密盘只读存储器(CD-ROM)、光学存储设备、磁存储设备、或上述的任何适当组合。存储器104包括操作系统105和一个或多个计算机程序106。
[0026]输入/输出(1/0)设备112、114 (包括但不限于键盘、显示器、指向设备等)可直接或通过1/0控制器110耦合到所述系统。
[0027]网络适配器108也可耦合到所述系统以使得数据处理系统变为能够通过中间的私人或公共网络耦合到其他数据处理系统或远程打印机或存储设备。调制解调器、电缆调制解调器和以太网卡仅仅是当前可用的类型的网络适配器108中的一些。
[0028]数据处理系统100可耦合到具有一个或多个数据库的存储体116(例如，非易失性存储区域，如磁盘驱动、光盘驱动、带驱动等)。存储体116可包括内部存储设备或附接的或网络可访问的存储体。存储体116中的计算机程序可加载到存储器104中并由处理器102以本领域已知的方式执行。
[0029]数据处理系统100可包括比图示更少的组件、这里未图示的额外的组件或图示的组件与额外的组件的某些组合。数据处理系统100可包括本领域已知的任何计算设备，如大型机、服务器、个人计算机、工作站、膝上型计算机、手持计算机、电话设备、网络设备、虚拟化设备、存储控制器等。
[0030]在一个示例中，数据处理系统100执行计算机程序106，其包括测试工具(其自身可以是计算机程序)，如CHUG测试工具(“CHUG”，可从美国纽约阿芒克的国际商业机器公司获得)。CHUG利用测试脚本以接收测试并确定测试是否通过。单独测试包括一系列记录，所述记录包括用于由测试的计算机程序执行的命令，如仿真由人类对键盘打字以将命令输入测试的程序而调用的命令的命令。单独测试还包括预期和/或非预期输出和各种测试控制功能。当与脚本中所指示的输出预期相违背时，所述违背出现的单独测试失败。
[0031]典型地，许多单独测试被分组为单个测试文件(脚本)，并且这些测试文件集中并以层次执行(如较大测试脚本的一部分)。CHUG工具的测试文件已知为HATT文件，并且按组安排的单独测试的开始通过以“H”开始的线而划界。每个H:组因此可以被认为是单独测试，并且多个H:组可以包括在称为测试脚本的测试的较大集合中。
[0032]测试遵循测试脚本的H:组的顺序。每个H:组与其他H:组独立地通过或失败。然而，因为测试连续执行，所以由在先H:组的执行而出现的情况可能影响在后H:组的通过或失败。因此，测试者可以在测试脚本的开始(如第一个或前两个测试中)布置重要的设置活动。
[0033]CHUG测试工具生成并输出测试结果。在一个示例中，输出是HTML格式。HTML输出通过测试(即，H:组)来表示，其中，显示测试输入信息(从HATT文件测试脚本复制)、之后是所述测试的逐行结果。HTML输出中的CHUG命令典型地以蓝色呈现，此后是调用命令之后输出的屏幕截图。因此，为了方便，测试脚本(在此情况下的HATT文件)可以从HTML结果文件重构(如果期望的话)。下面描述的本发明各方面(如修改测试的生成)利用了这一点。
[0034]图2描绘了包括用于程序的自动化测试的多个测试的示例原始测试脚本。在图2中,测试脚本是HATT文件的形式。测试脚本200包括至少六个顺序测试，每个的开始由H:记录标识。这些测试中的三个在图2中示出:第一测试202，对应于标记为“H:1初始设置”的第一 H:组；第五测试204，对应于标记为“H: 5DMSQEFL和DMSQSFSL测试”的第五H:组；以及第六测试206，对应于第六H:组“H:6CMSLEVEL测试”。在第一测试202和第五测试204之间为第二、第三和第四测试(未示出)。测试脚本200可包括顺序在第六测试206之后的额外测试。测试的每行称为记录。例如，第一测试202包含标识测试的开始的H:记录、C:记录(对应于命令)以及E:记录(指示预期输出)。
[0035]如所示，在后测试可能依赖于在先测试，如来自在先测试的设置命令。测试202(序列中的第一测试)包括若干由C:记录标记的命令。两个这样的命令包括定义标识为IFlF的临时盘的命令202a、以及格式化所创建的临时盘IFlF的命令202b。对于第一测试202的这些命令的每个的依赖性存在于第六测试206中。此外,在第五测试204中，命令204a和204b包括链接和访问命令，其链接保持程序DMSTESTS (刚刚使用过)和称为QLEVEL的程序(在在后测试206中引用)的盘。因此，第六测试206依赖于第五测试204的命令204a和204b，因为第六测试206引用QLEVEL程序(206b)。第六测试206还依赖于第一测试202。具体地，第六测试206的命令206a访问临时盘1F1F，并且命令206c调用称为CMSMAC的程序，其在由第一测试202定义的临时盘上。
[0036]第六测试206还包括预期输出206d。预期输出由“E: ”记录标记，并且测试206的预期输出是“CMS级207，服务级000”。如果作为执行测试206的结果获得此预期输出，则测试206通过。如果获得预期输出以外的输出，则测试206失败。测试206的失败在图3中示出。[0037]图3描绘基于运行图2的原始测试脚本而获得的测试结果的一部分。在此情况下，测试206 (图2)已经失败，并且测试结果包括失败测试206的失败输出。参照图3，在测试结果300中报告失败。当执行测试206时，尤其是执行命令206c (C:CMSMAC)时，获得失败输出302。输出302是由于在作为从执行命令206c所获得的输出的输出302与从此命令的执行而预期的预期输出之间的失配而造成的失败输出。虽然测试206的预期输出是“CMS级207，服务级000”(见图2的206d)，但是基于执行测试206实际获得的输出是输出302的四行。测试结果300以黑体文本304指示此失败。
[0038]当测试者知晓失败测试时，一种方法是自己简单地重运行原始失败测试。图4示出通过重运行来自图2的原始测试脚本的失败测试而获得的测试结果。图4的测试结果表示了简单重运行失败测试的问题。测试结果400指示:测试206再一次基于输出失配而失败。测试者可能倾向于得出成功重建问题的结论，因为获得了失败。然而，没有重建原始失败的确切的原因(图3)。在图4中，所获得的失败输出402指示未知CP/CMS命令。这是符合逻辑的，因为如上所述测试206对于测试202的依赖性，CMSMAC程序驻留在原始测试脚本的测试202中创建的临时盘上。获得图4的失败输出402的原因是因为如所预期的CMSMAC程序对于正测试的程序是未知的，因为测试202没有执行以创建CMSMAC程序所驻留的临时盘。因此，在后测试206的通过/失败至少部分依赖于测试202的设置命令202a和202b。此外，从图4所获得的失败输出与在先失败(图3的302)是完全不同的，在于CMSMAC程序可用，但是获得不同失配输出。因此，当自己执行测试206时已经创建了测试206的新的(不同的)失败，而没有获得原始的失败。
[0039]有效程序测试的重要方面是利用失败出现所需的条件的最小集合精确重建失败的能力。当以失败出现所需的条件的最小集合精确重建失败时，在开发消除失败的封装时，标识并针对这些条件。
[0040]根据本发明各方面，通过用于演示失败的最小条件的有效标识来促进自动化程序测试。获得来自于测试脚本的执行的测试结果，此测试结果包括由测试脚本的测试的执行而得到的失败输出。生成失败测试的修改版本。生成失败测试的修改版本，使得仅当在执行修改测试之后获得所获得的失败输出时修改测试才通过。因此，当且仅当重建并获得精确失败时修改测试才通过。迭代重测程序，其中，提供具有修改测试和选择的额外测试的测试脚本，用于由程序在每次迭代时执行。当修改测试通过时，已经重建失败。
[0041]图5描绘了根据本发明一个或多个方面的用于生成修改测试的处理的一个示例。处理通过复制直到失败测试的失败点为止的失败测试的记录而开始(502)。失败点是测试失败的失败测试点(例如，仅接在使得获得失败输出的命令之后的点)。接下来，当执行失败测试时获得的失败输出被添加作为修改测试的预期输出(504)。如所示，测试的预期输出是基于此测试的执行预期要接收的输出，因此指示测试通过所需要的输出。
[0042]接下来，在506，确定失败点是否是失败测试的预期输出。预期输出是当执行测试时预期要接收的输出。这与非预期输出相对，所述非预期输出是执行测试时预期不会接收的输出。指示非预期输出的记录意味着，为了测试通过必须不能接收所指示的非预期输出。查询506的目的在于区分因为获得禁止(非预期)输出而失败的失败测试的情况、以及因为所获得的输出是指定的预期输出以外的输出而失败的失败测试的情况。如果在506确定失败点不是失败测试的预期输出(即，替代地，其是非预期输出，508)，则处理结束。[0043]然而，如果在506替代地确定失败点是失败测试的预期输出，则失败点处失败测试的预期输出被添加作为修改测试的非预期输出(510)。当失败点处失败测试的预期输出添加为修改测试的非预期输出时，确保仅当以下为真时修改测试通过:(i)获得失败测试的失败输出(通过504添加的E:记录确定)以及(ii)未获得失败测试的预期输出(通过510添加的N:记录确定)。
[0044]此后者条件是重要的添加。测试可能生成很多输出，其中仅仅某些输出在确定成功或失败方面是有意义的。如果当通过运行修改测试而重测程序时，获得来自原始测试的失败输出，但是来自原始测试的预期输出碰巧也出现，则修改测试将通过。然而，在此情况下，还没有精确重建失败，因此修改测试的通过将不正确地指示已经重建了失败。为了说明，假设正测试的程序是要打印标准的26个字母的英文字母表，并且测试验证每个字母的出现。原始测试因此将包括所有26个字母的预期输出。假设测试由于获得了除“G”以外的所有字母而失败，即，失败输出是其他25个字母的每一个。修改测试的生成会将失败输出(所有其他25个字母)添加为修改测试的预期输出(504)。假设原始测试的预期输出(即，所有26个字母的输出)没有添加作为非预期输出(即，假设图5的处理不包括510)。因此，如果运行修改测试，则程序生成字母表的所有26个字母，因为获得预期输出(所有其他25个字母)(同样，也获得“G”)所以修改测试将通过。然而，没有重建“G”不存在的精确的失败。即，来自原始测试的失败输出将不包括“G”，但是从运行修改测试的输出而出现的“G”(在上述情景中，其将通过)不正确地指示重建了精确失败。
[0045]为了处理上面所述的问题，“G”不是(来自修改测试的执行的)输出的一部分的条件应当包括在修改测试中。因此，包括失败测试的预期输出(所有26个字母的集合)作为修改测试的非预期输出(即，图5的510)解决了这一点。当尽管观测到原始失败输出(所有其他25个字母)、但是也观测到原始预期输出(所有26个字母，包括“G”)时，修改测试应当并且将失败(并且指示没有精确重建原始失败)。
[0046]图6描绘了从图5的处理创建的修改测试的示例。使用来自之前的图的示例，其中测试是H:组，修改测试的生成通过复制直到失败点为止的设置、然后在失败点添加所获得的失败输出作为预期输出而生成了修改H:组。然后，如果失败点是E:(“预期”)记录，则其改为N:(“非预期”)记录并添加到修改测试。否则，即，失败点是N:(“非预期”)记录，不需要其他行动来生成修改测试。因此，在失败测试206是失败H:组的上面的示例中，在图6的修改测试600中，失败测试6 (206图2)的H:、D:和C:记录被复制直到测试206的失败点。失败点是从执行测试所获得的输出失败的E:或N:记录。测试仅能失败一次，因为对于测试的测试在失败点停止。在测试206的情况下，失败点是E:记录206d。
[0047]然后，预期输出添加到修改测试600以需要失败输出的出现。因此，失败输出(图3的302)添加为修改测试的预期输出(S卩，添加了 E:记录602)。注意，某些失败输出分量(如日期或时间标记)被识别并作为通配符(wildcarded)。在此示例中，失败输出302 (图3)包括时间标记302a。日期和时间标记通常包括在输出中以指示(失败)输出的时间并通常在重建失败方面不重要。因此，在生成修改测试600 (图6)中，来自执行测试206的失败输出被作为预期输出602添加到修改测试，但是来自失败输出302的时间标记302a使用“$”字符而通配符为修改测试600中的602a (图6的602a)。
[0048]最后，因为测试206的失败点是E:记录(预期输出)，所以将此预期输出作为非预期输出(N:记录604)而添加到修改测试600，指示为了修改测试通过，必须不能观测到失败点处的失败测试的预期输出。
[0049]如上所述，利用修改测试以重测程序，而尝试重建为重建精确误差所需的最小条件。当且仅当作为执行修改测试的结果而获得了精确误差时修改测试才通过。因此，在操作中，生成并提供修改测试以测试程序。在某些情况下，如上面参照图3所述，仅仅重运行直到失败点为止的失败测试将不重建精确的误差。因此，在某些情况下，单独修改测试的执行对于重建精确误差将是不充足的(即，单独运行修改测试将不通过)，例如，当失败测试对于测试脚本的顺序上在先的测试有依赖性时。使用修改测试的测试因此可能包括与用于测试程序的原始测试脚本的其他测试一起提供修改测试。
[0050]因此，在一个实施例中，重建误差的程序的测试可以通过首先仅仅尝试修改测试(并且可选地，任何清理(clean up)测试(如果它们存在于测试脚本中的话))而以结构方式进行。如果重建不成功，则可以以包括原始测试脚本的其他测试的测试脚本来提供修改测试以重测程序。例如，修改测试可以在还包括紧接在原始测试脚本的失败脚本之前的测试的测试脚本中提供。替代地或额外地，修改测试可以在还包括原始测试脚本的第一测试的测试脚本中提供。如果在执行所提供的测试脚本时修改测试仍然未能通过，则测试脚本中可以包括并提供修改测试、原始测试脚本的第一测试、以及原始测试脚本中紧接失败测试之前的测试。如果在运行测试脚本时修改测试仍然未能通过，则原始测试脚本的进一步其他的测试可以添加到具有修改测试的测试脚本并提供到程序。
[0051]在一个示例中，这些进一步测试的添加可以迭代地、顺序地执行(从失败测试向回工作到测试脚本的开始，或从测试脚本的开始工作到失败测试)，其中，原始测试脚本的测试序列中的下一测试被包括在具有修改测试的测试脚本中，并提供用于所述程序执行。在所有情况下，在每次迭代中提供用于由程序执行的测试脚本可包括在原始测试脚本中存在的清理测试。在一个实施例中，清理测试是在程序执行测试脚本的每次迭代中最后运行的。清理测试可以在每次迭代中执行，而无论对于此迭代测试脚本是否失败。
[0052]迭代创建越来越长的测试脚本中测试进行多久可以取决于多少时间(或其他资源)可用。例如，在一个示例中，可用资源有限，从而对于重测将仅允许四个组合:(i )单独的修改测试；(ii) {紧接在失败测试之前的测试，修改测试} ; (iii) {第一测试，修改测试};和(iv) {第一测试，紧接在失败测试之前的测试，修改测试}。在消耗了可用资源之后，接下来的尝试可能最好是整个原始测试脚本，以验证精确的误差重建甚至是可能的。
[0053]使用上述示例，图7到11描绘了构造的测试的示例。在第一次重建精确误差的尝试中，提供了修改测试而没有额外测试，用于重测程序。图7描绘了基于运行图6的修改测试而获得的测试结果的一部分。如图7所示，修改测试基于修改测试的预期输出和基于执行修改测试而获得的输出之间的失配而失败。具体地，基于执行修改测试而获得的输出702不匹配修改测试的预期输出602 (图6)。如上所述，预期输出602是来自原始测试206 (图2)的失败输出，并且修改测试的失败指示没有重建精确误差。更具体地，基于修改测试的执行而创建的错误输出702指示未知CP/CMS命令(与简单重运行失败测试的图4中获得的错误相同)。
[0054]修改测试因为原始测试脚本在第一 H:组(图2的测试202)中创建的临时盘不存在而失败。因为临时盘不存在，所以在临时盘上创建测试程序的尝试失败(其CMSMAC命令之前的原始失败测试206的“管道…”命令失败，并且当修改测试调用程序CMSMAC时，程序不存在，导致“未知CP/CMS命令”输出702)。运行修改测试产生失败，但是不是之前所经历的原样的失败。
[0055]在重建错误的下一尝试中，再次为重测程序提供修改测试，但是作为也包括初始(第一)测试的测试脚本的一部分提供修改测试，用于重测程序。将初始测试包含在测试脚本中，这可能促进修改测试的通过，例如当修改测试对于初始测试有依赖性时。图8示出了根据本发明一个或多个方面的、包括图6的修改测试和初始测试的测试脚本的一个示例。在图8中，测试脚本800包括原始测试脚本(图2)的第一测试202和修改测试600。因此，提供此测试脚本用于由程序执行，这将用原始测试脚本的第一 H:组加上原始测试脚本的修改的失败H:组重测程序。将第一 H:组包含在此测试脚本中，这将导致对于修改测试的CMSMAC命令存在由此创建的临时盘。
[0056]图9描绘了基于运行图8的测试脚本而获得的测试结果的一部分。在此场景中，尽管临时盘存在(依靠包含来自原始测试脚本的第一测试202)，然而，修改测试600对原始测试脚本的第五测试204 (即，测试204的LINK (链接WPACCess (访问)命令204a和204b)有依赖性(图8的802)。当测试脚本800的修改测试600尝试“QLEVEL”命令(802)时，命令失败，因为其所驻留的盘不是LINKed (被链接)和ACCessed (被访问)(其出现在来自第五测试204的命令204a和204b中)。因此，获得图9的失败输出902，指示QLEVEL命令的不可用性。如前所述，这是观测到的失败，但不是从原始测试脚本的执行而获得的原始失败。[0057]典型地，良好编写的原始测试脚本将在测试中不包含在对于除测试脚本的设置(第一)测试以外的任何其他测试的依赖性。换言之，良好编写的原始测试脚本中的依赖性将没有对于除此测试脚本的初始(第一)测试以外的测试的依赖性。然而，在一些情况下，如图2中的示例原始测试脚本200，在后测试的命令中的依赖性依赖于中间的测试(例如，测试206的命令206b依赖于第五测试204)。因此，基于如图9所示的修改测试的失败，期望将原始测试脚本的额外测试添加到测试脚本800以促进进一步的测试，以便尝试错误重建。
[0058]在一个示例中，将测试添加到包括修改测试的测试脚本、以及提供测试脚本用于由程序执行，这两者迭代执行。在每次迭代中，对测试脚本添加下一额外测试。额外测试是原始测试脚本的第一测试和原始测试脚本的失败测试之间的测试序列中的下一测试。在一个示例中,迭代通过以原始测试脚本中第一测试之后的测试的序列的顺序添加额外测试(即，通过添加第二测试、然后第三测试、然后第四测试等)而进行。
[0059]在另一示例中，迭代可以在序列中向后工作地进行(即，紧接在失败测试之前的第一测试、然后紧接在此测试之前的测试，等等)。这样的示例出现在图10中，图10描绘了根据本发明一个或多个方面、包括图6的修改测试和多个额外测试的测试脚本的另一示例。图10的测试脚本1000包括第一测试202、第五测试204和修改测试600。在此示例中，不仅第一测试202与修改测试600 —起包括在测试脚本中，而且测试脚本还包括来自第一测试202和原始失败测试206之间的测试序列的额外测试。在图10的示例中，添加原始失败测试之前的第一测试，即，第五测试204 (其是第一测试202和原始失败测试206之间的序列中的最后测试)被包括在测试脚本中。
[0060]图11描绘了基于运行图10的测试脚本而获得的测试结果的一部分。测试结果1100演示了修改测试现在当程序执行测试脚本1000时通过。在此情况下的修改测试的通过指示已经重建了从原始测试脚本获得的精确的误差。这通过修改测试的输出1102而示出，其与此测试的预期输出1104相匹配，并且不包含失败测试的非预期输出1106 (对应于失败测试206的原始预期输出206d)。
[0061]因为修改测试600通过,所以测试脚本1000 (图10)已经使用第一测试202、第五测试204和修改测试600重建了原始错误。这对于测试者是有价值的信息，测试者可以基于测试脚本1000的内容识别哪些测试是(或可能是)至少部分对导致原始失败要负责的。
[0062]如果替代地，测试脚本1000具有的修改测试600基于程序的执行而失败了，则下一测试(如紧接在原始测试脚本的测试204之前的测试)将在下一迭代中添加到测试脚本1000。
[0063]从上面，根据本发明一个或多个方面促进了自动化的程序测试。参照图12描绘和描述了用于促进自动化程序测试的一个示例。在一个示例中，通过数据处理系统(如图1的数据处理系统100)执行处理。在一个具体实施例中，被测试的程序驻留在执行图12的方法的数据处理系统上(并在其上执行测试脚本)。在另一实施例中，执行图12的方法的数据处理系统与程序所驻留并出现程序的测试的数据处理系统相分离。后者实施例的示例系统是接收测试结果、并生成和返回测试脚本到用于测执行试的系统的远程数据处理系统。
[0064]处理通过获得测试结果而开始(1202)。测试结果基于程序运行一个或多个测试(如测试脚本的一个或多个测试)而生成。接下来，识别一个或多个测试的失败测试的失败输出(1204)。自动生成基于失败测试的修改测试，并将其作为测试脚本提供用于由程序执行(1206)。在一个不例中，根据结合图5在上面描绘和描述的处理而生成修改测试。在一个示例中，测试脚本仅包括修改测试。在其他示例中，此时提供的测试脚本可以包括额外测试。
[0065]有时，在生成修改测试并提供在测试脚本中用于由程序执行之后，程序执行所提供的测试脚本的测试。判定在执行所提供的测试脚本的测试之后，修改测试是否已经通过(1208)。如果是，则处理结束。通过处理结束，所提供的测试脚本包括当由程序执行时重建原始失败的测试，这可能是对于程序测试者有用的信息。
[0066]如果替代地在1208判定修改测试未通过，则判定是否要对具有修改测试的测试脚本添加额外测试(1210)。在一个示例中，此询问判定是否存在由程序执行的原始的一个或多个测试的任何额外测试，其要与修改测试一起被测试。例如，检查包括原始的一个或多个测试的测试脚本，以判定是否其中存在要添加到具有修改测试的测试脚本并提供用于程序的进一步测试的其他测试。在另一示例中，询问1210判定是否额外资源可用和/或应当专用于程序的进一步测试。
[0067]如果询问1210判定没有额外测试要添加到具有修改测试的测试脚本，则处理结束。否则，处理通过选择一个或多个原始测试的另一测试(1212)并将所选择的测试添加到测试脚本(1214)而继续。在一个示例中，所选择的另一测试可以是具有一个或多个由程序执行的原始测试的测试脚本的第一测试。在另一示例中，所选择的另一测试可以是紧接在具有一个或多个原始测试的测试脚本中的原始失败测试之前的测试。替代地，所选择的另一测试可以是在第一测试和原始失败测试之间的测试序列中的下一测试。此外，在一些示例中，可能期望在此时选择并添加多于仅一个测试到测试脚本和/或移除测试脚本的一个或多个测试。
[0068]在任何情况下，现在具有所添加的所选择的另一测试的测试脚本被提供用于由程序执行(1216)。再次，在提供测试脚本用于由程序执行之后的某个时间，程序执行所提供的测试脚本的测试。处理然后返回到询问1208，其中再次判定是否修改测试已经通过。如上，如果修改测试已经通过，则处理结束，否则，处理重复(迭代)选择和添加另一测试到测试脚本，并且再次提供测试脚本用于由程序执行。例如，当(i)修改测试已经通过(1208)或(ii)判定没有额外测试要添加到具有修改测试的测试脚本(1210)时，诸如如果已经消耗了可用资源，或如果没有一个或更多原始测试的更多测试要添加到测试脚本，则处理结束。
[0069]用于与修改测试一起测试的额外测试的选择和添加可以服从任何期望的构造的进展。在一个示例中，修改测试与一个或多个原始测试的第一测试一起测试(例如，图8)，然后与紧接在原始失败测试之前的测试一起测试，然后与第一测试和来自在第一测试和原始失败测试之间的序列中向后工作或向前工作的测试序列中的下一测试(如在图10中，测试第一测试202和在从原始失败测试到第一测试向后工作的第一迭代中选择的测试204) —起测试。
[0070]要注意，处理不必是完美的才有用。如果图12的处理结束并且不能重建失败，则其自身对于测试者是有用的信息。如果失败的重建不可能，则至少测试者(如测试机器的人类操作者)没有花费时间尝试重建失败，并且操作者仅花费非常少的时间来评估不能重建失败。并且，在某些情况下，不能重建失败可以指示设计差或编写差的测试情况(原始测试脚本)，原始测试脚本的成功或失败没有确认或排除软件缺陷。
[0071]如上所述，根据本发明各方面，使用原始测试结构促进自动化程序测试，其产生输出文件，示出由自动化测试驱动的活动、并强调失败测试的失败输出。失败输出被修订为失败测试的修改版本的预期输出。此修改测试情况被定义为仅当获得(来自失败测试的)失败输出时才通过。此修改测试因此是原始测试结构所建议的方式的子集，并且所述子集用于尝试失败的重建。以预定顺序进行尝试，在最小重建的期望性和验证重建可能的需求之间进行平衡，并且所有上述都可以是自动化的。
[0072]所属【技术领域】的技术人员知道，本发明各方面可以实现为系统、方法或计算机程序产品。因此，本发明各方面可以具体实现为以下形式，即:可以是完全的硬件实施例、也可以是完全的软件实施例(包括固件、驻留软件、微代码等)，还可以是硬件和软件方面结合的实施例，本文一般可统称为“电路”、“模块”或“系统”。此外，本发明各方面还可以实现为在一个或多个计算机可读介质中包含的计算机程序产品的形式，该计算机可读介质中包含计算机可读的程序代码。
[0073]可以采用一个或多个计算机可读的介质的任意组合。计算机可读介质可以是计算机可读存储介质。计算机可读存储介质例如可以是一但不限于一电、磁、光、或半导体的系统、装置或器件，或者任意以上的组合。计算机可读存储介质的更具体的例子(非穷举的列表)包括:具有一个或多个导线的电连接、便携式计算机磁盘、硬盘、随机存取存储器(RAM)、只读存储器(ROM)、可擦式可编程只读存储器(EPR0M或闪存)、光纤、便携式紧凑磁盘只读存储器(CD-ROM)、光存储器件、磁存储器件、或者上述的任意合适的组合。在本文件的上下文中，计算机可读存储介质可以是任何可包含或存储程序的有形介质，该程序可以被指令执行系统、装置或者器件使用或者与其结合使用。[0074]体现在计算机可读介质上的程序代码可以用任何适当的介质传输，所述介质包括但不限于:无线、有线、光缆、RF等，或上述的任意合适的组合。
[0075]可以以一种或多种程序设计语言的任意组合来编写用于执行本发明各方面的操作的计算机程序代码，所述程序设计语言包括面向对象的程序设计语言一诸如Java、Smalltalk、C++等，还包括常规的过程式程序设计语言一诸如” C”程序设计语言或类似的程序设计语言。程序代码可以完全地在用户计算机上执行、部分地在用户计算机上执行、作为一个独立的软件包执行、部分在用户计算机上部分在远程计算机上执行、或者完全在远程计算机或服务器上执行。在涉及远程计算机的情形中，远程计算机可以通过任意种类的网络一包括局域网(LAN)或广域网(WAN)—连接到用户计算机，或者，可以连接到外部计算机(例如利用因特网服务提供商来通过因特网连接)。
[0076]现在参照图13，在一个示例中，计算机程序产品1300例如包括用于在其上存储计算机可读程序代码部件或逻辑1304的一个或多个计算机可读介质1302，以提供和促进本发明的一个或多个方面。
[0077]这里，参照根据本发明实施例的方法、装置(系统)和计算机程序产品的流程图和/或框图描述本发明各方面。应当理解，流程图和/或框图的每个方框以及流程图和/或框图中各方框的组合，都可以由计算机程序指令实现。
[0078]这些计算机程序指令可以提供给通用计算机、专用计算机或其它可编程数据处理装置的处理器，从而生产出一种机器，这些计算机程序指令通过计算机或其它可编程数据处理装置的处理器执行，产生了实现流程图和/或框图中的方框中规定的功能/操作的装置。
[0079]也可以把这些计算机程序指令存储在能使得计算机或其它可编程数据处理装置或其他装置以特定方式工作的计算机可读介质中，这样，存储在计算机可读介质中的指令就产生出一个包括实现流程图和/或框图中的方框中规定的功能/操作的指令装置(instruction means)的制造品(manufacture)。
[0080]也可以把计算机程序指令加载到计算机、其它可编程数据处理装置、或其它设备上，使得在计算机、其它可编程数据处理装置或其它设备上执行一系列操作步骤，以产生计算机实现的过程，从而使得在计算机或其它可编程装置上执行的指令能够提供实现流程图和/或框图中的方框中规定的功能/操作的过程。
[0081]附图中的流程图和框图显示了根据本发明的多个实施例的系统、方法和计算机程序产品的可能实现的体系架构、功能和操作。在这点上，流程图或框图中的每个方框可以代表模块、程序段或代码的一部分，所述模块、程序段或代码的一部分包含一个或多个用于实现规定的逻辑功能的可执行指令。也应当注意，在有些作为替换的实现中，方框中所标注的功能也可以以不同于附图中所标注的顺序发生。例如，两个连续的方框实际上可以基本并行地执行，它们有时也可以按相反的顺序执行，这依所涉及的功能而定。也要注意的是，框图和/或流程图中的每个方框、以及框图和/或流程图中的方框的组合，可以用执行规定的功能或操作的专用的基于硬件的系统来实现，或者可以用专用硬件与计算机指令的组合来实现。
[0082]而且，适于存储和/或执行程序代码的数据处理系统是可用的，其包括至少一个通过系统总线直接或间接耦合到存储器元件的处理器。存储器元件包括，例如，在程序代码的实际执行期间使用的本地存储器、大容量存储器以及高速缓冲存储器，其提供至少一些程序代码的临时存储，以便减少在执行期间必须从大容量存储器取回代码的次数。
[0083]输入/输出或I/O设备(包括但不限于键盘、显示器、指点设备、DASD、磁带、⑶、DVD、拇指驱动器(thumb drive)以及其他的存储介质等)可直接或通过介于其间的I/O控制器被耦合到系统。网络适配器也可被耦合到系统以使得数据处理系统能够通过介于其间的私有或公共网络而耦合到其他的数据处理系统或远程打印机或存储设备。调制解调器、电缆调制解调器和以太网卡仅是一些可获得的网络适配器类型。
[0084]这里所用的术语仅用于描述特定实施例，并且不意图限制本发明。如这里所使用的，单数形式“一个”和“这个”意图也包括复数形式，除非上下文清晰地另有所指。还将理解，术语“包括”、“具有”、“包含”和“含有”是开放性的动词。结果，“包括”、“具有”、“包含”和“含有”一个或多个步骤或元件的方法或设备拥有这样的一个或多个步骤或元件，但不限于仅拥有这样的一个或多个步骤或元件。同样，“包括”、“具有”、“包含”和“含有”一个或多个特征的方法的步骤或设备的元件拥有这样的一个或多个特征，但不限于仅拥有这样的一个或多个特征。此外，以特定方式配置的设备或结构指示至少以此方式配置，但也可以以未列出的方式配置。
[0085]呈现本发明的说明是为了示出和描述的作用，但不是意图穷尽性的或将本发明限制于所公开的形式。许多修改和变化对本领域普通技术人员来说是明显的，且不脱离本发明的范围和精神。选择和描述实施例是为了最佳地解释本发明的原理和实际应用，并使得本领域普通技术人员能针对适于考虑的特定用途的具有各种修改的各种实施例理解本发明。
【权利要求】
1.一种用于促进自动化程序测试的方法，所述方法包括: 获得基于程序执行一个或多个测试而生成的测试结果，其中，基于根据程序执行所述测试而获得的输出，所述测试通过或失败； 标识测试结果的失败输出，所述失败输出来自于所述一个或多个测试的失败测试，所述失败测试包括至少一个命令，并且所述失败输出基于执行所述至少一个命令而获得；以及基于所述失败测试，通过处理器自动生成修改测试，所述修改测试用于由所述程序执行以促进所述程序的测试，并且所述修改测试包括所述至少一个命令，其中，所述修改测试基于获得所述失败测试的所标识的失败输出而通过。
2.如权利要求1所述的方法，其中，所述失败测试还包括基于所述至少一个命令的执行而预期要获得的预期输出，其中，所述失败测试基于获得所述失败测试的所述预期输出以外的输出而失败，并且其中，所标识的失败输出包括所述失败测试的所述预期输出以外的所获得的 输出。
3.如权利要求2所述的方法，其中，自动生成所述修改测试包括:在所述修改测试中包含所述修改测试的预期输出，所述修改测试的预期输出是所述失败测试的预期输出以外的所获得的输出，其中，所述修改测试基于获得所述修改测试的预期输出而通过。
4.如权利要求1所述的方法，其中，所述失败测试还包括非预期输出，所述非预期输出是基于所述至少一个命令的执行而预期不会获得的输出，其中，所述失败测试基于获得所述非预期输出而失败，并且其中，所标识的失败输出包括所述非预期输出。
5.如权利要求4所述的方法，其中，自动生成修改测试包括:在所述修改测试中包含所述修改测试的预期输出，所述修改测试的预期输出是所述失败测试的非预期输出，其中，所述修改测试基于获得所述修改测试的预期输出而通过。
6.如权利要求1所述的方法，其中，所述一个或多个测试包括至少两个测试，并且其中，所述方法还包括: 提供用于由所述程序执行的修改测试； 基于所述程序对所述修改测试的执行，确定所述修改测试是否已通过； 基于确定所述修改测试未通过，选择所述至少两个测试的另一测试；以及 提供包括所述修改测试和所选择的另一测试的测试脚本用于由所述程序执行所述测试脚本，其中，所述测试脚本的执行包括由所述程序执行所述测试脚本中包含的测试。
7.如权利要求6所述的方法，其中，所述至少两个测试包括测试序列，并且其中，所选择的另一测试包括所述测试序列中的第一测试。
8.如权利要求7所述的方法，其中，所述失败测试的失败或通过至少部分依赖于所述第一测试的至少一个设置命令，并且其中，基于在所述程序执行所述测试脚本时所述第一测试的所述至少一个设置命令的执行，将所述第一测试包含于所述测试脚本中促进了所述修改测试的通过。
9.如权利要求6所述的方法，还包括: 基于所述测试脚本的执行，确定所述修改测试是否已通过；以及 基于确定所述修改测试未通过，重复选择另一测试、提供测试脚本、以及基于测试脚本的执行确定是否修改测试已通过，其中，重复提供的步骤包括将所选择的另一测试添加到所述测试脚本。
10.如权利要求9所述的方法，其中，所述失败输出指示程序中出现错误，其中，执行所述重复直到确定修改测试通过，并且其中，所述修改测试的通过指示所述测试脚本包括来自所述至少两个测试的、重建所述程序中的所述错误的出现所需要的测试。
11.如权利要求9所述的方法，其中，在所述测试序列中，至少一个测试存在于所述测试序列中的第一测试和所述失败测试之间，并且其中，重复选择的步骤在从所述失败测试到所述第一测试的测试序列中向后工作地选择所述至少一个测试的下一测试以添加到所述测试脚本。
12.如权利要求9所述的方法，其中，所述至少两个测试包括清理测试，并且其中，所提供的测试脚本还包括所述清理测试。
13.一种用于促进自动化程序测试的计算机系统，所述计算机系统包括: 存储器；以及 与所述存储器通信的处理器，其中，所述计算机系统配置为执行: 获得基于程序执行一个或多个测试而生成的测试结果，其中，基于根据程序执行所述测试而获得的输出，所述测试通过或失败； 标识测试结果的失败输出，所述失败输出来自于所述一个或多个测试的失败测试，所述失败测试包括至少一个命令，并且所述失败输出基于执行所述至少一个命令而获得；以及基于所述失败测试自动生成修改测试，所述修改测试用于由所述程序执行以促进所述程序的测试，并且所述修改测试包括所述至少一个命令，其中，所述修改测试基于获得所述失败测试的所标识的失败输出而通过。
14.如权利要求13所述的计算机系统，其中，所述失败测试还包括基于所述至少一个命令的执行而预期要获得的预 期输出，其中，所述失败测试基于获得所述失败测试的所述预期输出以外的输出而失败，并且其中，所标识的失败输出包括所述失败测试的所述预期输出以外的所获得的输出。
15.如权利要求13所述的计算机系统，其中，所述一个或多个测试包括至少两个测试，并且其中，所述计算机系统还配置为执行: 提供用于由所述程序执行的修改测试； 基于所述程序对所述修改测试的执行，确定所述修改测试是否已通过； 基于确定所述修改测试未通过，选择所述至少两个测试的另一测试；以及 提供包括所述修改测试和所选择的另一测试的测试脚本用于由所述程序执行所述测试脚本，其中，所述测试脚本的执行包括由所述程序执行所述测试脚本中包含的测试。
16.如权利要求15所述的计算机系统，其中，所述至少两个测试包括测试序列，并且其中，所选择的另一测试包括所述测试序列中的第一测试，其中，所述失败测试的失败或通过至少部分依赖于所述第一测试的至少一个设置命令，并且其中，基于在所述程序执行所述测试脚本时所述第一测试的所述至少一个设置命令的执行，将所述第一测试包含于所述测试脚本中促进了所述修改测试的通过。
17.如权利要求15所述的计算机系统，其中，所述计算机系统还配置为执行: 基于所述测试脚本的执行，确定所述修改测试是否已通过；以及 基于确定所述修改测试未通过，重复选择另一测试、提供测试脚本、以及基于测试脚本的执行确定是否修改测试已通过，其中，重复提供的步骤包括将所选择的另一测试添加到所述测试脚本。
18.一种用于促进自动化程序测试的系统，所述系统包括用于实现权利要求1-12的任一方法的任一步骤的装置。
【文档编号】G06F11/36GK103678116SQ201310416473
【公开日】2014年3月26日 申请日期:2013年9月13日 优先权日:2012年9月14日
【发明者】T.D.格里尔 申请人:国际商业机器公司