CN102341781A

CN102341781A - 软件测试台生成

Info

Publication number: CN102341781A
Application number: CN2010800118056A
Authority: CN
Inventors: R·L·斯通; C·A·库布利; A·J·萨格维; A·格林伯格
Original assignee: Microsoft Corp
Current assignee: Microsoft Technology Licensing LLC
Priority date: 2009-03-06
Filing date: 2010-02-26
Publication date: 2012-02-01
Anticipated expiration: 2030-02-26
Also published as: WO2010101792A3; CN102341781B; US20100229150A1; US8392896B2; WO2010101792A2

Abstract

描述了用于生成用于开发、测试软件(诸如用于管理IT过程和/或监视企业网络中的设备的软件)和/或支持对该软件的使用的测试台的系统和方法。该系统和方法通过处理清单以生成计算机网络的实例空间模型来进行操作，其中清单引用计算机网络的类型空间模型并包括传达用来将计算机网络的类型空间模型膨胀为计算机网络的实例空间模型的参数的编码。类型空间模型可以包括对象-关系有向图，该有向图描述多个潜在有向图实例，并且实例空间模型可以包括该多个潜在有向图实例中的一个。

Description

软件测试台生成

背景技术

正在开发和发布使网络管理员能协调信息技术(IT)过程和/或自动地监视企业网络中的设备的健康状况的软件产品和程序(一般称为“软件”)。一旦被安装，这样的软件可以生成和存储描述企业网络中的实际实体和它们之间的关系的数据以及涉及这样的实体的操作的数据。为了为特定企业或企业类型开发、测试这样的软件和支持对这样的软件的使用，如果软件被一个实际企业安装，能够针对适当地表示将由该软件所生成的数据的量和内容的测试数据运行该软件是十分重要的。

获取这样的数据的一种方法是在软件已经安装并被使用一段时间之后从企业本身获取它。然而，由于关于数据将如何被处理的隐私顾虑以及还由于收集这样的数据可能要求消耗企业的时间和/或资金，许多企业可能对此方法感到不舒服。甚至在一个企业愿意共享这样的数据的情况下，也可能有这样的数据或这样的数据的某些子集无法由软件开发人员获取和/或用于测试的技术原因。从特定企业获得的数据的独特性也可能使这样的数据不适合用于主流测试。

如果软件还没有被发布或者如果一个企业不愿意或不能够共享由软件所生成的数据，则无法从该企业直接获得测试数据。在此情况下，必须由开发人员采取某种方法来生成测试数据。考虑到通常所需的数据的量，手动生成不是可行的方法。因此，必须使用某种自动化方法。虽然自动化测试数据生成器能够产生大量的测试数据，但是它们往往是受限于它们不能生成公平地表示当软件由实际企业安装时由该软件产生的那种数据的丰富而有变化的测试数据。

与生成测试数据相关联的另一个挑战涉及准确地为某一企业或企业类型的测试数据进行建模，因为IT基础结构有相当大的不同。常规上，对企业进行分类的问题常常通过将企业放在预定义的类(例如，小型、中等市场、全球)中并随后作出关于每一个类的在某种程度上是任意的并且脱离实际数据的假设，而以非常粗略的方式来处理。分类的另一种方法涉及要求一个企业的代表填写一份详细的调查，该调查用来沿着各种维度(例如，大小、企业拓扑结构、对各种技术的使用、垂直行业、多民族或多地区、语言、面向因特网或面向内部、技术采用率等等)来分类企业。然而，常常难以将这样的信息与用于为企业生成代表性测试数据的参数相关联。此外，当回答调查时，代表常常对企业了解不足而难以提供准确的回答。

因而所需要的是用于生成用于开发、测试软件(诸如用于管理IT过程和/或监视企业网络中的设备的软件)和/或支持对该软件的使用的测试台的系统和方法。优选地，该系统和方法应该能以自动化方式为特定企业或企业类型生成大量的真实而丰富的测试数据，其中这样的测试数据公平地表示当该软件由该特定企业或企业类型安装时由该软件产生的那种数据。

发明内容

提供本发明内容是为了以精简的形式介绍将在以下具体实施方式中进一步描述的一些概念。本发明内容并不旨在标识出所要求保护的主题的关键特征或必要特征，也不旨在用于限定所要求保护的主题的范围。

此处描述了用于生成用于开发、测试软件(诸如用于管理IT过程和/或监视企业网络中的设备的软件)和/或支持对该软件的使用的测试台的系统和方法。该系统和方法能以自动化方式为特定企业或企业类型生成大量的真实而丰富的测试数据，其中，这样的测试数据公平地表示当该软件由该特定企业或企业类型安装时由该软件产生的那种数据。

具体而言，此处描述了一种用于生成用于开发、测试软件和/或支持对该软件的使用的测试台的计算机实现的方法。根据该方法，接收清单。清单引用计算机网络的类型空间模型，该类型空间模型包括硬件、软件、网络以及存储实体类型，并包括传达参数的编码，该参数可以被用来将计算机网络的所述类型空间模型膨胀为计算机网络的实例空间模型。然后，处理清单以创建计算机网络的实例空间模型。将表示实例空间模型的数据存储到物理存储介质中。

取决于实现，类型空间模型也可以包括进程数据实体。

在一个实施例中，编码传达基数信息，该信息指定在创建实例空间模型时要生成的实体类型实例或关系类型实例的具体数量。编码也可以传达属性信息，该信息指定要与在创建实例空间模型时所生成的实体类型实例相关联的属性。

在一特定实施例中，类型空间模型包括对象-关系有向图，该有向图描述多个潜在有向图实例，而实例空间模型包括该多个潜在有向图实例中的一个。

此处还描述了一种用于生成清单的计算机实现的方法。清单引用计算机网络的类型空间模型，该类型空间模型包括硬件、软件、网络以及存储实体类型，并包括传达参数的编码，该参数可以被用来将计算机网络的所述类型空间模型膨胀为计算机网络的实例空间模型。根据该方法，使用网络管理软件产品来收集关于企业网络的信息。从收集到的信息中提取由清单中所包括的编码传达的一个或多个参数。然后，使用所提取的参数来生成清单。

在一个实施例中，前述的方法还包括对于与多个不同的企业相关联的多个不同的企业网络执行收集、提取和使用步骤，以生成多个清单，并组合该多个清单中的两个或更多以创建原型清单。在一个特定实现中，组合多个清单中的两个或更多以创建原型清单包括基于由多个清单中的每一个清单中的编码所传达的参数来聚集这些清单，以生成一个或多个清单集群，以及基于由至少一个集群中所包括的各清单中的每一个清单中的编码所传达的参数，来创建与该集群相关联的原型清单。此处还描述了一种用于生成用于开发、测试软件和/或支持对该软件的使用的测试台的系统。该系统包括类型空间定义处理器、实体引擎以及数据库写入动作模块。类型空间定义处理器被配置成接收清单，并从其中获取计算机网络的类型空间模型以及可以被用来将计算机网络的类型空间模型膨胀为计算机网络的实例空间模型的参数，其中类型空间模型包括硬件、软件、网络以及存储实体类型。实体引擎被配置成处理类型空间模型和参数以创建计算机网络的实例空间模型。数据库写入动作模块被配置成将表示所述实例空间模型的数据存储到物理存储介质中。

下面将参考各个附图，详细描述本发明的进一步特点和优点以及本发明的各实施例的结构和操作。值得注意的是，本发明不仅限于此处所描述的具体实施例。这样的实施例只是出于例示的目的。基于此处所包含的原理，另外的实施例对那些相关领域技术人员是显而易见的。

附图简述

结合到本说明书并构成本说明书的一部分的附图示出了本发明，且与具体实施方式一起进一步用于说明本发明的原理，并使本领域技术人员能够实施和使用本发明。

图1是根据本发明的一实施例的示例测试台生成系统的框图。

图2描绘了根据本发明的一实施例的用于生成测试台的方法的流程图。

图3描绘了有向图的示例。

图4描绘了树的示例。

图5描绘了无环有向图的示例。

图6描绘了有环有向图的示例。

图7描绘了根据本发明的一实施例的实体引擎基于计算机网络的类型空间模型来生成计算机网络的实例空间模型的方法的流程图。

图8描绘了根据本发明的一实施例的准备和细化清单的数据流程。

图9描绘了可以被用来实现本发明的各个方面的示例基于处理器的计算机系统。

通过下面的结合附图对本发明进行的详细说明，本发明的特点和优点将变得更加显而易见，在附图中相同的附图标记在整个说明书中标识对应的元素。在附图中，相同的附图标记一般指示相同的、功能上类似的和/或在结构上类似的元素。元素首次在其中出现的附图由对应的附图标记中最左边的数字来指示。

具体实施方式

A.测试数据生成系统和方法

图1是根据本发明的一实施例的示例测试数据生成系统100的框图。示例测试数据生成系统100可以有利地被用来生成用于开发、测试软件产品或程序和/或支持对该软件产品或程序的使用的测试台。例如，测试数据生成系统100可以被用来生成一个测试台，该测试台可以用于开发、测试对用于执行网络管理功能的软件产品或程序和/或支持该软件产品或程序的使用，其中这些功能可包括，但不仅限于，管理IT过程和/或监视企业网络中的设备。在一个具体实施例中，测试数据生成系统100被用来生成测试发现数据以用于开发、测试MICROSOFT SYSTEM CENTER SERVICE MANAGER(微软系统中心服务管理器)的一个版本或MICROSOFT SYSTEM CENTER OPERATIONSMANAGER(微软系统中心操作管理器)的一个版本和/或支持对它们的使用，这些版本中的每一个都是位于美国华盛顿州雷德蒙市的微软公司发布的。然而，这些产品只作为示例，并且系统100可以被用来生成用于各种其他软件产品或程序的测试数据。

如图1所示，系统100包括许多元件和过程，下面将描述其中每一个。在一个实施例中，图1所示出的每一个过程都被实现为软件，软件可以由诸如下面参考图9所描述的示例基于处理器的计算机系统900之类的基于处理器的计算机系统来执行。在一种实现中，所有软件实现的过程都由单个计算机系统来执行。可另选地，不同的软件实现的过程可以由不同的计算机系统来执行，并且数据可以通过网络或某种其他渠道在不同的过程之间传递。

