CN109726093B

CN109726093B - 用于执行测试用例的方法、设备和计算机程序产品

Info

Publication number: CN109726093B
Application number: CN201711025184.7A
Authority: CN
Inventors: 王文俊; 吕烁
Original assignee: EMC IP Holding Co LLC
Current assignee: EMC Corp
Priority date: 2017-10-27
Filing date: 2017-10-27
Publication date: 2022-03-22
Anticipated expiration: 2037-10-27
Also published as: US20190129833A1; US10872034B2; US20200117586A1; CN109726093A; US10534699B2

Abstract

本公开的实施例涉及一种用于执行测试用例的方法和设备。该方法包括获得要被执行的测试用例集合，并且基于知识库来确定与测试用例集合中的每个测试用例相关联的测试平台类型和测试脚本。该方法还包括至少根据测试平台类型将测试用例集合划分成多个测试子集(即测试套件)，并且使用相应的测试环境和测试脚本来执行每个测试子集中的测试用例。本公开的实施例通过基于知识库自动生成多个测试套件，并且使用相应的测试环境和测试脚本来自动执行每个测试套件。因此，本公开的实施例能够实现测试套件的自动生成和执行，并且能够提高测试的运行效率。

Description

用于执行测试用例的方法、设备和计算机程序产品

技术领域

本公开的实施例总体上涉及测试领域，并且更具体地涉及用于执行测试用例的方法、设备和计算机程序产品。

背景技术

测试用例(test case)是指为了特定目的而编写的一组测试输入、执行条件以及预期结果，以便测试某个组件、模块或者功能是否满足预定需求。为了自动执行测试用例，需要编写相应的测试脚本，其通常表现为一系列的程序指令。通常，通过脚本语言来编写测试脚本，脚本语言是在执行时以解译为主的编程语言，比如Ruby、Perl、Python、Shell、C#等。

通常，每个待测试的对象包括多个组件，而针对每个组件可能存在一个或多个测试用例，因此，针对该对象通常需要执行多个测试用例，即测试用例集合。测试套件(testsuite)是指测试用例集合中的一组相关联的测试用例，也被称为测试子集。通过使用测试套件，可以将服务于同一个测试目的或同一运行环境下的一系列测试用例组合执行。

发明内容

本公开的实施例提供了一种用于执行测试用例的方法、设备和计算机程序产品。

在本公开的一个方面，提供了一种用于执行测试用例的方法。该方法包括：获得要被执行的测试用例集合，其中测试用例集合被划分成一个或多个测试子集；针对测试用例集合中的测试用例，基于知识库确定与测试用例相关联的测试平台类型和测试脚本；根据测试平台类型，确定测试用例所属的测试子集；以及基于测试脚本，执行测试子集中的测试用例。

在本公开的另一方面，提供了一种用于执行测试用例的设备。该设备包括处理单元以及存储器，其中存储器被耦合至处理单元并且存储有指令。所述指令在由处理单元执行时执行以下动作：获得要被执行的测试用例集合，其中测试用例集合被划分成一个或多个测试子集；针对测试用例集合中的测试用例，基于知识库确定与测试用例相关联的测试平台类型和测试脚本；根据测试平台类型，确定测试用例所属的测试子集；以及基于测试脚本，执行测试子集中的测试用例。

在本公开的又一方面，提供了一种计算机程序产品。该计算机程序产品被有形地存储在非瞬态计算机可读介质上并且包括计算机可执行指令，所述计算机可执行指令在被执行时使得计算机执行根据本公开的实施例的方法。

提供发明内容部分是为了简化的形式来介绍对概念的选择，它们在下文的具体实施方式中将被进一步描述。发明内容部分无意标识本公开的关键特征或主要特征，也无意限制本公开的各个实施例的范围。

附图说明

通过结合附图对本公开示例性实施例进行更详细的描述，本公开的上述以及其它目的、特征和优势将变得更加明显，其中在本公开示例性实施例中，相同的参考标记通常代表相同部件。

图1示出了根据本公开的实施例的用于执行测试用例的系统的架构的示意图；

