CN101933001A

CN101933001A - 在集群系统中执行软件性能测试作业

Info

Publication number: CN101933001A
Application number: CN2009801038836A
Authority: CN
Inventors: 格里史·威泽斯万; 塞潘·帕尼格拉; 丹尼尔·布里多; 斯蒂芬·纳尔逊; 乔治·吴
Original assignee: Yahoo Inc
Current assignee: Yahoo Assets LLC; Yahoo AD Tech LLC
Priority date: 2008-01-31
Filing date: 2009-01-27
Publication date: 2010-12-29
Anticipated expiration: 2029-01-27
Also published as: WO2009099808A1; TW200941214A; CN101933001B; HK1151370A1; US20090199047A1

Abstract

利用测试框架，开发者可以创建测试模块来在多个系统之间为软件测试计划集中资源和结果。利用来自测试框架的辅助，测试模块可以协助实现测试用例的创建、针对每个测试用例的测试作业的执行、每个测试作业期间性能统计信息的收集以及将收集的统计信息汇总成有组织的报告以便更容易分析。测试模块可以跟踪测试结果以便能够容易地比较响应于开发过程的历史期间的各种条件和环境的性能度量。测试框架还可以调度测试作业以便在测试作业所需的各种系统和资源空闲时执行。测试框架可以是独立于操作系统的，从而单个测试作业可以同时在多种系统上测试软件。

Description

在集群系统中执行软件性能测试作业

技术领域

这里描述的本发明的实施例一般地涉及软件性能测试，更具体而言涉及用于生成测试模块和利用所述测试模块执行测试作业的技术。

背景技术

本部分中描述的方法是可以从事的方法，但不一定是先前已经设想到或从事过的方法。因此，除非另有指明，否则不应认为本部分中描述的任何方法仅因为其被包括在本部分中就应被当作是现有技术。

性能测试

性能测试是软件开发的一个必要方面。在整个软件开发过程中，软件开发者通常对构成其软件的各种组件的性能进行测试。性能测试可以提醒软件开发者其代码中潜在的错误或效率低下。例如，性能测试可以暴露出针对软件组件与一个或多个被测的操作系统、硬件设备、软件包或网络环境之间的交互发生的效率低下或非预期的行为。作为另一示例，性能测试还可以提醒软件开发者其软件的各种组件和应用之间的潜在不兼容。

性能测试通常要求在仿真的真实世界条件下在仿真的真实世界环境中运行要测试的软件。例如，开发者可能通过在多个计算机上运行一简单的桌面应用并且测试该应用对多种输入正确响应，从而来测试该应用。更复杂的软件，例如以若干个负载均衡的服务器应用作为一特色的软件套件，可能要求在多个不同的系统上进行大量的测试，其中每个系统与大量的仿真客户端相交互。

测试计划

因为软件通常在整个开发期间必须被测试多次，所以软件开发者经常创建一个或多个测试计划，这些测试计划包括步骤和逻辑，用于(1)在仿真环境中调用各种软件组件的实例，以及(2)自动使得被调用的实例以预定的方式动作(即，仿真的条件)。软件开发者可以利用例如包括以脚本语言编写的代码的执行脚本来描述这种测试计划。执行测试计划中描述的步骤的过程在这里被称为“测试作业”。测试计划在整个开发过程期间可被重新用于测试作业以测试各种代码改变的影响。

另外，测试计划可包括这样一种逻辑，该逻辑用于改变计划的步骤以便计划可用于测试多种环境中的类似条件或者相同环境中的仿真条件的微小变化。测试计划例如可从控制此逻辑的命令行界面或配置文件接受输入。另外，测试计划可包含这样一种逻辑作为一特色，该逻辑用于检测测试计划被用于其中的操作环境，以便根据操作环境来调整计划。对在特定测试作业期间测试的环境或条件进行控制的一组测试参数可被称为“测试用例”。

收集性能统计信息

在测试作业期间，软件开发者可以从测试作业中涉及的各种计算机系统收集性能相关统计信息和事件。性能相关统计信息可包括指示出系统的某些方面在测试作业期间如何动作的多种度量。性能相关事件例如可包括由调试语句、差错语句或其他代码触发的注释所指示出的软件事件。性能相关统计信息和事件可利用由系统的日志生成组件生成的日志来收集，所述日志生成组件包括概要剖析器工具、资源监视器、操作系统、被测软件或被测系统上的任何其他软件包。另外，测试计划本身可包括用于向日志输出性能信息的步骤。手工收集这种统计信息可能是一项烦冗的任务，因为开发者必须在每个被测系统上搜索有关日志并且识别这些日志的与在该被测系统上执行测试作业的时间相关的部分。

因此，软件开发者通常在其测试计划中包括用于自动化统计信息收集的步骤。然而，要将这些步骤编写成代码也是很烦冗的。例如，用于收集统计信息的过程通常对于不同的操作系统是不同的。另外，不同的系统可能运行相同的操作系统，但却运行不同的日志生成组件。在被测软件要被部署在多种操作系统的情况下，这些不同之处使得编写代码以使测试作业期间的统计信息收集自动化的任务进一步复杂。

性能测试中的其他复杂因素

其他障碍增加了软件开发期间测试软件的复杂性。经常很难筛选原始收集的统计信息以分析重要性能指标或测试用例之间的差异。另外，测试计划一般是非常特定于一个应用或者一定类型的软件的，意味着它们不能被重新用于不同软件。还希望调度测试作业以利用诸如CRON之类的系统调度器来运行，以便软件开发者不必手工调用其希望运行的测试作业。然而，由于测试系统通常被用于多种测试作业，所以难以确保在特定系统上调度的测试作业不与另一个调度的测试作业重叠，从而污染了性能结果。

因为在实现测试计划的代码、在多种系统上基于多种测试用例执行测试作业、在每个测试作业期间从这些系统收集统计信息以及分析所收集的统计信息这些任务中的这些和其他困难之处，软件测试通常未被充分利用或者是劳动密集型的，尤其对于企业级软件更是如此。因此希望提高软件测试过程的效率。

附图说明

在附图中以示例方式而非限制方式图示了本发明，附图中类似的标号指代相似的元件，其中：

图1是图示出根据本发明实施例可用于在系统上测试软件应用的测试框架的框图；

图2示出了根据本发明实施例用于利用测试框架来执行对软件应用的性能进行测试的测试作业的流程图；

图3示出了根据本发明实施例用于输入数据以生成测试模块的示例性web界面；

图4示出了根据本发明实施例用于指定与测试模块参数相对应的一组名称-值对的web界面；

图5是根据本发明实施例用于跟踪由测试调度器使用的测试作业队列的示例性web界面；

图6示出了根据本发明实施例用于呈现测试结果的示例性web界面；

图7示出了根据本发明实施例用于查看测试结果中的数据报告的图形表示的示例性web界面；

图8示出了根据本发明实施例用于查看测试结果中的基于文本的数据的示例性web界面；

图9示出了根据本发明实施例用于查看测试结果中的数据报告的图形表示的示例性web界面；

图10是根据本发明实施例用于利用购物车模型构建测试结果中的数据的定制视图的示例性web界面；并且

图11是本发明的实施例可在其上实现的计算机系统的框图。

具体实施方式

在以下描述中，出于说明目的，阐述了许多具体细节以帮助全面理解本发明。然而，很明显，没有这些具体细节也可以实现本发明。在其他情况下，以框图形式示出公知的结构和设备，以避免不必要地模糊本发明。

这里根据以下大纲来描述实施例：

1.0.总概述

2.0.结构概述

3.0.功能概述

4.0.实现示例

4.1.生成测试模块

4.2.管理多个测试模块

4.3.定义测试用例

4.4.调用测试作业

4.5.调度测试作业

4.6.管理测试作业

4.7.收集统计信息

4.8.生成测试结果

4.9.呈现测试结果

4.10.操作系统独立性

4.11.实时监视

5.0实现机制-硬件概述

6.0.扩展和替换

1.0.总概述

公开了用于提高软件性能测试过程的效率的方法、技术和机制。根据一个实施例，用于可以创建测试模块来针对特定测试计划集中资源和结果。利用来自测试框架的辅助，测试模块可以协助实现例如测试用例的创建、针对每个测试用例的测试作业的执行、每个测试作业期间性能统计信息的收集以及将收集的统计信息汇总成有组织的报告以便更容易分析。测试模块可以跟踪测试模块所执行的每个测试作业的测试结果以便能够容易地比较响应于开发过程的历史期间的各种条件和环境的性能度量。

根据一个实施例，用户可以利用测试框架内的测试模块生成器创建测试模块。测试模块生成器可以接受测试计划以及为测试模块定义参数的一个或多个属性作为输入。基于测试计划和一个或多个属性，测试模块生成器可以生成测试模块。一个或多个属性定义的参数可以对应于测试计划的任何可能变化的要素。开发者在经由测试模块创建测试用例时可以向这些参数赋予不同的值。测试模块随后可以针对测试用例执行测试作业。

根据一个实施例，测试模块可以利用测试框架的某些组件来执行通常在测试作业的执行期间或之后执行的某些任务，包括生成用于定义和管理测试用例的用户界面、对测试作业进行集中调度以便它们不会重叠、收集统计信息、汇总统计信息、以及生成用于审查结果的报告界面。测试框架可包括能够独立于被测试的软件或者执行测试作业的操作环境来执行这些任务的组件。在这个过程中，测试框架极大地降低了实现测试计划所需的代码的复杂度和数量。

根据一个实施例，测试框架可用于基于测试用例来执行测试作业。基于测试用例的测试作业的细节被发送到测试管理组件以便解释。测试管理组件可对测试作业进行调度以在测试作业所需的各种系统和资源空闲时执行。基于测试细节，测试管理组件可以调用执行主机上的包括测试计划的执行脚本，从而启动测试作业过程。测试管理组件还可以在测试作业使用的系统上调用日志生成组件。测试管理组件还可以为测试作业提供管理性辅助。当测试作业完成时，测试管理组件可以激活统计信息收集组件，以搜集包含性能统计信息的日志。测试结果生成组件可以对这些日志应用过滤、汇总和其他操作以生成测试结果。测试结果随后可经由由测试报告组件生成的界面被呈现给用户。

根据一个实施例，测试框架可以是独立于操作系统的，从而单个测试作业可同时在运行多种操作系统的多种系统上测试软件。

在其他方面中，本发明涵盖了被配置为执行上述步骤的计算机装置和计算机可读介质。

2.0.结构概述

图1是图示出根据本发明实施例可用于在系统170上测试软件应用180的测试框架110的框图100。图1的元件仅仅是示例性的。本发明的实施例可以不需要图1所示的每个元件。

测试框架110包括若干个组件。这些组件中的每一个可以存在于同一计算机系统上-其可以是也可以不是系统170-或者存在于测试集群172的任何数目的分开的计算机系统上，其中系统170是测试集群172的成员。这些组件之一是测试模块生成器111，其可用于生成测试模块，例如测试模块120。

测试模块

测试模块120是协助实现测试作业(例如测试作业150)的执行的模块。用户可以执行这些测试作业以测试变化的条件下软件应用180的性能。测试模块120例如可以是能够访问测试框架110的独立程序单元。或者，测试模块120可以是由测试框架110根据存储的配置信息生成的对象的实例化。

测试模块120可与测试计划130相关联，测试计划130可包括在测试模块120协助执行的任何测试作业(包括测试作业150)期间实现的步骤。测试模块120可以直接包括测试计划130，或者它可以包括指向测试计划130的位置的指针。测试计划130例如可以是用脚本语言编写的代码的形式。此代码可以被计算机系统直接执行。测试计划130还可以是可以被编译并随后被计算机系统执行的代码的形式。测试计划130还可以是可以被计算机系统直接执行的已编译代码的形式。或者，测试计划130的编译、解释或执行可以由计算机系统上的平台或框架(包括测试框架110本身)来执行。

测试模块120可以接收测试用例(例如测试用例140)作为输入。可经由任何类型的界面(包括命令行或图形用户界面)接收测试用例140。例如，可经由输入到测试模块120的web界面中来接收测试用例140。测试用例可以定义一组条件，该组条件针对特定的测试作业指示出测试计划将如何被执行。例如，当调用包含测试计划130的执行脚本以启动测试作业150时，来自测试用例140的值可用作输入。测试计划130可包括根据输入的值改变测试计划130的步骤的逻辑。从而，每个测试用例140可导致遵循不同步骤并且产生不同结果的一个不同的测试作业150。作为另一示例，测试框架110或测试模块120可以包括依据测试用例140中指定的条件改变测试作业150的部署的逻辑。测试用例140还可以指定来自测试作业150的结果将如何被收集和分析。

