CN101841433A - 测试模型和方法 - Google Patents

Abstract

本公开内容提供了一种测试模型。该测试模型包括：被配置成包含多个待测服务的待测服务单元；被配置成指定多个与各个测试相关的测试数据的测试数据单元；被配置成为各个测试指定多个测试行为的测试行为单元；被配置成为各个测试指定多个测试计划的测试计划单元；被配置成包含各个测试的多个测试结果的测试结果单元；其中该待测服务单元与该测试数据单元、该测试行为单元、该测试计划单元和该测试结果单元相关联，并对它们进行访问。本公开内容还提供了一种测试方法。

Description

测试模型和方法

技术领域

本公开内容总体上涉及测试领域。

背景技术

基于标准的动态协作是面向服务的体系结构(Service-OrientedArchitecture，SOA)及其实现Web服务(WS)系统的关键特征。一般的WS体系结构定义了一个用于服务发布、发现和绑定的协作模型。服务是一个驻留在服务提供方的服务器上的可执行的软件组件，其远程地向服务使用方或应用传送结果。服务使用方查询服务中介，找到满足其需要的服务，并动态绑定到服务接口。通过开放标准的规范，诸如简单对象访问协议(SOAP)、Web服务描述语言(WSDL)和统一描述、发现和集成协议(UDDI)等，使得分布式的各方之间能够相互协作。

WS测试需要所涉及的相关各方都参与。服务中介必须通过执行独立的测试来确保它们所发布的服务的质量。服务使用方也可以在购买或使用服务之前，基于其所使用的场景来测试这些服务。需要将WS测试组织在一个集成的框架中，以便于可以共享诸如测试脚本、测试故障和可靠性报告、测试脚本等级以及服务之类的工具和数据，并能综合测试结果。因此，需要一种协作性校核和验证(CV&V)，以使得涉及的各方能够共享、交换和相互操作测试制品。这扩展了一般的WS体系结构的测试能力。

发明内容

根据本公开内容的一个方面，本公开内容提供了一种测试模型，包括：待测服务单元，测试数据单元、测试行为单元、测试计划单元和测试结果单元。该待测服务单元被配置成包含多个待测服务。该测试数据单元被配置成指定多个与各个测试相关的测试数据。该测试行为单元被配置成为各个测试指定多个测试行为。该测试计划单元被配置成为各个测试指定多个测试计划。该测试结果单元被配置成包含各个测试的多个测试结果。该待测服务单元与该测试数据单元、该测试行为单元、该测试计划单元和该测试结果单元相关联，并对它们进行访问。

根据本公开内容的又一方面，本公开内容提供了一种测试方法，包括步骤：使用一个或多个变异算子来生成多个变异体OWL文件；从该变异体OWL文件中检测一个或多个不一致的变异体；从该变异体OWL文件中移除所检测到的一个或多个不一致的变异体；执行剩余的变异体；生成测试结果。

以上概述仅为示意性的，并不意在以任何方式进行限制。除了上文所述的示意性方面、实施例、实施方案和特征之外，将通过参照附图和下文的详细描述而使进一步的方面、实施例和特征变得明显。

附图说明

图1示出了根据本公开内容的一个实施方案的基于本体的WS测试的示意性概图。

图2示出了根据本公开内容的一个实施方案的测试本体模型(TOM)100的示意性框架图。

图3示意性地示出了根据本公开内容的一个实施方案的TOM中的各个模型元件之间的概念和关系。

图4示意性地示出了根据本公开内容的一个示例性的Accommodation本体。

图5示意性地示出了根据本公开内容的一个派生的TravelTest本体的类层次结构。

图6示意性地示出了根据本公开内容的一个OWL-S本体模型。

图7示意性地示出了根据本公开内容的一个基于OWL-S规范的WS变异测试的总的体系结构。

图8示意性地示出了根据本公开内容的一个示例性的BookFinder服务。

图9示意性地示出了根据本公开内容的一个bibtex本体中的类层次结构。

具体实施方式

在下文的详细描述中，将参照形成本说明书一部分的附图。在附图中，相似的附图标记通常指代相似的部件，除非上下文中另行指出。在详细说明书、附图和权利要求书中所描述的示意性实施例并不意在限制。在不偏离在此展现的主体的精神和范围的情况下，可以采用其他实施例，并且可以进行其他变化。易于理解的是，在此所大致描述的以及附图中所图示的本公开内容的各方面可以在宽泛的配置变化中进行排列、替换、组合、分拆和设计，所有这些均被明确考虑于此。

图1示出了根据本公开内容的一个实施方案的基于本体的WS测试的示意性概图。如图1所示，服务语义规范(例如，在OWL-S(Web本体语言规范)中)作为一个输入被输入进测试系统。通过测试生成器可以自动生成测试用例。所生成的测试制品可以由测试本体模型(TOM)OWL规范详细描述，TOM OWL规范用作测试组件之间的契约，包括：

·测试生成器，解析Web服务(WS)规范并生成编码于TOM中的测试用例；

·测试统治器，组织测试计划，调度测试任务并协调测试执行；以及

·测试代理，在服务上移动并实践测试用例。