图2示出了根据本公开的实施例的用于执行测试用例的方法的流程图；

图3示出了根据本公开的实施例的用于生成测试套件的示意图；

图4示出了根据本公开的实施例的针对测试脚本的运行信息的示意图；

图5示出了根据本公开的实施例的用于在知识库中创建测试用例表的示意图；

图6示出了根据本公开的实施例的用于在知识库中创建测试用例运行记录表的示意图；

图7示出了根据本公开的实施例的用于测试用例的重试的示意图；以及

图8示出了可以用来实施本公开的实施例的设备的示意性框图。

具体实施例

下面将参照附图更详细地描述本公开的优选实施例。虽然附图中显示了本公开的优选实施例，然而应该理解，可以以各种形式实现本公开而不应被这里阐述的实施例所限制。相反，提供这些实施例是为了使本公开更加透彻和完整，并且能够将本公开的范围完整地传达给本领域的技术人员。

在本文中使用的术语“包括”及其变形表示开放性包括，即“包括但不限于”。除非特别申明，术语“或”表示“和/或”。术语“基于”表示“至少部分地基于”。术语“一个示例实施例”和“一个实施例”表示“至少一个示例实施例”。术语“另一实施例”表示“至少一个另外的实施例”。术语“第一”、“第二”等可以指代不同的或相同的对象。此外，本文中所描述的“测试套件”表示测试集合中的一组相关的测试用例，其可以基于预定策略而被划分，其也可以被称为测试子集、测试子任务、测试子工作。下文还可能包括其他明确的和隐含的定义。

传统地，针对包括多个测试用例的测试任务，测试人员需要手动地组合一个或多个测试用例以生成各个测试套件，并且手动地收集测试脚本，然后执行测试。在测试的过程中，测试人员还需要手动处理测试异常，并且逐一地收集测试结果。由于测试用例的数目可能非常庞大，而传统的测试过程繁杂，因而需要大量的人力，使得测试效率非常低。

本公开的实施例提出了一种用于执行测试用例的方案。根据在此描述的实施例，在获得要被执行的测试用例集合之后，基于知识库确定每个测试用例的测试平台类型，从而将测试用例集合自动划分成多个测试套件。然而使用相应的测试环境和测试脚本来自动执行每个测试套件。因此，本公开的实施例能够实现测试套件的自动生成和执行，并且能够提高测试的运行效率。

此外，根据本公开的实施例的知识库存储每个测试用例的相关信息，因而可以很方便地从其获得要被执行的测试用例集合。同时，本公开的实施例在划分测试套件时，除了考虑测试用例的测试平台类型，还可以考虑每个测试套件的总运行时间，从而使得所有测试套件的运行时间相差不多，以适合于多个测试套件之间的并行处理。

回归测试是指修改了旧代码后，重新进行测试以确认修改没有引入新的错误或导致其他代码产生错误。回归测试的目的是为了保证在系统添加新的组件或模块时旧的组件或模块仍然可以正常运行，其能够保证持续地推出新版本的系统。由于回归测试的测试工作量很大并且复用先前已经测试过的测试用例，因而将根据本公开的实施例的技术用于回归测试能够大幅提高测试效率。本领域技术人员应当理解，虽然根据本公开的一些实现应用于回归测试，但是本公开的实施例也可以应用于普通的软硬件测试。

以下参考图1至图8来说明本公开的基本原理和若干示例实现方式。应当理解，给出这些示例性实施例仅是为了使本领域技术人员能够更好地理解进而实现本公开的实施例，而并非以任何方式限制本公开的范围。

图1示出了根据本公开的实施例的用于执行测试用例的系统100的架构的示意图。如图1所示，系统100包括设备110和知识库120。设备110可以为具有处理能力的各种计算设备，包括但不限于个人计算机、服务器等，以下参考图8描述了设备110的一个示例实现。知识库120可以为数据库或服务器，其可以位于设备110的本地，也可以位于设备110的远端(例如，在云中)并且通过网络与设备110进行通信，以下参考图5、图6以及表1描述了知识库中的表单的示例实现。