测试用例140中指定的条件可以以多种方式来表示，包括名称-值对。例如，测试用例140可以包括诸如“exec_host＝10.1.1.15”之类的名称-值对，其将系统170标识为在其上执行测试计划130的执行脚本的计算机。

测试管理组件

测试框架110还可包括测试管理组件，例如测试管理器112。测试模块120可向测试管理器112发送描述测试作业150的测试细节191。基于测试细节191，测试管理器112可以调用并监督系统170上测试作150的执行。测试管理器112可以利用测试指令192来进行这些操作。测试作业150还可以利用测试反馈193来与测试管理器112交互。

测试管理器112可利用作为测试框架110的另一组件的测试调度器113来确定何时执行测试作业150以避免与其他测试作业同时在系统170上重叠执行测试作业150。虽然被示为测试框架110的独立组件，但测试调度器113也可被嵌入到测试管理器112中。

测试作业150是在系统170上执行测试计划130的步骤的过程。测试作业150在测试用例140中规定的条件下执行测试计划130。例如，测试作业150可以在具有从测试用例140得出的输入参数值的执行脚本中执行测试计划130的步骤。在系统170负责执行测试作业150这个意义上，系统170也可被称为执行主机。

测试作业150可以调用软件应用180并在所述条件下测试其性能。虽然软件应用180被示为存在于系统170上，但软件应用180实际上可以在测试集群172中的任何系统上。测试作业150还可以调用其他软件应用和组件。

统计信息和结果组件

测试框架110还可包括统计信息收集组件，例如统计信息收集器114。统计信息收集器114搜集在测试作业150的执行期间生成的日志160。虽然被示为测试框架110的独立组件，但统计信息收集器114也可被嵌入到测试管理器112中。

在系统170生成或存储日志160这个意义上，系统170也可被称为统计信息主机。日志160是系统事件、软件事件或随着时间的流逝性能度量的值的记录。日志160可包括多种模式的数据，包括CSV、XML、循环式数据文件和基于文本的日志。一般来说，日志160可包括数据行，每行包括时间戳和一个或多个度量值。

日志160可能是由很多种组件来生成的，所述组件包括软件应用180、概要剖析器(Profiler)175或资源监视器176。概要剖析器175可以是任何已知的概要剖析器，例如gprof、VTune或JProfiler。资源监视器176可以是系统提供的，因为其被嵌入在系统170的硬件中或者是作为在系统170上运行的操作系统的一部分提供的。资源监视器176也可是由另一工具(例如测试框架本身)管理的进程。来自测试管理器112或测试计划130的统计信息指令194可以提示和协调这些日志生成组件对日志160的生成。

日志160也可以是由测试作业150利用来自测试计划130内的步骤生成的，这些步骤可以打印调试消息和其他注释以及访问和操纵由上述日志生成组件产生的数据。

测试框架110还可包括统计信息汇总和分析组件，例如测试结果生成器115。测试结果生成器115可以基于日志160执行多种计算以产生与测试作业150相关联的测试结果155。所执行的具体计算可以根据测试框架110、测试模块120或测试用例140中的设置来确定。例如，测试结果生成器115可以去除与测试作业150指定记入日志的时间段之前的时间段相关的任何记入日志的数据。它还可以例如随着时间的流逝或者跨多个系统汇总和平均数据。它还可以突出日志中的某些关键统计信息或趋势。虽然被示为测试框架110的独立组件，但测试结果生成器115也可被嵌入到统计信息收集器114、测试模块120或测试报告器116中。

测试模块120利用测试报告器116来报告关于测试结果155的信息。测试报告器116可以生成能够显示测试结果155中的数据的日志和示图的图形或文本界面。例如，测试报告器116可以包含一种web界面作为一特色，该web界面允许用户从测试结果155中选择各个度量的数据报告来绘出示图。根据一个实施例，这种web界面可以是测试模块120的包括用于输入测试用例140的控件的更扩展的web界面的一部分。虽然被示为独立组件，但测试报告器116也可以是测试模块120的组件，或者它可以是测试框架110的组件，测试模块120与之相接口。

被测软件

根据一个实施例，除了系统170上的软件应用180之外，测试作业150还可调用测试集群172中的任何数目的其他系统上的软件套件的任何数目的组件。实际上，根据一个实施例，测试作业150可以只执行测试集群172中的除系统170外的系统上的软件应用和组件，以消除测试计划140中的开销资源消耗被反映在收集到的统计信息中的可能性。在两种情况下，统计信息收集器114都也可以从这些系统收集日志，或者这些系统可以将其日志转发到测试作业150在其上执行的系统(即，系统170)以供收集。

3.0.功能概述

图2示出了根据本发明实施例用于利用测试框架(例如测试框架110)来执行对软件应用的性能进行测试的测试作业的流程图200。

输入测试模块和测试用例信息

在步骤210中，用户创建测试计划(例如测试计划130)，用于测试一个或多个软件组件(例如软件应用180)的性能。因为测试计划将被用在测试框架内，所以用户不需要包括用于使基于测试计划执行测试作业期间的统计信息的收集、分析和报告自动化的大量步骤。示例性的测试计划在第4.1节中描述。

在步骤220中，用户生成测试模块，例如测试模块120。用于利用测试框架生成测试模块的示例性步骤在第4.1节中论述。

在步骤230中，用户为测试模块的各种参数输入值，这些值形成测试用例，例如测试用例140。用于输入这些值的一些示例性步骤在第4.3节中论述。

在步骤240中，测试模块向测试框架内的测试管理器或测试调度器发送指示出测试作业的数据，例如测试细节191。此数据可以指示出执行测试作业所必要的某些细节，例如包括测试计划、要在其上执行测试计划的一个或多个系统、要在其上执行被测软件的一个或多个系统、从其收集统计信息的一个或多个系统、测试计划中的各种参数的值、以及要搜集的统计信息的类型。测试模块可以为这些细节提供默认值，或者它可根据为测试用例指定的值来确定这些细节。

执行测试作业

在步骤250中，测试管理器确定执行测试作业所必要的资源是空闲的。它例如可利用对在测试系统的集群(例如测试集群172)中的每个系统上执行的测试作业进行监视的测试调度器来进行此操作。用于调度测试作业的示例性技术在第4.5节中论述。

在步骤260中，测试管理器调用测试作业的执行。用于调用测试作业的示例性技术在第4.4节中论述。

在步骤262中，测试作业与在一个或多个系统上被测试的一个或多个软件组件(例如软件应用180)交互。例如，测试作业可以调用一个系统上的服务器软件组件的实例以及另一系统上的客户端软件组件的实例。作为另一示例，测试作业可以向已经运行的客户端软件组件发送命令或数据，以指令其发出已经运行的服务器软件组件的某些请求。

测试作业可以根据测试计划中的预定逻辑来进行此交互。例如，测试作业可以利用由测试计划中的逻辑标识的命令行设置来调用软件组件的实例。测试作业还可以根据测试计划中的根据从测试管理器接收的指令(例如测试指令192)而变化的逻辑来进行此交互。这些指令可能是在步骤260中接收的，或者作为与测试管理器的继续交互的一部分，如下所述。例如，测试作业可以将数据文件输入到软件组件中以便评估。它可以基于测试计划中的将测试计划的执行脚本的调用期间输入的某个名称-值对转化为一文本文件的位置的标识的逻辑来确定该数据文件。

作为此步骤的一部分，测试作业可能还要求与测试管理器交互。例如，测试作业可能需要请求关于在系统故障情况下在其上调用软件组件的备用系统的指令。或者，测试作业可能需要通知测试管理器告知它：它已经进入了测试计划的某些阶段。它例如可以利用测试反馈193来进行此操作。测试作业和测试管理器之间的示例性交互在第4.6节中论述。

在可与步骤262同时发生的步骤264中，测试作业中调用的系统上的若干各种组件中的任何一个生成日志，例如日志160。这些日志例如可由测试作业本身、被测的软件组件、系统概要剖析器、系统资源监视器或者能够生成性能度量的日志的任何其他系统或组件生成。

在步骤266中，测试作业完成。作为测试作业的最终步骤，测试作业可以告知测试管理器其已完成执行。或者，测试管理器可以通过定期监视测试作业过程来发现测试作业已完成。

报告测试结果

在步骤270中，统计信息收集器收集在步骤264中生成的日志。此步骤可以响应于测试管理器确定测试作业已完成而执行。或者，该步骤可以在整个测试作业期间执行(即与步骤262-264并发执行)。收集这些日志的示例性方法在第4.7节中论述。

在步骤280中，测试结果生成器基于所收集的日志而生成测试结果。它可将测试结果发送回测试模块，其中这些测试结果与原始测试用例相关联。它可以例如通过汇总和分析所收集的日志以识别关键统计信息、重要结果、平均资源使用情况或者偏离的性能指标，来生成测试结果。测试结果生成器例如可以去除无关统计信息，例如与测试作业所调用的各种软件组件处于稳定状态的时刻(即，软件成功“启动”并且准备好测试的时刻)之前的时间段相关的统计信息。用于测试结果生成的示例性技术在第4.8节中论述。

根据一个实施例，记入日志的数据也可被直接发送到测试模块，测试模块可以自己汇总和分析该数据以产生测试结果中的一些或全部。

在步骤290中，测试模块向用户显示测试结果。例如，测试模块可以呈现测试结果中的数据的示图、表格或纯文本视图。它可以利用文本或图形界面来进行此操作，例如提供用于过滤或选择测试结果中的各种数据元素的控件的交互性web界面。呈现测试结果的示例性技术在第4.9节中论述。

流程图200的步骤只是示例性的-本发明的实施例可以以这些步骤的顺序上的和实现上的多种变化作为一特色。例如，测试模块可以直接调用测试作业的执行，而不要求步骤240和250。或者，测试管理器可以不使用调度器，从而消除了对步骤250的需要。

4.0.实现示例

4.1.生成测试模块

用户可以利用测试框架(例如测试框架110)来为测试计划(例如测试计划130)生成测试模块(例如测试模块120)。为此，用户可以向测试框架中的测试模块生成器(例如测试模块生成器111)发送指示出期望的测试模块的特性的数据。

示例性测试计划

如前所述，用户可以以多种形式来表示测试计划。存储在名为simple_script.pl的执行脚本中的以下PERL代码是一个这种示例性表示。具体而言，以下代码是涉及测试文件拷贝命令的性能的简单测试计划。

#！/usr/bin/perl

use strict；

use warnings；

use Fatal；

use File::Copy；

MAIN:{

my($file，$number_of_times)＝@ARGV；

#Say when the actual testing started

send_feedback(′START_EXECUTION′)；

#Run our command multiple times

for(0..$number_of_times){

copy($file，″file_copied″)

or die″Couldn′t copy ′$file′to′file_copied′：$！′″；

}

#Say when the actual testing ended

send_feedback(′END_EXECUTION′)；

}

sub send_feedback{

my($file)＝@_；

open(my $fh，′＞′，″log/$file″)；

print $fh time()，″\n″；

close($fh)；

}

测试模块生成数据

用户可以利用包括文本或图形界面在内的多种手段来发送指示出测试模块的特性的数据。图3是一个这种界面。图3示出了根据本发明实施例用于输入数据以生成测试模块的示例性web界面300。web界面300可以由测试模块生成器或测试框架的另一组件生成。

发送到测试模块生成器的数据可包括标识由测试模块执行的所有测试作业都应基于的测试计划的数据。例如，如文本框316所示，用户可以通过指定执行脚本或包含测试计划的步骤的其他资源的位置来标识测试计划。或者，发送到测试模块生成器的n数据可包括指定测试计划的实际步骤的数据。

测试模块参数的属性

发送到测试模块生成器的数据还可包括测试模块的参数的一个或多个属性。控件321和322图示了用于指定这种属性的一种方法。基于这些属性，测试模块生成器可以将可定制的参数结合到测试模块中。例如，用户可以利用控件322来指定一属性。用户可以指定属性名称“count”(计数)，如字段322a中所示。测试模块生成器可以将此属性结合到测试模块中，作为用于设置测试作业反复经过测试计划所测试的功能的次数的类似命名的参数。