本体基础结构针对服务应用领域以及测试策略提供了领域本体信息，有助于本体编辑和分析，并利用一些规则和推理技术改进了测试生成的智能。

图2示出了根据本公开内容的一个实施方案的测试本体模型(TOM)100的示意性框架图。如图2所示，根据本公开内容的一个实施方案的TOM 100包括测试数据TD 102、测试行为TB 104、测试计划TP 106、测试结果TR 108以及待测服务SUT 110。SUT 110可以与测试数据TD 102、测试行为TB 104、测试计划TP 106、测试结果TR 108相关联，并对它们进行访问。测试数据TD 102描述了针对SUT 110中定义的每一个输入/输出的数据相关概念，包括数据池、数据分区、数据选择策略和数据值。测试行为TB 104描述了针对每一个待实践的测试的测试准备、测试过程以及期望结果。测试计划TP 106描述了对测试用例进行分布式执行的组织、调度和配置。测试结果TR 108描述了用于统计分析和质量评估的所收集的测试结果。在图2中，TOM 100使用测试数据TD 102和测试行为TB 104来描述测试设计，使用测试计划TP 106和测试结果TR 108来描述测试执行。然而，应当理解的是，TOM 100并不限于包括上述的模型元件，一些模型元件可以被省略和/或组合，和/或可以包括进其他的适合的模型元件，例如TOM 100可以包括决策器V、测试仲裁器TA等。

图3示意性地示出了根据本公开内容的一个实施方案的TOM中的各个模型元件之间的概念和关系。如图3所示，每个SUT110可以与测试结果TR 108、测试计划106、测试204和数据池DP 1022相关联，并对它们进行访问。SUT 110可以从测试结果TR 108中得到与每个测试执行相对应的测试结果。在其整个生命周期中的不同的阶段，诸如在来自不同的桩所有者(诸如服务提供方、服务中介、服务消费者以及甚至是独立的测试者)所发起的单元测试、集成测试、系统测试以及回归测试中，SUT 110可以具有多个包含在测试计划TP 106中的测试计划。SUT 110可以由包括测试用例TC 206和测试套件TS 208的测试T 204所定义的多个测试来校核和验证。WSDL-S/OWL-S SUT规范中的每个数据都可以与定义在数据池DP 1022中的一组数据相关联。下文中将进一步讨论其他的模型元件以及它们之间的相互关系。

每个测试结果TR 108可以与测试仲裁器TA 216、测试计划TP 106和SUT 110相关联。测试结果TR 108可以访问测试仲裁器TA 216，并可以被测试计划TP 106和SUT 110所访问。测试结果TR 108包括与每个测试执行相对应的一个或多个测试结果。测试仲裁器216可以评估测试结果TR 108中的测试结果，其描述了测试结果的评估标准。

每个测试计划TP 106可以与测试结果TR 108、SUT 110和测试T 204相关联，它可以访问测试结果TR 108和测试T 204，并可以被SUT 110所访问。测试计划TP 106定义了一组用于组织和调度测试执行的测试计划，诸如是顺序执行测试或是并发执行测试。测试计划也定义了测试运行的配置，诸如针对分布式测试而将测试代理部署在局域网LAN中。测试计划包括测试的收集并拥有执行历史，并能够动态地合成测试用例以及重新配置测试执行。

每个测试T 204可以与SUT 110、测试计划TP 106、决策器V 214、配置器C 210、调度器S 212、测试用例TC 206和测试套件TS 208相关联，它可以访问决策器V 214、配置器C 210、调度器S 212，并可以被SUT 110和测试计划TP 106所访问，以及可以由测试用例TC 206和测试套件TS 208所泛化。测试T 204可以拥有包含于调度器S 212中的调度策略、包含于配置器C 210中的配置策略以及由决策器V所确定的决策，以利用调度策略指定诸如平行执行、顺序执行、循环执行或分支执行之类的执行顺序，利用配置策略来指定在分布式环境中执行和实践测试的测试组件的部署，利用决策来指示测试成功或失败。

每个测试用例TC 206可以与数据池DP 1022、测试行为TB 104、测试套件TS 208以及测试T 204相关联，它可以访问数据池DP 1022和测试行为TB 104，并可以被测试套件TS 208所访问。测试用例TC206包括带有输入、预期输出和一连串测试过程的可自动执行元件。测试用例TC 206从定义于数据池DP 1022中的数据得到输入和输出规范，并利用定义于测试行为TB 104中的行为规范来描述测试动作的顺序。可以将定义在测试用例TC 206中的一个或多个测试用例组织成包含于测试套件TS 208中的一个或多个测试套件。

每个数据池DP 1022可以与数据选择器DS 1026、SUT 110、测试用例TC 206和数据分区DP 1024相关联，它可以访问数据选择器DS 1026和数据分区DP 1024，并可以被SUT 110和测试用例TC 206所访问。数据池DP 1022中的每个数据池可以被定义成一组包含于数据分区DP 1024中的数据分区，以代表数据的等价类分区，这些数据池还可以从数据选择器DS 1026中获得不同的数据选择策略以引导针对某一测试上下文中的测试用例的一个或多个数据分区的选择。数据池包括针对具体的测试目的的测试数据。例如，一个服务可以拥有针对其所有数据的三个数据池，分别包括功能测试、可靠性测试和安全性测试。用于数据的数据池还可以进一步分为代表测试子领域的一个或多个数据分区。可以在运行中实时地根据拥有各种不同的数据选择标准的数据选择策略而从不同的数据分区选择数据。