参考图1，设备110包括测试套件生成模块130和测试套件执行模块140。测试套件生成模块130可以根据测试用例集合来动态地生成一个或多个测试套件(以下参考图3描述了动态生成多个测试套件的一个示例实现)，测试套件执行模块140可以包括用于执行测试套件的一个或多个测试执行引擎，如以下将详细描述的。在存在多个测试套件(每个测试套件可以包括一个或多个测试用例)的情况下，测试套件执行模块140中的多个测试执行引擎可以并行地执行多个测试套件，而每个测试引擎可以串行地执行每个测试套件中的所有测试用例。

如箭头150所示，测试套件生成模块130可以基于知识库生成多个测试套件。如箭头160所示，测试套件生成模块130可以将所生成的多个测试套件传递给测试套件执行模块140以用于执行。如箭头170所示，测试套件执行模块140通过查询知识库120来并行执行多个测试套件，并且可以将测试运行记录和测试报告写入到知识库120中。

图2示出了根据本公开的实施例的用于执行测试用例的方法200的流程图。本领域技术人员应当理解，方法200可以由以上参考图1所描述的设备110或者以下参考图8所描述的设备800来执行。

在202，获得要被执行的测试用例集合，其中测试用例集合基于预定策略而被划分成一个或多个测试子集(即测试套件)。例如，测试套件生成模块130可以根据用户选择来确定要被执行的测试用例集合，例如，用户可以直接选择一些测试用例。在一些实施例中，测试套件生成模块130还可以基于要被测试的组件集合，通过查询知识库120来获得测试用例集合，例如，用户可以选择要被测试的组件。以下表1示出了知识库120中的一个示例数据表。

表1：知识库中的示例数据表

测试用例名称	组件名称	测试平台类型	测试脚本地址	运行时间
					测试1	组件X	AAA	/…/bin/test1.rb	182s
测试2	组件X	AAA	/…/bin/test2.rb	255s
					测试3	组件X	BBB	/…/bin/test3.rb	72s
测试4	组件X	AAA	/…/bin/test4.rb	68s
					测试5	组件Y	BBB	/…/bin/test5.rb	165s
测试6	组件Y	CCC	/…/bin/test6.rb	230s
					测试7	组件Z	DDD	/…/bin/test7.rb	168s
测试8	组件Z	AAA	/…/bin/test8.rb	293s
					测试9	组件Z	AAA	/…/bin/test9.rb	117s
测试10	组件Z	BBB	/…/bin/test10.rb	85s

其中表1中的示例数据表包括每个测试用例名称、所属的组件名称、所需要的测试平台类型、对应的测试脚本地址、以及运行该测试所需的运行时间。表格中的测试用例可以是预先收集的测试用例，在例如自动回归测试的场景中，表格中的测试用例可以为已经执行过的历史测试用例。

在204，针对测试用例集合中的测试用例，基于知识库确定与测试用例相关联的测试平台类型和测试脚本。例如，测试套件生成模块130可以通过查询知识库120来确定每个测试用例的测试平台类型、测试脚本地址、所属的组件名称以及运行信息(以下参考图4描述了运行信息的一个参考实现)等。知识库120中可以存储使用各种编程语言编写的多个测试用例，其所运行的测试平台根据测试用例而变化，其中测试平台是测试用例的运行平台，例如硬件系统和/或操作系统。

在206，根据测试平台类型，确定测试用例所属的测试子集(即测试套件)。可选地，测试套件生成模块130可以将相同测试平台类型的测试用例分组在一个测试套件中。备选地，在划分测试套件时，除了考虑测试用例的测试平台类型之外，还可以考虑每个测试用例的运行时间，从而使得所有测试套件的运行时间相差不多，以适合于多个测试套件的并行处理。此外，有些测试用例在执行过程中会对系统造成破坏，因而这些测试用例之间无法共享测试平台。因此，测试套件划分不仅仅要考虑提高测试的效率，还可以考虑内部的一些其他需求。

在208，基于测试脚本，执行测试子集中的测试用例。例如，测试套件执行模块140可以基于测试平台类型来实例化针对测试平台类型的测试环境，并且针对每个测试套件，顺序地执行与测试套件中的多个测试用例相关联的多个测试脚本。