根据一个实施例，属性可以包括指定参数的默认值的信息。例如，用户可以指定诸如“％NUM_STATS_HOSTS％＝100”之类的属性，测试模块生成器可将其结合到测试模块作为NUM_STATS_HOSTS参数，其默认值为100。作为另一示例，web界面300的字段322d是用于指定经由控件322输入的“count”属性的默认值的控件。此外，属性可包括指定测试用例是否可改变此参数的值的信息，例如指示出值被“锁定”的标签。

根据一个实施例，每个属性可以包括指定要被用于选择将为该属性生成的参数的值的控件类型的信息。示例性的控件类型可包括标准HTML形式控件，例如文本框、复选框或者下拉列表。此控件信息可被测试模块用于为参数生成界面，如以下第4.2节所述。例如，web界面300的控件322包括允许选择可用于“count”属性的各种控件类型的字段322b。

每个属性还可包括枚举该属性的可能值的列表的信息。例如，定义名为“Sample Input File”的参数的属性可包括可在测试作业期间被选择来使用的若干个文件的枚举列表。作为另一示例，web界面300的字段322c允许了用户输入“count”属性的可能值的逗号分隔列表。

另外，除了内部名称(利用该内部名称，它将被测试框架所知)之外，每个属性还可包括指定可用来在界面中呈现它的标题的信息。另外，每个属性可包含指定该属性应当如何被使用的后勤信息，例如它是否应当被发送作为执行脚本的参数值，它是否是应当在测试作业之前运行的命令，它是否是应当在测试作业之后运行的命令等等。

按钮350是在被点击时允许用户添加额外属性的按钮。

虽然这些属性的可能用途是无穷的，但是这些属性的共同目的可包括为测试作业的以下操作条件中的任何一个定义参数或设置默认值：要仿真的用户的数目、要在其上执行测试作业的一个或多个系统、要在其上调用测试作业中涉及的各种软件组件的一个或多个系统的位置、在测试作业的执行之前和之后要运行的命令、服务器负载水平、要测试的查询的数目、要收集的数据的类型、被测的数据文件中的数据行的数目、测试数据文件的位置、一个或多个统计信息搜集系统、在何种条件下应当使能概要剖析、以及呈现所收集的数据的方式。

额外测试模块生成信息

web界面300包括用于指定测试模块生成的额外信息的多个控件。控件311是用于输入被测试的软件的产品名称的文本框图。控件312是用于输入测试框架所知的测试模块的内部名称的文本框。控件313是用于输入用户所知的测试模块的模块标题的文本框。控件314是用于输入测试模块的描述以便用户可容易确定模块的目的的文本框。控件315是用于输入标识模块的所有者的用户名的文本框。此所有者可能能够向其他用户赋予访问测试模块的许可。控件317是复选框，该复选框在被选中时指示出该测试模块可与其他测试作业同时共享执行主机。

控件331是使得测试模块能够在执行测试作业之前调用某些命令的复选框。控件332是使得测试模块能够在执行测试作业之后调用某些命令的复选框。控件333是使得测试模块能够在测试作业期间发生差错的情况下调用某些命令的复选框。控件334是使得测试模块能够在测试作业报告其已成功执行的情况下调用某些命令的复选框。控件335使能在基于测试模块执行测试作业期间进行概要剖析。

提交数据和生成测试模块

按钮340允许在框316中指定了测试计划并且在控件321和322中指定了属性的用户发送指定的数据到测试模块生成器以便处理。在接收到指定的数据后，测试模块生成器可以基于指定的数据来生成测试模块。

根据一个实施例，测试模块生成器可以以代码或已编译的可执行文件的形式来生成测试模块。代码或已编译的可执行文件可以是单独的，或者可以依赖于测试框架所暴露出的库。用户一旦希望访问测试模块功能或界面，就可以执行该代码或可执行文件。

根据一个实施例，测试模块生成器可以改为将测试模块表示为测试框架可访问的数据库或文件系统中的数据。为了访问测试模块，用户可以向测试框架发出命令，以实例化测试模块。测试框架可以基于数据库或文件系统中的表示数据来实例化测试模块。

默认参数

根据一个实施例，测试模块生成器还可为测试模块生成不基于任何接收到的属性的额外参数。例如，在不存在标识在其上执行测试作业的系统的属性的情况下，测试模块生成器可以在测试模块中结合用于选择在其上执行测试作业的任何数目的默认系统之一的参数。

测试模块模板

根据一个实施例，用户可以定义一测试模块为测试模块模板。当创建后续测试模块时，用户可以指示出其希望利用测试模块模板来构建测试模块。在同一测试模块模板上构建的测试模块可以共享与测试模块模板的继承关系。为测试模块模板定义的任何属性都将在后续测试模块中自动预设。用户随后可以在生成测试模块之前根据其希望来改变属性。或者，后续测试模块中的基于模板的属性可被锁定，使得用户不可改变它们。

根据一个实施例，测试模块和测试模块模板之间的继承关系可能在测试模块的整个生存期期间持续。从而，如果以任何方式为测试模块模板修改了一属性，则也将为测试模块修改该属性。这可能要求测试模块被重新生成。

4.2.管理多个测试模块

用户可以为任何数目的软件应用或软件套件生成任何数目的测试模块。实际上，因为用户可能具有用于测试关于软件应用的不同方面的性能的多个测试计划，所以用户可以为任何给定的软件产品生成任何数目的测试模块。为了帮助用户跟踪所生成的测试模块，测试框架可以提供用于访问、更新和删除测试模块的测试模块管理界面。此界面可以列出测试框架所生成的所有测试模块，并且可例如按照它们测试的软件的产品名称(例如web界面300的控件311中指定的产品名称)来排列它们。

4.3.定义测试用例

一旦测试模块已被生成，用户就可利用测试模块来启动测试作业。为此，用户可以首先向测试模块发送一组一个或多个名称-值对。每个名称-值对中的名称可对应于测试模块的相同名称的参数。这组一个或多个名称-值对可被认为是测试用例，例如测试用例140。用户可以利用图形的和文本的多种界面来将此测试用例发送到测试模块。例如，用户可以在数据库或结构化数据文件中定义多个测试用例，这些测试用例随后可被测试模块全都同时读取，或者根据自动化调度来逐一读取。

作为另一示例，图4示出了根据本发明实施例用于指定与测试模块参数相对应的一组名称-值对的web界面400。web界面400包括控件410，其中每个控件与一参数相关联。对于任何控件410，用户可以指定值。测试模块随后可使用此值以及相关联的参数的名称作为测试用例的名称-值对。

在web界面400中请求其值的参数中的一些可对应于被测试模块生成器利用第4.1节中说明的技术结合到测试模块中的参数。例如，图3中的控件322被示为接受名为“count”的属性作为输入。如第4.1节中说明的，此属性可用于将名为“count”的参数结合到测试模块中。如字段322b中所指定的，在文本框控件中请求web界面400中的计数参数的输入。具体而言，web界面400包括用于接收与这个结合的参数相对应的输入的控件422。类似地，web界面400包含对应于为web界面300的控件321输入的值的控件421。

在web界面400请求其值的其他参数可能是从在测试模块生成期间在web界面300中指定的其他属性得出的。例如，控件431、432和433分别请求用于使能概要剖析、概要开始延迟和概要长度的值。这些控件可能是响应于用户选中了web界面300中的框335、从而为测试模块生成发送一指示出应当为测试模块使能概要剖析的属性，而生成的。类似地，为在测试作业之前和之后要启动的命令请求值的控件434和435可能分别是响应于用户选中了web界面300中的框331和332而得出的。

在web界面400请求其值的其他参数可以为任何测试模块普遍提供。web界面400中的以下控件是这种普遍参数的示例：控件411，指定测试用例的用户可读标题；控件412，指定测试用例的用户可读描述，以便帮助用户迅速识别测试用例的目的；控件413，指定一个或多个执行主机的名称或地址，每一个由逗号分隔；控件414，指定一个或多个统计信息主机的名称或地址，每一个由逗号分隔；控件415，指定一个或多个预留主机的名称或地址，每一个由逗号分隔，并且每一个不得被任何其他测试作业使用以便此测试用例所标识的测试作业运行；以及控件418，指定可作为参数被传递到用于执行与测试模块相关联的测试计划的执行脚本的额外配置选项。

控件401是普遍提供的参数的另一示例。控件401允许用户指定此测试用例的测试用例标识符，该标识符可用于在测试模块中和测试框架中内部表示测试用例。如果此值为空，则测试模块将赋予默认值。

web界面400还可包括一按钮，该按钮在被点击时将把在控件410中指定的所有值以及每个值的相应字段名称发送到测试模块作为测试用例。

测试用例模板

根据一个实施例，用户可以定义一测试用例为测试用例模板。当创建后续测试用例时，用户可以指示出其希望利用测试用例模板来构建测试用例。在同一测试用例模板上构建的测试用例可以共享与测试用例模板的继承关系。为测试用例模板定义的任何值都将为后续测试用例中的相同参数自动预设。用户随后可以根据其希望来改变这些值。或者，后续测试用例中的基于模板的值可被锁定，使得用户不可改变它们。

4.4.调用测试作业

根据一个实施例，在接收到测试用例(例如测试用例140)后，测试模块(例如测试模块120)可以间接调用测试作业(例如测试作业150)的执行。为此，测试模块可以向测试管理组件(例如测试管理器112)发送关于测试作业的细节(例如测试细节191)。测试模块可以通过多种方式来发送这些测试细节，例如通过由测试管理器打开的专用端口或者作为插入到测试管理器能够访问的数据库中的行。测试管理器随后可以确定如何以及何时调用测试作业的执行。

测试细节

测试模块可在接收到测试用例后立即将这些测试细节发送到测试管理器。或者，它可以在发送测试细节之前等待额外的输入。例如，测试模块可以包括用于存储若干个接收到的测试用例的装置，这些测试用例中的每一个可与一标识符相关联。此标识符可能是在测试用例被接收到时由测试模块指派的，或者是通过作为测试用例本身的一部分输入的值指派的。当用户希望根据这些存储的测试用例之一调用测试作业的执行时，用户可发送指示出期望的测试用例的标识符的输入。

测试细节可以向测试管理器指示出关于如何执行测试作业或者如何为测试作业生成和收集结果的信息。此信息例如可包括测试模块的测试计划以及反映在测试用例中指定或者被硬编码到测试模块中的名称-值对的一个或多个属性。测试细节中的信息还可包括测试模块可能已从测试用例得出的或者可能已被硬编码到测试模块中的其他指令。

在接收到关于测试作业的测试细节后，测试管理器可确定如何利用这些测试细节来调用、管理测试作业以及从测试作业收集结果。例如，测试管理器可以在测试细节中查找具有某个预定的名称的属性或者标识在调用测试作业之前在系统上要加载的先决条件的某个预定的指令。作为另一示例，测试管理器可以搜索在调用测试作业时要使用的命令行参数的属性或指令。如果测试细节不包括与测试作业的所需细节相对应的指令或属性，则测试管理器可以根据由测试框架提供的默认指令来确定所需细节。

在执行主机上调用执行脚本

根据一个实施例，测试管理器可确定的一个细节是在其上调用测试作业的执行的一个或多个(例如系统170)的位置。这种系统可被称为“执行主机”。例如，测试管理器可以寻找测试细节中的包括诸如“exec_host＝10.1.1.15”之类的名称-值对的属性。根据此名称-值对，测试管理器可以确定IP地址为10.1.1.15的系统应当被用作执行主机。

作为另一示例，测试管理器可以在测试细节中寻找使用具有某些必要特征(例如一定量的安装的存储器、某种安装的软件或者一定数目的处理器)的任何两个可用系统作为执行主机的指令。测试管理器可以通过参考测试管理器已获取的关于测试框架能够访问的一个或多个指定的测试系统的特征的信息来根据这些指令确定两个执行主机。它还可监视这些指定的测试系统上的资源使用情况，以确定哪些系统当前可用。指定的测试系统可能是通过测试框架的配置接口来指定的，或者可能是由于其连接到测试集群而被指定的。