每个数据分区DP 1024可以与数据值DV 1028、数据选择器DS1026和数据池DP 1022相关联，它可以访问数据值DV 1028和数据选择器DS 1026，并可以被数据池DP 1022所访问。可以为OWL-S中的服务接口规范中的每一个参数创建包含于数据池DP 1022中的一个或多个数据池。基于参数本体定义，包含于数据分区DP 1024中的一个或多个数据分区可以基于对参数类关系、属性以及约束的分析来生成，并包含有一组可以通过测试历史来获得和积累到的样本值。测试数据分区之间的约束和相互关系也可以通过推导得到并可以被验证。包含于数据选择器DS 1026中的一个或多个数据选择策略被定义成指定测试策略，以用于为运行具体测试而选择分区。例如，“强鲁棒性”策略要求执行所有数据分区中的所有的测试数据。包含于数据值DV1028中的一个或多个数据值可以是每个数据分区中的代表性数据，它可以是自动生成的，用户交互式定义的或由测试历史积累而成的。在下文中，将更详细地描述数据分区。

为了清楚地示例，图3中描述的元件仅是单个元件。应当理解的是，对于SUT，根据不同的测试目的和要求，可以在TOM中创建和存储多个测试套件、测试用例、测试数据(包括数据池、数据分区、数据选择策略和数据值)、测试计划以及对应于测试计划的配置和调度策略。在执行完测试后，也可以在TOM中存储实际的测试用例，以用于进行测试结果统计分析和测试评估。

接下来将描述TOM中的各个元件以及它们之间的相互关系。首先在接下来的三段中，描述包括测试计划、测试数据池和测试用例的测试契约的OWL-规范的实例。

<owl:Ontology rdf:about＝″″>

  <owl:imports rdf:resource＝″http://www.owl-ontologies.com/TestModel.owl″/>

  <owl:imports rdf:resource＝″http://www.owl-ontologies.com/TCG4Camera.owl″/>

</owl:Ontology>

<testmodel:TestSuite rdf:ID＝″TestSuite_1″>

  <testmodel:hasScheduler rdf:resource＝″http://www.owl-ontologies.com/TestModel.owl#Sch_Sequence″/>

  <testmodel:hasTestSuite>

    <testmodel:TestSuite rdf:ID＝″TestSuite_2″>

      <testmodel:hasTestCase rdf:resource＝″http://www.owl-ontologies.com/TCG4Camera.owl#TestCase_1″/>

      <testmodel:hasTestCase rdf:resource＝″http://www.owl-ontologies.com/TCG4Camera.owl#TestCase_2″/>

      <testmodel:hasScheduler rdf:resource＝″http://www.owl-ontologies.com/TestModel.owl#Sch_Sequence″/>

    </testmodel:TestSuite>

  </testmodel:hasTestSuite>

  <testmodel:hasTestCase rdf:resource＝″http://www.owl-ontologies.com/TCG4Camera.owl#TestCase_1″/>

</testmodel：TestSuite>

<testmodel:TestPlan rdf:ID＝″TestPlan_1″>

  <testmodel:hasTestSuite rdf:resource＝″#TestSuite_1″/>

  <testmodel:hasTesuSuite rdf:resource＝″#TestSuite_2″/>

</testmodel:TestPlan>

基于OWL的测试计划规范

<testmodel:DataPool rdf:ID＝″DataPool_1″>

   <testmodel:hasDataPartition>

      <testmodel:DataPartition rdf:ID＝″DataPartition_2″>

        <testmodel:hasDataSelectcr rdf:resource＝″http://www.owl-ontologies.com/TestModel.owl#DataSelector_Seq″/>

        <testmodel:hasCntType rdf:datatype＝″http://www.w3.org/2001/XMLSchemadanyURI″>

        http://www.owl-ontologies.com/DPL4Camera.owl#Lens_2</testmodel:haeDatType>

      </testmodel:DataPartition>

   </testmodel:hasDataPartition>

   <testmodel:hasDataPartition rdf:resource＝″#DataPartition_1″/>

   <testmodel:hasDPariable rdf:resource＝″#DPLVariable_1″/>

  </testmodel:Datapool>

基于OWL的测试数据池规范

<testmodel:TestSpecification rdf:ID＝″TestSpecification_1″>

  <testmodel:hasExpResult rdf:resource＝″#ExpectResult_1″/>

  <testmodel:hasTestProcedure  rdf:resource＝″#TestProcedure_1″/>

  <testmodel:haslnputData>

     <testmodel:Stimulus  rdf:ID＝″Stlmulus_1″>

       <testmodel:hasValue>

         <dpl:Lens_1 rdf:ID＝″Lens_1_2″/>

       </testmodel:hasValue>

     </testmodel:Stimulus>

  </testmodel:hasInputData>