模型储存库102包括可以被用来存储由系统100所生成的测试数据的数据库或某种其他结构化数据集。在执行系统100的任何过程之前，模型储存库102被用元数据填充，该元数据描述了可以存在于模型储存库102中的实例实体的类型以便待测试的系统的其余部分正常地运转。实例实体可包括，例如，硬件、软件、网络和存储实体。此元数据可以被视为描述企业网络的“类型空间模型”的一种方式。在一个实施例中，数据库102包括通过在计算机系统上安装MICROSOFT SYSTEM CENTER OPERATIONS MANAGER的一个版本来创建的数据库。进一步根据此实施例，在一个或多个管理包中体现描述类型空间模型的元数据，管理包被作为安装过程的一部分和/或在安装过程之后加载到模型储存库102中。

储存库元数据读取器104是被配置成提取描述存储在储存库102中的类型空间模型的元数据并将它提供给类型空间定义处理器106的过程。

类型空间定义处理器106部分地被配置为从储存库元数据读取器104中接收所提取的描述类型空间模型的元数据，并处理所提取的元数据以生成引用类型空间模型的清单108。清单108可以被格式化，以便它可以被用户使用计算机实现的用户界面工具轻松地阅读和注释。在一个实施例中，清单108包括可扩展标记语言(XML)文档，但是这只是一个示例。

根据一种实现，用户手动地注释清单108以向其中添加某些经编码的参数。在图1中，这样的手动注释一般由用户输入框110来表示。如此处比较详细地描述的，被添加到清单108中的经编码的参数供实体引擎114使用，以将被清单108引用的类型空间模型转换为特定企业网络的存储器-实例化的模型，此处也被称为“实例空间模型”。例如，尽管类型空间模型可以描述一个企业网络内存在的实体的所有类型，但是由用户所添加的经编码的参数可以指定在特定实例空间模型内应该实际存在那些实体类型的多少实例。经编码的参数也可以指定应该与每一个实体实例相关联的属性。例如，可以指定可以被用来确定要与一个或多个实体实例相关联的属性值的属性规则。作为另一个示例，尽管类型空间模型可以描述一个企业网络中的各实体类型之间存在的关系的所有类型，但是由用户所添加的经编码的参数可以指定在特定实例空间模型内应该实际存在那些关系类型的多少实例。

在一个实施例中，由用户向清单108添加的经编码的参数包括基数信息，该信息指定在创建实例空间模型时要由实体引擎114生成的实体类型实例以及关系类型实例的具体数量。由用户向清单108添加的经编码的参数也可以包括属性信息，该信息指定要与在创建实例空间模型时由实体引擎114生成的各种实体实例相关联的属性。

类型空间定义处理器106进一步被配置成接收被注释的清单108，并基于该清单来在存储器中创建企业网络的类型空间模型112。在一个实施例中，类型空间模型112包括被清单108引用的适于由实体引擎114进行处理的类型空间模型的对象模型。此对象模型可以例如通过对已注释的清单108进行并行化(de-serialize)来获得。类型空间模型112还作为注释过程的一部分来合并被引入到清单108的参数。在一个实施例中，类型空间定义处理器106可用于将这些参数中的一个或多个从在清单中所使用的格式(例如，串格式)转换为另一种格式(例如，整数值)，以便合并在类型空间模型112内。

实体引擎114被配置成读取类型空间模型112，并基于类型空间模型112以及其中合并的参数来创建特定企业网络的实例空间模型116。例如，实体引擎114可以通过根据类型空间模型112内所合并的基数信息创建类型空间模型112内所包括的每一个实体以及关系类型的0-n个实例，来生成实例空间模型116。作为另一个示例，实体引擎114可以通过根据类型空间模型112内所合并的属性规则将属性与各种实体实例相关联，来创建实例空间模型116。

如此处针对本发明的特定实现更详细地讨论的，取决于对清单108进行注释的方式，实体引擎114可以按确定性的或非确定性的方式来生成实例空间模型116。

一旦由实体引擎114创建了实例空间模型116，储存库写入动作模块118用于将实例空间模型116写入到模型储存库102。此过程包括将表示实例空间模型116的数据存储到物理存储介质中。在一个实施例中，将表示实例空间模型116的数据存储到物理存储介质的过程可以被分成多个循环。在每一个循环中，从实体引擎114接收表示实例空间模型116的数据的一部分，然后，由储存库写入动作模块118存储到模型储存库102。如下实现可能是所希望的：可用于存储表示实例空间模型的数据的存储器量是受限的。

尽管图1中未示出，但是系统100也可以包括一个或多个可选插件模块。插件模块可以与实体引擎114和储存库写入动作模块118一起使用，以修改和/或增强这些元件中的一个或两者的操作。在一个实施例中，至少一个插件模块被用来使储存库写入动作模块118的数据存储操作被如前所述地分成多个循环。插件模块还可以进一步被用来修改和/或增强实体引擎114创建实例空间模型116的方式或储存库写入动作模块118将表示实例空间模型116数据写入到物理存储介质的方式。

图2描绘了根据本发明的一实施例的用于生成测试台的方法的流程图200。现在将继续参考如上文参考图1所描述的系统100的元件来描述流程图200的方法。然而，该方法不仅限于该实现。

如图2所示，流程图200的方法从步骤202开始，在该步骤中，储存库元数据读取器104从模型储存库102中提取描述计算机网络的类型空间模型的元数据。类型空间模型可以描述，例如，计算机网络内存在的实体类型以及各实体类型之间存在的关系类型。

在步骤204中，实体定义处理器106处理所提取的元数据以生成引用类型空间模型的用户-可阅读的/可编辑的清单108。此步骤可以包括，例如，将类型空间模型串行化为诸如XML文档之类的用户可阅读的/可编辑的文档。

在步骤206中，用户对清单108进行注释以将经编码的参数添加到其中。用户可以例如经由计算机实现的用户界面工具来对清单108进行注释。经编码的参数可包括例如基数信息，该基数信息指定在创建实例空间模型时要生成的实体类型实例或关系类型实例的具体数量。经编码的参数也可以包括例如属性信息，该信息指定要与在创建实例空间模型时所生成的至少一个实体类型实例相关联的属性。例如，可以指定可以被用来确定要与一个或多个实体类型实例相关联的属性值的属性规则。如在下面的章节C中所描述的，在某些实现中，此注释步骤也可以自动地执行。

在步骤208中，类型空间定义处理器106接收清单108的经注释的版本并处理它以获得计算机网络的类型空间模型112。类型空间模型112合并了在步骤206中添加到清单108的参数。

在步骤210中，实体引擎114基于类型空间模型112以及其中包括的参数来创建计算机网络的实例空间模型116。例如，实体引擎114可以通过根据类型空间模型112中所合并的基数信息创建类型空间模型112中所包括的每一个实体以及关系类型的0-n个实例，来生成实例空间模型116。作为另一个示例，实体引擎114可以通过根据类型空间模型112内所合并的属性规则将属性与各种实体实例相关联，来生成实例空间模型116。在步骤212中，储存库写入动作模块118将表示由实体引擎114所创建的实例空间模型116的数据存储到模型储存库102中。

现在将描述系统100的特定实现以及流程图200，其中计算机网络的类型空间模型包括对象-关系有向图，该有向图描述多个潜在有向图实例，并且其中计算机网络的实例空间模型包括该多个潜在有向图实例中的一个。

B.示例系统实现

现在将描述系统100的特定实现，其中要生成的测试数据是与MICROSOFT SYSTEM CENTER OPERATIONS MANAGER(下面简称为“SCOM”)的一个版本相关联的数据库的测试发现数据。在此实施例中，系统100被配置成创建基本上类似于将在正常SCOM发现过程中生成的发现数据的SCOM发现数据。如下文所描述的，这样的发现数据将企业网络建模为有向图。需要注意的是，在此章节所描述的系统100的实现的各方面也可以被用来生成与MICROSOFT SYSTEM CENTER SERVICE MANAGER(下面简称为“SCSM”)的版本相关联的数据库的测试发现数据。由此，此章节也可以包括对SCSM的引用。

值得注意的是，此实施例只是作为示例描述的。相关领域技术人员将容易理解，此处所描述的概念可以被扩展到为其他软件产品以及程序生成测试数据，包括，但不仅限于，使用由类型空间元数据所定义的实体以及关系来生成有向图实例空间的其他软件产品以及程序。

1.背景以及术语

为促进对此实施例的理解，定义某些术语是有帮助的。下面是将涉及有向图的概念与SCOM数据库建模技术的语言进行关联的简要定义。

SCOM数据库被设计成提供企业网络的简明视图。为实现这一点，该数据库对计算机，这些计算机之间的关系，安装在这些计算机上的软件，以及这性计算机以及软件的健康状况、性能以及状态进行建模。该模型是以有向图的形式来表示的，并存储在SCOM数据库中。

a.有向图术语

现在将讨论通常用来描述有向图的某些术语。有向图可以被定义为一组节点和边，其中边将节点彼此连接。每一条边都采取在一个节点开始并在一个节点结束的箭头的形式。图3描绘了具有连接三个节点(表示为302、304以及306)的三条边(表示为312、314以及316)的示例有向图300。

i.节点和边

有向图中的节点可以包括用来表示某一状态、位置或对象的点、圆或某种其他符号。节点的示例可以是地图上的城市。有向图中的边可以表示节点之间的路线。例如，可以将连接城市A与城市B的高速公路的向北行驶的车道表示为一条边。也可以将该同一条高速公路的向南行驶的车道表示成连接城市B与城市A的边。

ii.环和有环有向图

可以使用术语“父节点”和“子节点”来描述某些有向图中的边从其开始和结束的节点。由此，继续参考前面的涉及城市A和城市B的城市示例，高速公路的向北行驶的边具有父节点“A”和子节点“B”。向南行驶的边具有父“B”节点和子节点“A”。对有向图的某些描述通过简单地声明“A”是“B”的父节点，“B”是“A”的父节点来简化这一点。由于此示例中的任一节点是另一节点的父节点，因此该有向图是有环的。

环可能是平凡的或复杂的。在同一节点开始和结束的边是平凡的。更加复杂的环可包括追溯从一个节点开始和在该节点终止的路线的许多节点和边。追溯有向图的算法必须考虑环以避免无限循环。

iii.树

树可以被定义为具有下列特征的有向图：(1)一个节点可以具有从它指出的0-n条边；(2)一个节点可以具有指向它的0-1条边；以及(3)该有向图不能具有任何环。在树中，节点和边彼此构成父子关系。例如，图4描绘了具有四个节点(表示为402、404、406和408)和三条边(表示为412、414和416)的树400。在树400中，可以说节点402是节点404、406和408的父节点，因为边412、414和416从节点402分别指向节点404、406和408。

iv.无环有向图