在一些实施例中，测试套件执行模块140还可以获得运行参数。在测试运行的过程中，测试套件执行模块140执行参数替换，并且自动执行异常处理和故障重试。在一些实施例中，在完成执行测试子集之后，测试套件执行模块140可以从运行日志收集测试结果，并且基于所收集的测试结果来生成测试报告。

在一些实施例中，可以由测试套件执行模块140中的多个测试执行引擎并行地执行多个测试套件，从而整体上提高测试运行的速度。以这种方式，多个测试套件之间并行执行，每个测试套件的多个测试用例之间串行执行。

图3示出了根据本公开的实施例的用于生成测试套件的示意图300。应当理解，图3中的知识库302可以为图1中所描述的知识库120，并且假设知识库302中存储有表1中所示出的数据表。如图3所示，知识库302中包括多个测试用例，每个测试用例与其对应的组件名称相关联地被存储，例如，测试1是针对组件X的，测试5是针对组件Y的，等等。

在测试人员需要测试组件X和组件Y的情况下(例如，用户通过可视化界面选择组件X和组件Y)，与组件X和组件Y相关联的所有测试用例被获得，以形成测试用例集合304，其包括测试1、测试2、测试3、测试4、测试5、以及测试6。通过查询知识库302，还可以确定每个测试用例所需要的测试平台类型，如306所示出的，测试1、测试2和测试4运行在AAA平台上，测试3和测试5运行在BBB平台上，而测试6运行在CCC平台上，其中平台AAA、BBB、CCC可以例如为不同的硬件系统和/或操作系统。

如图3所示，可以基于测试平台类型和每个测试套件的总运行时间，将测试用例集合304划分成多个测试套件，也即，包括测试1和测试4的测试套件308、包括测试2的测试套件310、包括测试3和测试5的测试套件312、以及包括测试6的测试套件314(如果测试1、测试2、测试4都被划分在一个测试套件中，将造成该测试套件的运行时间远大于其他的测试套件)。应当理解，也可以不考虑测试套件的总运行时间而只考虑测试平台类型，在这种情况下，针对测试平台类型AAA的测试套件308和测试套件310将被合并成一个测试套件。

应当理解，每个测试脚本将被运行为具有相应参数的独立过程。在测试脚本运行过程中，需要使用测试脚本信息以及一些控制信息(例如超时信息)。在一些实施例中，测试脚本信息可以包括测试用例名称、测试用例所属的组件名称、测试脚本所存储的地址或位置、以及包括在执行过程中需要被替换的变量的运行参数等。在一些实施例中，控制信息可以包括关键测试用例的通过或中止信息、最小版本控制、最大版本控制、日志详细程度级别、以及可以用于控制的其他信息。这些信息可以被组合在一起形成针对测试脚本的运行信息(也称为“hash line”)，其可以在执行期间由测试套件执行模块140进行解译。在一些实施例，在将测试用例集合划分成多个测试套件之前，可以对运行信息进行去重处理。

图4示出了根据本公开的实施例的针对测试脚本的运行信息的示意图。例如，测试套件生成模块130可以基于知识库120获得测试脚本的运行信息。如图4所示，测试脚本的运行信息包括组件名称(component字段)、测试用例名称(testname字段)、测试脚本地址或位置(script字段)、运行参数(params字段)、最小版本控制(minlimitver字段)以及超时信息(timeout字段)，等等。

图5示出了根据本公开的实施例的用于在知识库中创建测试用例表的示意图。在自动生成测试套件的过程中，测试套件生成模块130可以在知识库120中存储测试用例名称与运行信息(hash line)之间的映射关系。如图5所示，测试用例表可以包括测试用例名称(case_name字段)、组件名称(component字段)、运行信息(hash_line字段)、以及测试平台类型(testbed_type字段)，其中测试用例名称为主键。