</testmodel:TestSpecification>

基于OWL的测试用例规范

接下来，将采用示例的形式描述基于本体的数据分区的生成。下文示出了一个可以采用OWL-S来描述的被称为TravelSearch的服务本体。该服务输入为Activity和Accommodation，输出为Destination。

<process:AtomicProcess rdf:ID＝″TravelSearchProcess″>

    <service:descraber rdf:resource＝″#TravelSearchService″/>

    <process:husInput rdf:resource＝″#Activity″/>

    <process:hasInput rdf:resource＝″#Accomodation″/>

    <process:n:hasOurput  rdf:resource＝″#Destination″/>

</Process:AtomicProcess>

<process:Input rdf:ID＝″Activity″>

     <process:parameterType

      rdf:datatype＝″<xed:#anyURI″><bibtex:#Activicy</process:par<coeterType>

</process:Input>

<process:Input  rdf:ID＝″Accomodation″>

     <process:parameterTyre

     rdf:datatype＝″<xed:#any URI″>Cbibtex:#Accomodation</process:parueterType>

</process:Input>

<process:Output  rdf:ID＝″Destination″>

    <process:parameterType

    rdf:datatype＝″<xed:#anyURI″>#concepts；#Destination</process:paramecerType>

</process:Output>

图4示意性地示出了根据本公开内容的一个示例性的Accommodation本体。Accommodation有三个子类，分别为Hotel，BedAndBreakfast和BudgetAccommodation。BudgetAccommodation有一个子类Campground，Hotel有一个子类LuxuryHotel。Accommodation有一个属性hasRating，该属性有三个值：OneStar，TwoStar和ThreeStar。此外，Accommodation具有以下约束：

1.BudgetAccommodation可以具有一星OneStar或二星TwoStar等级，即：

BudgetAccommodation≡(Accommodation∩hasRating(OneStar∪TwoStar))。

2.Campground可以具有一星OneStar等级，即：

$\mathrm{Campground}\&Subset;(\mathrm{Accom}\mathrm{mod}\mathrm{ation}\&cap;\mathrm{hasRating}\left(\mathrm{OneStar}\right)).$

3.LuxuryHotel可以具有三星ThreeStar等级，即：

$\mathrm{LuxuryHotel}\&Subset;(\mathrm{Hotel}\&cap;\mathrm{hasRating}\left(\mathrm{ThreeStar}\right)).$

如上文所述，每个SUT可以与一组测试用例，一组执行测试数据的数据池、一组用于调度测试执行的测试计划和一组对应于每一测试执行的测试结果相关联。一个测试用例包括两个部分：数据部分和行为部分。如图3所示，测试数据可以被建模成三层：数据池、数据分区和数据值。服务接口规范中的每个参数可以与一组数据池定义相关联。数据池包括一组用于具体测试目的的测试数据。用于数据的数据池还可以进一步被分成代表测试子领域的数据分区。根据本体类定义，分区可以被递归式地分解成子分区。如图4所示，以TravelSearch为例，输入参数accommodation可以具有用于功能测试的数据池，并根据它所被标记的等级OneStar，TwoStar和ThreeStar而被分成三类。因此，它可有助于针对“仅重新测试用于ThreeStar的accommodation的搜索服务”的回归测试。行为部分定义了测试用例的动作和顺序。这些动作可以是测试准备、事件触发、数据输入和测试清除。TOM能够使动作及其相关的数据之间动态相关。

定义在TOM中的数据池可以针对每个OWL-S中的服务接口规范中的每个参数被创建。基于参数本体定义，数据分区可以基于参数类关系、属性和约束的分析被生成。测试数据分区的约束和关系也可以被派生和验证。

生成分区测试用例的过程可以如下：

步骤1.分析由OWL-S描述的SUT一个或多个参数。

步骤2.针对不同测试目的为参数创建数据池。

步骤3.为每个参数的每个数据池派生数据分区的类层级。

步骤4.派生并定义数据分区的类约束和关系。

步骤5.在每个分区中派生数据值。

这是一个基于服务领域(S)中的服务本体(O^s)，派生出测试领域(T)中的测试数据分区本体(O^T)的迭代过程。可以通过递归实践以下行为来分级地识别数据分区：

1.直接将S中的本体类映射到T中。也就是说，对于S中的每个类，在T中有一个等价类。类似的，子类关系也可以从S直接映射到T。

2.S的类属性分析。数据分区的测试本体类可以进一步分割成子类，其中每个子类代表了服务本体的一个属性的数据分区。

3.类关系和属性约束分析，以移除以上步骤中识别出的冗余的类。

4.识别测试数据分区的类关系和属性约束。

以Accommodation为例，图5示意性地示出了根据本公开内容的一个派生的TravelTest本体的类层次结构，其代表用于测试输入参数Accommodation的数据分区。它首先通过将Travel本体直接映射成TOM而识别出六个测试本体类，用灰色标记。同样Travel本体中的子类关系也可以直接映射到TravelTest本体。由于Accommodation具有带有3个值的属性hasRating，通过将带有属性hasRating的所有6个类分解，可以进一步生成18个子分区。TravelTest本体的约束移除了派生出的18个子类中的9个。

