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

专利名称：在集群系统中执行软件性能测试作业的制作方法
技术领域：
这里描述的本发明的实施例一般地涉及软件性能测试，更具体而言涉及用于生成 测试模块和利用所述测试模块执行测试作业的技术。
背景技术：
本部分中描述的方法是可以从事的方法，但不一定是先前已经设想到或从事过的 方法。因此，除非另有指明，否则不应认为本部分中描述的任何方法仅因为其被包括在本部 分中就应被当作是现有技术。性能测试性能测试是软件开发的一个必要方面。在整个软件开发过程中，软件开发者通常 对构成其软件的各种组件的性能进行测试。性能测试可以提醒软件开发者其代码中潜在的 错误或效率低下。例如，性能测试可以暴露出针对软件组件与一个或多个被测的操作系统、 硬件设备、软件包或网络环境之间的交互发生的效率低下或非预期的行为。作为另一示例， 性能测试还可以提醒软件开发者其软件的各种组件和应用之间的潜在不兼容。性能测试通常要求在仿真的真实世界条件下在仿真的真实世界环境中运行要测 试的软件。例如，开发者可能通过在多个计算机上运行一简单的桌面应用并且测试该应用 对多种输入正确响应，从而来测试该应用。更复杂的软件，例如以若干个负载均衡的服务器 应用作为一特色的软件套件，可能要求在多个不同的系统上进行大量的测试，其中每个系 统与大量的仿真客户端相交互。测试计划因为软件通常在整个开发期间必须被测试多次，所以软件开发者经常创建一个或 多个测试计划，这些测试计划包括步骤和逻辑，用于(1)在仿真环境中调用各种软件组件 的实例，以及(2)自动使得被调用的实例以预定的方式动作(即，仿真的条件)。软件开发 者可以利用例如包括以脚本语言编写的代码的执行脚本来描述这种测试计划。执行测试计 划中描述的步骤的过程在这里被称为“测试作业”。测试计划在整个开发过程期间可被重新 用于测试作业以测试各种代码改变的影响。另外，测试计划可包括这样一种逻辑，该逻辑用于改变计划的步骤以便计划可用 于测试多种环境中的类似条件或者相同环境中的仿真条件的微小变化。测试计划例如可从 控制此逻辑的命令行界面或配置文件接受输入。另外，测试计划可包含这样一种逻辑作为 一特色，该逻辑用于检测测试计划被用于其中的操作环境，以便根据操作环境来调整计划。 对在特定测试作业期间测试的环境或条件进行控制的一组测试参数可被称为“测试用例”。收集性能统计信息在测试作业期间，软件开发者可以从测试作业中涉及的各种计算机系统收集性能 相关统计信息和事件。性能相关统计信息可包括指示出系统的某些方面在测试作业期间如 何动作的多种度量。性能相关事件例如可包括由调试语句、差错语句或其他代码触发的注 释所指示出的软件事件。性能相关统计信息和事件可利用由系统的日志生成组件生成的日志来收集，所述日志生成组件包括概要剖析器工具、资源监视器、操作系统、被测软件或被 测系统上的任何其他软件包。另外，测试计划本身可包括用于向日志输出性能信息的步骤。 手工收集这种统计信息可能是一项烦冗的任务，因为开发者必须在每个被测系统上搜索有 关日志并且识别这些日志的与在该被测系统上执行测试作业的时间相关的部分。因此，软件开发者通常在其测试计划中包括用于自动化统计信息收集的步骤。然 而，要将这些步骤编写成代码也是很烦冗的。例如，用于收集统计信息的过程通常对于不同 的操作系统是不同的。另外，不同的系统可能运行相同的操作系统，但却运行不同的日志生 成组件。在被测软件要被部署在多种操作系统的情况下，这些不同之处使得编写代码以使 测试作业期间的统计信息收集自动化的任务进一步复杂。性能测试中的其他复杂因素其他障碍增加了软件开发期间测试软件的复杂性。经常很难筛选原始收集的统计 信息以分析重要性能指标或测试用例之间的差异。另外，测试计划一般是非常特定于一个 应用或者一定类型的软件的，意味着它们不能被重新用于不同软件。还希望调度测试作业 以利用诸如CRON之类的系统调度器来运行，以便软件开发者不必手工调用其希望运行的 测试作业。然而，由于测试系统通常被用于多种测试作业，所以难以确保在特定系统上调度 的测试作业不与另一个调度的测试作业重叠，从而污染了性能结果。因为在实现测试计划的代码、在多种系统上基于多种测试用例执行测试作业、在 每个测试作业期间从这些系统收集统计信息以及分析所收集的统计信息这些任务中的这 些和其他困难之处，软件测试通常未被充分利用或者是劳动密集型的，尤其对于企业级软 件更是如此。因此希望提高软件测试过程的效率。