图6示出了根据本公开的实施例的用于在知识库中创建测试用例运行记录表的示意图。在测试套件执行模块140完成执行每个测试套件之后，会分析所生成的测试日志，并且将针对每个测试用例的测试记录存储到知识库中。如图6所示，测试用例运行记录表可以包括测试用例名称(case_name字段)、版本号(build_no字段)、发布时间(post_time字段)、测试状态(status字段)、持续运行时间(duration字段)、命令标识(cmd_id字段)、日志细节(log_details字段)、摘要标识(digest_id字段)以及任务名称(job_name字段)。

在完成执行所有测试套件之后，系统将取回测试结果并且生成最终报告，然后可以以可视化文档(例如HTML文件)的形式发送给用户。例如，测试报过的内容可以包括每个测试用例的测试结果状态(通过或者未通过)、日志细节、测试执行的时间、以及故障情况等等。在一些实施例中，可以将故障追踪工具中的故障信息也存储到知识库中。以这种方式，在下一次再发生相同故障时，故障的相关参考信息会从知识库中一起被取回。

在系统测试过程中，某个或某些测试用例的执行需要依赖于其他测试用例，因此，如果测试过程中发生故障，可以调整故障的顺序再进行故障重试。例如，测试套件执行模块140可以响应于在测试子集的执行期间发生多个故障，将与多个故障中的第一故障相关联的第一测试用例在次序上调整到与第二故障相关联的第二测试用例之后。然后，针对调整后的多个故障，测试套件执行模块140可以再次执行与多个故障相关联的测试用例。

图7示出了根据本公开的实施例的用于测试用例的重试的示意图700。如图7所示，在时间轴780上，在时间点781至785的第一轮测试运行期间，某个测试套件中的七个测试用例710、720、730、740、750、760以及770顺序地被执行。然而，在时间点782处，测试用例720发生故障；在时间点783处，测试用例740发生故障；以及在时间点784处，测试用例760发生故障。

根据本公开的实施例，可以对发生故障的测试用例调整执行顺序并且再次执行测试，例如，将最先发生故障的测试用例720放到最后执行。继续参考图7，在时间点785至786的第二轮执行期间，按照调整后的顺序依次执行测试用例740、测试用例760以及测试用例720，从而使得这三个测试用例都成功通过。本领域技术人员应当理解，如果调整后仍然发生故障，则可以重复以上过程继续调整发生故障的测试用例的运行顺序。

因此，根据本公开的实施例的技术，用户仅需选择要被测试的组件或者要被测试的测试用例，而不需要关心测试套件具体如何生成，由此实现测试套件的自动生成和执行。因此本公开的实施例能够提高测试的运行效率，实现可靠的故障处理、以及输出详细的测试报告。

图8示出了一个可以用来实施本公开的实施例的设备800的示意性框图。如图所示，设备800包括中央处理单元(CPU)801，其可以根据存储在只读存储器(ROM)802中的计算机程序指令或者从存储单元808加载到随机访问存储器(RAM)803中的计算机程序指令，来执行各种适当的动作和处理。在RAM 803中，还可存储设备800操作所需的各种程序和数据。CPU 801、ROM 802以及RAM 803通过总线804彼此相连。输入/输出(I/O)接口805也连接至总线804。

设备800中的多个部件连接至I/O接口805，包括：输入单元806，例如键盘、鼠标等；输出单元807，例如各种类型的显示器、扬声器等；存储单元808，例如磁盘、光盘等；以及通信单元809，例如网卡、调制解调器、无线通信收发机等。通信单元809允许设备800通过诸如因特网的计算机网络和/或各种电信网络与其他设备交换信息/数据。

上文所描述的各个过程和处理可由处理单元801执行。例如，在一些实施例中，方法可被实现为计算机软件程序，其被有形地包含于机器可读介质，例如存储单元808。在一些实施例中，计算机程序的部分或者全部可以经由ROM 802和/或通信单元809而被载入和/或安装到设备800上。当计算机程序被加载到RAM 803并由CPU 801执行时，可以执行上文描述的方法中的一个或多个步骤。

在一些实施例中，以上所描述的方法200可以被实现为计算机程序产品。计算机程序产品可以包括计算机可读存储介质，其上载有用于执行本公开的各个方面的计算机可读程序指令。