例如，分区Clz_Hotel和Clz_LuxuryHotel可以分别被生成服务本体Hotel和LuxuryHotel的等价体。Hotel和LuxuryHotel之间的子类关系还可以被直接映射到Clz Hotel和Clz LuxuryHotel。通过将Clz_LuxuryHotel分解成Clz_OneStarLuxuryHotel、Clz_TwoStarLuxuryHotel和Clz_ThreeStarLuxuryHotel，可以进一步识别出3个子类。然而，根据第三约束，LuxuryHotel仅可以是ThreeStar。基于此约束，可以推断出：

1.Clz_OneStarLuxuryHotel和Clz_TwoStarLuxuryHotel没有意义；以及

2.Clz_LuxuryHotel≡Clz_ThreeStarLuxuryHotel。

因此，根据冲突1和重复2，3个子类可以被移除。类似地，可以根据约束1，移除子分区{Clz_OneStarBuddgetAccommodation，Clz_TwoStarBuddgetAccommodation，Clz_ThreeStarBuddgetAccommodation}，以及根据约束2移除子分区{Clz_OneStarCampground，Clz_TwoStarCampground，Clz_ThreeStarCampground}。

OWL支持本体类中的以下关系定义：

1.子类：存在X，X是Y的子类。

2.等价类：两个类具有完全相同的实例，并可以相互替换。

3.互斥类：是指一个类的实例，不能同时也是其他类的实例。它意味着两个分区不可以相互重叠。

4.交集类：一个复杂类可以通过类和/或属性约束的交集来定义。它意味着 类的所有个体都应该满足所有的类和约束。

5.并集类：一个复杂类可以通过类和/或属性约束的并集来定义。它意味着 类的个体应该满足类和约束中的任意一个。

6.补集类：它是指如果X是Y的补集类，那么X具有所有不在Y中的个体。

对于派生的数据分区，服务领域中的所有关系可以被直接映射到测试领域中。接下来的例子，是一个从TravelTest本体实施例派生而来的数据分区上的互斥关系。在该实例中，Hotel和BedAndBreakfast可以具有两个互斥类。Clz_Hotel和Clz_BedAndBreakfast可以是两个与它们分别等价的对应的测试数据分区。因此，可以推断出Clz_Hotel和Clz_BedAndBreakfast也是两个互斥类。

(Clz_Hotel≡Hotel)∩

(Clz_BedAndBreakfast≡BedAndBreakfast)∩

$(\mathrm{Clz}\_\mathrm{TwoStarHotel}\&Subset;\mathrm{Clz}\_\mathrm{Hotel})\&cap;$

$(\mathrm{Clz}\_\mathrm{TwoStarBedAndBreakfast}\&Subset;\mathrm{Clz}\_\mathrm{BedAndBreakfast})$

OWL支持本体类属性约束的定义，包括基数约束和值约束。基数约束定义了类属性值的最小数(min)和最大数(max)。例如，Accommodation可以恰好具有一个等级Rating。值约束定义了值范围和属性范围。Owl:allValueFrom要求对于具有指定属性的实例的类的每个实例，属性值可以是由Owl:allValueFrom条款指出的类的所有成员。例如，假设人们仅可以在国家公园(NationalPark)(Destination)中徒步旅行(Hiking)(Activity)。因此，Hiking本体的属性isPossibleIn具有“仅NationalPark”的约束。Owl:hasValue约束(has)允许我们基于所存在的具体的属性值来描述类。例如，假设对于一个Accommodation，仅有三个等级可以被定义，因此，Accommodation的属性hasRating具有owl：hasValue：被接受的值的枚举“{OneStar，TwoStar，ThreeStar}”。

派生的数据分区的属性约束也可以被直接从本体映射而得到。例如，类等级中的所有分区完全具有一个hasRating的属性值。然而，因为一些分区可以通过属性分解而得到，定义在本体中的值约束通常不能直接被映射到数据分区。例如，Clz_ThreeStar的属性hasRating仅可以具有一个值“hasRating”。

数据分区定义一个或多个测试类。测试数据实例可以通过为类属性填上实际值而生成，尤其是值约束和基数约束。假设一个属性具有基数约束为区间[n1，n2]，值约束为枚举集S＝{d1，d2，...dm}。为了生成测试数据值，可以从S中随机地选择K个数据，其中n1＜＝K＜＝n2。

可以建立一个数据库，以导入预定义的数据或积累的历史数据。例如，通过截取SOAP消息，可以捕获服务使用概要，然而录入用于以后测试的输入/输出数据。测试生成器查询数据库以选取值并填入测试用例中。

也可以定义用于派生数据值的规则。规则语言，诸如语义Web规则语言(SWRL)可以支持输入数据的依赖和约束规范。接下来的一个例子是两个旅行者(tourist)之间的同伴(companion)关系。两个旅行者x和y，如果具有相同的指南g，则认为他们是同伴。

def-has_Companion＝Tourist(？x)∧Tourist(？y)

∧Guide(？g)∧hasGuide(？x，？g)∧hasGuide(？y，？g)

∧differentFrom(？x，？y)

→has_Companion(？x，？y)