无环有向图可以被定义为具有下列特征的有向图：(1)一个节点可以具有从它指出的0-n条边；(2)一个节点可以具有指向它的0-n条边；以及，(3)该有向图不能具有任何环。值得注意的是，无环有向图和树之间的唯一区别是，一个节点可以具有一个以上的父节点。图5描绘了具有七个节点(表示为502、504、506、508、510、512和514)和六条边(表示为522、524、526、528、530和532)的示例无环有向图500。在无环有向图500中，可以说节点502是节点506、508和510的父节点，因为边522、524和526从节点502分别指向节点506、508和510。此外，还可以说节点504是节点510、512和514的父节点，因为边528、530和532从节点504分别指向节点510、512和514。

v.有环有向图

有环有向图类似于无环有向图，只是已经移除了针对环的限制。有环图可以被定义为具有下列特征的有向图：(1)一个节点可以具有从它指出的0-n条边；(2)一个节点可以具有指向它的0-n条边；以及，(3)该有向图可以具有环。图6描绘了具有七个节点(表示为602、604、606、608、610、612和614)和八条边(表示为622、624、626、628、630、632、634和636)的示例有环有向图600。在有环有向图600中，可以说节点602是节点606、608和610的父节点，因为边622、624和626从节点602分别指向节点606、608和610。可以说节点604是节点610、612和614的父节点，因为边628、630和632从节点604分别指向节点610、612和614。

此外，在有环有向图600中，可以说节点606是节点614的父节点，因为边634从节点606指向节点614。反过来，可以说节点614是节点606的父节点，因为边636从节点614指向节点606。节点606和614之间的互逆的父子关系构成一个环。

b.SCOM术语

如上文所指出的，SCOM数据库将企业网络建模为有向图。尽管如此，用来描述SCOM数据库的术语在某种程度上不同于上述的有向图术语。下面将试图部分地说明某些SCOM术语和对应的有向图术语之间的关系。

i.实体和实体类型

SCOM使用术语“实体”来表示节点。实体可以包括，例如，但不仅限于，计算机、软件产品或程序的实例(例如，位于美国华盛顿州雷德蒙市的微软公司发布的MICROSOFT SQL SERVER(微软SQL服务器)或MICROSOFTINTERNET INFORMATION SERVICES(微软因特网信息服务)的实例)、数据库、网站、或组名。可以为每一个实体定义类型。例如，可以为实体定义诸如“Windows.Computer(Windows计算机)”、“SQL.Engine(SQL引擎)”、“Database(数据库)”等等之类的类型。需要注意的是，在SCSM中，实体可以包括，例如，但不仅限于，更改请求、用户对事件的评论、更改请求中的完成更改请求手动活动的分析者条目、软件更新等等。

ii.关系以及关系类型

SCOM使用术语“关系”来表示连接实体的边。可以使用术语“源实体”和“目标实体”来描述关系的方向。在SCOM中有三个显式的关系类型：主存关系、包含关系和引用关系。需要注意的是，在SCSM中，一个示例关系可以是“计算机安装了软件更新”。

主存关系定义树状结构。例如，计算机可以主存MICROSOFT SQLSERVER的0-n个实例、MICROSOFT INTERNET INFORMATION SERVICES的0-n个实例等等。

包含关系定义潜在无环有向图。例如，MICROSOFT SQL SERVER的一组所有实例可包括计算机A、计算机B、以及计算机C上的实例。计算机C可以另外主存MICROSOFT INTERNET INFORMATION SERVICES的实例，使得该组所有MICROSOFT INTERNET INFORMATION SERVICES实例还将包括计算机C。由于两个组都指向计算机C，因此该有向图不是树。

引用关系潜在地是有环的。例如，主存在计算机A上的MICROSOFTEXCHANGE SERVER(微软Exchange(交换)服务器)(由位于美国华盛顿州雷德蒙市的微软公司发布)的实例可以引用主存在计算机B上的MICROSOFT EXCHANGE SERVER的实例。而主存在计算机B上的MICROSOFT EXCHANGE SERVER的实例又可以引用主存在计算机A上的实例。这种关系系列是有环的。

SCOM数据库模型还包括可以被称为“继承关系”的隐含关系类型。继承关系引用特定形式的主存，其中任何实体都可以(可任选地)从另一实体继承。例如，类型“Windows.Computer”的实体可以从类型“System.Computer(系统计算机)”的实体继承。另外，另一类型“Unix.Computer(Unix计算机)”的实体也可以从“System.Computer”继承。如果存在“Windows.Computer”的实例，则它从“System.Computer”的恰好一个实例继承。在SCOM中，继承始终是单个继承，类似于C#编程语言中的类的单个继承。

SCOM用来描述企业网络的元数据不将继承信息编码为关系类型。结果，此处所描述的其他方法用于编码此信息。

iii.实体寿命

SCOM中的主存关系定义存在准则。例如，如果从计算机中移除MICROSOFT SQL SERVER的实例，则与该实例相关联的任何数据库也都被移除。作为另一个示例，如果用户在主存了三个MICROSOFT SQL SERVER数据库的计算机上安装MICROSOFT SQL SERVER的实例，则SCOM数据库将认识到这四个新实体的存在。停止使用主存MICROSOFT SQL SERVER的这些实例以及相关联的数据库的计算机相当于使整个树消失。由此，主存和实体寿命是紧密地链接的概念。

iv.实体访问

在SCOM中，使用包含关系来定义访问和安全性准则。例如，SCOM组可以是主存MICROSOFT SQL SERVER的所有计算机的组，另一个组可以是主存MICROSOFT INTERNET INFORMATION SERVICES的所有计算机。根据此示例，SCOM会将主存MICROSOFT SQL SERVER和MICROSOFTINTERNET INFORMATION SERVICES两者的计算机定义为包含在这两个组中。由此，MICROSOFT SQL SERVER组将指向该计算机，并且MICROSOFTINTERNET INFORMATION SERVICES组将指向该同一个计算机。由于这两个组都指向同一个计算机，因此相关联的“包含”图是无环有向图。

如上文所指出的，SCOM可以使用包含图来定义访问准则。例如，具有对一个组的访问权限的IT操作员可能没有对另一个组的访问权限。如此，在第一组和第二组各自都包含同一个计算机的情况下，只有对第一组的访问权限的操作员将能够访问被包括在这两个组内的计算机，但不能访问第二组中的其他计算机中的任何一个。

v.数据库实体以及关系表

SCOM数据库包含两个类型-空间元数据表：一个描述实体类型，一个定义各实体类型之间的关系类型。数据库另外还定义了两个其他表，包含实体实例的表以及包含实体关系实例的表。每一个实体以及关系实例都包含对相关联的元数据实体或关系类型的引用。其他相关的表在系统内存储特定实体类型和实例的属性类型以及实例值。

在只有一个表包含对每一个实体实例的引用而另一个表包含对每一个关系实例的引用的情况下，这两个实例-表定义一个大型有环有向图。然而，为便于理解下面所描述的测试数据生成系统100的特定实现，将所有主存关系(包括继承关系)描绘为红色、将所有包含关系描绘为蓝色、并将所有引用关系描绘为绿色是十分有用的。只看红色边以及它们的连接节点会揭示树结构的森林。看蓝色边以及它们的节点会示出无环图的族。看蓝色边以及它们的节点应该示出有环图的族。

2.示例实体引擎实现

如上文参考图1所讨论的，实体引擎114被配置成基于由清单108所描述的类型空间模型以及由用户添加到其中的参数，来创建特定企业网络的实例空间模型。在当前所描述的SCOM相关的实现中，实例空间模型包括形成有向图的对象的一组存储器实例。为创建实例空间模型，实体引擎114读取并验证经注释的清单108，然后根据某种确定性算法来生成每一个SCOM实体以及关系类型的0-n个实例。利用适当地注释的清单108，由一个计算机上的实体引擎114所生成的实例空间模型应该与由另一计算机上的实体引擎114所生成的实例空间模型相同。然而，在一种实现中，对清单108作出的注释也可以指定非确定性的实例空间模型。例如，这样的注释可以根据特定测试方案的需求来指定根据随机整数函数的实体/关系基数。

a.实体引擎生成实例空间模型的示例算法

在描述清单108的示例之前，首先描述实体引擎114可以用来处理清单108的一种方式是有帮助的。在SCOM相关的实现中，清单108可以包含可以被用来生成多个不同的有向图实例的一组SCOM实体以及关系类型，其中每一个有向图实例都是不同的企业网络的模型。例如，清单108可以包含来自SCOM数据库(即，类型空间)的“ManagedType(托管类型)”和“RelationshipType(关系类型)”表的副本。

进一步根据这样的实现，用户利用与特定有向图实例应该采取什么形状有关的信息来注释清单108，其中该特定有向图实例是特定企业网络的模型。在一个实施例中，由用户添加到清单108的信息包括基数信息和/或属性规则信息，该基数信息指定要由实体引擎114所生成的SCOM实体类型实例以及关系类型实例的具体数量，该属性规则信息指定如何实例化要与由实体引擎114所生成的各种实体实例相关联的属性。

该组SCOM实体以及关系类型可以被视为类型空间模型，而该特定有向图实例可以被视为实例空间模型。由此，实体引擎108从类型空间图来创建实例图。

图7描绘了实体引擎114可以用于基于经注释的清单108来生成有向图实例的示例方法的流程图700。该方法的开始由标记为“开始”的框702来表示。在该方法启动之后，控制流向步骤704，在该步骤中，创建根实体实例并将其排入此处被称为“EntityQueueCollection(实体队列集合)”的队列中。

根实体实例表示树的根节点，此处被称为“构造树”，它是由实体引擎104所生成的并被用作用于循环访问实例空间模型的起始点。实体引擎114基于在清单108中所定义的SCOM“根类型”来生成根实体实例。在一个实施例中，实体引擎114根据下列算法来标识根类型：

在SCOM(或SCSM)中，根类型将是Sytem.Entity(系统实体)。

在SCOM中，继承意味着，如果一个实体从另一实体继承，则它同时是所定义的类型以及其继承链中的所有类型。例如，在SCOM中，Windows.Computer从System.Computer继承。这意味着，Windows.Computer实例(如果它存在的话)也是System.Computer。

SCOM数据库中的所有实体从System.Entity类型继承。这一类型是不从另一实体类型继承的唯一实体类型。由此，System.Entity类型提供用于迭代通过SCOM实例空间模型的起始点(根)。

在创建了根实体实例并使其入队之后，实体引擎114根据由清单108所描述的类型空间模型中的关系来构建实体实例的“构造树”。如图7所示，构造树的构建从判断步骤706开始，在该步骤中，实体引擎114确定在队列“EmityQueueCollection”中是否有任何实体实例。如果在“EntityQueueCollection”中有任何实体实例，则使该队列的最前面的实体实例出队，如步骤708所示。