在附图中以示例方式而非限制方式图示了本发明，附图中类似的标号指代相似的 元件，其中图1是图示出根据本发明实施例可用于在系统上测试软件应用的测试框架的框 图；图2示出了根据本发明实施例用于利用测试框架来执行对软件应用的性能进行 测试的测试作业的流程图；图3示出了根据本发明实施例用于输入数据以生成测试模块的示例性web界面；图4示出了根据本发明实施例用于指定与测试模块参数相对应的一组名称-值对 的web界面；图5是根据本发明实施例用于跟踪由测试调度器使用的测试作业队列的示例性 web界面；图6示出了根据本发明实施例用于呈现测试结果的示例性web界面；图7示出了根据本发明实施例用于查看测试结果中的数据报告的图形表示的示 例性web界面；图8示出了根据本发明实施例用于查看测试结果中的基于文本的数据的示例性 web界面；图9示出了根据本发明实施例用于查看测试结果中的数据报告的图形表示的示
6例性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.总概述公开了用于提高软件性能测试过程的效率的方法、技术和机制。根据一个实施例， 用于可以创建测试模块来针对特定测试计划集中资源和结果。利用来自测试框架的辅助， 测试模块可以协助实现例如测试用例的创建、针对每个测试用例的测试作业的执行、每个 测试作业期间性能统计信息的收集以及将收集的统计信息汇总成有组织的报告以便更容 易分析。测试模块可以跟踪测试模块所执行的每个测试作业的测试结果以便能够容易地比 较响应于开发过程的历史期间的各种条件和环境的性能度量。根据一个实施例，用户可以利用测试框架内的测试模块生成器创建测试模块。测 试模块生成器可以接受测试计划以及为测试模块定义参数的一个或多个属性作为输入。基 于测试计划和一个或多个属性，测试模块生成器可以生成测试模块。一个或多个属性定义 的参数可以对应于测试计划的任何可能变化的要素。开发者在经由测试模块创建测试用例 时可以向这些参数赋予不同的值。测试模块随后可以针对测试用例执行测试作业。
7
根据一个实施例，测试模块可以利用测试框架的某些组件来执行通常在测试作业 的执行期间或之后执行的某些任务，包括生成用于定义和管理测试用例的用户界面、对测 试作业进行集中调度以便它们不会重叠、收集统计信息、汇总统计信息、以及生成用于审查 结果的报告界面。测试框架可包括能够独立于被测试的软件或者执行测试作业的操作环境 来执行这些任务的组件。在这个过程中，测试框架极大地降低了实现测试计划所需的代码 的复杂度和数量。根据一个实施例，测试框架可用于基于测试用例来执行测试作业。基于测试用例 的测试作业的细节被发送到测试管理组件以便解释。测试管理组件可对测试作业进行调度 以在测试作业所需的各种系统和资源空闲时执行。基于测试细节，测试管理组件可以调用 执行主机上的包括测试计划的执行脚本，从而启动测试作业过程。测试管理组件还可以在 测试作业使用的系统上调用日志生成组件。测试管理组件还可以为测试作业提供管理性辅 助。当测试作业完成时，测试管理组件可以激活统计信息收集组件，以搜集包含性能统计信 息的日志。测试结果生成组件可以对这些日志应用过滤、汇总和其他操作以生成测试结果。 测试结果随后可经由由测试报告组件生成的界面被呈现给用户。根据一个实施例，测试框架可以是独立于操作系统的，从而单个测试作业可同时 在运行多种操作系统的多种系统上测试软件。在其他方面中，本发明涵盖了被配置为执行上述步骤的计算机装置和计算机可读 介质。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可以包括诸如“execjwst = 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。此数据可以指示出执行测试作业所必要的某些细节，例
10如包括测试计划、要在其上执行测试计划的一个或多个系统、要在其上执行被测软件的一 个或多个系统、从其收集统计信息的一个或多个系统、测试计划中的各种参数的值、以及要 搜集的统计信息的类型。测试模块可以为这些细节提供默认值，或者它可根据为测试用例 指定的值来确定这些细节。执行测试作业在步骤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/perluse strict ；use warnings ；use Fatal ；use File: :Copy ；MAIN: {my($file, $number_of_times) = iARGV ；#Say when the actual testing startedsend_feedback(' START_EXECUTION')；#Run our command multiple timesfor (0. . $number_of_times) {copy($file, “ file_copied〃 )or die" Couldn' t copy ' $file' to' file_copied' $ ！'〃；}#Say when the actual testing endedsend_feedback(' END_EXECUTI0N')；}
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”属性的可能值的逗 号分隔列表。另外，除了内部名称(利用该内部名称，它将被测试框架所知)之外，每个属性还 可包括指定可用来在界面中呈现它的标题的信息。另外，每个属性可包含指定该属性应当 如何被使用的后勤信息，例如它是否应当被发送作为执行脚本的参数值，它是否是应当在
13测试作业之前运行的命令，它是否是应当在测试作业之后运行的命令等等。按钮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)的位置。这种系统可被称为“执行主机”。例如，测试管理器可 以寻找测试细节中的包括诸如“execjiost = 10. 1. 1. 15”之类的名称-值对的属性。根据 此名称-值对，测试管理器可以确定IP地址为10. 1. 1. 15的系统应当被用作执行主机。作为另一示例，测试管理器可以在测试细节中寻找使用具有某些必要特征(例如 一定量的安装的存储器、某种安装的软件或者一定数目的处理器)的任何两个可用系统作 为执行主机的指令。测试管理器可以通过参考测试管理器已获取的关于测试框架能够访问 的一个或多个指定的测试系统的特征的信息来根据这些指令确定两个执行主机。它还可监 视这些指定的测试系统上的资源使用情况，以确定哪些系统当前可用。指定的测试系统可 能是通过测试框架的配置接口来指定的，或者可能是由于其连接到测试集群而被指定的。为了调用执行主机上测试作业的执行，测试管理器可以向执行主机发送测试指令 (例如测试指令192)。这些测试指令可以被执行主机以使得执行主机开始执行测试作业的 方式来解释。例如，测试指令可包括命令行语句，该语句按名称来引用包含测试计划的步骤 的脚本或可执行文件。这种脚本或可执行文件也可以被称为“执行脚本”。测试管理器可以 利用多种机制向执行脚本发送测试指令，所述机制包括远程过程调用、安全外壳或telnet 会话中的命令、或者经由由测试框架管理的进程操作的专用端口的命令。如果执行主机对于测试指令没有响应，或者如果执行主机发送指示出它无法执行 测试作业的测试反馈，则测试管理器可以采取若干动作之一。测试管理器可以采取的一个 动作是向测试模块返回指示出测试作业失败的测试结果。测试管理器可以采取的另一动作 是在测试细节中查找指示出其可改为在其上调用测试作业的一个或多个备用执行主机的 信息。或者，测试管理器可以从为测试框架定义的执行主机的默认列表中选择备用执行主 机。测试管理器可以采取的另一动作是查找测试框架可访问的、拥有与执行主机的质量类 似的质量的替换系统，并且尝试使用该替换系统作为执行主机。一旦执行主机已接收到具有调用测试作业的指令的消息，它即可以利用对于包含 测试作业的测试计划的执行脚本来说适当的任何手段来调用测试作业。例如，如果测试计 划是用Java或C++来编写的，则执行主机可以编译执行脚本，然后运行它。如果测试计划 是以经解释的语言来编写的，例如用外壳脚本或PERL脚本来编写的，则执行主机将立即开 始解释执行脚本。测试指令中的额外信息测试指令可包括其他信息。例如，测试管理器可包括与用于改变测试计划的参数 相对应的名称_值对作为启动执行脚本的命令行语句的一部分。例如，如果执行脚本被命 名为“testscript. pl”，则调用执行脚本的命令将为“testscript. pl-load 1000”，其中 "-load 1000”将测试计划中名称为“load”的参数的值设置为1000。测试管理器可以利用 其从测试模块接收到的测试细节来确定要输入到测试计划中的名称-值对。根据一个实施 例，测试管理器可以将其在测试细节中接收到的所有名称_值对包括作为调用命令行语句 的一部分。或者，它可以只发送未以其他方式用于预定的测试框架功能的属性的名称-值
17对。对于只接受经由命令行的参数值而不接受名称-值对的执行脚本，测试管理器可 以在命令行语句中仅包括值。例如，考虑与图4的web界面400的控件421和422相对应 的参数。测试模块可能向测试管理器发送了包括这两个参数的名称和为这两个参数指定的 值的属性。然而，测试管理器可能不具有与计数或文件属性相关联的任何功能。因此，测试 管理器可以在用于执行该执行主机的命令行中传递计数和文件属性的值。这些值可以按它 们被列出的顺序被传递。从而，由于web界面400中指定的执行脚本是Simple_SCript. pi, 因此调用命令可以是“simple_script.pl sample_file 50”。simple_script. pi 包含被配 置为分别将这些值自动识别为$file和$number_0f_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节中所述。 这种通知可以采取测试用例标识符的形式，在此情况下测试管理器使用测试用例标识符来 从包含先前接收到的测试作业的存储中检索测试的测试细节。或者，调度细节可包括了测 试作业的所有测试细节。调度器可以将这些测试细节重发送到测试管理器以便立即处理。变化根据一个实施例，调度细节可以定义测试作业所必需的系统的质量和数量。当调 度器确定具有必要质量和资源的必要数量的系统可用时，调度器可确定到启动测试作业的 时间了。作为其对测试管理器的指令的一部分，调度器随后可确切限定哪些系统可用。测 试管理器随后可在管理测试作业时使用此信息_例如，它可以使用此信息来识别一个或多 个执行主机和一个或多个统计信息主机。测试管理器还可以将此信息作为初始测试指令的 一部分发送到执行主机，以使得测试作业可以确定在其上执行被测试的软件的各种组件的 一个或多个可用系统。根据一个实施例，测试调度器可以使用冲突解决和资源使用优化例程来确保测试 作业队列中的多个测试作业以及时、高效的方式被执行。测试调度器还可以利用调度细节 中的优先级区分信息。因此，例如，测试调度器可能能够比其通常遍历队列时更迅速地在队 列中推进优先的测试作业。根据一个实施例，测试调度器可以预留资源使用信息所指示出的资源以供将来使
19用，以便确保测试作业将具有充分的资源。例如，测试调度器可以预留一组系统以便在测试 作业的开始时间使用，从而确保届时没有其他进程在使用系统的资源。作为另一示例，测试 调度器可以向一系统发送指令，以禁止新测试作业使用该系统，直到特定的测试作业已结 束使用该系统为止。根据一个实施例，测试调度器能够例行监视测试作业的队列，因为它是连续运行 的进程。或者，测试调度器可以被诸如CR0N之类的系统调度器定期调用。每当测试调度器 被调用时，测试调度器就可以为作业队列中的每个测试作业检查测试作业的调度细节，以 便判定是否到时间启动该测试作业。它还可以使用这些调度细节来确定在何时系统调度器 应当接下来调用测试调度器。根据一个实施例，测试模块可以经由测试调度器向测试管理器发送测试细节，而 不是直接向测试管理器发送测试细节。例如，测试模块可以将测试细节直接插入到测试调 度器所维护的数据库中的一行或多行中。利用测试细节，或者在测试细节没有提供对开始 时间或必要资源的指示的情况下利用默认信息，调度组件可以基于测试细节确定何时启动 测试作业。它随后可将测试细节传递到测试管理器或者以其他方式指令测试管理器如何找 到测试细节。根据一个实施例，每个执行主机可以运行其自己的测试调度和测试管理进程。这 样，测试框架可以确保一个系统的故障将不会导致测试框架中的所有测试作业的丢失。分 开的测试调度器和测试管理进程可以与测试框架的中央调度器和测试管理器协同工作，以 获得冗余性。用于跟踪测试作业队列的界面图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。根据一个实施例，在测试作业期间用于测试软 件的每个系统可被认为是统计信息主机。或者，只有被测试作业使用的某些系统可被指定 为统计信息主机。测试细节可以按与测试细节指定一个或多个执行主机的方式很大程度上 相同的方式指定这些统计信息主机。另外，测试作业本身可以指定或确定一组统计信息主 机，并且测试作业可以向测试管理器标识这些统计信息主机。统计信息指令可包括使得性能监视组件开始或结束将性能统计信息记入日志的 命令。例如，响应于指示出差错状态或繁忙状态的测试反馈，测试管理器可被配置为发送指 令概要剖析器开始将数据记入日志的统计信息指令。作为另一示例，响应于指示出准备就
22绪状态的测试反馈，测试管理器可以向测试反馈或测试细节所指定的某些类别的性能监视 组件发送开始记入日志的统计信息指令。作为另一示例，响应于指示出准备就绪状态结束 的测试反馈，测试管理器可以发送指令性能监视组件将记入日志的数据发送到统计信息收 集器114或中央仓库以便收集执行主机上的统计信息的统计信息指令。根据一个实施例，测试作业可以请求测试管理器在一个或多个特定系统上或者在 测试作业中使用的所有系统上启动概要剖析器。作为响应，测试管理器可以向所指示出的 一个或多个系统发送统计信息指令。统计信息指令可包括在被接收方系统执行时调用概要 剖析器的命令。根据一个实施例，可改由统计信息收集器发送上述统计信息指令。响应于接收到 请求执行统计信息相关任务的测试反馈，测试管理器可以将该请求传递到统计信息收集组 件，例如统计信息收集器114。统计信息收集器随后可执行统计信息相关任务。根据一个实施例，统计信息主机不一定是在其上执行被测软件的系统。更确切地 说，统计信息主机可以是运行一个进程的系统，该进程使得它可以监视和监督正在执行被 测软件的其他系统上的性能日志的生成。结束测试作业测试管理器还可以负责在检测到测试作业已完成时执行某些管理性任务。它可以 例如通过监视执行主机上的执行脚本进程来检测测试作业的完成。它还可监视其他测试作 业进程。或者，测试作业可以发送测试反馈，以通知测试管理器测试作业已完成。如果测试管理器原本接收的测试细节包含了指示出在测试作业结束时要在执行 主机上执行的一个或多个命令的指令或属性，则测试管理器此时可以向执行主机发送具有 这些命令的测试指令。这些命令可以对所收集的性能日志执行多种操作。这些命令还可以 清除临时文件或将执行主机的环境恢复到其在测试管理器调用测试作业之前的状况。测试管理器还可以指令调度器在此时取消对测试作业中涉及的系统的预留，以便 调度器可以从测试作业队列中起动新测试作业。测试管理器还可以经由例如电子邮件消息来通知用户测试作业已完成。电子邮件 消息可包括到用于查看测试结果的界面(例如第4. 9节中论述的web界面)的链接。根据一个实施例，测试管理器随后可指令统计信息收集器(例如统计信息收集器 114)开始收集和处理在测试作业期间生成的性能统计信息。收集性能统计信息在以下第 4. 7节中论述。经由文件系统发送测试反馈根据一个实施例，测试作业可以经由文件系统向测试管理器递送测试反馈，例如 测试反馈193。测试作业可以在测试作业和测试管理器均可访问的文件系统中创建文件。 例如，测试作业可以将这些文件写入到系统170上的文件系统中的共享目录。测试管理器可以定期监视其共享目录以发现新文件。测试管理器可以将具有某些 预定名称的文件解释为测试反馈。例如，如果它看到名为START_PROFILER的文件，则测试 管理器将把该文件解释为请求测试管理器在测试作业所使用的系统上启动概要剖析器的 测试反馈。类似地，名为BEGIN_EXE⑶TI0N_STATE的文件可被解释为指示出准备就绪状态。测试作业还可以在文件内容内包括测试反馈。例如，它可以使用START_PROFILER 文件的内容来指示出在其上启动概要剖析器的系统。实际上，在一些实施例中，测试作业可以仅通过文件内容来传达测试反馈-文件的名称可能仅因为其向测试管理器指示出该 文件包含测试反馈而相关。作为另一示例，在第4. 1节中呈现的示例性执行脚本simple_ test.pl的测试计划包括通过向文件系统写入具有指定名称的文件来发送测试细节的 send_feedback例程的步骤。4.7.收集统计信息根据本发明的一个实施例，测试框架可以包含统计信息收集组件(例如统计信息 收集器114)作为一特色，以协助实现反映测试作业中使用的系统的性能的日志(例如日志 160)的收集。统计信息收集器可在整个测试作业期间搜集这些日志，或者它可以只是在测 试管理器指示出测试作业完成时搜集日志。测试管理器可以将某些指令传递到统计信息收集器，这些指令使得它能够确定它 应当采取哪些行动来获得这些日志。这些指令可以是根据测试细节、测试反馈、默认测试框 架设置或三者的任何组合得出的。这些指令例如可标识统计信息主机的列表、执行主机、测 试作业的开始和结束时间、测试作业的某些状态的开始和结束时间、是否使能概要剖析、统 计信息主机或测试作业向其输出日志的一个或多个共享仓库的位置，等等。统计信息收集 器可能能够自己确定这些细节中的一些_例如，它可能能够根据共享仓库内用于测试反馈 的文件确定开始和结束时间。根据本发明的一个实施例，在测试作业结束时，统计信息收集器向测试作业暗示 的多种日志生成组件中的每一个请求性能日志。统计信息收集器可能能够访问例如统计信 息主机的列表。或者，统计信息收集器可能能够自己获知用于一测试作业的统计信息收集 器的列表。统计信息收集器还可能能够访问或得出在每个统计信息主机上运行的资源监视 器和概要剖析器的列表。统计信息收集器可以向这些组件中的每一个请求它们可能已利用 与测试作业相关的度量收集的任何日志。为了允许日志生成组件判定日志是否相关，统计 信息收集器可识别开始时间和结束时间。开始时间和结束时间可以是整个测试作业的，或 者只是测试作业处于特定状态的一段时间的。统计信息收集器还可尝试从网络上的共享目 录收集日志，其中，按照测试细节或测试反馈所指示，被测软件或测试作业可能已向该共享 目录输出了日志。根据本发明的一个实施例，收集性能统计信息的负担的大部分可被转移到统计信 息主机本身。每个统计信息主机可以运行用于在该个体统计信息主机处收集日志的进程。 这种进程的代码可由测试框架提供。在接收到指示出测试作业的结束(或者指示出测试作 业的一状态(统计信息主机被请求收集其数据)的结束)的统计信息指令后，统计信息主 机上的进程可以向统计信息收集器发送所收集的日志。或者，统计信息主机上的进程可以 向执行主机发送日志，以被存储在专用于特定测试作业的集中仓库中。例如，统计信息主机 上的进程可以向同一共享文件夹发送日志，在该文件夹中测试作业的执行主机创建指示出 测试反馈的文件。根据一个实施例，测试计划本身可包含用于从每个统计信息主机上的日志生成组 件搜集日志的指令。例如，测试作业可能调用了被测软件的日志生成能力。它可以定位所 生成的日志并将它们直接转发到统计信息收集器或者将它们放置在用于该测试作业的集 中日志仓库中。默认系统性能统计信息
24
根据一个实施例，测试框架可以针对其调用的每个测试作业，从每个统计信息主 机收集默认的一组系统性能统计信息，不论这种统计信息是否被明确请求。这些默认统计 信息例如可包括处理器使用情况、存储器使用情况、网络利用情况、虚拟存储器使用情况、 正在执行的进程的数目、硬盘使用情况、总线使用情况，等等。统计信息收集器可以直接从统计信息主机上的资源监视器收集这些统计信息。例 如，统计信息收集器可以从嵌入在统计信息主机的操作系统中的资源监视器收集统计信 息。或者，每个测试框架上由测试框架发起的进程可以搜集这些统计信息。根据一个实施例，测试框架可以从测试集群中的所有系统收集该默认的一组系统 性能统计信息，而不论是否存在关于测试作业涉及测试集群中的特定系统的指示。测试作 业中未涉及的系统的统计信息可以在测试结果生成期间被确定和去除，或者它们可被保留 在测试结果中。4.8.生成测试结果在统计信息收集器收集了任何可用的日志_例如日志160-之后，统计信息收集器 可以将这些日志转发到测试结果生成组件，例如测试结果生成器115。或者，统计信息收集 器可以将日志返回到测试管理器或测试模块，它们中的任一个随后可将其转发到测试结果 生成器。测试结果生成器随后可将日志转化成测试结果。作为测试结果的一部分，测试结果生成器可以创建任何数目的数据报告，其中每 个数据报告可以包括与在所收集的日志中记录了其值的一个或多个性能度量或事件相关 的数据。每个数据报告可以包括时间序列数据、基于文本的日志条目或表格式数据，以及标 识相关性能度量等的元数据。测试结果可以以多种形式来生成。用于存储测试结果的一种形式可以是文件系统 上的数据文件的集合。例如，每个数据报告可被存储为一个文件，该文件是按照数据报告的 元数据或者发源数据报告的数据的日志来命名的。为了协助实现容易的浏览，这些数据文 件可以在与测试作业相关联的目录下以树状结构组织。这种目录可以在测试框架或测试模 块可访问的文件系统上。这种目录例如可以按照测试用例或测试细节中包括的测试作业标 识符来命名。树状结构可包括每个统计信息主机和每个日志生成组件的分支。它还可包括 根据汇总或分析生成的数据报告的分支。基于测试框架定义的方案，测试结果生成器也可改为将测试结果存储为数据库中 的行和表格或者XML文件中的元素。根据一个实施例，只要通过将每个收集的日志转化成单个数据报告，就可以生成 简单的测试结果。单个日志的内容可成为单个数据报告的数据。测试结果生成器可以基于 例如日志的文件名、日志内的头部或者与包含日志的文件相关联的属性来为数据报告生成 元数据。根据一个实施例，测试结果生成器可以通过对日志执行包括过滤、汇总和分析在 内的多种操作来创建更增强的测试结果。测试结果生成器可以默认执行这些和其他操作， 或者测试结果生成器可以在接受日志的同时接受输入，根据这些输入，测试结果生成器可 以确定执行哪些操作以及如何执行它们。所述输入例如可根据测试用例或测试细节来得
出o去除无关数据作是过滤无关数据。日志的每一行可包含指示出何 时发生了事件或者取得了度量值的时间戳。当它接收到日志时，测试结果生成器可能也从 发送方实体接收了指示出测试作业的开始时间和结束时间的数据。测试结果生成器可以去 除日志的所有未落在开始和结束时间之间的行。在一些情况下，所使用的开始或结束时间可以基于测试作业何时进入某个状态而 不是测试作业何时实际开始。测试结果生成器可能接收到了指示出测试作业的多个状态的 开始和结束时间的数据。测试结果生成器可被配置为去除不与特定状态(例如“执行”状 态)相对应的数据。此特定状态可以是为测试框架默认定义的，或者它可能是在测试细节 中被传达给测试管理器、然后被传递到测试结果生成器的。对数据重采样测试结果生成器可以执行的另一操作是数据重采样。日志可包含按某个频率取得 的度量值。测试结果生成器可以接收指示出测试结果应当以更低的频率报告度量的输入。 测试结果生成器可以对度量值重采样，以便在为测试结果生成的数据报告中它们是以期望 的频率被报告的。例如，日志可以每0. 1秒报告度量。测试用例可能请求了每秒报告度量。通过在 日志的每十行上对度量值取平均，并随后向数据报告输出十行的平均以及十行的中值时间 戳，就可以对度量重采样。在期望报告度量的频率高于日志中存储的频率的情况下，测试生成器也可能能够 为该度量内插数据，以便帮助用户猜测在特定时间该度量可能是什么值。按测试作业状态组织数据测试结果生成器还可以根据由测试管理器或统计信息收集器收集的状态数据来 对来自日志的数据进行组织。测试结果生成器可以将日志细分为针对每个状态的单独数据 报告。每个数据报告可以仅包括在测试作业处于数据报告的特定状态中时取得的度量值或 发生的事件。每个这种数据报告的元数据可以标识数据报告所属的状态。关联相关度量测试结果生成器可以将某些度量关联到同一数据报告中。例如，可能存在具有属 于相关度量的时间序列数据的单独日志。测试结果生成器可以将这些度量输出到同一数据 报告中的表格格式，以便这些度量可以更容易被关联。在度量值是在不同时间或按不同频 率取得的情况下，合并度量可能需要例如对度量重采样或者调节度量的时间戳。测试结果生成器还可以基于相关度量执行计算，以便更好地标识度量之间的关联 性。例如，存储器使用情况可以被除以线程计数，以得出反映系统上的每个线程所使用的存 储器的平均量的数据报告。这种关联的数据报告的元数据可以标识诸如“每线程存储器”的 标题。元数据还可以标识个体度量“存储器”和“线程”的数据报告，以便允许用户向下钻 取到更多细节。跨系统汇总统计信息测试结果生成器还可以跨多个系统生成汇总的数据报告。测试结果生成器可以识 别来自测量相同度量的不同系统的日志(或者已经生成的数据报告)。如果每个日志中的 度量是以相同的频率在大致相同的时间采样的，则测试结果生成器只要通过对每个特定时 间对来自每个系统的度量值取平均，就可以生成汇总数据报告。如果度量是在不同的时间
26或按不同的间隔采样的，则测试结果生成器可以采用若干操作来汇总它们，例如对度量重 采样并随后对其取平均。将日志转化成示图可查看统计信息测试结果生成器还可以采用技术来将某些基于事件的日志转化成可以图形可视 化的数据报告。例如，日志生成组件可能在每次某个事件发生时向日志输出了一行。测试 结果生成器可以根据这些事件确定每秒发生事件的次数。它可以在数据报告中输出一行， 该行带有测试作业的每秒的时间戳在该秒中发生的事件的数目。从而，数据报告随后可被 可视化为示出每秒的事件数目的示图。突出关键统计信息测试结果生成器可以分析特定数据报告中的度量值以确定对于该数据报告关注 的标准统计信息，包括平均值、最小值、最大值、标准偏差等等。这些值可被存储供以后用作 数据报告的元数据。突出重要或非预期结果测试结果生成器还可以采用分析技术来突出数据中的重要或非预期结果。它可以 在测试结果中包括包含这种重要或非预期结果的数据报告的列表。例如，测试结果生成器可被配置为突出这样的度量这些度量的值在测试作业的 过程期间的改变高于某个预定的百分比。作为另一示例，测试结果生成器可被配置为突出 具有超过标准偏差的值的度量。作为另一示例，测试结果生成器可能接收了指示出特定度量的某个阈值的指令。 此阈值可能是在测试细节中指定的。例如，用户可能将此阈值作为测试用例的一部分提交。 或者，测试模块可能通过分析先前执行的测试作业中的该度量的值而确定了此阈值。如果 对于特定数据报告中的度量，该阈值被超过，则测试结果生成器可以将该数据报告添加到 重要或非预期结果的列表。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_c0mmand. 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的另一窗口中显示这些分析和汇总操作的结果。比较来自其他测试作业的结果根据一个实施例，来自测试作业的测试结果可以被保存，以便将来对照来自将来
29的测试作业的测试结果查看和分析。对于新测试结果中的任何数据报告，测试报告器可以 自动在先前存储的测试结果中查找类似度量的数据报告。它可以将先前测试结果中的类似 度量的示图覆盖在新测试结果中的类似度量的示图上，以便比较。这样，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包括控于删除、取消选择和保存web界面1000的定制视图。web界 面1000还可包括用于打印定制视图的控件。web界面1000还包括允许用户输入注释以供 将来参考的注释框1050。用户可以创建和保存任何数目的这种定制视图，每一个具有不同 的标题。根据一个实施例，定制视图与测试模块而不是单个测试结果相关联。一旦被保存， 定制视图就可以为针对该测试模块生成的所有测试结果示出。当用户保存定制视图时，测 试模块可以保存指示出由定制视图中的每个数据报告记录的一个或多个度量的元数据。对 于任何后续的测试结果，测试报告器可以使用此元数据来确定在该后续测试结果的定制视 图中要示出的数据报告。例如，用户可以创建一定制视图，该定制视图包括示出第一测试结果的处理器利 用情况的示图。当用户保存此定制视图时，测试模块可以存储指示出该定制视图包括了处 理器利用情况度量的示图的信息。当用户查看后续测试结果时，测试报告器可以为后续测 试结果自动生成相应定制视图。相应定制视图可以包括示出第二测试结果的处理器利用情 况的示图。如果后续测试结果不包含处理器利用情况度量的数据报告，则后续测试结果的 定制视图可以简单地不包括处理器利用情况度量的示图。根据一个实施例，保存的定制视图可以与测试用例模板相关联而不是与测试模块 总地相关联，意味着针对基于相同测试用例模板的测试作业生成的任何测试结果都可自动 包括为针对基于同一测试用例模板的另一测试作业生成的另一测试结果保存的定制视图。 测试用例模板在4. 3中论述。4. 10.操作系统独立性根据本发明的一个实施例，测试框架的各个方面是独立于平台的，意味着测试框 架可被部署在具有运行多种操作系统的系统的测试集群上。根据一个实施例，测试框架可包括能够自动检测执行主机和统计信息主机的操作 系统的代码。当_经由例如安全外壳或telnet会话-向操作系统本身发送测试指令或统 计信息指令时，测试框架可以以可在检测到的操作系统上执行的格式发出命令或重新编排 命令格式。根据一个实施例，测试框架可被配置为自动搜索测试集群中的每个系统上的资源 监视或概要剖析组件。测试框架可包括可用在特定系统的操作系统上的多个概要剖析器或 资源监视组件的列表。测试框架可以搜索列表中的每个组件，或者在其找到第一个可接受 的组件时停止搜索。它例如可以搜索文件系统中的一个或多个默认位置以定位特定概要剖 析器或资源监视组件的可执行文件。它随后可调用此可执行文件。它还可以使用例如系统 注册表来定位特定的概要剖析器或资源监视应用。根据一个实施例，测试框架可被配置为在测试集群中的每个系统上安装其自己的 概要剖析或资源监视组件，从而确保它将能够访问每个系统上的概要剖析或资源监视组 件。根据一个实施例，每当在测试细节中标识一统计信息主机时，如果测试框架无法定位到 适当的概要剖析器或资源监视组件，则测试框架可以在该统计信息主机上安装其自己的概 要剖析或资源监视组件。对于在测试集群中的系统上运行的每个操作系统，测试框架可以 存储在该操作系统上运行的概要剖析和资源监视组件的安装程序。根据一个实施例，测试框架可被配置为与测试集群中的每个操作系统上的至少一
31个概要剖析器和资源监视组件生成的日志通信并理解这些日志。它例如可以知道控制每个 概要剖析或资源监视组件所必需的配置参数。或者，它可以知道如何为每个概要剖析或资 源监视组件向专用端口发送命令。它还可以知道概要剖析或资源监视组件存储其日志的默 认位置。根据一个实施例，测试框架中的每个系统可以运行测试框架所管理的管理进程。 测试框架不需要知道如何与系统的操作系统和日志生成组件远程通信，而是可以改为与此 进程通信。此进程随后可被配置为代表测试框架与操作系统和日志生成组件本地通信。根据一个实施例，测试框架和测试模块的界面可以是独立于平台的。例如，界面可 以是可在任何操作系统上的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-EPR0M、任何其他存储器芯片或卡盘，下文中描述的载波，或者计算机可以读 取的任何其他介质。各种形式的机器可读介质可用于将一条或多条指令的一个或多个序列传送到处 理器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.扩展和替换在以上说明书中，已参考对于每种实现方式可能不同的许多具体细节描述了本发 明的实施例。因此，关于本发明是什么以及申请人希望本发明是什么的唯一和排他指示是 根据本申请授权的那套采取其授权时的特定形式的权利要求，包括任何后续的更正。这里 针对这种权利要求中包含的术语明确阐述的任何限定都应当决定这种术语在权利要求中 使用时的含义。因此，在权利要求中没有明确记载的限定、要素、性质、特征、优点或属性都 不应当以任何方式限制这种权利要求的范围。因此，说明书和附图应被认为是说明性的而 不是限制性的。
3权利要求
一种用于为在多主机系统上运行的应用收集性能统计信息的由计算机实现的方法，包括以下步骤在测试框架处接收指定测试细节的输入，其中所述测试细节包括测试计划；基于所述输入，所述测试框架在执行主机上执行所述测试计划，其中执行所述测试计划包括在多个主机中的每一个上发起应用的至少一部分的执行；从所述多个主机中的每个主机接收指示出特定时间段的性能统计信息的性能数据；基于所述性能数据，所述测试框架生成测试结果，该测试结果包括针对多个性能度量的多个数据报告；以及所述测试框架向用户呈现所述测试结果。
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)接收指定测试作业的测试细节的输入，其中所述测试细节包括所述测试作业的测 试计戈丨J ；(2)确定所述测试集群中的能用于实现所述测试作业的所述测试计划的一个或多个步 骤的一个或多个系统；(3)判定所述一个或多个系统中的任何一个是否被预留用于任何其他测试作业；(4)如果所述一个或多个系统都没有被预留用于任何其他测试作业，则根据所述测试 计划执行所述测试作业；以及(5)如果所述一个或多个系统中的任一个被预留用于另一测试作业，则等待一段时间， 然后重复步骤3-5。
18.如权利要求17所述的方法，其中，确定所述一个或多个系统包括参考所述测试细 节中包括的一组期望系统特性，该组期望系统特性包括以下特性中的至少一种处理器类 型、操作系统、盘存储设备、系统存储器和安装的软件。
19.如权利要求17所述的方法，其中，判定所述一个或多个系统中的任一个是否被预 留用于任何其他测试作业包括监视在一个或多个系统中的每一个上执行的一个或多个进 禾呈。
20.如权利要求19所述的方法，还包括以下步骤 为所述测试集群中的每个系统维护预留信息；在根据所述测试计划执行所述测试作业后，更新所述预留信息以指示出所述一个或多 个系统被预留；以及在检测到所述测试作业已完成所述测试计划后，更新所述预留信息以指示出所述一个 或多个系统未被预留；其中，判定所述一个或多个系统中的任一个是否被预留用于任何其他测试作业的步骤 包括对于所述一个或多个系统中的每个特定系统判定所述预留信息是否指示出所述特定 系统被预留。
21.—种在包括多个系统的测试集群中执行用于测试软件性能的测试作业的由计算机 实现的方法，包括以下步骤在所述测试框架处，执行以下步骤接收指定所述测试作业的测试细节的输入，其中所述测试细节包括所述测试作业的测 试计戈丨J ；确定实现所述测试计划所需的一个或多个资源；确定所述测试集群中的能作为实现所述测试作业的所述测试计划的步骤的所述一个 或多个资源的一个或多个系统；确定所述一个或多个系统中的特定系统不包括所述一个或多个资源中的至少一个； 使得所述一个或多个资源被安装在所述特定系统上； 根据所述测试计划执行所述测试作业。
22.如权利要求21所述的方法，其中，所述一个或多个资源包括执行脚本，该执行脚本 包括表示所述测试计划的代码。
23.如权利要求21所述的方法，其中，所述一个或多个资源包括要被所述软件处理的 测试数据。
24.如权利要求21所述的方法，其中，所述一个或多个资源包括配置信息。
25.如权利要求21所述的方法，其中，所述一个或多个资源包括所述软件的组件。
26.如权利要求21所述的方法，其中，所述一个或多个资源包括运行所述软件的组件 所需的包。
27.一种计算机可读存储介质，存储着一个或多个指令序列，这些指令序列在被一个或 多个处理器执行时，使得这一个或多个处理器执行如权利要求1-26中任何一个所述的方法。
全文摘要
利用测试框架，开发者可以创建测试模块来在多个系统之间为软件测试计划集中资源和结果。利用来自测试框架的辅助，测试模块可以协助实现测试用例的创建、针对每个测试用例的测试作业的执行、每个测试作业期间性能统计信息的收集以及将收集的统计信息汇总成有组织的报告以便更容易分析。测试模块可以跟踪测试结果以便能够容易地比较响应于开发过程的历史期间的各种条件和环境的性能度量。测试框架还可以调度测试作业以便在测试作业所需的各种系统和资源空闲时执行。测试框架可以是独立于操作系统的，从而单个测试作业可以同时在多种系统上测试软件。
文档编号G06F15/00GK101933001SQ200980103883
公开日2010年12月29日 申请日期2009年1月27日 优先权日2008年1月31日
发明者丹尼尔·布里多, 乔治·吴, 塞潘·帕尼格拉, 斯蒂芬·纳尔逊, 格里史·威泽斯万 申请人:雅虎公司