为了调用执行主机上测试作业的执行，测试管理器可以向执行主机发送测试指令(例如测试指令192)。这些测试指令可以被执行主机以使得执行主机开始执行测试作业的方式来解释。例如，测试指令可包括命令行语句，该语句按名称来引用包含测试计划的步骤的脚本或可执行文件。这种脚本或可执行文件也可以被称为“执行脚本”。测试管理器可以利用多种机制向执行脚本发送测试指令，所述机制包括远程过程调用、安全外壳或telnet会话中的命令、或者经由由测试框架管理的进程操作的专用端口的命令。

如果执行主机对于测试指令没有响应，或者如果执行主机发送指示出它无法执行测试作业的测试反馈，则测试管理器可以采取若干动作之一。测试管理器可以采取的一个动作是向测试模块返回指示出测试作业失败的测试结果。测试管理器可以采取的另一动作是在测试细节中查找指示出其可改为在其上调用测试作业的一个或多个备用执行主机的信息。或者，测试管理器可以从为测试框架定义的执行主机的默认列表中选择备用执行主机。测试管理器可以采取的另一动作是查找测试框架可访问的、拥有与执行主机的质量类似的质量的替换系统，并且尝试使用该替换系统作为执行主机。

一旦执行主机已接收到具有调用测试作业的指令的消息，它即可以利用对于包含测试作业的测试计划的执行脚本来说适当的任何手段来调用测试作业。例如，如果测试计划是用Java或C++来编写的，则执行主机可以编译执行脚本，然后运行它。如果测试计划是以经解释的语言来编写的，例如用外壳脚本或PERL脚本来编写的，则执行主机将立即开始解释执行脚本。

测试指令中的额外信息

测试指令可包括其他信息。例如，测试管理器可包括与用于改变测试计划的参数相对应的名称-值对作为启动执行脚本的命令行语句的一部分。例如，如果执行脚本被命名为“testscript.pl”，则调用执行脚本的命令将为“testscript.pl-load 1000”，其中“-load 1000”将测试计划中名称为“load”的参数的值设置为1000。测试管理器可以利用其从测试模块接收到的测试细节来确定要输入到测试计划中的名称-值对。根据一个实施例，测试管理器可以将其在测试细节中接收到的所有名称-值对包括作为调用命令行语句的一部分。或者，它可以只发送未以其他方式用于预定的测试框架功能的属性的名称-值对。

对于只接受经由命令行的参数值而不接受名称-值对的执行脚本，测试管理器可以在命令行语句中仅包括值。例如，考虑与图4的web界面400的控件421和422相对应的参数。测试模块可能向测试管理器发送了包括这两个参数的名称和为这两个参数指定的值的属性。然而，测试管理器可能不具有与计数或文件属性相关联的任何功能。因此，测试管理器可以在用于执行该执行主机的命令行中传递计数和文件属性的值。这些值可以按它们被列出的顺序被传递。从而，由于web界面400中指定的执行脚本是simple_script.pl，因此调用命令可以是“simple_script.pl sample_file 50”。simple_script.pl包含被配置为分别将这些值自动识别为$file和$number_of_times变量的值的测试计划。

测试指令还可包括其他命令。例如，测试指令可包括为特定测试作业准备系统的环境的命令。这种命令可以设置环境变量、预留执行主机上的资源、启动所需的进程、或者确保资源依赖性已得到满足。实际上，测试管理器可包括在执行主机上没有必要资源的情况下拷贝或安装必要资源的命令。例如，如果执行主机不能访问执行脚本，则测试管理器可以将执行脚本拷贝到执行主机。如果必要，测试管理器还可以发出编译执行脚本的命令。作为另一示例，测试管理器可以发出在执行主机上安装测试作业所要求的某些包的命令，如第4.6节中所述。

测试管理器可以利用它在测试细节中接收的属性得出其他命令用于包括在初始化测试指令中。例如，测试管理器可以确定某个预定的名称包括要在执行主机上在执行脚本前执行的一个或多个命令。控件434的参数是一个这种属性的示例。此策略可被扩展到可在除启动执行脚本之前以外的其他时间在测试指令中发出的命令。例如，测试管理器可以查找与一属性相关联的后勤信息，该后勤信息(1)指示出该属性的值是要在执行主机运行的命令；并且(2)标识用于运行该命令的一个或多个条件，例如在测试作业之前或之后，或者在测试作业成功或失败时。

变化

根据一个实施例，测试管理器不是将某些名称-值对作为输入提供到执行脚本的参数，而是可以将某些名称-值对保存到执行主机的可由执行脚本访问的配置文件中。或者，执行脚本可以包括用于向测试管理器发送测试反馈(例如测试反馈193)的逻辑。此测试反馈可包括对测试管理器发送指示出某些参数的值的后续测试指令的请求。

根据一个实施例，测试模块可以改为利用与测试管理器用来调用测试作业的过程很大程度上相同的过程来直接调用测试作业的执行。在接收到测试用例后，测试模块可以立即基于其测试计划和测试用例来调用测试作业的执行。或者，测试模块可以等待为接收到的测试用例调用测试作业，直到其接收到这么做的命令为止。

根据一个实施例，测试管理器可以自己运行测试计划的步骤，而不是在执行主机上调用执行脚本。

4.5.调度测试作业

根据一个实施例，测试管理器不是在接收到测试细节后立即调用测试作业，而是可以利用调度组件(例如测试调度器113)来调度测试作业以便以后执行。为此，测试管理器可以向测试调度器传递某些调度细节。测试管理器可以从测试细节得出这些调度细节，或者在测试细节中不存在足以得出调度细节的信息的情况下，它可以传递默认调度细节。

调度细节例如可包括开始时间和测试用例标识符。测试管理器可以根据测试细节中的start_time属性和test_id属性来得出开始时间和测试用例标识符，而start_time属性和test_id属性进而又可反映来自原始测试用例的名称-值对。调度细节还可包括资源使用信息，其标识了测试作业所必需的资源。例如，调度细节可定义在测试作业中将涉及的特定系统，包括执行主机、统计信息主机和预留主机。然而，如果例如测试模块是在共享执行主机设置被使能的情况下生成的，则一些实施例可能不要求执行主机完全空闲。

在接收到调度细节后，测试调度器可以将调度细节与先前接收到的其他测试作业的调度细节一起存储在作业队列中。此作业队列例如可存在于测试框架可访问的数据库中。测试调度器可以例行地监视该队列，以判定是否应当通知测试管理器到启动某个测试作业的时间了。例如，如果一测试作业的调度细节指示出特定的开始时间，并且当前系统时间等于或者过了该特定开始时间，则测试调度器可以通知测试管理器到启动测试作业的时间了。

作为另一示例，测试作业的调度细节可以包括资源使用信息，例如指示出测试作业需要系统X、Y和Z的信息。测试调度器可以将该资源使用信息与资源可用性信息相比较，以判定测试作业是否有必要资源可用。例如，测试调度器可以存储指示出哪些系统当前在运行测试作业的信息。或者，测试调度器可以监视测试框架可访问的每个系统上的进程和处理器使用情况。如果资源可用性信息指示出系统X、Y和Z都可用，则测试调度器可以确定到启动测试作业的时间了。

测试调度器还可以使用开始时间信息结合资源使用信息来确定何时运行测试作业。从而，测试调度器可以仅在测试作业需要的资源在测试作业的指定开始时间之后可用时才确定到启动测试作业的时间了。

当测试调度器确定到时间启动测试作业时，它可以通知测试管理器到调用测试作业的时间了。在接收到这种通知后，测试管理器随后可调用测试作业，如第4.4节中所述。这种通知可以采取测试用例标识符的形式，在此情况下测试管理器使用测试用例标识符来从包含先前接收到的测试作业的存储中检索测试的测试细节。或者，调度细节可包括了测试作业的所有测试细节。调度器可以将这些测试细节重发送到测试管理器以便立即处理。

变化

根据一个实施例，调度细节可以定义测试作业所必需的系统的质量和数量。当调度器确定具有必要质量和资源的必要数量的系统可用时，调度器可确定到启动测试作业的时间了。作为其对测试管理器的指令的一部分，调度器随后可确切限定哪些系统可用。测试管理器随后可在管理测试作业时使用此信息-例如，它可以使用此信息来识别一个或多个执行主机和一个或多个统计信息主机。测试管理器还可以将此信息作为初始测试指令的一部分发送到执行主机，以使得测试作业可以确定在其上执行被测试的软件的各种组件的一个或多个可用系统。

根据一个实施例，测试调度器可以使用冲突解决和资源使用优化例程来确保测试作业队列中的多个测试作业以及时、高效的方式被执行。测试调度器还可以利用调度细节中的优先级区分信息。因此，例如，测试调度器可能能够比其通常遍历队列时更迅速地在队列中推进优先的测试作业。

根据一个实施例，测试调度器可以预留资源使用信息所指示出的资源以供将来使用，以便确保测试作业将具有充分的资源。例如，测试调度器可以预留一组系统以便在测试作业的开始时间使用，从而确保届时没有其他进程在使用系统的资源。作为另一示例，测试调度器可以向一系统发送指令，以禁止新测试作业使用该系统，直到特定的测试作业已结束使用该系统为止。

根据一个实施例，测试调度器能够例行监视测试作业的队列，因为它是连续运行的进程。或者，测试调度器可以被诸如CRON之类的系统调度器定期调用。每当测试调度器被调用时，测试调度器就可以为作业队列中的每个测试作业检查测试作业的调度细节，以便判定是否到时间启动该测试作业。它还可以使用这些调度细节来确定在何时系统调度器应当接下来调用测试调度器。

根据一个实施例，测试模块可以经由测试调度器向测试管理器发送测试细节，而不是直接向测试管理器发送测试细节。例如，测试模块可以将测试细节直接插入到测试调度器所维护的数据库中的一行或多行中。利用测试细节，或者在测试细节没有提供对开始时间或必要资源的指示的情况下利用默认信息，调度组件可以基于测试细节确定何时启动测试作业。它随后可将测试细节传递到测试管理器或者以其他方式指令测试管理器如何找到测试细节。

根据一个实施例，每个执行主机可以运行其自己的测试调度和测试管理进程。这样，测试框架可以确保一个系统的故障将不会导致测试框架中的所有测试作业的丢失。分开的测试调度器和测试管理进程可以与测试框架的中央调度器和测试管理器协同工作，以获得冗余性。

用于跟踪测试作业队列的界面

图5是根据本发明实施例用于跟踪由测试调度器(例如测试调度器113)使用的测试作业队列的示例性web界面500。web界面500可由测试调度器或测试框架的另一组件提供。

web界面500包括表格510和560，它们分别与名为Indexer和snt_a20的测试模块相关联。表格510包括行520和行530，而表格560包括行570。行520和530对应于Indexer测试模块的测试作业，这些测试作业具有标识符1417和1418。行570对应于snt_a20模块的具有标识符1433的测试作业。

行520的状态列指示出测试作业1417当前正在执行，而行530的状态列指示出测试作业1418当前在等待执行。实际上，测试作业1418将等待执行，直到测试作业1417结束执行为止，这是因为如行520和530中每一个的主机名列所指示出的，测试作业1418定义了至少一个与测试作业1417相同的必要资源。同时，如行570的状态列所指示出的，测试作业1433正在执行，但它是在测试作业1417之后启动的，这是因为如主机名列所指示出的，测试作业1433没有列出与测试作业1417相同的任何必要资源。

根据一个实施例，web界面500可包含控件，用于强制测试作业队列中的一个或多个测试作业的状态改变。另外，web界面500可包含用于改变行520、530和570中每一个的优先级列中的值的控件。

4.6.管理测试作业

一旦测试作业的执行脚本已在执行主机上被启动，则执行主机将根据它接收到的作为执行脚本的参数的输入的任何值来执行测试计划的各种步骤。如前所述，测试作业可以执行任何数目的任务来测试软件性能，例如调用或发送输入到各种软件组件。一旦被启动，执行脚本就可以很大程度上在没有来自测试管理器的输入的情况下进行。

然而，在一些情况下，测试管理器可能需要执行某些管理性任务来辅助测试作业。在这些情况下，测试计划可被设计为向测试管理器发送测试反馈(例如测试反馈193)，以指示出测试作业要求执行管理性任务。

提供额外或备用参数值