计算机可读存储介质可以是可以保持和存储由指令执行设备使用的指令的有形设备。计算机可读存储介质例如可以是――但不限于――电存储设备、磁存储设备、光存储设备、电磁存储设备、半导体存储设备或者上述的任意合适的组合。计算机可读存储介质的更具体的例子(非穷举的列表)包括：便携式计算机盘、硬盘、随机存取存储器(RAM)、只读存储器(ROM)、可擦式可编程只读存储器(EPROM或闪存)、静态随机存取存储器(SRAM)、便携式压缩盘只读存储器(CD-ROM)、数字多功能盘(DVD)、记忆棒、软盘、机械编码设备、例如其上存储有指令的打孔卡或凹槽内凸起结构、以及上述的任意合适的组合。这里所使用的计算机可读存储介质不被解释为瞬时信号本身，诸如无线电波或者其他自由传播的电磁波、通过波导或其他传输媒介传播的电磁波(例如，通过光纤电缆的光脉冲)、或者通过电线传输的电信号。

本文所描述的计算机可读程序指令可以从计算机可读存储介质下载到各个计算/处理设备，或者通过网络、例如因特网、局域网、广域网和/或无线网下载到外部计算机或外部存储设备。网络可以包括铜传输电缆、光纤传输、无线传输、路由器、防火墙、交换机、网关计算机和/或边缘服务器。每个计算/处理设备中的网络适配卡或者网络接口从网络接收计算机可读程序指令，并转发该计算机可读程序指令，以供存储在各个计算/处理设备中的计算机可读存储介质中。

用于执行本公开操作的计算机程序指令可以是汇编指令、指令集架构(ISA)指令、机器指令、机器相关指令、微代码、固件指令、状态设置数据、或者以一种或多种编程语言的任意组合编写的源代码或目标代码，所述编程语言包括面向对象的编程语言，以及常规的过程式编程语言。计算机可读程序指令可以完全地在用户计算机上执行、部分地在用户计算机上执行、作为一个独立的软件包执行、部分在用户计算机上部分在远程计算机上执行、或者完全在远程计算机或服务器上执行。在涉及远程计算机的情形中，远程计算机可以通过任意种类的网络—包括局域网(LAN)或广域网(WAN)—连接到用户计算机，或者，可以连接到外部计算机(例如利用因特网服务提供商来通过因特网连接)。在一些实施例中，通过利用计算机可读程序指令的状态信息来个性化定制电子电路，例如可编程逻辑电路、现场可编程门阵列(FPGA)或可编程逻辑阵列(PLA)，该电子电路可以执行计算机可读程序指令，从而实现本公开的各个方面。

这些计算机可读程序指令可以提供给通用计算机、专用计算机或其它可编程数据处理装置的处理单元，从而生产出一种机器，使得这些指令在通过计算机或其它可编程数据处理装置的处理单元执行时，产生了实现流程图和/或框图中的一个或多个方框中规定的功能/动作的装置。也可以把这些计算机可读程序指令存储在计算机可读存储介质中，这些指令使得计算机、可编程数据处理装置和/或其他设备以特定方式工作，从而，存储有指令的计算机可读介质则包括一个制造品，其包括实现流程图和/或框图中的一个或多个方框中规定的功能/动作的各个方面的指令。

也可以把计算机可读程序指令加载到计算机、其它可编程数据处理装置、或其它设备上，使得在计算机、其它可编程数据处理装置或其它设备上执行一系列操作步骤，以产生计算机实现的过程，从而使得在计算机、其它可编程数据处理装置、或其它设备上执行的指令实现流程图和/或框图中的一个或多个方框中规定的功能/动作。

附图中的流程图和框图显示了根据本公开的多个实施例的设备、方法和计算机程序产品的可能实现的体系架构、功能和操作。在这点上，流程图或框图中的每个方框可以代表一个模块、程序段或指令的一部分，所述模块、程序段或指令的一部分包含一个或多个用于实现规定的逻辑功能的可执行指令。在有些作为替换的实现中，方框中所标注的功能也可以以不同于附图中所标注的顺序发生。例如，两个连续的方框实际上可以基本并行地执行，它们有时也可以按相反的顺序执行，这依所涉及的功能而定。也要注意的是，框图和/或流程图中的每个方框、以及框图和/或流程图中的方框的组合，可以用执行规定的功能或动作的专用的基于硬件的系统来实现，或者可以用专用硬件与计算机指令的组合来实现。