假设服务要求作为同伴的两个旅行者的两个输入参数。通过推理该规则，测试生成器可以生成一个测试输入。

在以上的描述中，已经采用TravelTest作为一个实例来描述了基于本体的数据分区的生成。在接下来的描述中，将描述一种自动的变异测试。

图6示意性地示出了根据本公开内容的一个OWL-S本体模型。如图6所示，OWL-S从三个方面为服务建模了上层本体：服务概要(ServiceProfile)、服务基础(ServiceGrounding)和服务模型(ServiceModel)。服务概要提供了服务以及它的提供方的高层描述，用于告知、请求以及匹配服务，包括服务概述、服务功能以及功能属性。服务基础定义了从概要表示到具体规范的映射，具体描述了如何访问服务，诸如协议和消息格式、串行化、传送以及寻址。服务模型描述了能够使服务启动、组合、监控等的服务能力。可以使用两个组件来定义OWL-S过程模型：过程本体描述包括输入、输出、前置条件以及效果；过程控制本体描述过程状态，诸如启动、执行和完成。

图7示意性地示出了根据本公开内容的一个基于OWL-S规范的WS变异测试的总的体系结构。它包括以下组件。

变异体生成器(MG)：它通过对OWL-S规范进行少量的句法改变来干扰待测WS。可以基于原始的OWL-S领域规范和领域本体规范来定义变异算子。可以在两个层次上生成变异体：本体变异体和规范变异体。

过程执行引擎(PEE)：描述WS的原始的OWL-S和变异体OWL-S均可以在PEE上实践，PEE执行所需的服务。它或者在实际环境中执行或者在模拟环境中执行。所有的测试结果可以保存在永久性仓库中。当发现变异体本体不一致或前置条件验证失败时，可以放弃该执行。

等价变异体检测分析器(EMDA)：它将比较来自相同的测试用例的原始的测试结果或变异体测试结果，以区别杀死的变异体和等价变异体。

测试充分性评估和报告器(TAER)：它基于预定义的标准计算变异分数并评估测试充分性。

在本说明书中，考察了以下类型的由OWL-S描述的WS的典型错误：

1.数据错误：针对其I/O参数，服务不正确地使用了数据或数据类型。OWL-S根据OWL本体规范定义数据类型。OWL-S中的数据错误可以由不正确地使用本体类而引起。例如，它使用了超类或子类。

2.条件错误：OWL-S允许使用逻辑公式规范的条件i/o定义。任何出现在公式定义中的错误可以引起条件错误。

3.过程错误：一个合成过程包括了包括顺序、分裂、分裂-结合，任意次序、迭代、如果-那么-否则(If-Then-Else)以及选择之类的构造。系统构建器可能不正确地开始了过程构造来合成服务。

4.数据依赖错误：在一个合成服务中，服务的输入可以依赖于其他服务的输出。当一个服务错误地引用了它所依赖的其他的服务以及数据，则引起了错误。

为了检测这些敏感的缺陷，可以定义如下四类变异分析。

输入/输出数据变异

在OWL-S中，输入描述了针对服务/过程执行所需的信息，输出描述了在执行后服务/过程所产生的信息。OWL-S允许根据从领域本体抽取的OWL类来定义输入/输出的类型。输入变异算子可以从两个方面来定义：输入/输出类型以及OWL本体类定义。

条件变异

可以根据条件来执行输入和输出。OWL-S支持使用逻辑公式的输入/输出条件规范，来表达诸如KIF和PDDL之类的前置条件。条件规范对于过程的定义和执行可以非常重要。然而，逻辑表达式可能往往有错误。条件变异定义了一组变异算子，它对包括变弱、增强或改变条件的条件规范制造少量的干扰。

控制流变异

类似于过程语言，OWL-S控制构造定义了用于执行每个过程/服务的顺序和条件。一组变异算子在过程变异测试中用它的有效替代替换控制构造。不同于传统的过程语言，OWL-S定义了控制构造的本体和语义。例如，迭代构造可以被定义以用作Repeat-Wile和Repeat-Until的公共的超类。通过在控制构造的本体定义上推理，可以得到变异。

数据流变异

OWL-S使用参数绑定以描述过程之间的数据依赖。在服务/过程之间可以有许多种不同的数据依赖关系模式，包括：输入/输出依赖、输出/输出依赖、输入/输入依赖等。可以定义算子以通过改变诸如绑定的数据源和约束之类的绑定关系的定义和属性来检测数据流错误。

在以上的描述中，已经讨论了OWL-S模型，基于OWL-S规范的WS变异测试的总的体系结构以及OWL-S变异算子的分类。接下来，将讨论输入变异算子。

可以根据OWL条款来定义OWL-S描述过程的输入，该输入可以被映射到定义了语义约束的领域本体。本文描述的变异算子可以从两个方面改变WS：一方面，OWL-S输入类型变异改变了OWL-S过程模型中的参数类引用；另一方面，OWL本体变异改变了OWL-S方案中的类定义。