测试作业可请求测试管理器执行的一个管理性任务是提供在初始测试指令中可能没有提供的额外测试细节。例如，测试管理器可能没有为测试计划所需要的每个参数提交值。测试作业可以提交为某个参数请求值的测试反馈。此测试反馈例如可经由由测试管理器使用的专用端口或者由测试框架暴露出的到测试管理器的API来提交。测试管理器可以经由该专用端口通过测试指令来返回相应值。

作为管理性任务的另一示例，测试计划可能要求使用当前不可用的系统。测试作业可以响应于检测到该系统不可用而提交请求测试管理器识别测试作业能够使用的另一系统的测试反馈。测试管理器可能能够利用例如在测试细节中标识的备用系统的列表或者为测试框架指定的备用系统的默认列表来定位适合的系统。或者，测试管理器可以识别测试框架能够访问的、在配置上类似于该不可用的系统的另一系统。另一替换方式可以是测试管理器认为测试作业失败了并且返回指示出失败的测试结果。

作为管理性任务的另一示例，测试计划可能知道其需要一定数目的统计信息主机，但不知晓可用统计信息主机可能位于何处。它可向测试管理器发送反馈，请求分配一定数目的统计信息主机。测试管理器(可能连同调度器)可以从测试集群中的一组空闲系统中分配该一定数目的统计信息主机。测试管理器可以返回标识每个所分配的统计信息主机的测试指令。测试管理器也可以为所分配的统计信息主机执行各种初始化任务。

资源依赖性任务

测试管理器可执行的管理性任务的另一示例是对测试作业中涉及的系统的资源依赖性管理。测试管理器可以在调用测试作业之前主动执行此任务，也可以根据测试模块的请求执行此任务。为了执行此任务，测试管理器需要知晓测试作业中将涉及的系统中的至少一些，以及测试作业所需的资源中的至少一些。

在调用测试作业之前，测试管理器可利用它为测试作业接收的测试细节来确定所述系统或资源。例如，测试细节可包含明确指定所述系统和资源的指令或属性。或者，测试管理器可能能够通过分析测试计划或者被测软件的代码来辨别此信息中的至少一些。另外，测试管理器可以基于测试框架的默认资源列表来猜测测试作业可能需要的一些资源。此默认资源列表可以针对被测软件具体定义、针对测试作业使用的代码编写语言具体定义或者为所有测试作业一般性地定义。

在测试管理器调用测试作业之后，测试作业本身可向测试管理器发送测试反馈，该测试反馈标识出一个或多个系统，在这些系统上，测试管理器应当确保某些资源可用。测试计划可包含用于经由例如专用端口或API将此测试反馈发送到测试管理器的逻辑。

在确定或接收指示出在其上确保一个或多个资源已被安装的一个或多个系统的指令之后，测试管理器可以使用若干种方法来确保在所指示出的一个或多个系统上这一个或多个资源将是可用的。例如，如果所指示出的资源是软件应用或包，则测试管理器可以联络所指示出的系统上的包管理组件并且请求该包管理组件识别软件应用或包的哪个版本(如果有的话)被安装。这种包管理组件可以由所指示出的系统的操作系统提供，由安装在所指示出的系统上的开发平台提供，或者以其他方式安装在所指示出的系统上。如果包管理组件指示出对于测试作业来说不充分的版本，或者没有安装这种软件，则测试管理器可以向包管理组件发送指令，这些指令将使得它安装软件应用或包的期望版本。它还可以指令包管理组件安装所指示出的软件应用或包的期望版本可依赖于的其他软件应用或包的任何其他版本。

测试管理器可确保在所指示出的系统上可用的资源的其他示例可包括测试文件和数据库。例如，被测软件可利用某些文件来执行被测功能。这些文件可配置被测软件、作为被测软件的输入被处理、或者以其他方式控制被测软件的行为。测试管理器可以将这些文件的测试版本拷贝到所指示出的系统。作为另一示例，被测软件可以处理来自数据库的数据。测试管理器可以确保在所指示出的系统上的数据库中存在特定的一组测试数据。

或者，测试管理器可以采取更直接的步骤来确保资源被安装在所指示出的系统上。它例如可以尝试通过分析所指示出的系统的注册表或文件系统中的信息来发现所安装的软件应用的版本。或者，它可以尝试通过将软件的文件直接拷贝到所指示出的系统来更直接地安装软件应用或包的期望版本。它还可以尝试调用安装进程来在系统上安装软件的期望版本。根据一个实施例，测试框架可以在所指示出的系统上执行系统管理进程，以执行这些步骤中的一些或全部。

统计信息相关任务

测试作业还可以请求测试管理器执行与生成统计信息和性能日志相关的某些任务。测试作业例如可以向测试管理器发送测试反馈，请求指示出状态事件-即，测试作业已进入或离开某个状态。测试管理器可被配置为为测试作业维护指示出其何时进入或离开各种状态的状态数据。它随后可将此状态数据发送到统计信息收集组件或测试结果生成组件，以用于生成测试结果，如4.8中所述。

测试作业可以定义任何数目的状态，例如准备就绪状态、繁忙状态、稳定状态、执行状态，等等。例如，当测试作业已经完成了某些初始化任务(这些任务的性能统计信息可能是无关的)时，可以认为测试作业已进入了执行状态。当处理器使用率超过预定的百分比时，可以认为测试作业进入了繁忙状态。当软件差错发生时，可以认为测试作业进入了差错状态。测试作业可定义与特定软件功能、软件交互或软件执行的阶段相关的其他状态。

测试管理器还可被配置为在接收到指示出某些预定状态的测试反馈时，向被总称为统计信息主机的一组系统上的性能监视组件(例如概要剖析器195或资源监视器176)发送统计信息指令，例如统计信息指令194。根据一个实施例，在测试作业期间用于测试软件的每个系统可被认为是统计信息主机。或者，只有被测试作业使用的某些系统可被指定为统计信息主机。测试细节可以按与测试细节指定一个或多个执行主机的方式很大程度上相同的方式指定这些统计信息主机。另外，测试作业本身可以指定或确定一组统计信息主机，并且测试作业可以向测试管理器标识这些统计信息主机。

统计信息指令可包括使得性能监视组件开始或结束将性能统计信息记入日志的命令。例如，响应于指示出差错状态或繁忙状态的测试反馈，测试管理器可被配置为发送指令概要剖析器开始将数据记入日志的统计信息指令。作为另一示例，响应于指示出准备就绪状态的测试反馈，测试管理器可以向测试反馈或测试细节所指定的某些类别的性能监视组件发送开始记入日志的统计信息指令。作为另一示例，响应于指示出准备就绪状态结束的测试反馈，测试管理器可以发送指令性能监视组件将记入日志的数据发送到统计信息收集器114或中央仓库以便收集执行主机上的统计信息的统计信息指令。

根据一个实施例，测试作业可以请求测试管理器在一个或多个特定系统上或者在测试作业中使用的所有系统上启动概要剖析器。作为响应，测试管理器可以向所指示出的一个或多个系统发送统计信息指令。统计信息指令可包括在被接收方系统执行时调用概要剖析器的命令。

根据一个实施例，可改由统计信息收集器发送上述统计信息指令。响应于接收到请求执行统计信息相关任务的测试反馈，测试管理器可以将该请求传递到统计信息收集组件，例如统计信息收集器114。统计信息收集器随后可执行统计信息相关任务。

根据一个实施例，统计信息主机不一定是在其上执行被测软件的系统。更确切地说，统计信息主机可以是运行一个进程的系统，该进程使得它可以监视和监督正在执行被测软件的其他系统上的性能日志的生成。

结束测试作业

测试管理器还可以负责在检测到测试作业已完成时执行某些管理性任务。它可以例如通过监视执行主机上的执行脚本进程来检测测试作业的完成。它还可监视其他测试作业进程。或者，测试作业可以发送测试反馈，以通知测试管理器测试作业已完成。

如果测试管理器原本接收的测试细节包含了指示出在测试作业结束时要在执行主机上执行的一个或多个命令的指令或属性，则测试管理器此时可以向执行主机发送具有这些命令的测试指令。这些命令可以对所收集的性能日志执行多种操作。这些命令还可以清除临时文件或将执行主机的环境恢复到其在测试管理器调用测试作业之前的状况。

测试管理器还可以指令调度器在此时取消对测试作业中涉及的系统的预留，以便调度器可以从测试作业队列中起动新测试作业。

测试管理器还可以经由例如电子邮件消息来通知用户测试作业已完成。电子邮件消息可包括到用于查看测试结果的界面(例如第4.9节中论述的web界面)的链接。

根据一个实施例，测试管理器随后可指令统计信息收集器(例如统计信息收集器114)开始收集和处理在测试作业期间生成的性能统计信息。收集性能统计信息在以下第4.7节中论述。

经由文件系统发送测试反馈

根据一个实施例，测试作业可以经由文件系统向测试管理器递送测试反馈，例如测试反馈193。测试作业可以在测试作业和测试管理器均可访问的文件系统中创建文件。例如，测试作业可以将这些文件写入到系统170上的文件系统中的共享目录。

测试管理器可以定期监视其共享目录以发现新文件。测试管理器可以将具有某些预定名称的文件解释为测试反馈。例如，如果它看到名为START_PROFILER的文件，则测试管理器将把该文件解释为请求测试管理器在测试作业所使用的系统上启动概要剖析器的测试反馈。类似地，名为BEGIN_EXECUTION_STATE的文件可被解释为指示出准备就绪状态。

测试作业还可以在文件内容内包括测试反馈。例如，它可以使用START_PROFILER文件的内容来指示出在其上启动概要剖析器的系统。实际上，在一些实施例中，测试作业可以仅通过文件内容来传达测试反馈-文件的名称可能仅因为其向测试管理器指示出该文件包含测试反馈而相关。作为另一示例，在第4.1节中呈现的示例性执行脚本simple_test.pl的测试计划包括通过向文件系统写入具有指定名称的文件来发送测试细节的send_feedback例程的步骤。

4.7.收集统计信息

根据本发明的一个实施例，测试框架可以包含统计信息收集组件(例如统计信息收集器114)作为一特色，以协助实现反映测试作业中使用的系统的性能的日志(例如日志160)的收集。统计信息收集器可在整个测试作业期间搜集这些日志，或者它可以只是在测试管理器指示出测试作业完成时搜集日志。

测试管理器可以将某些指令传递到统计信息收集器，这些指令使得它能够确定它应当采取哪些行动来获得这些日志。这些指令可以是根据测试细节、测试反馈、默认测试框架设置或三者的任何组合得出的。这些指令例如可标识统计信息主机的列表、执行主机、测试作业的开始和结束时间、测试作业的某些状态的开始和结束时间、是否使能概要剖析、统计信息主机或测试作业向其输出日志的一个或多个共享仓库的位置，等等。统计信息收集器可能能够自己确定这些细节中的一些-例如，它可能能够根据共享仓库内用于测试反馈的文件确定开始和结束时间。

根据本发明的一个实施例，在测试作业结束时，统计信息收集器向测试作业暗示的多种日志生成组件中的每一个请求性能日志。统计信息收集器可能能够访问例如统计信息主机的列表。或者，统计信息收集器可能能够自己获知用于一测试作业的统计信息收集器的列表。统计信息收集器还可能能够访问或得出在每个统计信息主机上运行的资源监视器和概要剖析器的列表。统计信息收集器可以向这些组件中的每一个请求它们可能已利用与测试作业相关的度量收集的任何日志。为了允许日志生成组件判定日志是否相关，统计信息收集器可识别开始时间和结束时间。开始时间和结束时间可以是整个测试作业的，或者只是测试作业处于特定状态的一段时间的。统计信息收集器还可尝试从网络上的共享目录收集日志，其中，按照测试细节或测试反馈所指示，被测软件或测试作业可能已向该共享目录输出了日志。

根据本发明的一个实施例，收集性能统计信息的负担的大部分可被转移到统计信息主机本身。每个统计信息主机可以运行用于在该个体统计信息主机处收集日志的进程。这种进程的代码可由测试框架提供。在接收到指示出测试作业的结束(或者指示出测试作业的一状态(统计信息主机被请求收集其数据)的结束)的统计信息指令后，统计信息主机上的进程可以向统计信息收集器发送所收集的日志。或者，统计信息主机上的进程可以向执行主机发送日志，以被存储在专用于特定测试作业的集中仓库中。例如，统计信息主机上的进程可以向同一共享文件夹发送日志，在该文件夹中测试作业的执行主机创建指示出测试反馈的文件。

