理论计算机科学电子笔记111（2005）161-182www.elsevier.com/locate/entcs基于模型的内置测试*Hans-Gerhard Gross1Fraunhofer IESE，Kaiserlestern，德国，Ina Schieferdecker2柏林工业大学FraunhoferFOKUS，德国柏林，乔治丁3Fraunhofer FOKUS，柏林，德国，摘要从预制组件组装新的软件系统作为一种有吸引力的替代传统的软件开发实践越来越多的研究。CCM、.Net或EJB等组件技术伴随着MDA等基于模型的方法。然而，重点仍然是系统设计和开发，而不是系统验证和测试。 只有当单独开发的组件能够以最小的成本有效地协同工作时，开发时间和成本才会预期减少。冗长而昂贵的现场验证和验收测试直接破坏了异构组件和后期系统集成的好处。 本文扩展了基于契约的内置测试，其中组件具备在运行时检查其执行环境的能力，从系统模型中导出内置测试，在模型级上表示它们，并从这些测试模型中生成可执行的测试。 这种基于模型的方法提高了自动化水平在生成和实现内建测试中，因此也提高了内建测试的质量并减少了开发内建测试所需的资源关键词：UML建模，基于模型的测试，测试建模，测试自动化，测试和测试控制符号，基于测试的测试1571-0661 © 2004 Elsevier B.V. 在CC BY-NC-ND许可下开放访问。doi：10.1016/j.entcs.2004.12.001162H.- G. Gross等人理论计算机科学电子笔记111（2005）1611介绍模型驱动的基于组件的开发的愿景是允许软件供应商通过从高质量的、预制的、可重用的部件组装新的应用程序来避免传统开发方法的开销，这些部件是用模型指定和实现的。由于应用程序的大部分因此可以由预制件构造，因此可以预期，应用程序开发中涉及的总时间和成本将减少，并且最终应用程序的质量将提高。这种期望是基于一个隐含的假设，即在部署时集成组件所涉及的工作量低于通过传统技术开发和验证应用程序所涉及的工作量。然而，这并没有考虑到这样的事实，即当一个本来没有故障的组件被集成到其他组件的系统中时，它可能无法按预期运行。这是因为它所连接的其他组件预期用于不同的目的，具有不同的使用情况，或者本身存在故障。 当前的组件技术可以帮助验证互连组件的语法兼容性（即，它们使用并提供正确的签名），但它们在确保应用程序从独立开发的组件组装时正确运行方面做得很少。换句话说，它们不检查相互连接的组件的语义兼容性，因此各个部分被组装成有意义的配置。因此，软件开发人员可能被迫执行更多的集成和验收测试，以达到相同的系统可靠性置信水平组件系统在运行时的正确功能取决于根据客户机/服务器模型的各个组件对的正确交互。基于契约的开发可以被看作是对象范式的扩展[22]，其中管理一对对象（以及组件）的交互的规则集通常被称为契约。这将组件与其客户之间的关系描述为正式协议，表达了各方的权利和义务。因此，要根据指定的契约测试单个客户端/服务器交互的正确功能，需要验证组件系统作为一个整体将正确运行。*这项工作得到了德国联邦医疗保险基金项目MDTS（01AK933）的电信系统的模型驱动开发。1电子邮件地址：grossh@iese.fhg.de2电子邮件：ina@cs.tu-berlin.deschieferdecker@fokus.fraunhofer.de3电子邮件地址：din@fokus.fraunhofer.deH.- G. Gross等人理论计算机科学电子笔记111（2005）161163内置合约测试基于将合约测试构建到组件中的概念，以便它们可以验证它们在部署时动态“插入”的服务器将完成其合约。考虑内置的测试工件早在设计阶段就开始了，因为系统的总体架构被开发和/或组件的接口被建模。机内测试可以也应该从系统模型中衍生出来，并应与系统设计、系统模型和系统实现一起以综合方式进行开发。在文献中，内置测试通常指的是添加到组件代码中内置测试并不是一个新概念。断言是软件工程中最早的内置测试概念之一，尽管人们不能真正称之为内置测试。断言是一个布尔表达式，它定义了正确执行对象或一个组件[12，22]。软件中的断言遵循与容易内置到硬件组件中的自检设施相同的原则。每当执行断言的布尔表达式时，它都会检查某个监视变量的值是否在其预期的域中。在文献中，断言和内置测试经常被用作同义词，例如[22]，然而我们认为它们是根本不同的概念：断言缺少一个表示内置测试的重要成分，即测试或测试用例的概念断言可以在测试中使用，并在测试执行期间为错误检测提供有价值的信息，但不能说断言或其执行代表测试。 测试是在受控条件下进行的实验，测试过程或测试框架;因此，只有当我们将测试用例作为组件的组成部分时，我们才能谈论内置测试。内建测试策略包括内建自测试隐喻，其思想来自于通常内置于硬件组件中的自测试功能。内建自测试组件是包含自己的测试用例的软件模块。粗略地说，我们可以说这些是软件组件，带有自己的测试，用于检查自己的实现。将自测试构建到软件组件中的一个动机是检查组件实现的不同变体，这些变体都基于单个组件规范[10，11]。换句话说，一个组件不仅仅被看作是它的实现，或者我们将在我们的系统中部署的物理东西实现自测试策略是一种典型的构件开发时测试方法。这意味着它是一个164H.- G. Gross等人理论计算机科学电子笔记111（2005）161测试单个单元的方法。它不太适合于检查单个单元的组件中的组件交互。对象技术为实现这种类型的对象测试提供了合适的工具。例如，我们可以在Java中有一个基类，它包括功能的实现，然后通过继承用测试代码扩展它。扩展类的测试代码提供了将检查基类实现的测试用例。扩展还将提供一些接口，可用于调用测试。如果我们想测试这样的组件，我们可以简单地实例化它的可测试版本，并通过附加的测试接口开始测试。如果我们想将类集成到现有的组件基础结构中，我们可以简单地实例化原始版本，即基类。在测试过程中，只要类没有定义任何不被继承的私有项，扩展类就可以通过继承机制访问原始功能。这种类型的内置自测试的优点是，我们可以打破被测对象的封装事实上，我们可以打破封装边界进行测试，这既可以看作是一种治疗，也可以看作是一种诅咒。它是一种治疗方法，因为我们可以应用高度特定于实现的测试用例。毕竟，我们可以访问所有的内部属性，这导致了测试对象的高可观测性和可控性。乍一看，这非常适合测试。然而，以这种方式打破封装边界也是一种诅咒，因为如果我们应用这种高度依赖于实现的测试用例，我们将永远无法在不同的实现中重用测试。例如，我们可以在一个测试中访问不同的属性，这些属性在另一个实现中根本不存在，这样我们就可以实际上废弃这个测试。另一种类似的方法，但动机略有不同，那就是添加组件自测试，并将它们永久保留在对象或组件实现中以供重用[7，8，9]。这种策略背后的主要思想是利用典型对象技术的扩展机制，不仅将类的功能继承到它的子类，而且还以容易内置的测试用例的形式继承它的测试功能。测试用例是通过对象提供的附加测试接口调用的。对象的用户可以访问它的正常接口，并在正常模式下获得其指定的功能乍一看，它似乎与前面的方法相同，但有一个微妙的区别。在前面的例子中，方法只是简单地以一种方便的方式将单元测试附加到组件实现和从组件实现在这里，我们总是将测试构建到一个对象中，并且它们从基类继承到所有H.- G. Gross等人理论计算机科学电子笔记111（2005）161165扩展类。因此，我们拥有与基类在所有继承类中提供的这种方法的主要动机是，软件组件或对象将获得相同的自测试能力，可以被视为大多数硬件组件的标准。 另外，与硬件组件相比，软件组件可以继承它们的特征，并且因此在后续版本中提供相同的自测试能力。然而，软件组件在一个重要方面不同于硬件组件虽然硬件组件是由可以随着时间的推移而物理降解的材料构建的，但软件组件不是。软件组件以数字格式编码，可以轻松检查（如有必要，可进行更正），以确保不会随时间发生变化。因此，类似于硬件方法[8，9]的软件自测试的概念在基于组件的软件测试中并不直接适用或有用。这种类型的内置测试只在组件演化和维护中有用，因为只有这样的活动才会真正改变组件的代码，并使回归测试成为必要。组件重新运行之前对自己执行的测试是没有意义的，因为根据定义，组件本身不会改变。然而，能够并且通常确实会发生变化的是组件所处的环境。因此，内置测试的目标不应该是测试组件换句话说，我们必须评估组件将被部署到的环境不偏离组件被开发的预期，并且组件不偏离其新环境被开发的预期。内置合约测试解决了这个问题。到目前为止，已经开发了内置测试的原则[8，11]。然而，基于模型的设计、规范和执行尚未得到广泛考虑。特别是在MDA（模型驱动架构）领域，需要将内置测试建模作为组件和系统开发的一个组成部分。随着UML 2.0 [20]和UML 2.0 Testing Profile [21，27]的发展，基于模型的组件和测试开发的技术基础已经建立。本文将具体讨论使用UML进行基于模型的方法进行内置测试。本文首先介绍了内置测试的主要概念，并从系统模型生成内置测试。随后，讨论了内置测试的规范及其执行。一个例子演示了基于模型的内置测试的应用。本文最后展望。166H.- G. Gross等人理论计算机科学电子笔记111（2005）1612基于模型的内置测试Meyer将客体与其客户之间的关系定义为正式协议或合同，表达了关系中各方这意味着各个组件将它们的契约方定义为提供服务（这是客户端-服务器关系中的服务器）或需要服务（这是客户端-服务器关系中的客户端内置合约测试的重点是在组装应用程序时验证两个组件之间的这些成对的客户机/服务器交互。这通常在应用程序首次配置时的部署时执行，或者在执行系统期间执行重新配置时执行。2.1内置测试仪组件配置涉及在系统中的组件之间创建单独的成对客户端/服务器关系。这通常是由外部的“第三方”完成的，我们称之为组件的上下文。这将创建客户端和服务器的实例，并将服务器到客户端（即，由此在它们之间建立客户端连接）。为了履行其对自己客户端的义务，获取新服务器的组件必须验证服务器是否这意味着客户端必须检查服务器是否提供了客户端所期望的服务。因此，客户端被以测试器组件的形式增强了内置的测试软件。这被称为服务器测试器组件，当客户端被确认可以使用服务器时执行为了实现这一点，客户端将把服务器的引用传递给它自己的如果测试失败，测试器组件可能会引发合同测试异常，并将应用程序员指向失败的位置。测试涉及使用预定义的输入值调用相关组件的方法，并根据预期结果检查返回的结果。参考输入数据和预期结果作为测试案例。在对象范式下，测试用例通常不仅涉及方法调用结果的检查，还涉及根据外部状态检查状态转换的正确性。因此，服务器测试器组件的测试套件包含根据不同测试标准开发的许多测试用例，例如状态转换模型的覆盖率或功能规范的覆盖率。这些通常通过测试来增强，H.- G. Gross等人理论计算机科学电子笔记111（2005）161167等价类划分和边界值分析[1，5，6]。拥有测试器组件并在其获取的服务器上执行合约测试的客户端称为测试客户端或测试组件[13]。2.2内置测试接口面向对象和基于组件的开发范式建立在抽象数据类型的原则之上，这些原则主张将数据和功能组合在一个实体中。 国家过渡-因此，测试是组件验证的重要组成部分。为了检查组件的操作是否正常工作，仅仅将其返回值与预期值进行比较是不够的。还必须检查组件的外部可见状态和转换是否符合这些外部可见的状态是组件契约的一部分，组件的用户必须知道这些契约然而，由于组件的这些外部可见状态体现在其内部状态属性中，因此存在一个基本的困境。封装和信息隐藏的基本原则规定，组件的外部客户端不应该看到内部实现和内部状态信息。因此，组件的外部测试软件无法获取或设置任何内部状态信息。正确组件的用户只需假设不同的操作调用将导致组件的不同的外部可见状态。但是，组件通常不会以任何方式使此状态信息可见。这意味着在特定状态模型中定义的预期状态转换通常无法正确测试。因此，契约测试范例基于这样的原则，即组件应该通过扩展正常的功能服务器来公开它们的逻辑或外部可见（而不是内部）状态。一个测试接口提供了额外的操作，这些操作可以读取和写入共同确定逻辑状态的内部状态属性。这些辅助接口操作通常通过典型的断言检查技术[1，4]导出，尽管对于合约测试，它们的定义和应用要正式得多，因为它们本质上成为组件正常功能的一部分测试接口通过状态检查和设置操作来增强被测服务器的功能。状态检查操作验证组件当前是否处于不同的逻辑状态（用于验证测试用例的后置条件）。状态设置操作将组件168H.- G. Gross等人理论计算机科学电子笔记111（2005）161满足测试用例的先决条件）。状态检查操作比状态设置操作更基本。后者往往涉及相当大的发展支出。因此，在大多数情况下，状态设置将通过调用正常功能接口的操作来实现。随后，状态检查方法可用于验证测试用例的先决条件（初始状态）是否满足。在服务器测试器组件中，测试用例可以通过两种可选方式应用。第一种方法是调用状态设置操作（如果适用）以确保测试用例所需的先决条件，根据测试标准使用预定输入参数调用被测试操作，最后调用状态检查操作以验证测试用例所需的后置条件。第二种方式适用于被测组件未提供状态设置操作的情况。然后，必须调用组件的正常功能接口的操作，以将组件带入测试所需的初始状态。由于这些操作是应该被测试的软件的一部分，因此必须调用状态检查操作来验证测试用例应用的正确前提条件。最后，调用测试方法，并使用状态检查操作来验证post条件是否符合预期结果。提供测试接口并由合约测试人员组件测试的组件称为可测试服务器或可测试组件[13]。2.3内置测试组件客户端和服务器之间的区别仅仅是指在两个组件之间的成对交互中可以扮演的角色。当从全局角度来看时，各个组件可以并且通常确实扮演客户端和服务器的角色。组件的任何客户端/服务器关系都可能受到合同测试的影响。在服务器角色中，组件提供支持由其客户端的测试器组件执行的测试的测试接口一个同时扮演这两种角色的组件（即为客户端提供测试接口，并包含自己的测试组件来测试服务器）被称为内置测试（或BIT）组件。H.- G. Gross等人理论计算机科学电子笔记111（2005）161169Fig. 1. 内建测试的一般架构。2.4内建测试架构图1显示了契约测试架构的原理。每个测试组件都提供了一个扩展原始组件（图中阴影部分）的测试接口，并且它提供了相关客户端测试组件可以用来支持测试的测试操作。每个测试组件（客户机）都拥有一个服务器测试组件。它包含检查服务器是否遵守与客户端的约定的测试3从UML生成内建测试基于UML的测试与基于代码的测试技术有许多共同的概念。源代码可以被看作是一个系统或其部分的具体表示，而UML模型是同一系统的更抽象的表示。更具体的表示包含关于系统工作的越来越详细的信息。它可以与放大所考虑的工件进行比较，170H.- G. Gross等人理论计算机科学电子笔记111（2005）161更细粒度的表示，但逐渐失去了对整个系统的概述。不太具体的表示包含较少的细节信息，但显示更多的整个系统。 这可以与缩小到更粗粒度的表示级别进行比较，从而更容易概述整个系统，但会丢失可见的细节。使用基于模型的开发技术和UML进行开发和测试的优点是，系统可以完全通过一个单一的符号在所有级别的细节上表示，从只显示其主要部分和最基本功能的系统的非常高级别和抽象的表示，到最具体的可能抽象级别，类似于并非常接近源代码表示。这意味着在开发项目中，我们只关心消除描述性文档中的一般性，而不必在不同的符号之间移动并确保它们之间的一致性。在考虑测试时也是如此。基于代码的测试关注于识别满足给定代码覆盖标准的测试场景，并且完全相同的概念可以应用于该代码的更抽象的表示，即UML模型。在这方面，我们当然也可以有用于测试的模型覆盖标准。换句话说，系统的更抽象的表示会导致更抽象的测试工件，而更具体的表示会导致该系统的更具体的测试工件。因此，以同样的方式，我们正在消除我们表示的一般性，以便获得更细粒度的细节级别，并最终获得系统的最终源代码表示，与此同时，我们必须消除该系统的测试工件的一般性，并逐步向更细粒度的测试细节水平迈进。此外，UML中的系统模型必须伴随着UML中的测试模型，为此目的，UML测试概要[21，27]已经开发出来。3.1白盒覆盖标准和UML覆盖率是软件测试中一个古老而基本的概念。测试中使用的覆盖标准基于这样的假设，即只有错误代码的执行才可能表现出故障，与预期的偏差。 如果故障部分在测试中从未执行过，则不太可能通过测试识别，因此程序路径测试-例如，测试技术是软件开发项目中最古老的软件测试和测试用例生成概念之一。多年来，这种覆盖的思想已经导致了相当多的结构化测试技术，这些技术主要基于程序流程图[2]，例如分支覆盖，谓词覆盖或DU路径覆盖。这些传统的覆盖标准都有一个共同点，即它们都是基于文件，H.- G. Gross等人理论计算机科学电子笔记111（2005）161171非常接近实施水平的数据（即流程图、源代码）。传统上，这些覆盖标准只应用于单元级别，将测试模块视为一个白盒，其实现是已知的，并且可供测试人员使用。在更高的层次上，在集成测试中，单个模块只被视为黑盒，没有内部知识。传统上，集成测试通常在最外面的子系统上执行，该子系统包含所有单独测试的单元，因此我们假设该最外面的子组件的白盒知识，而不是集成的单独单元。传统的开发只将单元测试中的白盒测试和集成测试中的黑盒测试这两个层次分开。此外，可能会对整个系统由最高级别的要求驱动。更现代的递归和基于组件的开发方法并不提倡这种严格的分离，因为单个单元可以被认为是独立的子系统，即没有内部知识可用的组件，或者集成子系统，即也是内部知识可能容易获得的组件。特别是在基于组件的开发中，我们不能真正严格地将单元与子系统分开，根据是否只有黑盒信息（例如外部可见功能和行为）或广告白盒信息（例如内部功能和行为）可用，这两种方法可以容易地并行应用。典型的白盒策略包括最低抽象级别上的语句覆盖或节点覆盖。在这种情况下，只有当具体的实现可用时（即对于语句覆盖），或者如果至少实现算法以图表的形式已知（即对于节点覆盖），才可以开发测试用例。语句覆盖通常是不可行的，或者对UML来说是不实用的，除非我们产生一个直接映射到源代码语句的模型，但是如果节点覆盖是基于一个低级的UML活动图，那么它可能是实用的。活动图与传统的流程图非常相似，尽管活动图也可以表示实体之间的协作（即通过所谓的泳道）。其他覆盖标准，如决策覆盖、条件覆盖或路径覆盖，也可能适用于UML，但它总是取决于我们可以从模型中提取的信息3.2黑盒测试技术与UML大多数功能测试用例生成技术都是基于领域分析和划分的。域分析取代或补充了用于检查输入的极值和极限值的常见启发式方法[3]。172H.- G. Gross等人理论计算机科学电子笔记111（2005）161域被定义为输入空间的一个子集，它以某种方式影响了被测组件的处理。域是通过约束不等式确定的，约束不等式是定义输入空间的哪些位置属于感兴趣域例如，域可以映射到等效域分析用于划分测试，有时也被称为划分测试，大多数功能测试用例生成技术都基于此。例如，等价划分是这组技术中的一种，它将所有可能的输入集划分为等价类。这种等价关系定义了输入集属于同一划分的属性传统上，这种技术只涉及输入值域，但随着对象技术的出现，它可以扩展到行为等价类。UML行为模型，例如状态图，为这种行为等价性分析提供了良好的基础，即测试用例设计集中于通过状态模型定义的外部可见行为的差异或相似性3.3使用UML测试概要进行由于大多数测试都是手动开发的，因为自动化测试衍生技术仍然存在一些限制和/或手动扩展和增强，因此它们的单独规范是有利的。出于这种动机，OMG已经开始开发UML测试概要，专门针对基于模型的开发中的典型测试概念。UML测试概要是基于UML元模型的UML 2.0的扩展。它定义了一种建模语言，用于可视化，指定，分析，构建和记录测试系统的工件。测试概要特别支持软件测试基础设施的规范和建模。它遵循UML相同的基本原则，因为它为测试的结构方面提供了概念，如测试组件、测试上下文和测试系统接口的定义，以及测试的行为方面，如测试程序、测试设置、执行和评估的定义。核心UML可用于建模和描述测试功能，因为测试软件开发可以被视为功能软件属性的任何其他开发。然而，由于软件测试是基于一些特殊的测试相关概念，这些概念是由测试概要作为UML的扩展这些概念主要分为测试体系结构、测试行为和测试数据的概念测试体系结构规定了测试系统的结构方面，包括：H.- G. Gross等人理论计算机科学电子笔记111（2005）161173• 被测系统（System Under Test，SUT），测试规范中的一个或多个对象可以被识别为SUT。• 测试组件，定义为测试系统中可以与SUT或其他组件通信以实现测试行为的对象。• 一种对测试系统中不同对象的测试结果进行评估的方法，以便确定测试用例或测试集的总体结论。这种评估过程称为仲裁。 用户可以使用配置文件的默认仲裁方案（即经典的功能仲裁，其中否定结果优先于肯定结果），或者使用仲裁测试组件定义自己的仲裁方案测试行为指定了检查测试目标所必需的操作和评估，测试目标描述了应该测试的内容。例如，UML交互图、状态机和活动图可用于定义测试激励、来自SUT的观察、测试控制/调用、协调和动作。然而，当这些行为被指定为测试时，主要关注的是规范或预期行为的定义。意外消息的处理是通过指定默认值来实现的，这些默认值提供了定义更完整但抽象的测试模型的方法。这简化了验证并提高了测试模型的可读性。如果观察到主测试用例行为没有显式处理的事件，则会触发默认值的单独行为。主测试行为和默认行为之间的划分取决于设计者。在测试配置文件中，默认行为应用于静态行为结构。例如，可以将默认值应用于组合碎片-元素（在交互中）、状态机、状态和区域。测试概要介绍了测试行为规范所需的进一步概念，例如：• 一个测试用例，它是一个测试套件的操作，指定一组协作测试组件如何与SUT交互以实现测试目标。• 判定是一个预先定义的枚举，指定可能的测试结果，例如：通过、不确定、失败和错误。• 验证动作，可由本地测试组件执行，以表示仲裁器被告知本地测试结果。• 日志操作，用于在执行过程中记录条目，以供进一步分析。• 一个finish动作，表示组件的测试用例行为的完成，而不终止组件。174H.- G. Gross等人理论计算机科学电子笔记111（2005）161测试规范的另一个重要方面是在测试数据中使用通配符例如，在指定处理意外事件或包含许多不同值的事件的行为因此，UML测试概要引入了通配符，允许指定：（1）任何值，表示一组可能值中的任何值，以及（2）任何或省略的值，表示任何值或缺少值（在多重性范围从0向上的情况下）。这些概念提供了使用UML 2.0构建精确的测试规范和以集成的方式开发系统和测试所需的能力。这也适用于内置测试，因为它们需要与传统黑盒测试相同的概念。4执行内置测试如果内置测试已经在UML 2.0测试概要（U2TP）中生成和指定，则可以生成它们的可执行版本，并映射到现有的测试执行环境：(i) JUnit是一个开源的单元测试框架，被用Java实现单元测试的开发人员广泛使用。映射主要集中在JUnit框架上。例如，当不存在到JUnit框架的简单映射时，可以使用现有的JUnit扩展，例如用于重复测试用例运行或用于活动测试用例(ii) TTCN-3（测试和测试控制符号[14，28，25]）被广泛认为是在电信和数据通信领域测试系统开发的标准。TTCN-3是一种测试规范和实现语言，用于定义分布式系统黑盒测试的测试过程。虽然TTCN-3是开发测试概要的基础之一，但它们在某些方面存在差异，但UML测试概要规范可以用TTCN-3模块表示，并在TTCN-3测试平台上执行。尽管如此，U2 TP和TTCN-3仍然处于不同的抽象级别：TTCN-3处于详细的测试用例规范级别，即可以直接导出可执行测试的级别。 U2TP也可以用于更抽象的层次只定义测试目标或测试用例的主要组成部分，而不给出执行测试所需的所有细节。虽然这在测试设计过程中有很大的优势，但为了生成可执行的测试，必须采取额外的手段。例如，UML的表达能力2.0序列图允许用一个图来描述一整套测试用例，因此必须应用测试生成方法来导出H.- G. Gross等人理论计算机科学电子笔记111（2005）161175从这些图表中提取这些测试。由于TTCN-3是执行内置测试的强大选项，并且拥有自己的TTCN-3测试平台[29]，因此我们选择使用它。TTCN-3是从一组基本测试概念构建的，这使得TTCN-3具有相当的通用性和应用独立性。TTCN-3测试规范由不同的部分组成，包括测试数据结构的类型定义，具体测试数据的模板定义，测试行为的功能和测试用例定义，以及测试用例执行的控制定义。这些概念的语义定义明确，测试执行的主要原则以TTCN-3的测试执行接口的形式定义TTCN-3测试规范的组成部分来自U2 TP内置测试规范，包括测试类型和数据定义以及测试行为函数和测试用例的定义。内置测试组件配备了TTCN的特定于组件的可执行版本-3个测试以及访问TTCN-3运行时环境进行测试执行。5例本节通过一个示例详细说明了基于模型的内置测试的各个部分和步骤。以RIN系统[23]为例，该系统在日常工作任务中支持工作人员或维护人员。该通信系统托管多个通信设备，这些通信设备通过无线电网络互连，并由多个桌面工作场所控制和支持。桌面工作区帮助维护人员完成任务并提供额外信息。他们可以通过查看来自工作人员视频设施的视频信号来指导工作人员完成复杂的任务，通过音频设备向工作人员提供建议，并提供其他信息，例如下载用户手册或基于视频的维修指南。每个通信设备都具有通过资源信息网络对所有其他设备公开的定义的能力。作为网络一部分的每个设备都将安装一个RIN客户端、一个RIN服务器和一些RIN插件。服务器控制资源插件并与连接的其他设备的客户端通信客户端从关联设备的RIN服务器获取信息。在通信系统范围内的所有设备可以在它们通信之前从它们相关联的节点检索关于它们此刻能够做哪些事情的信息。通过这种方式，各个节点永远不会因无法按预期处理的数据而过载对于前-176H.- G. Gross等人理论计算机科学电子笔记111（2005）161图二. RIN系统组件的UML样式表示。例如，桌面工作站的视频应用程序可以确定手持设备的当前存储器状态，并根据该信息决定它是否可以发送彩色帧或仅发送黑白帧，它还可以降低帧速率，或要求手持设备从其存储器中删除一些未使用的应用程序这些决定取决于用户的配置文件如图2所示，RIN系统由三个组件组成：RIN客户端、RIN服务器和RINSystemPlugin。• RINClient：该组件需要主机系统信息，如“系统内存状态”或“系统电源状态”。它连接到RINServer组件以处理此类请求。对于这个连接，RINClient使用（组件RINClient还提供接口RINClientCallBack。该接口用于从RIN服务器将所需信息传输回RIN客户端。• RIN服务器：该组件必须存在于每台计算机上;它接收客户端请求（通过 RINServerAccess ） 并 将 客 户 端 请 求 传 输 到 相 应 的 插 件 组 件RINSystemPlugin，该插件组件提供接口RINSystem用于接收客户端请求。通过接口RIN-ServerCallBack，RINServer从适当的插件接收必要的信息• RINSystemPlugin：这个组件运行在每台计算机上，并为RINServer提供 不 同 的 系 统 信 息 。 RINServer 使 用 RIN-SystemPlugins 的 接 口RINSystem来传输RINClient的请求。在RINSystemPlugin组件收集了所有必需的信息之后，它通过RINServer提供的接口RINServerCallBack将所有数据返回给RINServer。RIN系统为高度灵活的通信提供了主干H.- G. Gross等人理论计算机科学电子笔记111（2005）161177图三. RIN系统架构，包括内置测试架构（阴影框）。可以处理许多异构移动设备的系统。这意味着单个设备可能基于各种可用平台，在硬件，操作系统和应用程序方面存在差异。该系统的使用仅限于包含其服务的应用程序。这意味着，在同一个网络应用程序中，可以使用相当多的不同平台，RIN系统在这些平台上运行。因此，RIN系统必须在每个平台和配置上进行测试。这是一个平台测试，检查与底层中间件平台的正确连接。另一个功能是根据设备如何配备硬件提供不同的系统插件。对于测试，这意味着可以在不同的平台上添加不同类型的插件组件。它们都必须遵守服务器为与这些插件通信而实现的契约。这些测试都位于较低的抽象层，即网络或通信层。广告应用程序级测试确保应用程序从相应的插件中检索正确的信息，即从应用程序发送到插件（通过服务器）的大量高级请求。每个应用程序都将使用它所访问的每个插件的测试器组件进行扩充。所有测试均完全基于合同测试方法。图3显示了带有内置契约测试的RIN系统的组织。178H.- G. Gross等人理论计算机科学电子笔记111（2005）161图四、 RIN服务器的内置测试模型服务器的测试用例覆盖例如客户端的注册（测试用例注册）、来自客户端的请求或“旁路”请求（测试用例请求）或释放资源（测试用例释放）。RIN服务器的测试用例集，即测试套件，以及这些测试的执行顺序如图4所示。只有在测试用例注册成功的情况下，才执行测试用例请求和发布。请求测试用例的细节如图5所示。它是从RIN服务器的行为模型导出的，以状态图的形式给出该测试被转换为TTCN-3，并以简化的形式（不提供测试类型和数据信息）在public function getName（）;altstep Default（）在RINClient上运行{[] testPort.getReply {setverdict（fail）;stop} [] catch.timeout {setverdict（fail）;stop;}}testcase Registering（）在RINClient系统RINServer{return（）;//检查先决条件testPort.call（IsInState（waiting），t）{[] testPort.getReply（IsInState（-）：true）{setverdict（pass）}[] testPort.getReply（IsInState（-）：false）{setverdict（inconc}）; stop}[] catch.timeout {setverdict（inconc}）; stop;}}H.- G. Gross等人理论计算机科学电子笔记111（2005）161179图五、 UML风格的序列模型，用于示例测试用例Registering。//主测试体testPort.call（Register（validClient），t）{[] testPort.getReply（Register（validClient））{setverdict（pass）}}//检查结果testPort.call（IsRegistered（validClient），t）{[]testPort.getreply（IsRegistered（-）：true）{setverdict（pass）}}//检查后置条件testPort.call（IsInState（registered），t）{[]testPort.getreply}（IsInState（-）：true）{setverdict（pass）}}}外部函数validClient（）用于检索信息从环境中找到一个有效的客户测试用例Registering可以由Client内置测试组件执行（运行于），并测试RINServer组件（系统）。它最初激活一个默认值来处理所有服务器没有响应或没有响应。测试首先检查测试的先决条件，然后通过尝试注册有效的客户端来继续主体。然后，检查结果：客户端是否真正注册，RINServer是否处于注册状态。所有有效执行测试结果都是通过 无效的执行会导致失败。 如果测试的前提条件未满足，将返回不确定结果TTCN-3中的测试足够详细，可以生成可执行代码，180H.- G. Gross等人理论计算机科学电子笔记111（2005）161见图6。 测试执行架构。我们在Java的案例编译后的Java字节码在TTCN-3执行环境中部署和执行。测试执行架构如图6所示。为了能够将测试组件与目标组件连接起来，需要一个符合TTCN-3执行接口TRI [15]和TCI [16，26]的测试适配器。测试适配器使用所谓的连接器在不同的通信中间件（CORBA、CCM、RMI、Siena、UDP等）之间进行调解，这使得适配器对于各种执行上下文中的内置测试组件是通用的和可重用的。适配器实现测试系统的抽象操作（连接、发送、接收、调用、获取等）。对于RIN系统，CORBA连接器用于调用RIN服务器方法。6总结本文介绍了通过使用UML测试概要，以及使用测试和测试控制符号TTCN-3和相应的TTCN-3工具和运行时环境自动执行这些测试，目前，从UML中的系统模型生成测试以及从UML Testing Profile规范到TTCN-3的映射都是手动完成的。未来的工作将考虑通过亲，
我的内容管理
展开