图8示意性地示出了根据本公开内容的一个示例性的BookFinder服务。如图8所示，服务具有类类型Book输入，声明在领域本体中，并具有字符串类型的输出。OWL文件(bibtex.owl，简称为bibtex)定义了涉及服务的领域本体。根据本公开内容的一个bibtex本体中的整个类层次结构在图9中示意性地示出。

OWL-S中的输入类型(“parameterType”)描述了参数的类或数据类型。它可以被映射到OWL本体中的类。当服务引用错误的类型，例如错误的本体类时，就会发生错误。表1概括了输入类型的变异算子。

表1

变异算子将OWL-S中的服务/过程的输入引用改变为类，这些类可以是原输入类型的超类、子类或兄弟类，以测量是否测试集合覆盖了参数的范围和约束。

OWL和RDFS允许类有多重由“rdfs：subClassOf”定义的继承关系。一个子类继承其超类的所有属性并可以利用其自己的定义扩展超类。通常，子类具有比其超类更多的约束。因为泛化关系，子类中的实例也应该属于超类。例如，类书(book)可以定义成类出版物(Publication)的子类。

在过程i/o的定义中，往往会引用错误的范围和约束。对于一个实际的类C，对其超类superC的引用将放松约束，然而对其子类subC的引用将加强约束。在前一示例中，一个在superC中的实例，可以在C范围外。因此，它们可以使软件出错。在后一示例中，软件可以拒绝一些在C范围中但在subC范围外的实例。OWL类支持多重继承关系，这可以引起更多的潜在的问题。

在Book的实例中，假设服务支持对书的各种条件的搜索，诸如书名和出版商。搜索服务可以将Book类作为输入。如果它不正确地使用了超类Publication，则服务将返回包括书、杂志和字典的所有出版物。在另一方面，如果它不正确地使用了子类学术书AcademicBook作为输入，则服务将仅返回学术书，而将所有其他类的书像课本、旅游书以及科幻书排除在外。

可以根据OWL本体中的类来定义服务输入，具有属性和值约束。范围或约束的改变可以引起不一致的问题。这样一组变异算子改变了类定义，包括属性、约束和关系。表2列出了这些算子。

表2

当一个本体中的一个具体的类等价于其他本体中的类时，来自这两个本体的概念可以合并。定义在OWL中的等价类必须具有完全相同的实例。也就是说，对于任意两个类C₁，C₂和实例c，如果C₁≡C₂，那么

则c∈C₂，反之亦然。在bibtex本体中，类“paperback_book”可以简单地定义为“softback_book”的等价类，如(a)所示。然而，等价标记常常可能是一个手动过程。当领域非常大并且本体复杂时，任何不正确的理解都可以导致不正确的标记。该组变异算子通过增加、移除和替换等价定义改变了OWL等价定义，如(b)和(c)中所示。

<owl:Class rdf:ID＝″hardback_book″>

  <owl:equivalcntClass rdf:resource-″#hardcove_book″/>

</owl:Class>

(a)原始等价类定义

<owl:Class rdf:ID＝″hardbback_book″>

<owl:equivalentClass rdf:resource＝″#hardcover_book″>

<owl:equivalentClass rdf:resource＝″#softcover_book″/>

</owl:Class>

(b)添加等价类定义

<owl:Class rdf:ID＝″hardback_book″>

<owl:equivalentClassrdf:resource＝″#book″/>

</owl:Class>

(c)替换等价类定义

类的集合的互斥性保证了一个类的实例不能同时是另一个具体类的实例。也就是说，如果C₁和C₂是互斥类，那么

OWL使用owl:disjointWith构造器来表达互斥关系，如(d)所示。

类似于等价类变异，互斥类变异改变了互斥类关系，包括添加、移除和替换关系。在下文中，(e)和(f)示出了互斥类定义实例的示例性变异。

<owl:Class rdf:about＝″#Book″>

<rdfs:subClassOf rdf:resource＝″#publication″/>

<owl:disjointWith rdf:resource＝″#magazine″/>

</owl:Class>

(d)原始互斥类定义

<owl:Class rdf:about＝”#Book”>

  <rdfs:subClassOf rdf:resource＝”#publication”/>

  <owl :disjointWith rdf:resource＝”#magazine”/>

  <owl:disjointWith rdf:resource＝”#publication”/>

</owl:Class>

(e)添加互斥类定义

<owl:Class rdf:about＝”#Book”>

  <rdfs:subClassOf rdf:resource＝”#publ ication”/>

  <owl:disjointWith rdf:resource＝”#publication”/>

</owl:Class>

(f)替换互斥类定义

OWL支持使用集合算子的复杂类定义，诸如交集、并集和补集。例如，类TravelBook可以是Travel本体的类Book的子集，如(g)所示。它可以使用交集来定义：

TravelBook＝Book∩{t|t∈Thing，t.hasCategory＝″Travel″}。对于类TravelBook的任意实例，它属于类Book且具有属性“hasCategory＝Travel”。

<owl:Class rdf:ID＝″travelbook″>

<owl:Class>

 <owl:interscctionOf  rdf:parseType＝″Collection″>

  <owl:Classrdf:about＝″#Book″/>

  <owl:Restriction>

    <owl:onProperty>

      <owl:FunctionalProperty rdf:about＝″#hasCategory″/>

     </owl:onProperty>

     <owl:hasValue rdf:resource＝″#Travel″/>

    </owl:Restriction>

   </owl:intersectionOf>

 </owl:Class>