根据一个实施例，测试计划本身可包含用于从每个统计信息主机上的日志生成组件搜集日志的指令。例如，测试作业可能调用了被测软件的日志生成能力。它可以定位所生成的日志并将它们直接转发到统计信息收集器或者将它们放置在用于该测试作业的集中日志仓库中。

默认系统性能统计信息

根据一个实施例，测试框架可以针对其调用的每个测试作业，从每个统计信息主机收集默认的一组系统性能统计信息，不论这种统计信息是否被明确请求。这些默认统计信息例如可包括处理器使用情况、存储器使用情况、网络利用情况、虚拟存储器使用情况、正在执行的进程的数目、硬盘使用情况、总线使用情况，等等。

统计信息收集器可以直接从统计信息主机上的资源监视器收集这些统计信息。例如，统计信息收集器可以从嵌入在统计信息主机的操作系统中的资源监视器收集统计信息。或者，每个测试框架上由测试框架发起的进程可以搜集这些统计信息。

根据一个实施例，测试框架可以从测试集群中的所有系统收集该默认的一组系统性能统计信息，而不论是否存在关于测试作业涉及测试集群中的特定系统的指示。测试作业中未涉及的系统的统计信息可以在测试结果生成期间被确定和去除，或者它们可被保留在测试结果中。

4.8.生成测试结果

在统计信息收集器收集了任何可用的日志-例如日志160-之后，统计信息收集器可以将这些日志转发到测试结果生成组件，例如测试结果生成器115。或者，统计信息收集器可以将日志返回到测试管理器或测试模块，它们中的任一个随后可将其转发到测试结果生成器。测试结果生成器随后可将日志转化成测试结果。

作为测试结果的一部分，测试结果生成器可以创建任何数目的数据报告，其中每个数据报告可以包括与在所收集的日志中记录了其值的一个或多个性能度量或事件相关的数据。每个数据报告可以包括时间序列数据、基于文本的日志条目或表格式数据，以及标识相关性能度量等的元数据。

测试结果可以以多种形式来生成。用于存储测试结果的一种形式可以是文件系统上的数据文件的集合。例如，每个数据报告可被存储为一个文件，该文件是按照数据报告的元数据或者发源数据报告的数据的日志来命名的。为了协助实现容易的浏览，这些数据文件可以在与测试作业相关联的目录下以树状结构组织。这种目录可以在测试框架或测试模块可访问的文件系统上。这种目录例如可以按照测试用例或测试细节中包括的测试作业标识符来命名。树状结构可包括每个统计信息主机和每个日志生成组件的分支。它还可包括根据汇总或分析生成的数据报告的分支。

基于测试框架定义的方案，测试结果生成器也可改为将测试结果存储为数据库中的行和表格或者XML文件中的元素。

根据一个实施例，只要通过将每个收集的日志转化成单个数据报告，就可以生成简单的测试结果。单个日志的内容可成为单个数据报告的数据。测试结果生成器可以基于例如日志的文件名、日志内的头部或者与包含日志的文件相关联的属性来为数据报告生成元数据。

根据一个实施例，测试结果生成器可以通过对日志执行包括过滤、汇总和分析在内的多种操作来创建更增强的测试结果。测试结果生成器可以默认执行这些和其他操作，或者测试结果生成器可以在接受日志的同时接受输入，根据这些输入，测试结果生成器可以确定执行哪些操作以及如何执行它们。所述输入例如可根据测试用例或测试细节来得出。

去除无关数据

测试结果生成器可执行一个操作是过滤无关数据。日志的每一行可包含指示出何时发生了事件或者取得了度量值的时间戳。当它接收到日志时，测试结果生成器可能也从发送方实体接收了指示出测试作业的开始时间和结束时间的数据。测试结果生成器可以去除日志的所有未落在开始和结束时间之间的行。

在一些情况下，所使用的开始或结束时间可以基于测试作业何时进入某个状态而不是测试作业何时实际开始。测试结果生成器可能接收到了指示出测试作业的多个状态的开始和结束时间的数据。测试结果生成器可被配置为去除不与特定状态(例如“执行”状态)相对应的数据。此特定状态可以是为测试框架默认定义的，或者它可能是在测试细节中被传达给测试管理器、然后被传递到测试结果生成器的。

对数据重采样

测试结果生成器可以执行的另一操作是数据重采样。日志可包含按某个频率取得的度量值。测试结果生成器可以接收指示出测试结果应当以更低的频率报告度量的输入。测试结果生成器可以对度量值重采样，以便在为测试结果生成的数据报告中它们是以期望的频率被报告的。

例如，日志可以每0.1秒报告度量。测试用例可能请求了每秒报告度量。通过在日志的每十行上对度量值取平均，并随后向数据报告输出十行的平均以及十行的中值时间戳，就可以对度量重采样。

在期望报告度量的频率高于日志中存储的频率的情况下，测试生成器也可能能够为该度量内插数据，以便帮助用户猜测在特定时间该度量可能是什么值。

按测试作业状态组织数据

测试结果生成器还可以根据由测试管理器或统计信息收集器收集的状态数据来对来自日志的数据进行组织。测试结果生成器可以将日志细分为针对每个状态的单独数据报告。每个数据报告可以仅包括在测试作业处于数据报告的特定状态中时取得的度量值或发生的事件。每个这种数据报告的元数据可以标识数据报告所属的状态。

关联相关度量

测试结果生成器可以将某些度量关联到同一数据报告中。例如，可能存在具有属于相关度量的时间序列数据的单独日志。测试结果生成器可以将这些度量输出到同一数据报告中的表格格式，以便这些度量可以更容易被关联。在度量值是在不同时间或按不同频率取得的情况下，合并度量可能需要例如对度量重采样或者调节度量的时间戳。

测试结果生成器还可以基于相关度量执行计算，以便更好地标识度量之间的关联性。例如，存储器使用情况可以被除以线程计数，以得出反映系统上的每个线程所使用的存储器的平均量的数据报告。这种关联的数据报告的元数据可以标识诸如“每线程存储器”的标题。元数据还可以标识个体度量“存储器”和“线程”的数据报告，以便允许用户向下钻取到更多细节。

跨系统汇总统计信息

测试结果生成器还可以跨多个系统生成汇总的数据报告。测试结果生成器可以识别来自测量相同度量的不同系统的日志(或者已经生成的数据报告)。如果每个日志中的度量是以相同的频率在大致相同的时间采样的，则测试结果生成器只要通过对每个特定时间对来自每个系统的度量值取平均，就可以生成汇总数据报告。如果度量是在不同的时间或按不同的间隔采样的，则测试结果生成器可以采用若干操作来汇总它们，例如对度量重采样并随后对其取平均。

将日志转化成示图可查看统计信息

测试结果生成器还可以采用技术来将某些基于事件的日志转化成可以图形可视化的数据报告。例如，日志生成组件可能在每次某个事件发生时向日志输出了一行。测试结果生成器可以根据这些事件确定每秒发生事件的次数。它可以在数据报告中输出一行，该行带有测试作业的每秒的时间戳在该秒中发生的事件的数目。从而，数据报告随后可被可视化为示出每秒的事件数目的示图。

突出关键统计信息

测试结果生成器可以分析特定数据报告中的度量值以确定对于该数据报告关注的标准统计信息，包括平均值、最小值、最大值、标准偏差等等。这些值可被存储供以后用作数据报告的元数据。

突出重要或非预期结果

测试结果生成器还可以采用分析技术来突出数据中的重要或非预期结果。它可以在测试结果中包括包含这种重要或非预期结果的数据报告的列表。

例如，测试结果生成器可被配置为突出这样的度量：这些度量的值在测试作业的过程期间的改变高于某个预定的百分比。作为另一示例，测试结果生成器可被配置为突出具有超过标准偏差的值的度量。

作为另一示例，测试结果生成器可能接收了指示出特定度量的某个阈值的指令。此阈值可能是在测试细节中指定的。例如，用户可能将此阈值作为测试用例的一部分提交。或者，测试模块可能通过分析先前执行的测试作业中的该度量的值而确定了此阈值。如果对于特定数据报告中的度量，该阈值被超过，则测试结果生成器可以将该数据报告添加到重要或非预期结果的列表。

4.9.呈现测试结果

根据一个实施例，测试结果(例如测试结果155)可被返回给测试模块。用户可通过测试模块的界面来请求查看测试结果。测试模块可以利用报告组件(例如测试报告器116)来生成测试模块的界面。

测试报告器可以是或者使用任何图形或文本界面。测试报告器可以基于测试结果中的数据报告来生成示图、表格和文本视图。测试报告器可以以多种方式来组织这些视图，以允许用户更迅速地访问数据。测试报告器可以包含用于对测试结果数据执行进一步操作以及构建额外数据报告的多种交互式控件作为一特色。

示例性web界面

图6-10图示出测试报告器116可生成的示例性界面。图6-9中的测试结果的组织和呈现仅是示例性的，并且对于不同的测试作业和不同的测试模块可以有很大变化。也可改为使用用于组织和可视化测试结果的多种其他技术。

图6示出了根据本发明实施例用于呈现测试结果的示例性web界面600。web界面包括控件608，用于输入测试作业的标识符-例如，web界面400的控件401中指定的标识符。一旦利用控件608选择了测试作业，web界面600就可以显示选项卡，例如选项卡601-604。选项卡601-604中的每一个可以提供与所选择的测试作业相关联的信息的视图。例如，当被点击时，选项卡601可以示出为产生该测试作业的测试用例输入的信息。

如果已为所选的测试作业确定了测试结果，则用户可以点击选项卡603和604来查看测试结果。选项卡603可用于浏览测试结果603中的数据报告的图形显示。选项卡604可用于浏览测试结果604中的数据报告的文本显示。

测试结果的组织

树610是树状结构，其可用于定位和浏览针对特定系统的特定类型的数据报告。例如，树610可用于浏览基于web界面400中指定的测试用例为测试作业生成的测试结果。如控件414中所示，由此测试用例产生的测试作业只使用了两个统计信息主机，其中每一个分别在测试结果中作为树610的分支611和612列出。如果测试结果包括了跨系统汇总的数据，则树也可以包括用于选择这种数据的分支。

图7示出了根据本发明实施例用于查看测试结果中的数据报告的图形表示的示例性web界面700。web界面700示出了web界面600对用户展开树610的分支611的反应。树710是分支611的展开视图。此分支下的所有数据报告都是关于名为perflab40的系统的。

树710包括两个子分支：应用结果713和系统结果714。这些子分支按日志生成组件的类型来组织perflab40的数据报告。应用结果713对应于由被测软件生成的日志，而系统结果714对应于为perflab40收集的默认系统统计信息。根据一个实施例，树710可以包括针对利用其他类型的日志生成组件(例如概要剖析器)的其他测试作业的其他子分支。

每个子分支包括更具体地标识发源了测试结果的数据报告的日志生成组件的额外子分支。例如，子分支715将软件组件exec_command.sh标识为其统计信息的来源，而子分支716将ysar资源监视器标识其系统结果714的来源。子分支716被进一步组织成5个子分支720-724，其中每一个对应于作为日志从ysar资源监视器输出的一个不同的循环式数据文件。

确定如何在视觉上表示数据报告

根据一个实施例，测试报告器可以通过分析数据报告中的数据来确定如何在视觉上表示数据报告。具有包含时间戳的行的数据报告可以视为时间序列数据并被相应地图解。表格格式(即，具有行和列)的其他数据可被视为表格式数据并利用表格、条形图或饼状图来图解。非表格格式的数据可以被示为纯文本日志。

或者，测试报告器可以使用与发源数据报告的数据的日志相关联的文件扩展名来确定数据报告的正确视觉呈现。例如，具有.rrd扩展名的数据报告可以被视为时间序列数据。具有.csv扩展名的数据报告可被视为表格式数据。具有.log扩展名的数据报告可被视为纯文本日志。

测试结果中的数据报告的图形视图可以通过能够将测试结果的时间序列或CSV数据报告变换成示图的任何绘图工具来生成。例如，可以通过利用gnuplot绘出数据报告来生成示图。

查看基于时间序列的数据