以上已经描述了本公开的各实施例，上述说明是示例性的，并非穷尽性的，并且也不限于所披露的各实施例。在不偏离所说明的各实施例的范围和精神的情况下，对于本技术领域的普通技术人员来说许多修改和变更都是显而易见的。本文中所用术语的选择，旨在最好地解释各实施例的原理、实际应用或对市场中技术的技术改进，或者使本技术领域的其它普通技术人员能理解本文披露的各实施例。

Claims

1.一种用于执行测试用例的方法，包括：

获得要被执行的测试用例集合，所述测试用例集合被划分成一个或多个测试子集；

针对所述测试用例集合中的测试用例：

基于知识库确定与所述测试用例相关联的测试平台类型和测试脚本；

根据所述测试平台类型，确定所述测试用例所属的测试子集；以及

基于所述测试脚本，执行所述测试子集中的所述测试用例；以及

基于所述知识库获得所述测试脚本的运行信息，所述运行信息包括所述测试脚本的运行时间信息并且能够用于所述测试用例的所述执行，

其中所述测试用例集合基于所述测试平台类型和所述运行时间信息而被划分成所述一个或多个测试子集，使得所有测试子集的运行时间之差处于阈值范围内。

2.根据权利要求1所述的方法，其中获得要被执行的测试用例集合包括：

基于要被测试的组件集合，通过查询所述知识库来获得所述测试用例集合。

3.根据权利要求1所述的方法，其中执行所述测试子集中的所述测试用例包括：

由多个测试执行引擎并行地执行所述多个测试子集。

4.根据权利要求1所述的方法，其中执行所述测试子集中的所述测试用例包括：

基于所述测试平台类型，实例化针对所述测试平台类型的测试环境；以及

顺序地执行与所述测试子集中的多个测试用例相关联的多个测试脚本。

5.根据权利要求4所述的方法，其中顺序地执行与所述测试子集中的多个测试用例相关联的多个测试脚本包括：

响应于在所述测试子集的执行期间发生多个故障，将与所述多个故障中的第一故障相关联的第一测试用例在次序上调整到与第二故障相关联的第二测试用例之后；

针对调整后的所述多个故障，再次执行与所述多个故障相关联的测试用例。

6.根据权利要求1所述的方法，还包括：

在完成执行所述测试子集之后，从运行日志收集测试结果；以及

基于所收集的测试结果来生成测试报告。

7.根据权利要求1所述的方法，其中所述方法用于自动回归测试，并且所述知识库通过收集历史执行的测试用例而被构建。

8.一种用于执行测试用例的设备，包括：

处理单元；以及

存储器，耦合至所述处理单元并且存储有指令，所述指令在由所述处理单元执行时执行以下动作：

针对所述测试用例集合中的测试用例：

9.根据权利要求8所述的设备，其中获得要被执行的测试用例集合包括：

10.根据权利要求8所述的设备，其中执行所述测试子集中的所述测试用例包括：

由多个测试执行引擎并行地执行所述多个测试子集。

11.根据权利要求8所述的设备，其中执行所述测试子集中的所述测试用例包括：

12.根据权利要求11所述的设备，其中顺序地执行与所述测试子集中的多个测试用例相关联的多个测试脚本包括：

13.根据权利要求8所述的设备，所述动作还包括：

基于所收集的测试结果来生成测试报告。

14.根据权利要求8所述的设备，其中所述设备用于自动回归测试，并且所述知识库通过收集历史执行的测试用例而被构建。

15.一种计算机程序产品，所述计算机程序产品被有形地存储在非瞬态计算机可读介质上并且包括计算机可执行指令，所述计算机可执行指令在被执行时使计算机执行根据权利要求1至7中任一项所述的方法。