在判断步骤710，实体引擎114确定它是否已经迭代通过了在步骤708出队的实体实例的所有主存和继承关系类型。根据由清单108所描述的类型空间模型，确定可以应用于特定实体实例的各种主存和继承关系类型。如果实体引擎114在判断步骤710确定它已经迭代通过了相关实体实例的所有主存和继承关系类型，则控制返回到判断步骤706，以确定“EntityQueueCollection”中是否有更多实体实例。

然而，如果实体引擎114在判断步骤710中确定它没有迭代通过在步骤708出队的实体实例的所有主存和继承关系类型，则它评估与每一个剩余的主存或继承关系类型相关联的基数值，如步骤714所示。如上文所讨论的，可以例如由用户在对清单108的注释期间指定与主存或继承关系相关联的基数值。

如果实体引擎114在判断步骤714中确定与剩余的主存或继承关系类型相关联的基数值不大于零，则对相关实体实例的相关主存或继承关系类型的处理被视为完成，并且控制返回到判断步骤710以确定对于相关的实体实例是否有其他剩余的主存或继承关系类型需要进行迭代。

然而，如果实体引擎114在判断步骤714中确定与剩余的主存或继承关系类型相关联的基数值大于零，则控制流向步骤716，在该步骤中，实体引擎114基于与特定主存或继承关系类型相关联的基数值来创建0-n个目标实体实例。在步骤716中，实体引擎114还初始化属性包，并列出与每一个所创建的目标实体实例相关联的实例。如此处所使用的，术语“属性包”是指与实体实例相关联的属性集合。此处将更详细地描述属性包和列表实例的使用。

步骤716之后，控制流向步骤718，在该步骤中，实体引擎114创建一个关系实例，该关系实例将相关实体实例(作为源实体)链接到在步骤716中创建的每一个目标实体实例。在步骤718之后，控制流向步骤720，在该步骤中，实体引擎114将在步骤716中创建的每一个目标实体实例排入队列“EntityQueueCollection”中。然后，控制返回到判断步骤710，在该步骤中，再一次确定实体引擎114是否已经迭代通过了先前在步骤708中出队的实体实例的所有主存/继承关系类型。

在以上文所描述的方式生成构造树之后，在“EntityQueueCollection”中没有更多实体实例。此时，控制将从判断步骤706流向步骤722。在步骤722中，实体引擎114基于由用户添加到清单108中的参数，为该构造中的每一个实体实例创建包含和/或引用关系。在一个实施例中，此步骤涉及迭代通过整个构造树，以标识应该基于清单108中所包括的参数来为其创建包含和/或引用关系的实体实例，并创建这样的关系。其他实施例使用插件模块来以模仿操作软件将做什么的方式来形成包含和引用关系，或者因为对于某些包含和引用关系利用定制的算法性能会更佳。

在步骤722完成之后，流程图700的方法结束，如标记为“完成”的框724所示。此时，已经创建了完整的实例空间模型。在一个实施例中，在结束步骤724之后，将表示完整的实例空间模型的数据存储到SCOM数据库。在替换实施例中，将流程图700的一个或多个处理步骤期间或完成之后间歇性地将表示实例空间模型的数据存储到SCOM数据库中。

b.示例实体引擎实现细节

前面描述了可以由实体引擎114在系统100的SCOM相关的实施例中实现的示例算法。下面描述了根据这样的实施例的进一步的实现细节。这些细节只是作为示例而已，不打算限制本发明。

i.发现队列和实例空间迭代

由于SCOM实例空间模型潜在地是有环有向图，因此实体引擎114必须具有迭代通过该有向图中的全部实例而不会无限地循环的方法。为实现这一点，在实体引擎114的一种实现中，以如下方式配置如前所述的“EntityQueueCollection”队列：实体引擎114只访问有向图中的每一个实体以及关系实例一次。

根据这样的实现，EntityQueueCollection就像普通队列那样起作用，因为它使实体实例入队和出队。然而，队列添加了这样的一种方法：如果入队请求产生环，则该方法忽略该入队请求，如果入队请求不产生环，则该方法处理该入队请求。在一个实施例中，第一次使特定实体实例入队时，EntityQueueCollection在散列表中创建对应于该实体实例的条目。当接收到第二个以及随后的使同一个实体实例入队的请求时(如通过访问散列表所确定的)，EntityQueueCollection忽略它们。此方法允许任意有向图的每一个节点正好被访问一次，且对于纯树上的操作不是必需的。

ii.继承关系类型

SCOM数据库不将继承指定为真实关系。即，在SCOM“RelationshipType”表中没有“继承”类型。本发明的一个实施例通过要求清单108将继承指定为类型“Inherit(继承)”的关系来解决此问题。在这样的实施例中，清单108与SCOM数据库的不同之处在于，它具有四个而不是三个关系类型。在一个实施例中，当在储存库102的元数据表中被识别时，储存库元数据读取器104自动地将这些关系插入到清单108中。

在SCOM中，继承关系的基数是平凡的，因为根据定义，继承基数只能具有值0或1：即，关系存在或不存在。然而，通过包括继承关系可以解决下列难题：(1)清单108(以及SCOM)指定实体类型“Windows.Computer”；(2)“Windows.Server.Computer(Windows服务器计算机)”从“Windows.Computer”继承；(3)“Windows.Client.Computer(Windows客户机计算机)”从“Windows.Computer”继承；以及(4)计算机要么是服务器(类型“Windows.Server.Computer”)，要么是客户机(类型“Windows.Client.Computer”)，但不是两者都是。

通过将两个继承关系类型添加到“Windows.Computer”，一个用于“Windows.Server.Computer”，一个用于“Windows.Client.Computer”，则可为计算机-到-服务器关系指定基数1，为计算机-到客户端关系指定0，或者反之亦然。

iii.关系基数以及实体类型

如上文所描述的，实体引擎114生成构造树的过程假设每一个关系类型都具有已定义的基数。另外，在一种实现中，该过程将根实体类型的基数自动地定义为1。实体类型以及这些类型之间的关系也可以被用来确定某些关系实例的基数。

在SCOM中，实体类型的“类型”是下列各项中的一个：Abstract(抽象)、Singleton(单独)、Concrete(具体)或Hosted(被主存)。Abstract意味着，实体类型存在于元数据中，但是决不会作为实例空间模型中的实例而存在。Singleton、Concrete或Hosted实体可以存在于实例空间模型中。这些类型的定义以及各实体类型之间的关系可以被实体引擎114用来根据下列约定来定义基数的某些类型：(1)如果abstract实体具有与另一个abstract实体的继承关系，则实体引擎114将该关系的基数定义为1；(2)如果abstract实体具有与singleton实体类型的继承关系，则实体引擎114将该关系的基数定义为1，无需注释清单108；以及(3)在所有其他情况下，实体引擎114都将关系的基数定义为零，除非用户已经在清单108中指定了另一个基数值。

上面的约定允许实体引擎114构造树在无需确定在清单108中是否指定了基数值的情况下生成构造树，直到诸如引擎遇到其中目标类型是concrete且源类型是abstract的第一继承关系实例之时为止。此时，实体引擎114必须使用如在清单108中所指定的基数值，或假设基数是零。

iv.分层符号表

由于SCOM数据库中的每一个实体实例都可以具有不同的属性值(例如，显示名称、IP地址等等)，因此实体引擎114提供用于为在流程图600的方法中创建的每一个实体实例容易地生成测试值的手段是合乎需要的。为解决此问题，本发明的一个实施例包括“分层符号表”，利用该表，用户可以经由对清单108的注释容易地创作这些值。现在将描述实现这样的分层符号表的一种方式。

a.名/值对

分层符号表的基础是名和值对。每一个符号都具有名和值。例如，名可以是“DisplayName(显示名)”，而值是“Computer_1(计算机_1)”，或者名可以是“IpAddress(Ip地址)”，而值是“101.102.103.104”。在一个实施例中，由实体引擎114在流程图700的方法中所创建的实体实例将与分层符号表中的名/值对的列表相关联。例如，每一个实体实例都可以与表中的若干条目相关联，这些条目中的每一个条目都最终将存储在数据库102中。

b.属性实例化期间的符号替换

在一个实施例中，清单108是XML文档，其将属性规则定义表示为具有名属性和表示一个值的内部文本的元素。当实例化实体时，实体引擎114将该名称和内部文本复制到与带有一个例外的实体类型定义中所定义的每一个属性的实体实例相关联的属性实例。