在web界面700中，子分支720当前被选择。子分支720包括5个不同度量的数据报告，其中每个度量可以通过选中相应的度量选择控件730-734而被示为示图。示图740是“用户”度量的值的时间序列示图，其绘出了在测试作业的过程期间在perfab40上的处理器利用情况。虽然没有示出，但是web界面还可以包括与其他度量选择控件731-734相对应的数据的图形视图。

根据一个实施例，web界面700还可以包含允许用户将数据报告覆盖在同一示图中的控件作为一特色。例如，web界面700可以包含示图740旁边的下拉或复选框选择器作为一特色。这些选择器可以允许用户选择一个或多个其他数据报告来在示图740上绘出。这样，用户可以更容易地发现数据之间的关联性。

查看表格式数据

根据一个实施例，web界面700还可以用于查看诸如CSV之类的表格格式的数据报告。测试报告器可以将这种数据报告表现为表格。或者，web界面700可以尝试将数据报告表现为条形图、饼状图或者任何其他类型的示图。

如果数据报告包含时间戳列，则测试报告器可以将数据报告的每列表现为同一示图中的单独度量。或者，测试报告器可以将数据报告中的每列视为可以单独查看和使能的单独时间序列示图。

或者，用于查看测试结果的web界面可以包含这样一个控件作为一特色：该控件允许用户在表格、时间序列示图或者其他类型的用于查看数据报告的示图之间进行选择。

查看纯文本日志

某些数据报告可能不能很好地在视觉上转化。例如，事件的日志或调试输出可能包含多个不相关的语句。这些语句对于测试结果可能仍是重要的。从而，测试报告器可以允许用户直接查看这些日志的内容。

图8示出了根据本发明实施例用于查看测试结果中的基于文本的数据的示例性web界面800。用户可能例如通过点击web界面600的选项卡604而到达了web界面800。与web界面700一样，web界面800包含用于按系统和日志生成组件组织数据报告的树状结构作为一特色。此树状结构是树800。树810仅包括不能被图形可视化的基于文本的数据报告；然而，测试报告器也可为能够以图形方式查看的数据报告提供纯文本视图。

如树810所示，web界面800被示为对从名为simple.log的软件生成日志得出的数据报告进行可视化。框820是将此数据报告显示为纯文本的可滚动文本框。

为数据报告识别关键统计信息

示图740下面是示出可能被结合到了示图740的数据报告的元数据中的统计信息的关键统计信息指示符745的列表，例如平均值、最大值和最小值。根据一个实施例，这些值在示图740本身上可以利用颜色或符号来指示出。

过滤数据

用于呈现测试结果的界面还可以包括过滤数据报告中的数据的呈现的控件。例如，控件751和752允许用户限制所绘出的数据的时间范围。

web界面700还可以包含其他控件作为一特色，这些其他控件在被点击时使得测试报告器执行与第4.8节中说明的那些类似的分析和汇总操作。测试报告器可以在web界面700的另一窗口中显示这些分析和汇总操作的结果。

比较来自其他测试作业的结果

根据一个实施例，来自测试作业的测试结果可以被保存，以便将来对照来自将来的测试作业的测试结果查看和分析。对于新测试结果中的任何数据报告，测试报告器可以自动在先前存储的测试结果中查找类似度量的数据报告。它可以将先前测试结果中的类似度量的示图覆盖在新测试结果中的类似度量的示图上，以便比较。这样，web界面可以帮助用户识别基于类似测试用例的测试作业的测试结果之间的趋势。web界面甚至可包括总结页，该总结页示出在一个或多个先前测试结果中值有很大不同的度量的示图和其他信息。

根据一个实施例，测试报告器可能能够基于测试结果的组织来识别具有类似度量的数据报告的测试结果。或者，测试报告器可以自动假定基于同一模板测试用例的测试作业的测试结果具有类似的数据报告。

用户还可以选择先前的测试结果来进行比较，如web界面700中所示。控件760允许用户识别其他测试作业的逗号分隔列表。如果这些其他测试作业中任何一个的测试结果包括基于与当前查看的那些类似的度量的数据报告(例如，如果测试结果也具有perflab40的用户处理器利用情况数据)，则测试报告器可以将这些数据报告覆盖在web界面700中的相应示图上。

额外示例性界面

图9示出了根据本发明实施例用于查看测试结果中的数据报告的图形表示的示例性web界面900。图9与图7类似，只不过它示出了可如何为一不同的子分支721图解数据报告。从而，图9包括了不同的一组度量选择控件930，它们对应于可利用不同的示图(例如示图940)来可视化的数据报告的度量。

识别非预期趋势

根据一个实施例，当像图6中那样没有选择树的分支时，主视图窗格620可以包括去往示出具有重要或非预期数据的数据报告的示图的链接。主视图窗格620还可包括用于直接示出这些数据报告的示图。主视图窗格620还可包括已针对该测试作业或者针对先前测试作业识别为重要的度量的示图。

报告插件

根据一个实施例，测试框架或测试模块可提供用于创建生成各个数据报告的额外视图的插件的可扩展API。例如，安装的插件可在测试结果中的每个数据报告的默认视图旁边暴露出一控件。该控件可以是一按钮，该按钮在被点击时弹出具有数据报告的替换视图的窗口。这种替换视图例如可以是不同的示图类型或者特殊的文本显示。这种替换视图还可以过滤数据报告或显示从对数据报告执行的分析性操作得出的数据。

统计信息购物车

图10是根据本发明实施例用于利用购物车模型构建测试结果中的数据的定制视图的示例性web界面1000。这种定制视图可以例如经由与web界面600的选项卡601、602、603和604类似的定制视图选项卡1005来访问。

如图7和8所示，每个表现出的数据报告，无论它是示图、表格还是文本框，都可包括复选框控件。web界面700、800或900可被配置为包括按钮，该按钮将其复选框已被选中的数据报告添加到定制视图，如图10所示。例如，来自web界面900的示图940可能已通过按钮950被添加到web界面1000中示出的定制视图。web界面1000可包括通过这种手段添加的许多额外示图。

定制视图可被保存，以便在下次用户查看测试结果时参考。web界面1000包括控件1011、1012和1013，分别用于删除、取消选择和保存web界面1000的定制视图。web界面1000还可包括用于打印定制视图的控件。web界面1000还包括允许用户输入注释以供将来参考的注释框1050。用户可以创建和保存任何数目的这种定制视图，每一个具有不同的标题。

根据一个实施例，定制视图与测试模块而不是单个测试结果相关联。一旦被保存，定制视图就可以为针对该测试模块生成的所有测试结果示出。当用户保存定制视图时，测试模块可以保存指示出由定制视图中的每个数据报告记录的一个或多个度量的元数据。对于任何后续的测试结果，测试报告器可以使用此元数据来确定在该后续测试结果的定制视图中要示出的数据报告。

例如，用户可以创建一定制视图，该定制视图包括示出第一测试结果的处理器利用情况的示图。当用户保存此定制视图时，测试模块可以存储指示出该定制视图包括了处理器利用情况度量的示图的信息。当用户查看后续测试结果时，测试报告器可以为后续测试结果自动生成相应定制视图。相应定制视图可以包括示出第二测试结果的处理器利用情况的示图。如果后续测试结果不包含处理器利用情况度量的数据报告，则后续测试结果的定制视图可以简单地不包括处理器利用情况度量的示图。

根据一个实施例，保存的定制视图可以与测试用例模板相关联而不是与测试模块总地相关联，意味着针对基于相同测试用例模板的测试作业生成的任何测试结果都可自动包括为针对基于同一测试用例模板的另一测试作业生成的另一测试结果保存的定制视图。测试用例模板在4.3中论述。

4.10.操作系统独立性

根据本发明的一个实施例，测试框架的各个方面是独立于平台的，意味着测试框架可被部署在具有运行多种操作系统的系统的测试集群上。

根据一个实施例，测试框架可包括能够自动检测执行主机和统计信息主机的操作系统的代码。当-经由例如安全外壳或telnet会话-向操作系统本身发送测试指令或统计信息指令时，测试框架可以以可在检测到的操作系统上执行的格式发出命令或重新编排命令格式。

根据一个实施例，测试框架可被配置为自动搜索测试集群中的每个系统上的资源监视或概要剖析组件。测试框架可包括可用在特定系统的操作系统上的多个概要剖析器或资源监视组件的列表。测试框架可以搜索列表中的每个组件，或者在其找到第一个可接受的组件时停止搜索。它例如可以搜索文件系统中的一个或多个默认位置以定位特定概要剖析器或资源监视组件的可执行文件。它随后可调用此可执行文件。它还可以使用例如系统注册表来定位特定的概要剖析器或资源监视应用。

根据一个实施例，测试框架可被配置为在测试集群中的每个系统上安装其自己的概要剖析或资源监视组件，从而确保它将能够访问每个系统上的概要剖析或资源监视组件。根据一个实施例，每当在测试细节中标识一统计信息主机时，如果测试框架无法定位到适当的概要剖析器或资源监视组件，则测试框架可以在该统计信息主机上安装其自己的概要剖析或资源监视组件。对于在测试集群中的系统上运行的每个操作系统，测试框架可以存储在该操作系统上运行的概要剖析和资源监视组件的安装程序。

根据一个实施例，测试框架可被配置为与测试集群中的每个操作系统上的至少一个概要剖析器和资源监视组件生成的日志通信并理解这些日志。它例如可以知道控制每个概要剖析或资源监视组件所必需的配置参数。或者，它可以知道如何为每个概要剖析或资源监视组件向专用端口发送命令。它还可以知道概要剖析或资源监视组件存储其日志的默认位置。

根据一个实施例，测试框架中的每个系统可以运行测试框架所管理的管理进程。测试框架不需要知道如何与系统的操作系统和日志生成组件远程通信，而是可以改为与此进程通信。此进程随后可被配置为代表测试框架与操作系统和日志生成组件本地通信。

根据一个实施例，测试框架和测试模块的界面可以是独立于平台的。例如，界面可以是可在任何操作系统上的web浏览器中查看的web界面，例如图3-8中所示的那些。或者，界面可以是某种其他的普遍可读的形式，例如基于Java的客户端。

根据一个实施例，测试框架的每个组件也可以是独立于平台的，因为它是利用诸如Java之类的可以不加改变地在任何操作系统上编译和执行的语言来编写为代码的。或者，用于测试框架的代码可以针对每个操作系统被移植成可在该操作系统上编译和执行的语言。

4.11.实时监视

根据一个实施例，统计信息收集器可以实时收集日志。测试结果生成器可以实时创建测试结果，这些测试结果随后可被测试报告器实时报告。这种实时报告可允许用户更容易地确定被测软件中的错误和效率低下的原因，因为当它们的影响发生时，用户可以被提示以这些影响。

此外，测试报告器可以生成用于实时报告测试结果的交互式界面，该界面允许了用户动态改变测试用例的某些条件。例如，该实时交互式界面可以包含“使能概要剖析”按钮作为一特色。用户可以响应于观看到实时结果而点击此按钮。测试模块随后可向测试管理器发送新的测试细节。当认识到新的测试细节具有与已经执行的测试作业相等的测试作业标识符时，测试管理器可以向测试作业中涉及的执行主机或统计信息主机发送补充测试指令或统计信息指令，这些指令使得它们开始对已经执行的测试作业进行概要剖析。

5.0.实现机制-硬件概述

图11是图示出本发明的实施例可在其上实现的计算机系统1100的框图。计算机系统1100包括用于传输信息的总线1102或其他通信机构以及与总线1102相耦合用于处理信息的处理器1104。计算机系统1100还包括诸如随机访问存储器(RAM)或其他动态存储设备之类的主存储器1106，其耦合到总线1102，用于存储信息和处理器1104要执行的指令。主存储器1106还可用于存储在处理器1104执行指令期间的临时变量或其他中间信息。计算机系统1100还包括只读存储器(ROM)1108或其他静态存储设备，其耦合到总线1102，用于存储静态信息和处理器1104的指令。提供了诸如磁盘或光盘之类的存储设备1110，其耦合到总线1102，用于存储信息和指令。