</owl:Class>

(g)复杂类变异

用于集合运算的构造器可以被合并且被嵌入复杂类定义中。类定义的复杂性使得它成为错误的主要来源。该组算子从两个方面改变了通过种入错误到本体中而定义的复杂类的语义：集合运算变异(ClsSetOpAdd和ClsSetOpRep)和集合操作数变异(ClsAdd，ClsDel和ClsRep)。带有集合运算变异算子的变异测试可以测量测试的输入覆盖。

用于集合操作的变异算子改变了类定义的范围和约束。ClsSetOpAdd添加一个新的集合操作到类定义，而ClsSetOpRep用另一个集合操作替换该集合操作。例如，ClsSetOpRep可以将上文中的TravelBook实例中的交集操作改成并集操作。它将类TravelBook语义改变成如下：TravelBook＝Book∪{t|t∈Thing，t.hasCategory＝″Travel″}。不同于变异定义中的原始定义，类TravelBook中的任何实例可以或者属于类Book或属于具有属性“hasCategory＝″Travel″”的任何事物。例如，旅行地图或旅游车也可以被识别为是一个TravelBook。这不仅扩大了原始的TravelBook定义，还放松了对其的限制。

用于集合操作数变异的变异算子改变了对集合操作的源类的引用。ClsAdd添加一个新的类引用到集合操作中。ClsDel从集合操作中移除一个类引用，ClsRep替换集合操作中的类引用。以TravelBook为例，表3示出了算子的语义改变。例如，可以看到：(1)ClsAdd将范围限制为儿童旅游书；(2)ClsDel将范围扩展到涉及旅游的任何事物；(3)ClsRep将范围改变为旅游杂志。

表3

OWL支持带有owl：one of构造器的枚举成员实例的类定义。例如，类BookCover可以是两个实例的集合：硬封面(hard-cover)和软封面(soft-cover)。也就是，BookCover＝{hard-cover，soft-cover}。用于枚举类的变异算子可以改变实例的集合，包括添加实例(InsAdd)，移除实例(InsDel)以及替换实例(InsRep)。

可以将原型发展为自动分析WS OWL-S规范、生成变异体并对服务进行模拟测试。它可以和开放源软件集成在一起，包括用于解释OWL-S文件并执行该过程的Mindswap OWL-S引擎，用于分析本体的Jena以及用于本体推理的Pellet。

表4中示出了针对输入类型Book及其子类，诸如fiction，kidsbook和Travelbook，总共生成900个变异的本体。在变异的生成过程中，有214个变异体被检测出不一致的问题而被移除。686个一致的变异体可以被用来评估测试集合的有效性，表5中示出了测试结果。

表4

表5

应该理解，尽管上文结合WS进行描述，本公开内容也可以应用于面向服务的体系结构(SOA)/面向服务的计算(SOC)，包括商务模型、OWL-S执行引擎、企业型服务总线(ESB)、服务登记等。还应该理解，本公开内容也可以应用于涉及软件系统的SOA/SOC/WS的开发和维护过程，包括服务开发、部署以及重组等。

可以理解的是，本公开内容不限于上述的系统和方法。本公开内容可以以各种形式被改变而不背离本公开内容所附的权利要求书的精神和范围。

Claims (10)

1.一种测试模型，包括：

待测服务单元，被配置成包含多个待测服务；

测试数据单元，被配置成指定多个与各个测试相关的测试数据；

测试行为单元，被配置成为各个测试指定多个测试行为；

测试计划单元，被配置成为各个测试指定多个测试计划；

测试结果单元，被配置成包含各个测试的多个测试结果；

以及其中该待测服务单元与该测试数据单元、该测试行为单元、该测试计划单元和该测试结果单元相关联，并对它们进行访问。

2.如权利要求1所述的测试模型，其中所述测试模型是基于本体的。

3.如权利要求1或2所述的测试模型，进一步包括被配置成指定测试结果的评估标准的仲裁器。

4.如权利要求1或2所述的测试模型，还包括包含有测试用例单元和测试套件单元的测试单元。

5.如权利要求1或2所述的测试模型，其中所述测试数据单元还包括：数据池单元、数据选择器单元、数据分区单元以及数据值单元。

6.如权利要求5所述的测试模型，其中所述数据分区单元包括数据的等价类分区的集合。

7.一种测试方法，包括步骤：

使用一个或多个变异算子来生成多个变异体OWL文件；

从该变异体OWL文件中检测一个或多个不一致的变异体；

从该变异体OWL文件中移除所检测到的一个或多个不一致的变异体；

执行剩余的变异体；

生成测试结果。

8.如权利要求7所述的测试方法，其中所述测试方法是基于本体的。

9.如权利要求7或8所述的测试方法，其中所述变异算子被分类为：数据错误、条件错误、过程错误以及数据依赖错误。

10.如权利要求7或8所述的测试方法，其中所述变异算子被分类为：输入/输出数据变异、条件变异、控制流变异以及数据流变异。

Images