如果内部文本包含特殊字符串“[##symbol Reference##](符号引用)”，则实体引擎114替换匹配“[##”和“##]”括号之间的串的预先定义的符号的值。通过此技术，用户可以创建下面的表1中所示出的名/值对。

表1

在此示例中，当(且仅当)Id符号在每一个实例的属性包中不同时，使用这三个属性定义的每一个实体实例都接收DisplayName和ComputerDomainName的不同的属性值。

c.特殊符号-Id、InstanceNumber(实例编号)和Tag(标签)

在一个实施例中，实体引擎114预留某些符号名称以供内部使用。三个示例是“Id”、InstanceNumber，以及“Tag”。Tag是实体的Tag属性中所定义的值。“Id”符号是通过串接Tag值、下划线以及实例编号来为每一个实例创建的值。如果abstract-到-concrete(抽象-到-具体)关系具有基数100，则实体引擎114创建100个目标实体实例，并向每一个实例分配实例编号0-99。假设该实体类型的Tag是“Computer(计算机)”，则每一个实体实例的Id值将是“Computer_0”到“Computer_99”。通过使用上文参考符号替换所提及的关系定义，这意味着，每一个实体实例的ComputerDomainName值将是“Computer_0.local.test.com”到“Computer_99.local.test.com”。清单108的注释者可以在与XML元素相关联的内部文本中引用符号[##Id##]、[##InstanceNumber##]，以及[##Tag##]，以填充属性值。

d.特殊引用修改符-“Parent(父)”

清单108的注释者能够引用父实体中的属性值是有用的。此能力直接引用Windows.Server.Computer实例与它从其继承的实例具有相同的值的必要性。下面的表2描述了使用父引用的实例化。在一个实施例中，储存库元数据读取器104可以被配置成为实体中的属性自动地插入[##Parent.propertyName##](父属性名)引用值，其中父实体包含相同的属性名。这减少了所需的清单注释的量，因为只必需定义属性规则，因为父和子继承实体已经被正确地填充。

表2

虽然从上面的表2看出清单108的注释者可能需要编辑Windows.Server.Computer和Windows.DC.Server.Computer的属性定义，但是在一种实现中，某些方法可以读取清单108，认识到实体实例是继承的，并通过串接“[##Parent.”、属性名，以及“##]”来填充所有属性内部文本。需要注意的是，Windows.DC.Server.Computer是域控制器的实体类型——在SCOM(或SCSM)中，这一类型从Windows.Server.Computer继承。

构造树定义分层符号表的层次结构。由于每一个实体实例都是基于带有非零基数的关系类型创建的，因此除System.Entity实例之外的每一个实体实例都具有父实例。对于遇到的每一个父引用，父引用沿着构造树向上走。某些测试者可以使用“[##Parent.Parent.DisplayName##](父父显示名)”来定义域控制器实例的显示名，尽管通常没有理由这样做。此值将使用来自Windows.Computer而不是Windows.Server.Computer的属性值。对于串接Parent前缀的唯一限制是该实例的构造树的深度。在一个替换实现中，可以使用“第一父”修改符，以使得符号定位器沿着树向上走到达带有该属性名的“第一父”并使用此值。这意味着，清单108的注释者不必使用Parent.Parent.Parent.propertyName来跳过两层。

e.特殊引用修改符-标签(Tag)引用

如果实体类型具有在清单108中指定的固定Tag值，则符号替换可以使用该Tag值。如此，如果Windows.Computer类型具有“Computer”的固定Tag值，则域控制DisplayName可以使用“[##Tag##][##InstanceNumber##]”规则来填充Windows.Computer.DisplayName。在此情况下，最终名称将是Computer.0、Computer.1等等，而不是当使用[##ID##]规则时的Computer_0。

f.引用全局符号以及查找算法

清单108内的某些值可以产生显著不同的实例空间模型。例如，功能测试者可能只使用10个计算机来进行功能测试。然而，负载测试者可能希望将同一个清单用于50,000个计算机。在适当地设计的清单中，通过只改变一个值就可以实现这一点。类似地，可能需要改变与清单108相关联的模式以在开发机器上操作并随后在一系列室验室机器上操作。

为此，实体引擎114的一个实施例从清单108读取全局符号列表，作为创建分层符号表的第一步骤。这些名/值对正好像每一个实体实例的属性集合那样操作。此集合还是当解决符号引用时实体引擎114所尝试的最后位置。简言之，分层查找可以按如下方式进行：

g.符号函数

在SCOM内，某些值是其他值的虚拟重复。上面所列的各种引用技术解决了这些“重复”值问题中的许多，从而允许对清单108的更加容易并且更加稳健的注释。一些未解决的问题如下：(1)计算机的NTLM(NT LAN管理器)名称通常都是大写，但否则与计算机名相同；(2)IP地址，特别是开发人员机器上的IP地址不能与公司网络(Corp net)值有冲突；以及(3)某些测试要求范围内的随机值。

为解决这些需求，根据本发明的一实施例的清单108允许向每一个符号定义添加一个可选函数。如果存在，实则体引擎114将按名称查找该函数，使用由清单108所指定的值(在符号替换之后)，运行与该函数名相关联的方法，然后返回新的串。返回的串变为实体实例的符号的值。此技术直接解决上文所提出的问题。

下面的表3提供了根据一个实现可以提供的某些函数的示例。这些函数只作为示例。所使用的函数可以反映特定软件系统的需求。函数一般可以具有下列签名：InstantiatedValue＝FunctionName(manifestValue)(实例化的值＝函数名(清单值))，其中清单值是分层符号查找之后的清单值。

表3

h.不通过符号处理来解决的特征

上文所讨论的分层符号表、符号替换、函数处理及其他概念有助于创建测试所需的真实的SCOM数据。另外，全局符号允许在清单108内定义值，使得对长清单的复杂编辑没有必要。

要解决的另一个问题是为客户机/服务器继承关系提供基数信息。下面的表4示出了检查逗号分隔列表中的头两个字符串(在符号替换之后)名为″？＝″的可能的函数。如果头两个字符串相等，则函数返回第三值。如果值不同，则函数返回第四值。

表4

由于函数″？＝″，如果RelClient是0，则RelServer是1，反之亦然。这对于向客户机/服务器继承关系提供基数信息足够了。

v.列表

根据本发明的一个实施例，“列表”被用来允许清单108的注释者以直观的形式向实体引擎114提供信息。每一个列表都具有名称、大小以及类型。此外，一旦被初始化，每一个列表都包括“项”的有序集，其中每一个项又是属性集合。

a.加权列表

加权列表是可以只使用相对较小数量的列表项以及相关联的属性定义来定义相对大的列表的机制。加权列表的项定义该项在总列表大小内的相对大小。如此，带有三个项的加权列表可以表示一个网络中的50,000台计算机，一个网络中的500台计算机、或一个网络中的5台计算机的初始值。在此情况下，唯一区别是列表的大小属性。

例如，考虑由50个服务器和500个客户端构成的计算机网络。客户机与服务器的比率是10∶1。加权列表使用“N”值代替项的大小，来如下所示地表示此信息：

在内部，任何列表都只包括清单108中指定的信息。因此，通过指定同一列表带有大小5,000或50,000，没有存储器增长。所改变的是返回的值。下面的表5示出了从此列表定义导出的示例分布。

列表大小	服务器数量	客户机数量
			10	1	9
550	50	500
			5000	454	4546
50000	4545	45455

表5

需要注意的是，在表5中，总列表大小是服务器以及客户机的数量的总和，但是，当列表大小不是11的倍数时，客户机和服务器的数量不精确。在任何情况下，甚至在比率产生实数而不是整数的情况下，WeightedList(加权列表)类确保“虚拟”项的总数是列表大小。

检查上面所列的XML还示出了带有值true的属性NisaWeight。将该值变为false允许将“N”值解释为一个固定数字而不是权重。这允许创建更感兴趣的分布，而不管列表的大小如何，只有固定数量的域控制器。下面的XML描述了一个示例：

上面的XML对以下情况建模：对于每500个工作站，有两个MICROSOFTSQL SERVER(SQL)服务器、5个MICROSOFT INTERNET INFORMATIONSERVICES(IIS)服务器，以及一个MICROSOFT EXCHANGE SERVER(Exchange)服务器。然而，无论网络是什么大小(需要注意的是，大小可以取决于全局符号值)，将只有三个域控制器。下面的表6示出了各种分布。

表6

如上表所示出的，由于整数运算的要求，加权列表对大的体重比敏感。为了“缩小”用于功能测试和调试的列表，可以将加权列表算法设计成能遵循下列约定：(1)虚拟列表中的每一项将具有1或更大的实际大小—没有哪一项的长度将等于0；(2)如果加权项加总的非加权项的总数“N”值大于列表大小，则算法在清单108中报告一个错误；以及(3)在初始列表大小计算之后，加权列表调整项的大小，以确保所有项的虚拟大小的总和等于列表的指定大小。

如果清单108的注释者需要精确的分布，则他们可以注释清单108，以便列表大小减去非加权项长度是总权重的倍数。

b.简单列表

简单列表根据清单108中指定的项的数量来确定它们的大小。如果清单108指定3项，则列表大小是3；如果清单108指定了10项，则列表大小是10。

在简单列表的情况下，清单108的注释者将省略列表大小属性以及N和NisaWeight属性，因为权重属性对于简单列表没有意义并且系统内部计算列表大小。

c.设备列表

设备列表被特殊化，以用于向盘实体提供设备代码。在一种实现中，设备列表大小在1和24之间。这些列表不必指定项，因为列表生成指定数量的项，每一个项都具有属性名/值对，其中名是“Device(设备)”而值是“c:”到“z:”。如果清单108的注释者指定设备列表大小为3，则连续的设备将是“c:”、“d:”、以及“e:”。如果列表大小是12，则连续的设备将是“c:”到“n:”。

vi.使用列表的关系填充—主存和继承

上文所讨论的各种列表类型提供了填充关系的简单手段。如所讨论的示例列表所暗示的，创建各种类型的计算机的分布是列表使用情况的主要示例。这是可能的，因为实体引擎114使用与列表内的虚拟位置相关联的属性值来“播种”关系的目标实体。

a.关系实例化

下面的示例通过为列表的每一项引入属性集合来扩展用于创建各种计算机的模型。加权列表具有定义工作站、服务器、以及也是域控制器的服务器的三个项。

回想一下，Windows.Server.Computer和Windows.Client.Computer从Windows.Computer继承，而Windows.Server.DC.Computer从Windows.Server.Computer继承。这一安排需要三个基数值，一个用于客户端关系，一个用于服务器关系，以及一个用于域控制器关系。

当实体引擎114遇到抽象(abstract)System.Computer实体定义时，该定义包含上面的列表以及与Windows.Computer的关系，该关系又指定PopulateUsingList＝“ComputerList”。实体引擎114使用此信息来创建101个Windows.Computer实体(列表大小)。然而，在使用Windows.Computer属性定义实例化每一个Windows.Computer实体的属性值之前，实体引擎114利用列表属性填充101个属性包中的每一个。如此，头90个Windows.Computer属性包包含其中RelClient＝＝1、RelServer＝0和RelDc＝0的值。下面10个包含RelClient＝＝0，RelServer＝1，以及RelDc＝0。最后一个实体包含RelClient＝＝0，RelServer＝1，以及RelDc＝1。

在Windows.Computer实体定义内，有许多关系。这些包括与Windows.Client.Computer和Windows.Server.Computer的关系。与Windows.Client.Computer的关系指定SelectionSize(选择大小)＝“RelClient”，而与Windows.Server.Computer的关系指定SelectionSize＝“RelServer”。由于属性包包含关系实例化之前这些关系的值(由于列表填充功能)，因此取决于列表属性包值，这些关系具有基数1或0。如此，实体引擎114为头90个Windows.Computer实体创建继承了Windows.Client.Computer的实体，为下面11个实体创建继承了Windows.Server.Computer的实体。

在实例化Windows.Server.Computer实体之后，实体引擎114看到带有SelectionSize＝″[##FirstParent.RelDc##]″的与Windows.Server.DC.Computer的已继承的关系。由于在构造树中Windows.Server.DC.Computer是Windows.Server.Computer的子实体，因此符号处理器去往该父实体，并使用来自分层符号表的RelDc值。如此，11个服务器中只有最后一个也从Windows.Server.DC.Computer继承。

上面的填充的结果是在实体引擎114的存储器空间中创建了203个实体：101个Windows.Computer，90个Windows.Client.Computer，11个Windows.Server.Computer，以及1个Windows.Server.DC.Computer。所有Windows.Computer都包含与适当的客户机或服务器计算机实体的继承关系，最后一个服务器也具有与域控制器实体的继承关系。

b.填充Tag值

列表填充也可以允许填充子实体的Tag值。例如，在一种实现中，如果列表项包含其中名称是Tag的属性名/值对，则实体引擎114创建带有对应的Tag值的子实体，如下面的XML片段所示出的。

当使用上面的列表填充与Windows.Computer的关系时，利用“Ws”的Tag值实例化每一个Windows.Client.Computer。此值替换由清单为Windows.Client.Computer所指定的任何EntityType(实体类型)Tag值。如此，Windows.Client.Computer实例具有Ws_0到Ws-89的Id值。不是域控制器的Windows.Server.Computer具有Svr_90到Svr_99的Id。域控制器具有Dc_100的Id。通过允许填充功能指定Tag值，可以在使用最终测试台调试和日志细读期间更好地标识实体实例。它还允许为实体创建当检查SCOM的或SCSM的显示视图时更加容易识别的显示值。

c.使用简单列表以及设备列表来填充关系

有时，清单108的注释者可能只需几个实体实例来填充列表。两个示例是填充SQL引擎内的数据库和为计算机指定几个盘。

对于SQL数据库的情况，下面的简单列表提供了用于填充SQL引擎以及其对应的数据库之间的关系的真实数据。

在计算机主存逻辑器件的情况下，下面的XML片段提供可能的实现。

上面的设备具有如由DiskListSize(盘列表大小)属性所指定的1-3项。由于利用此XML定义的实体的每一个实例都将创建不同的值，因此某些计算机将具有1个盘，而某些计算机将具有2个盘，而某些计算机将具有3个盘。

vii.使用列表的关系填充—包含和引用

如上文所讨论的，在完成构造树之后，实体引擎114填充包含和引用关系。此时，除包含和引用关系之外，实例空间已完成。填充这些关系需要标识现有的目标实体实例并创建源和目标之间的新关系实例。

包含和引用关系可以使用简单列表来填充。这些列表标识用来标识包含或引用关系的目标的简单列表项的正常属性。用来发现目标的算法可以被表示为“SearchMethod(搜索方法)”，并可以基于下列各项中的任何一项来找出目标：

·ScopeRegex-这是用于匹配满足范围准则的实体实例Id的正则表达式。

·ScopeTypes-这是满足范围准则的实体类型的逗号分隔的列表。

·IncludeIds-这是用于在填充关系时在搜索以便包括的范围内的实体实例Id的实体Id的逗号分隔列表。

·IncludeTypes-这是标识在填充关系时要包括的类型(在范围内)的实体类型的逗号分隔列表。

·ExcludeIds-这是用来修剪由包括准则所标识的实体的列表的实体Id的逗号分隔列表。如果有Id匹配，则引擎从用来填充关系的实体的有效列表中剪除该实体。

·ExcludeTypes-这是实体属性类型的逗号分隔列表。引擎剪除其类型与此列表中的任何类型相同的实体。

·PlugIn-此可任选参数指定需要可选插件模块中的一个函数来确定端点。

所有上面的属性名/值对都是可任选的。如果存在SearchMethod属性，则搜索方法(SearchMethod)作者自由使用其他名/值对中的任何一个或一个也不使用。如果SearchMethod不存在，则搜索使用由上面的参数所描述的默认搜索方法来进行。如果没有范围准则或没有包括准则，则默认搜索不标识任何实例。

下面的示例列表允许SystemCenter.HealthService(系统中心健康服务)来标识主存它的Windows.Computer。由于Windows.Computer实例经由带有SelectionSize＝“1”的关系来主存SystemCenter.HealthService实例，因此实体引擎114为每一个计算机实体创建一个健康服务(HealthService)实体以及它们之间的主存关系。该引用关系必须从适合于创建此引用关系的构造树中的所有实例指回到一个Windows.Computer实例。此示例对监视它所在的计算机的健康服务进行建模。

上面的XML指定了引用关系的有效目标。搜索算法递归地沿着构造树上升。在每一个步骤，它将找到的实体与范围(Scope)准则进行匹配。由于Windows.Computer主存Health.Service，因此这只是一个步骤。一旦被标识，范围实例标识其中存在所需实体的构造树的子集。在此情况下，范围准则以及包括准则标识范围内的根实例。由于此范围在范围中的别处不包含Windows.Computer，因此只有一个目标实例。

需要注意的是，选择准则使用SelectionSize来限制由搜索功能所标识的潜在关系的实际数量。

viii.示例实体引擎代码

在一个实施例中，实体引擎114被实现为包含对象定义以及读取表示清单108的串行化XML结构以及从它创建实例化的存储器模块所需的方法的动态链接库(DLL)。在此模块内定义的主要对象可以被定义为如下：

EntitvEngine(实体引擎)-这个类包含将XML定义转换为包括Entity(实体)以及Relationship(关系)对象的实例空间所需的方法。它公开了包括下列各项的若干方法和属性：

·Load(加载)和LoadFile(加载文件)-这些方法通过将清单并行化来触发实体定义模块来准备类型空间。结果是存储器类型空间。

·Initialize(初始化)-此方法根据存储器类型空间(并行化的清单)来在存储器实例中创建实例空间。

·Discover(发现)-此方法迭代通过构造树，当它在构造树中前进时，报告EntityDiscovered(发现的实体)和RelationshipDiscovered(发现的关系)事件。

·EntityDiscovered事件-每当Discover方法遇到concrete(具体)或hosted(被主存)实体时，此事件都被引发。

·RelationshipDiscovered事件-每当发现方法遇到Hosted(被主存)、Containment(包含)或Reference(引用)关系时，此事件都被引发。

Entity-定义实体实例的类。它展示了包括下列各项的多个属性：

·XmlEntity(Xml实体)-这是指向并行化的XML清单内的实体类型定义的指针。

·Properties(属性)-这是包含根据XML规范创建的名/值对实例的属性集合(也叫做“属性包”)。

·Lists(列表)-这是包含根据XML规范创建的列表的列表集合。

·RelationPointingToAnother(指向另一个的关系)-此集合包含指向目标实体实例的所有关系。

·RelationsPointingToThis(指向这一个的关系)-此集合包含对从另一实体实例指向此实体实例的所有关系的引用。

·UserObject(用户对象)-参见下面的描述。

·实体实例还展示其他C#属性，包括Id、Tag、Guid、引擎引用等等。

Property-这个类定义了属性集合内的属性实例。每一个实例都展示Name、Guid、IsKey，以及Value(值)作为C#属性。

Relationship-这个类定义关系。其主要C#属性包括源实体、目标实体、Guid、UserObject、以及其属性集合。

在一个实施例中，实体引擎内的对象易于创建，并易于在各种测试环境中使用。下面描述了可以用于在大多数测试环境中开始的简单代码样本。

a.创建存储器实例空间

下面的代码示出了开发人员如何从XML清单文件“sample.xml”在他们的唯一测试环境内创建存储器实例空间。“待做”注释表示测试者将放置代码以使用实例空间的位置。

b.迭代通过存储器实例空间

下一代码样本示出了使用引擎的发现方法迭代通过构造树。“待做”注释表示测试者将创建存储器实例空间的代码位置。

c.将对象附加到实体以及关系对象

由于引擎处理使得不可能继承Entity或Relationship对象以包括任意测试数据，因此这两个对象都使用对象包含来允许测试开发人员将类附加到实例空间内的这些对象。Relationship和Entity类各自都包含UserObject字段的下列实现：

IUserObject具有以下定义。

下面的代码示出了经由对象包含将MyEntityObject(我的实体对象)挂钩到Entity对象。对于Relationship对象，类似的方法也是可能的。需要注意的是，当用户在Entity或Relationship内设置UserObject时，该Entity设置方法自动地填充MyEntityObject的InstanceObject(实例对象)。因此，每当新的MyEntityObject实例初始化Entity的UserObject属性时，MyEntityObject的HostEntity(主存实体)属性都将包含非空的Entity引用。

3.示例清单实现

清单108向实体引擎114定义输入格式，实体引擎114使用先前讨论的引擎概念来创建所有所需的实体以及关系实例。此章节描述了SCOM相关的实施例中的用于创建合式(well-formed)的清单108的方法，其中清单108包括XML文档。

根据此实施例，XML清单定义文档的根元素的三个主元素。实体引擎114按照给定顺序处理这些三个部分，不管XML内的顺序如何。这些部分如下：

·全局属性-应用于整个应用程序的一组属性定义，如数据库连接串、调试标志等等。

·实体类型定义-描述引擎应该实例化的实体类型、属性、列表、以及关系的一组元素。

·发现规则-诸如当向根管理服务器报告数据时SCOM发现过程将使用的发现规则guid(全局唯一标识符)的列表。

上面的三个主要部分足以让实体引擎114开始处理。下面是概略XML示例，示出了根元素(名为“Xml”)的主元素。

下面详细描述了属性、实体类型、以及发现规则元素。

a.全局属性

全局属性形成名和值定义的集合。实体引擎114按照指定的顺序来实例化它们。这些名/值对形成分层符号表的基础。每一个全局属性都具有下列属性和内部文本：

如所示的，每一个全局属性定义都具有名称(在此情况下是nnnn)，可选函数名(ffff)和可任选内部文本(vvvv)。清单108的注释者可以在函数名或者内部XML中使用符号子站。由于全局符号按顺序评估，因此这样的注释者必须在使用符号之前通过排序全局属性定义来定义符号。

b.实体类型

下面的XML提供了可以用于SCOM数据的实体类型定义的骨架图。尽管实体引擎114不了解SCOM，但XML串行化和并行化过程需要某些属性和值，以便属性与SCOM数据库进行通信。

每一个实体定义元素定义三个子元素：属性类型、列表，以及关系。由于实体引擎114按此顺序使用XML，清单108的注释者应该遵守相同的顺序，以取得最大的可读性。下面定义了Entity XML骨架。每一个元素都是可任选的，意味着如果实体定义没有列表，则List(列表)元素不必出现等等。

每一个实体元素都具有如下所示的属性：

·Tag-用来创建Id值的可任选属性。如果实体的标签(Tag)是“Ws”，并且系统需要生成该实体类型的50个实例，则Id实例值将是Ws_0、Ws_1…Ws_49。如果没有标签，则系统使用所需的名称属性来生成唯一标签或经由PopulateUsingList(使用列表填充)来接收标签值。

·Name(名称)-名称属性是必需的。它为所有关系、HostedBy(主存自)、以及XML中的别处的InheritFrom(继承自)属性值定义了目标名称。名称不能包含符号引用。

·Guid-此属性是必需的。此guid是对基础的托管实体表中的对应于此实体定义的行的引用。

·Type(类型)-此属性是必需的。它定义实体的类型，并包含从基础的托管实体表中的IsAbstract、IsSingleton以及IsHosted布尔值导出的值。实体可以是抽象(abstract)、具体(concrete)或被主存(hosted)。

·InheritFrom(继承自)-此可任选属性定义此实体从其继承的类型。实体引擎114只允许只一个实体定义，无需任何InheritFrom实体——根实体(System.Entity)。

·HostedBy-此可任选属性定义主存此实体的另一实体类型。

InheritFrom和HostedBy属性包含冗余数据，因为其他XML元素中的关系包含该相同信息。通常，XML预处理器填充这些属性(来自关系)，以使得清单108的注释者不必编辑它们。

i.属性类型定义

实体的属性定义是类似于全局属性的那些名称和值定义的名称和值定义的集合。下面的XML提供了属性定义的示例。

属性名是唯一必需的属性。在实体集合内它必须是唯一的。然而，名称不必在XML内的所有实体定义之间是唯一的，只在一个实体的属性集合内是唯一的(即，Incident(事件)和ChangeRequest(更改请求)实体两者都可以具有CreatedDate(创建日期)属性)。下面概述了其他属性约定：

·Guid属性，如果存在的话，将属性标识为存储在实体实例的SCOM数据库中的一个值。包含Guid属性的属性类型必须对应于SCOM数据库中所定义的属性类型。

·由于SCOM数据库使用guid来标识数据库中的值，因此属性名不必对应于数据库中的名称。

·如果不存在Guid属性，则名/值对是(根据定义)变量。属性类型集合中的变量的数量没有限制。

·PrimaryKey(主键)属性，如果存在的话，标识SCOM数据值，该SCOM数据值标识用于标识SCOM数据库内的实体实例的主键。预处理器通常填充此属性，如果数据库要求的话。

·所有属性类型定义都使得值出现在分层符号表中。另外，PopulateUsingList关系可以利用附加的变量来预先填充集合。清单108的注释者应该创建列表属性名，以避免与实体的属性类型定义内所定义的名称冲突。

ii.实体列表定义

如前面所讨论的，实体列表定义项的集合和属性集合。每一个列表都包含项的列表。项又包含属性值列表。句法如下：

在一个实施例中，列表、项的属性，以及属性元素必须遵守下列规则：

·列表以及项标签是必需的。列表标签在实体的列表内必须是唯一的。项标签在它们的对应的列表内必须是唯一的。

·列表Type属性必须对应于由实体引擎所支持的列表类型。

·除加权列表之外，列表大小是可任选的。它可以包含对分层符号表中找到的值的符号引用。

·加权列表中的NisaWeight和N属性是必需的，但是在其他列表类型中被忽略(如果存在的话)。

·属性名在一个项内必须是唯一的。通常，这些属性名提供基数、范围或目标数据以填充关系。因此，每一个项具有相同的属性名是常见的，其中每个都带有不同的值。

·函数名和内部XML值在被实例化的实体的上下文中使用符号替换来进行评估。任何一个都可以包含符号引用。

iii.关系类型定义

每一个实体都包含关系列表。关系具有下列XML：

在一个实施例中，关系XML必须符合下列约定：

·标签属性是可任选的。通常，预处理器填充此属性。然而，清单108的注释者可能发现当调试XML清单时提供唯一标签值是方便的。

·名称属性是必需的，但是主要用于XML可读性。如果标签属性丢失，则引擎将使用它的名称属性或其子串作为每一个关系实例的标签值。

·关系类型必须是下列值中的一个：Inherited(继承)、Hosting(主存)、Containment(包含)或Reference(引用)。包括继承关系提供了为abstract-到-concrete关系引入基数的手段，但是这些关系不传播到SCOM数据库的Relationship表。将被继承的实体与父键值一起存储足以存储继承类型。

·Guid属性是必需，因为它标识SCOM数据库内的关系。

·TargetTypeName(目标类型名)属性是必需的。它标识关系的目标，并且因此在XML中的别处必须存在带有等于目标名称的名称的某种实体定义，否则会发生错误。

·SelectionSizeFunction(选择大小函数)和SelectionSize属性像属性函数和内部XML值那样起作用，以产生关系基数。串替换之后的结果必须是有效整数值。大于零的整数值管控关系实例化。

·PopulateUsingList属性必须标识有效列表，如果存在的话。列表引用可以使用Parent或Tag前缀来标识不在当前实体中的列表。

当检查引擎对象时，开发人员将发现，每一个关系都具有类似于为实体实例所产生的那种的唯一Id值。在没有Tag属性的情况下，该引擎使用关系名称的唯一子串来创建标签值。Id值又是与下划线串接，再与实例编号串接的标签。数值范围从零到N，其中N小于关系基数。

需要注意的是，SCOM(或SCSM)中的关系可以包含属性或变量。例如，将软件更新分配给计算机的SCSM引用关系具有称为“InstallationFailed(安装失败)”的带有真或假值的属性值。在一个实施例中，储存库元数据读取器104将适当的Guid与名和值相关联。清单注释者将添加真或假值(或者或许FunctionName＝“RandomBool”)。如果名值对没有Guid，则实体引擎114将该名/值当作变量，并且将不会把值持久存储到模型储存库102。下面是关系属性集合中的变量的示例。

上面的示例示出了关系变量(没有Guid属性-然而，在此情况下，该变量的值是GUID值)，如此，写入动作模块118将不会试图将此关系属性写入到储存库102。然而，当处理该关系时，该名值对对于写入动作模块118可用。在一个实施例中，写入动作模块118查找特殊的“DiscoveryRuleGuid(发现规则Guid)”变量，并使用它作为关系数据库API调用中的必需参数。尽管此值不作为属性持久存储到储存库102，清单注释者可以按需将值提供给写入动作模块118的API。诸如此属性变量等属性变量示出了清单注释者如何将值传递到写入动作模块118，即使写入动作模块118只具有对实例空间116的直接访问。

诸如上述属性等属性将数据提供给发现数据处理器方法。当前，将实体以及关系匹配到规则Guid的逻辑是非常原始的。以上允许XML作者指定用于调用关系存储API的准确的Guid。假设所选定的guid值是代理的发现方法将使用的值。

c.发现规则

下列XML示出了DiscoveryRule(发现规则)XML的示例。需要注意的是，发现规则是在SCSM清单中不存在用于SCOM的可任选的XML元素。

SCOM储存库元数据读取器从SCOM规则表中提取这些(SCOM储存库元数据的一部分)，并将它们放在XML中。

4.示例实体定义处理器实现

在现在将描述的一个实施例中，实体定义处理器106被实现为DLL，并被配置成串行化、并行化和归并包括清单108的XML文档。根据此实施例，实体定义处理器106包含多个公共方法，包括下列两个：

Deserialize(并行化)方法被配置成作为串(xml)来接受清单XML，并返回XML对象。串行化方法被配置成将XML对象串行化，并作为串返回XML清单。用户可以使用entityEvent(实体事件)委托来捕捉任一方法中的任何XML错误及其他信息事件。

如上文所使用的，术语“归并”是指将来自一个清单的用户注释归并到另一个清单的过程。这通常允许将对较旧版本的清单的手写注释归并到由较新版本的模型储存库上的储存库元数据读取器104所生成的清单，以产生可以在较新版本的类型空间操作的新清单。这也是原型清单(此处将更详细地描述)被归并到下一代产品清单以生成未来测试台的机制。

简要地，归并过程的目标是将同样多的注释从旧清单转移到由储存库元数据读取器104所生成的空白清单。由于在一个实施例中，经归并的清单和旧清单两者都是XML文件，因此文件区别查看器允许开发人员评估“打开”在旧清单中未实现的特征所需的任何附加注释。

XML类是从EntitySchema.xsd文件导出的。如此，各种XML元素表现为全局属性、实体定义和发现规则的阵列。这些又包含在该xsd中定义的每一个元素的类的阵列。阵列对于添加/移除操作是麻烦的。因此，XML类包含将所有阵列转换为集合并将所有集合转换回阵列的方法(在串行化之前)。进一步根据此实施例，实体定义处理器106包括由该Xsd所定义的类的集合以及在阵列和集合之间进行转换所需的方法。

C.清单的准备和细化

图8描绘了根据本发明的一实施例的可以准备和细化清单的数据流800。如图8所示，生成一个或多个清单804，并随后基于用户输入802来对其进行注释。上文参考流程图200的步骤202、204和206描述了可以由用户生成和注释清单的过程。然后，将清单802提供给测试数据生成系统(诸如上文参考图1所描述的测试数据生成系统100)，以生成测试数据。然后，可以使用所生成的测试数据作为用于开发和/或测试软件产品的测试台的一部分，如过程806所表示的。可以使用多个清单来开发软件产品和/或以各种负载并使用各种测试数据内容来测试软件产品。

当还没有发布软件产品时，上述方法特别有用，因为在该情况下，将不会有企业操作数据可用来导出用于注释清单804的合适参数(例如，基数值和属性信息)。在此情况下，清单804可以被视为“发布前清单”。

在发布软件产品之后，由各种企业安装它，如由过程808所表示的。这些企业中的一个或多个可以选择参与操作数据报告(ODR)过程810，通过该过程收集由安装的软件产品所生成的和/或与安装的软件产品相关联的操作数据并将其传回给该软件产品的开发人员。这样的操作数据可包括，例如，涉及企业的一个或多个储存库实例空间的统计信息。

原型清单创建过程812从各种企业接收ODR数据，并分析该数据以标识不同的企业原型或集群。可以使用诸如k-均值之类的数学方法来执行这分析。可以预料，具有类似的网络拓扑结构的企业将落入相同或类似的原型或集群。一个示例原型可以是主存web农场的企业。这些企业可以是可标识的，因为它们的web服务器中的每一个都示出了每服务器有数百或数千网站。另一个示例原型可以是被视为“早期的技术采用者”的企业。这些企业可以是可标识的，因为它们示出了主要运行较新的操作系统的计算机，只有小部分的计算机运行较旧的技术。其他公司可能符合其他原型。

一旦标识了原型，原型清单创建过程812确定表示与原型相关联的网络拓扑结构的一组参数，并以自动化方式将这些参数插入到清单中。例如，可为每一个已标识的原型来定义一组基数规则和属性规则，然后将它们插入到清单中。以此方式所生成的清单在图8中被表示为原型清单814。然后，使用这些清单来对软件产品806执行进一步的测试。

由于过程812所执行的操作，每一个原型清单814都可以有利地被用来为不同类型的企业生成高质量的测试数据。这允许对每一种不同的企业类型进行更有针对性的产品测试806。这又使产品测试者能标识和解决某些类型的组织所特有的问题。解决这样的问题可包括，例如，发布先发制人的服务补丁或开发可以被包括在软件产品的未来版本内的新解决方案。

值得注意的是，无论清单是通过用户注释创建的(与发布前清单804的情况相同)还是通过原型清单创建过程创建的(与原型清单814的情况相同)，测试数据生成系统都以相同的方式操作。然而，数据流800的一个优点是，随着软件开发人员在产品发布周期中迭代，它可以自动地为下一版本细化其清单。此外，由于根据数据流800从各种企业返回到软件开发人员的ODR数据只包括关于企业的计算机网络的高级统计信息，因此数据流800有利地允许以避免任何企业机密信息被提供给软件开发人员或测试者的方式来从企业接收重要反馈。

使用户能够注释清单对于测试企业还没有安装的软件产品的特征而言是特别需要的。同样，能够在软件产品的生命周期内在尽可能接近用户环境中测试该软件产品是合乎需要的。例如，虽然可能为特定类型的10,000个实体指定一软件产品，但是某些企业可能日常地将该软件产品与该类型的50,000个实体一起使用，并抱怨性能不好。根据本发明的一实施例，如果这样的企业将ODR数据发送给软件开发人员，则软件开发人员将能够生成可使得该开发人员理解问题是什么的测试数据。一旦开发人员理解了问题，开发人员就可以建议解决它的办法。如此，本发明的一个实施例可允许软件开发人员再现用户性能问题，从而使开发人员能更好地测试和细化软件。

D.示例计算机系统实现

图9描绘了在其上可以执行本发明的各个方面的计算机系统900的示例性实现。计算机系统900旨在以常规个人计算机的形式表示通用计算系统。

如图9所示，计算机系统900包括处理单元902、系统存储器904，以及将包括系统存储器904的各种系统组件耦合到处理单元902的总线906。系统总线906表示若干类型的总线结构中的任何一种总线结构的一个或多个，包括存储器总线或存储器控制器、外围总线、加速图形端口，以及使用各种总线体系结构中的任何一种的处理器或局部总线。系统存储器904包括只读存储器(ROM)908和随机存取存储器(RAM)910。基本输入/输出系统912(BIOS)存储在ROM 908中。

计算机系统900还具有下列驱动器中的一个或多个：用于读写硬盘的硬盘驱动器914、用于读写可移动磁盘918的磁盘驱动器916，以及用于读写诸如CD ROM、DVD ROM或其他光学介质之类的可移动光盘922的光盘驱动器920。硬盘驱动器914、磁盘驱动器916，以及光驱动器920分别通过硬盘驱动器接口924、磁盘驱动器接口926，以及光学驱动器接口928连接到系统总线906。驱动器以及它们相关联的计算机可读介质为服务器计算机提供了对计算机可读指令、数据结构、程序模块，及其他数据的非易失性存储。虽然描述了硬盘、可移动磁盘和可移动光盘，但是也可以使用诸如闪存卡、数字视频盘、随机存取存储器(RAM)、只读存储器(ROM)等等之类的其他类型的计算机可读介质来存储数据。

多个程序模块可被存储在硬盘、磁盘、光盘、ROM，或RAM上。这些程序包括操作系统930、一个或多个应用程序932、其他程序模块934，以及程序数据936。应用程序932或程序模块934可包括，例如，用于实现如此处参考图1所描述的测试数据生成系统100的任何或全部功能元件的逻辑。应用程序932或程序模块934也可以包括，例如，用于实现图2和7中所描绘的流程图的一个或多个步骤的逻辑。因而，这些附图中所示出的每一步骤都也可以被视为被配置成执行该步骤所描述的功能的程序逻辑。

用户可以通过诸如键盘938和定点设备940之类的输入设备向计算机900中输入命令和信息。其他输入设备(未示出)可以包括话筒、操纵杆、游戏手柄、圆盘式卫星天线、扫描仪等等。这些及其他输入设备常常通过耦合到总线906的串行端口接口942连接到处理单元902，但是也可以通过其他接口，诸如并行端口、游戏端口、通用串行总线(USB)端口，来进行连接。

监视器944或其他类型的显示设备也可以经由诸如视频适配器946之类的接口来连接到系统总线906。监视器944被用来呈现协助用户/操作员配置和控制计算机900的GUI。除了监视器之外，计算机900还可包括其他外围输出设备(未示出)，如扬声器和打印机。

计算机900通过网络接口950、调制解调器952、或用于通过网络建立通信的其他装置连接到网络948(例如，诸如因特网之类的WAN或LAN)。调制解调器952(可以是内置的或外置的)，通过串行端口接口942连接到系统总线906。

如此处所使用的，术语“计算机程序介质”和“计算机可读介质”被用来泛指诸如与硬盘驱动器914相关联的硬盘、可移动磁盘918、可移动光盘922，以及诸如闪存卡、数字视频盘、随机存取存储器(RAM)、只读存储器(ROM)等等之类的其他介质。

如上文所指出的，计算机程序(包括应用程序932及其他程序模块934)可以存储在硬盘、磁盘、光盘、ROM或RAM上。这样的计算机程序也可以通过网络接口950或串行端口接口942来接收。这样的计算机程序，当执行时，使得计算机900能实现此处所讨论的本发明的特征。相应地，这样的计算机程序表示计算机900的控制器。

本发明还涉及包括存储在任何计算机可使用介质上的软件的计算机程序产品。这样的软件，当在一个或多个数据处理设备中执行时，使数据处理设备如此处所描述的那样操作。本发明的各实施例使用现在已知的或将来已知的任何计算机可使用或计算机可读介质。计算机可读介质的示例包括，但不仅限于，诸如RAM、硬盘驱动器、软盘、CD ROM、DVD ROM、zip磁盘、磁带、磁存储设备、光存储设备、MEM(存储器)、基于纳米技术的存储设备等等之类的存储设备。

E.结论

尽管上文描述了本发明的各实施例，但是，应该理解，它们只是作为示例来呈现的，而不作为限制。相关领域技术人员将理解，在不偏离如所附权利要求书所定义的本发明的精神和范围的情况下，可以在形式和细节方面进行各种修改。因此，本发明的范围不应该受到上述示例性实施例的任一个的限制，而只应根据下面的权利要求和它们的等效内容进行定义。

Claims

1.一种用于生成用于开发、测试软件和/或支持对该软件的使用的测试台的计算机实现的方法，包括：

接收引用计算机网络的类型空间模型的清单，所述类型空间模型包括硬件、软件、网络和存储实体类型，所述清单包括传达参数的编码，所述参数可以被用来将所述计算机网络的类型空间模型膨胀为所述计算机网络的实例空间模型(208)；

处理所述清单以创建所述计算机网络的实例空间模型(210)；以及

将表示所述实例空间模型的数据存储到物理存储介质中(212)。

2.如权利要求1所述的方法，其特征在于，所述类型空间模型还包括进程数据实体。

3.如权利要求1所述的方法，其特征在于，所述编码传达基数信息，所述基数信息指定在创建所述实例空间模型时要生成的实体类型实例或关系类型实例的具体数量。

4.如权利要求1所述的方法，其特征在于，所述编码传达属性信息，所述属性信息指定要与在创建所述实例空间模型时所生成的实体类型实例相关联的属性。

5.如权利要求1所述的方法，其特征在于，所述类型空间模型包括对象-关系有向图，所述有向图描述多个潜在有向图实例，并且其中所述实例空间模型包括所述多个潜在有向图实例中的一个。

6.如权利要求1所述的方法，其特征在于，还包括：

从模型储存库中提取描述所述类型空间模型的元数据；以及

处理所提取的元数据以生成所述清单。

7.如权利要求1所述的方法，其特征在于，还包括：

通过经由计算机实现的用户界面工具编辑所述清单来将所述参数添加到所述清单中。

8.一种用于生成引用计算机网络的类型空间模型的清单的计算机实现的方法，所述类型空间模型包括硬件、软件、网络以及存储实体类型，所述清单包括传达参数的编码，所述参数可以被用来将所述计算机网络的类型空间模型膨胀为所述计算机网络的实例空间模型，所述方法包括：

使用网络-管理软件产品来收集有关企业网络的信息(810)；以及

从所收集到的信息提取所述清单中所包括的所述编码所传达的所述参数中的一个或多个；以及

使用所提取的参数来生成所述清单(814)。

9.如权利要求8所述的方法，其特征在于，所述收集步骤包括将从与企业网络相关联的企业收集到的信息传送到远程实体以用于创建所述清单。

10.如权利要求8所述的方法，其特征在于，进一步包括：

对于与多个不同的企业相关联的多个不同的企业网络，执行所述收集、提取和使用步骤以生成多个清单；以及

将所述多个清单中的两个或更多个组合起来以创建原型清单。

11.如权利要求8所述的方法，其特征在于，将所述多个清单中的两个或更多个组合起来以创建原型清单包括：

基于由所述多个清单中的每一个清单中的所述编码所传达的所述参数来聚集所述多个清单，以生成一个或多个清单集群；以及

基于由至少一个集群中所包括的每一个清单中的所述编码所传达的所述参数来创建与该集群相关联的原型清单。

12.一种用于生成用于开发、测试软件和/或支持对该软件的使用的测试台的系统，包括：

类型空间定义处理器(106)，其被配置成接收清单(108)并从中获取计算机网络的类型空间模型(112)和可以被用来将所述计算机网络的类型空间模型膨胀为所述计算机网络的实例空间模型的参数，其中所述类型空间模型(112)包括硬件、软件、网络以及存储实体类型；

实体引擎(114)，其被配置成处理所述类型空间模型(112)和所述参数以创建所述计算机网络的实例空间模型(116)；以及

数据库写入动作模块(118)，其被配置成将表示所述实例空间模型的数据存储到物理存储介质中。

13.如权利要求12所述的系统，其特征在于，所述参数包括基数信息，所述基数信息指定在创建所述实例空间模型时要生成的实体类型实例或关系类型实例的具体数量。

14.如权利要求12所述的系统，其特征在于，所述参数包括属性信息，所述属性信息指定要与在创建所述实例空间模型时所生成的实体类型实例相关联的属性。

15.如权利要求12所述的系统，其特征在于，所述类型空间模型包括对象-关系有向图，所述有向图描述多个潜在有向图实例，并且其中所述实例空间模型包括所述多个潜在有向图实例中的一个。