计算机系统1100可以经由总线1102耦合到显示器1112，例如阴极射线管(CRT)，用于向计算机用户显示信息。包括字母数字和其他键的输入设备1114被耦合到总线1102，用于向处理器1104传输信息和命令选择。另一类用户输入设备是光标控制装置1116，例如鼠标、轨迹球或光标方向键，用于向处理器1104传输方向信息和命令选择，并用于控制显示器1112上的光标移动。该输入设备通常具有两个轴(第一轴(例如x)和第二轴(例如y))上的两个自由度，其允许设备指定平面中的位置。

本发明涉及使用计算机系统1100来实现这里描述的技术。根据本发明的一个实施例，这些技术由计算机系统1100响应于处理器1104执行包含在主存储器1106中的一条或多条指令的一个或多个序列而执行。这种指令可以被从另一计算机可读介质(如存储设备1110)读取到主存储器1106中。对包含在主存储器1106中的指令序列的执行使得处理器1104执行这里描述的过程步骤。在替换实施例中，可以使用硬线电路来替代软件指令或与软件指令相组合以实现本发明。因此，本发明的实施例并不限于硬件电路和软件的任何特定组合。

这里所用的术语“机器可读介质”指参与提供使得机器以特定方式工作的数据的任何介质。在利用计算机系统1100实现的实施例中，例如，在向处理器1104提供指令以供执行时，涉及了各种机器可读介质。这种介质可以采取许多形式，包括但不限于存储介质和传输介质。存储介质包括非易失性介质和易失性介质。非易失性介质例如包括光盘或磁盘，如存储设备1110。易失性介质包括动态存储器，如主存储器1106。传输介质包括同轴电缆、铜线和光纤，包括构成总线1102的线路。传输介质也可以采取声波或光波的形式，例如在无线电波和红外数据通信期间生成的声波或光波。所有这种介质都必须是有形的，以使得介质所承载的指令能够被物理机构检测到，该物理机构将指令读取到机器中。

机器可读介质的常见形式例如包括软盘、柔性盘、硬盘、磁带或任何其他磁介质，CD-ROM、任何其他光介质，穿孔卡、纸带、任何其他具有孔图案的物理介质，RAM、PROM和EPROM、FLASH-EPROM、任何其他存储器芯片或卡盘，下文中描述的载波，或者计算机可以读取的任何其他介质。

各种形式的机器可读介质可用于将一条或多条指令的一个或多个序列传送到处理器1104以供执行。例如，指令可以首先承载在远程计算机的磁盘上。远程计算机可以将指令加载到其动态存储器中，并利用调制解调器经由电话线发送指令。计算机系统1100本地的调制解调器可以接收电话线上的数据，并使用红外发送器来将数据转换为红外信号。红外检测器可以接收在红外信号中携带的数据，并且适当的电路可以将数据置于总线1102上。总线1102将数据传送到主存储器1106，处理器1104从主存储器1106取得指令并执行指令。主存储器1106接收的指令可以可选地在处理器1104执行之前或之后存储在存储设备1110上。

计算机系统1100还包括耦合到总线1102的通信接口1118。通信接口1118提供到与本地网络1122相连接的网络链路1120的双向数据通信耦合。例如，通信接口1118可以是综合业务数字网络(ISDN)卡或调制解调器，以提供与相应类型电话线的数字通信连接。又例如，通信接口1118可以是局域网(LAN)卡，以提供与兼容LAN的数据通信连接。也可以实现无线链路。在任何这种实现方式中，通信接口1118发送并接收电的、电磁的或光信号，这些信号携带了表示各种类型信息的数字数据流。

网络链路1120通常通过一个或多个网络提供到其他数据设备的数据通信。例如，网络链路1120可以通过本地网络1122提供与主机计算机1124或由因特网服务供应商(ISP)1126操作的数据设备的连接。ISP1126进而通过全球分组数据通信网络(现在通常称为“因特网”1128)提供数据通信服务。本地网络1122和因特网1128都使用携带数字数据流的电的、电磁的或光信号。经过各种网络的信号和在网络链路1120上并经过通信接口1118的信号(这些信号携带去往和来自计算机系统1100的数字数据)是传输信息的载波的示例性形式。

计算机系统1100可以通过(一个或多个)网络、网络链路1120和通信接口1118发送消息并接收数据，其中包括程序代码。在因特网示例中，服务器1130可以通过因特网1128、ISP 1126、本地网络1122和通信接口1118发送针对应用程序的请求代码。

接收到的代码可以在接收时被处理器1104执行，和/或被存储在存储设备1110或其他非易失性存储介质中以供以后执行。以这种方式，计算机系统1100可以获得载波形式的应用代码。

6.0.扩展和替换

在以上说明书中，已参考对于每种实现方式可能不同的许多具体细节描述了本发明的实施例。因此，关于本发明是什么以及申请人希望本发明是什么的唯一和排他指示是根据本申请授权的那套采取其授权时的特定形式的权利要求，包括任何后续的更正。这里针对这种权利要求中包含的术语明确阐述的任何限定都应当决定这种术语在权利要求中使用时的含义。因此，在权利要求中没有明确记载的限定、要素、性质、特征、优点或属性都不应当以任何方式限制这种权利要求的范围。因此，说明书和附图应被认为是说明性的而不是限制性的。

Claims

1.一种用于为在多主机系统上运行的应用收集性能统计信息的由计算机实现的方法，包括以下步骤：

在测试框架处接收指定测试细节的输入，其中所述测试细节包括测试计划；

基于所述输入，所述测试框架在执行主机上执行所述测试计划，其中执行所述测试计划包括：

在多个主机中的每一个上发起应用的至少一部分的执行；

从所述多个主机中的每个主机接收指示出特定时间段的性能统计信息的性能数据；

基于所述性能数据，所述测试框架生成测试结果，该测试结果包括针对多个性能度量的多个数据报告；以及

所述测试框架向用户呈现所述测试结果。

2.如权利要求1所述的方法，其中，所述多个主机中的第一主机在执行第一操作系统，并且所述多个主机中的第二主机在执行与所述第一操作系统不同的第二操作系统。

3.如权利要求1所述的方法，其中，所述测试细节还包括一个或多个属性，并且其中执行所述测试计划还包括利用所述一个或多个属性中的至少一些属性作为包括所述测试计划的执行脚本的参数的值，来调用所述执行脚本。

4.如权利要求1所述的方法，还包括以下步骤：所述测试框架基于所述测试细节中定义的执行主机特性来确定所述执行主机的身份。

5.如权利要求1所述的方法，还包括以下步骤：所述测试框架基于所述测试细节中定义的特性来确定所述多个主机的身份。

6.如权利要求1所述的方法，其中从所述多个主机中的每个主机接收指示出特定时间段的性能统计信息的性能数据的步骤还包括：

所述多个主机中的至少一些主机将性能度量和事件的日志拷贝到共享的存储位置；

所述测试框架从所述共享的存储位置读取所述日志。

7.如权利要求1所述的方法，其中接收性能数据、生成测试结果和呈现所述测试结果的步骤是与执行所述测试计划的步骤并发执行的。

8.如权利要求1所述的方法，还包括以下步骤：

在所述多个主机中的一主机处接收利用特定的性能监视工具跟踪一个或多个性能度量的指令；

在执行所述测试计划的同时，利用所述性能监视工具跟踪所述一个或多个性能度量；并且

其中，所述指示出特定时间段的性能统计信息的性能数据包括所述一个或多个性能度量的值。

9.如权利要求1所述的方法，其中，接收性能数据的步骤包括以下步骤：所述测试框架向所述多个主机中的每个主机上的系统嵌入资源监视器请求默认的一组性能数据。

10.如权利要求1所述的方法，其中，所述特定时间段由开始时间和结束时间来定义，其中所述开始时间对应于所述执行主机开始执行所述测试计划的时间，并且所述结束时间对应于所述执行主机完成执行所述测试计划的时间。

11.如权利要求1所述的方法，其中，所述特定时间段由开始时间和结束时间来定义，其中在所述执行主机处执行所述测试计划包括：

执行所述测试计划中的一组初始化步骤；

在执行所述一组初始化步骤之后，执行所述测试计划的使得所述执行主机创建指示出所述开始时间的第一测试反馈的第一步骤；以及

执行所述测试计划的使得所述执行主机创建指示出所述结束时间的第二测试反馈的第二步骤。

12.如权利要求1所述的方法，其中，生成测试结果的步骤包括过滤所述性能数据以仅包括来自第二时间段的性能数据，其中所述第二时间段至少是基于在所述执行主机处执行所述测试来确定的。

13.如权利要求1所述的方法，其中，生成测试结果的步骤包括对来自所述多个主机中的每个主机的性能数据取平均以创建单个数据报告。

14.如权利要求1所述的方法，其中，生成测试结果的步骤包括将所述性能数据与第二性能数据相比较，其中所述第二性能数据是(a)在在所述执行主机上执行所述测试计划的步骤之前生成的和(b)在所述执行主机上执行所述测试计划的同时由所述多个主机生成的。

15.如权利要求1所述的方法，其中，向用户呈现所述测试结果的步骤包括对于所述测试结果中的每个数据报告生成一个或多个视图，所述一个或多个视图至少包括示图和文本日志。

16.如权利要求1所述的方法，其中：

所述性能数据包括循环式数据文件；

所述测试结果包括基于所述循环式数据文件的数据报告；

呈现所述测试结果的步骤包括确定为所述数据报告生成时间曲线图，其中所述确定是响应于确定所述数据报告基于循环式数据而执行的。

17.一种在包括多个系统的测试集群中执行测试作业的由计算机实现的方法，包括在测试框架处进行的以下步骤：

(1)接收指定测试作业的测试细节的输入，其中所述测试细节包括所述测试作业的测试计划；

(2)确定所述测试集群中的能用于实现所述测试作业的所述测试计划的一个或多个步骤的一个或多个系统；

(3)判定所述一个或多个系统中的任何一个是否被预留用于任何其他测试作业；

(4)如果所述一个或多个系统都没有被预留用于任何其他测试作业，则根据所述测试计划执行所述测试作业；以及

(5)如果所述一个或多个系统中的任一个被预留用于另一测试作业，则等待一段时间，然后重复步骤3-5。

18.如权利要求17所述的方法，其中，确定所述一个或多个系统包括参考所述测试细节中包括的一组期望系统特性，该组期望系统特性包括以下特性中的至少一种：处理器类型、操作系统、盘存储设备、系统存储器和安装的软件。

19.如权利要求17所述的方法，其中，判定所述一个或多个系统中的任一个是否被预留用于任何其他测试作业包括监视在一个或多个系统中的每一个上执行的一个或多个进程。

20.如权利要求19所述的方法，还包括以下步骤：

为所述测试集群中的每个系统维护预留信息；

在根据所述测试计划执行所述测试作业后，更新所述预留信息以指示出所述一个或多个系统被预留；以及

在检测到所述测试作业已完成所述测试计划后，更新所述预留信息以指示出所述一个或多个系统未被预留；

其中，判定所述一个或多个系统中的任一个是否被预留用于任何其他测试作业的步骤包括对于所述一个或多个系统中的每个特定系统判定所述预留信息是否指示出所述特定系统被预留。

21.一种在包括多个系统的测试集群中执行用于测试软件性能的测试作业的由计算机实现的方法，包括以下步骤：

在所述测试框架处，执行以下步骤：

接收指定所述测试作业的测试细节的输入，其中所述测试细节包括所述测试作业的测试计划；

确定实现所述测试计划所需的一个或多个资源；

确定所述测试集群中的能作为实现所述测试作业的所述测试计划的步骤的所述一个或多个资源的一个或多个系统；

确定所述一个或多个系统中的特定系统不包括所述一个或多个资源中的至少一个；

使得所述一个或多个资源被安装在所述特定系统上；

根据所述测试计划执行所述测试作业。

22.如权利要求21所述的方法，其中，所述一个或多个资源包括执行脚本，该执行脚本包括表示所述测试计划的代码。

23.如权利要求21所述的方法，其中，所述一个或多个资源包括要被所述软件处理的测试数据。

24.如权利要求21所述的方法，其中，所述一个或多个资源包括配置信息。

25.如权利要求21所述的方法，其中，所述一个或多个资源包括所述软件的组件。

26.如权利要求21所述的方法，其中，所述一个或多个资源包括运行所述软件的组件所需的包。

27.一种计算机可读存储介质，存储着一个或多个指令序列，这些指令序列在被一个或多个处理器执行时，使得这一个或多个处理器执行如权利要求1-26中任何一个所述的方法。