轻量级粗粒度协调测试设计：通信系统可伸缩性与可视化模型

66《理论计算机科学电子札记》66卷第2期（2002）网址：http://www.elsevier.nl/locate/entcs/volume66.html18页通过轻量级粗粒度协调实现可Tiziana Margaria蒂齐安娜·马加里亚1，2METAFrame Technologies GmbH德国多特蒙德伯恩哈德·斯特伦2多特蒙德大学德国多特蒙德摘要我们提出了一个解决问题的系统级测试的功能复杂的通信系统的轻量级协调的基础上。这里的支持方面是采用粗粒度的方法来进行测试设计，这是整个测试环境的可伸缩性的核心。这导致了一个可以理解的建模范式的系统范围内的测试用例，这是足够的工业测试工程师的需求和要求。这种方法是粗粒度的，因为它放弃了系统功能的详细模型（这在考虑的工业环境中是不可行的）。协调是轻量级的，因为它允许基于功能的粗略模型对系统级行为（在这种情况下是复杂的测试用例）进行无编程定义。这些功能使测试工程师能够图形化地设计复杂的测试用例，此外，甚至可以通过模型检查自动检查其预期目的1介绍通信系统的系统级测试对于所有利益相关者（技术提供商、服务提供商和依赖这些系统作为其业务基础的客户公司）来说本质上是业务关键问题。这也是一个非常复杂的问题，因为它涉及到各种技术异构的子系统。虽然单元测试1 电子邮件：TMargaria@METAFrame.de2电子邮件：{Tiziana.Margaria，Bernhard.Steffen}@ cs.uni-dortmund.de2002年由ElsevierScienceB出版。 诉 操作访问根据C CB Y-NC-N D许可证进行。马加里亚、斯泰芬67虽然每个子系统的测试都是可用的，但仍然缺少一种集成的方法：系统级测试必须几乎完全手动设计和执行我们在这里提出了一个基于协调的综合测试环境，实现了在西门子的商业，国家的最先进的计算机电话集成系统的情况下，复杂的系统级测试的高层次的协调。这里的核心方面是采用粗粒度的方法来进行测试设计，这对于整个测试环境的可伸缩性至关重要。这使得一个可理解的建模系统范围内的测试用例，足够的工业测试工程师，这是基于一个轻量级的coordination模型。这些功能使测试工程师能够图形化地设计复杂的测试用例，此外，甚至可以通过模型检查自动检查它们的预期目的。在下文中，我们介绍了具体的应用场景（第2节），描述了我们基于协调的可伸缩性方法（第2节）。3到5），涉及测试用例设计、测试执行和通过粗粒度模型检查的验证。最后，我们将讨论相关工作（第6节），并在结论（第7节）中对益处和当前前景进行评论2CTI系统级测试实践应用领域涉及计算机电话集成（CTI）系统，即复合（对平台方面敏感）、嵌入式（由于硬件/软件协同设计实践）、向多个客户端提供高可用性服务的反应式系统，因此其在分布式架构（例如客户端/服务器架构）上运行。 支持的功能包括 目前，支持LAN的中档电话交换机与各种第三方（通常是客户端-服务器）在PC上运行的应用程序之间的协作。WAN功能和移动电话的集成预计将用于下一代交换机，因此它必须在概念上被当今的环境所捕获。在任何安装的场景中，复杂的子系统都以各种不同的方式相互影响，因此要掌握当今电话系统的测试场景，需要一种集成、开放和可扩展的方法来支持整个测试过程的管理，从测试的规范和设计到测试的执行和测试结果的分析。作为一个典型的例子，一个集成的CTI平台，图。1显示了中档电话交换机及其环境。该交换机连接到ISDN电话网络，并通过LAN直接通信，或通过应用服务器与运行在PC上的CTI应用程序间接通信。与电话一样，CTI应用程序也是有源组件：它们可以激励交换机（例如发起呼叫），并对交换机发送的激励做出反应（例如通知来电）。系统级测试研究这些子系统之间的相互作用. 通常，每个参与的子系统都需要单独测试马加里亚、斯泰芬68测试协调员LANV.24伊佩尔蒙呼叫中心客户UPNS0呼叫中心服务器Fig. 1. 集成CTI平台工 具 . 在 图 1 的 场 景 中 ， 需 要 三 种 不 同 的 测 试 工 具 ： 电 话 ） ，Hipermon[6] ， 一 个 电 话 和 LAN 接 口 跟 踪 器 ， 以 及 RationalRobot[14]，一个GUI捕获/重放测试工具，用于位于应用PC上的应用程序。因此，为了测试由几个相互通信的独立子系统组成的系统，必须能够在异构平台的上下文中协调一组异构的测试工具。这项任务超出了当今商业测试管理工具的能力传统的基于形式化方法的测试自动化方法在这种情况下无法进入实践，因为它们需要所涉及系统的细粒度形式化模型作为基础。实际上，没有一个描述的子系统有任何正式的模型，但都有一个运行的参考实现，它本身是一个移动的目标，但事实上构成了所有功能和回归测试活动的基础。因此，我们需要一种能够在现有的快速发展的黑盒或灰盒实现之上开发正式协调层的方法由于被测系统的灰盒/黑盒可用性，因此协调必须是粗粒度的。由于系统的快速发展（周期为一周到三个月），协调必须是非常轻量级的：一旦子系统发生变化，就没有希望拥有“重新编程”新测试用例的资源适应和改变必须很容易马加里亚、斯泰芬69测试协调员（设置）伊佩尔蒙开关胡西姆RationalRobot呼叫中心代理UPN器械例外测试协调员（评估诊断）图二. ITE环境和编程自由。 总的来说，这定义了• 测试工程师习惯于认为，• 可以容易地组成和维护测试用例和测试套件• 测试场景可以被配置和初始化，• 关键的测试用例一致性要求（包括版本兼容性和可执行性的框架条件）很容易制定，• 必须进行错误诊断。2.1作为叠加的部署在西门子的ITE（集成测试环境）包含一个专用的测试协调器（TC），见图。构成系统的1个工具马加里亚、斯泰芬70ITE的测试管理、组织和协调层。TC是一个针对现有通用环境测试领域的 应 用程 序 特 定 专业 化 ， 用 于 管理 复 杂 的 工作 流 程 （METAFrameTechnologies的Agent Building Center ABC [18]）。 ABC操作器内置了免编程协调和功能组件库管理功能。该平台也构成了新版本ETI（电子工具集成平台）的基础[17，2]。测试协调员负责定义和执行叠加在被测系统上的复杂行为。挑战恰恰在于如何以一种独立、可理解和可管理的方式处理这种叠加：• 它应该有足够的表达能力来捕获协调任务，例如操纵测试工具、测量响应以及在系统级测试用例• 它应该是非侵入性的，即，我们不能强迫改变子系统的代码，这既是出于经济原因，也是缺乏可行性：大多数应用程序都是完全的黑盒。• 它应该是直观的和可控的，而不需要编程技能。这意味着我们需要一种轻量级的，可能是图形化的协调定义方法，并且应该可以轻松及时地验证协调模型。在我们的解决方案中，我们采用了一种粗粒度的方法来建模系统的行为，该方法考虑了所需的简单性，并允许模型的直接动画以及通过模型检查进行验证3粗粒度系统模型实例化TC以覆盖工具或CTI应用程序包括设计一组应用程序特定的测试块，这些测试块覆盖应用程序的相关行为，并在测试运行期间执行。测试块体现了子系统的粗粒度功能，其实现没有进一步正式描述。它们构成了系统的计算核心测试设计人员使用这些测试块，通过在TC画布上拖放来图形化地构造测试用例。由此产生的测试图可以直接在现场的系统上执行，同时，它们构成了通过模型检查进行验证的正式模型。图2显示了一个典型的测试图，它说明了场景的复杂性。每个测试块都标有其控制的子系统的名称。一些测试块直接控制被测子系统（例如初始化开关时），而另一些测试块控制相应的测试工具。很容易看出，即使这个相对简单的测试用例也需要访问几乎所有马加里亚、斯泰芬71图1的测试场景的参与者以不同的方式，并且即使对于小的配置（只有一个PC应用程序），当前的手动协调实践也必须需要专业人员，是繁琐的，耗时的，到目前为止还不是详尽的，并且容易出错。ITE测试协调员的主要目标是将测试工程师从以下手动活动中解放出来：• 通过在很大程度上自动化测试块生成来编程测试块，以及• 通过自动协调执行（初始化、执行、分析和报告）来执行系统级测试。为了设计适当的系统级测试用例，有必要知道系统提供了什么功能，如何操作系统（以及相应的测试工具），以便刺激功能，以及如何确定功能是否工作。这些信息由测试专家收集，在识别系统的可控和可观察接口后，将我们的粗粒度的方法允许测试工程师捕捉这些用户级的测试活动直接在协调级别的可执行测试块。3.1ITE组件模型ITE有一个非常简单的组件模型：(i) 表征块的名称(ii) 描述工具、子系统或测试用例专用块的类–报告生成），(iii) 一组形式参数，使块的更一般的用法（例如电话ID），(iv) - 一 组 分 支 ， 其 根 据 测 试 块 执 行 的 结 果 （ 例 如 ， 对 于CheckAgentLabel块，等于或不等于）来引导测试执行的流程，以及(v) 以协调语言编写的执行代码，通常用于包装实现功能的实际代码。很容易看出，该组件模型的名称、类、形式参数和分支提供了组件的非常抽象的表征，稍后将使用这些表征来检查协调图的一致性。计算部分被封装在执行代码中，执行代码独立于协调级别，因此它被编写（或者，如在本申请中，生成）一次，然后在不同的场景中重复使用（例如，测试几个CTI应用）。马加里亚、斯泰芬72图3.第三章。分类法片段作为SIB调色板）3.2形式化测试用例模型测试用例由基本模块组成，称为SIB（服务独立构建块）。这些SIB的复杂性范围从基本语句到引导路由或应用程序机器的相对较大的过程。在我们的测试设计环境中，它们根据分类法进行分类，这反映了它们的基本特征。分类法是有向的非循环图，其中宿表示SIB，SIB是分类法中的原子实体，并且其中中间节点表示组，组是满足某些基本属性（表示为谓词）的模块集合。图图3显示了我们的分类法的一个片段，它是由ITE测试用例编辑器呈现的。它显示了SIB调色板的两个快照：在左边，我们识别出例如用于互联网操作（web）和用于操纵测试工具RationalRobot（SQA- Common）的组，在右边，我们看到用于电话活动（GUICommon和Phone）的组。马加里亚、斯泰芬73测试用例内部建模为Kripke结构，其节点代表基本SIB，其边缘代表分支条件：定义3.1测试用例模型被定义为三元组（S，Act，T rans），其中• S是可用SIB• Act是可能分支条件• Tranns={（s，a，sJ）}是一个变迁集，其中s，sJ∈S，a∈Act.通过这种非标准的抽象在我们的模型中，我们得到了一个分离的关注面向控制的协调层，其中测试工程师不与实现细节，而设计或评估测试用例的困扰，和底层的面向数据的通信机制，anisms之间的参与子系统，这是隐藏在测试块实现。我们的工具支持自动生成根据几种通信机制（CORBA [10]，RMI [19]和其他更特定于应用程序的机制）的测试块，如[11]所述。3.3测试块库西门子在很短的时间内就以这种方式建立了一个测试块库，涵盖了代表和实现的测试块，例如：（参见再次FIG.2和3）：共同行动：测试工具、系统组件、测试用例和一般报告功能的更新，特定于交换机的操作：具有不同扩展的交换机，呼叫相关操作：通过PBX网络发起和接听呼叫， 本地交换机，CTI应用程序相关操作：通过图形用户界面操作CTI应用程序的其他操作代理的登录/登录、建立会议方、通过GUI发起呼叫或检查GUI元素的标签。3.4生成测试块这种简单而结构良好的构件模型使得可协调构件的自动生成成为可能。在这个应用领域中，只有少数组件是由直接编程的代码生成的（在某些专有工具或API的某些脚本语言中，例如用于与Hipermon通信）。大多数组件直接从实验期间的行为记录中获得（例如，来自Rational Robot的通信“答案”的主体大多数测试块的一般结构实际上是相似的：用某种典型的propri- etary语言编写的参数化测试脚本必须传输到子系统或其测试工具，或从子系统或其测试工具传输。我们提供了自动生成工具专用适配器代码的工具，马加里亚、斯泰芬74从这些测试脚本中生成合法的测试块。因此，新测试块的定义相当简单：现场的测试人员记录执行某些操作的GUI测试脚本，测试工程师如上所述定义抽象组件，脚本代码自动包装到一个测试块，可以直接提供给测试工程师，他们图形化地构建新的测试用例。4ITE的协调组织我们在ITE中定义协调所需的一切已经由 测试用例模型以及每个测试块的可执行代码。我们用于描述测试用例的图结构也定义了可执行代码上的协调序列的叠加，因此它独立于所选择的通信范式和底层编程语言。4.1框架ITE的协调环境基于底层Agent Building Center工具（ABC）中的应用程序开发范式，该工具是面向协调的。在ABC中，应用程序开发实际上由粗粒度级别上的构建块的面向行为的组合组成构建块是在功能的基础上识别的，应用程序专家可以理解，并且通常包含许多“经典”编程单元（无论是过程，类，模块还是函数）。它们被组织在特定于应用程序的集合中。与（其他）基于组件的方法相反，对于面向对象的程序开发，ABC集中在动态行为上：（复杂的）功能被图形化地粘在一起，以产生在控制方面体现应用行为的类似于图的结构。在整个面向行为的开发过程中，ABC操作员通过模型检查（第5节）访问用于验证约束库的机制。模型检查器单独检查数百个通常非常小的应用程序和特定目的的约束，这些约束都是在流程图结构上进行的。这允许在违反约束的情况下提供简洁和可理解的诊断信息（见图1）。5），因为反馈是在协调图上提供的，即在应用程序级别而不是在代码上。这些特点是根据不同专业知识水平分配劳动力的关键。编程专家：他们负责软件基础结构、编译服务的运行时环境以及单个构建块的编程。领域建模专家：他们对构建块进行分类，马加里亚、斯泰芬75配位序列协作指令均匀......协调层工具专用图层HLL函数调用HLL从呼叫(A)（B）见图4。 ITE情景通常根据技术标准，如其版本或特定的硬件或软件要求，其来源（在哪里开发），最重要的是，根据其对给定应用领域的意图。由此产生的分类方案是根据模态公式进行约束定义的基础应用程序专家：他们通过定义协调结构来开发具体的应用程序这在没有编程的情况下就发生了：它们以图形方式将构建块组合成粗粒度的流程图。这些协调图可以通过解释器立即执行，以验证预期的行为（快速原型）。模型检查保证了构造图与约束库的一致性。4.2测试场景在ITE中，测试用例扮演着应用程序在ABC中扮演的角色，我们能够利用开发环境带来的所有好处：特别是，设计环境提供了设计层次化测试用例的能力，解释器为测试用例的执行提供了有效的机制。4.3测试用例执行ITE中测试用例执行的一般原理如图所示4（A）。从协调的角度来看，测试用例模型被解释为协调图，其中实际执行的协调序列（图中的路径）在运行时由实际测试块的执行结果确定。在图1的具体测试案例2、支化确定协调规范协调图通过测试结果进行协调顺序序列解释器HLL指令集成组件委托执行HLL口译员输入数据输出数据工具适配器CORBAIDLCorba/Java RMI工具HLL解释器马加里亚、斯泰芬76通 过 检 查 点 的 结 果 （ 即 checkA-gentLabel 、 upnCheckDisplay 和checkWindow）在协调级别上进行检查。协调序列通过序列解释器（跟踪工具）执行：对于每个测试块，它将执行委托给相应的执行代码。这反映了我们将协调和计算分离的策略：它体现了组件代码上的协调叠加工具间通信通过函数调用的参数传递和工具功能调用来实现，函数调用通过它们的参数将抽象数据传递到封装底层功能的适配器，如图4（B）所示。这些功能可以通过Corba或Java RMI机制访问。 在系统级测试的具体设置中，测试工具是测试脚本，可以通过相应的测试工具将其传递给子系统（委托堆栈原则）。我们基于协调的测试环境的实际影响超出了我们的预期：ITE已经成功用于基于西门子HICOM系列交换机的先进CTI应用的工业系统级测试[11，5]。在这样的场景中，我们已经能够完全自动化测试用例的执行，并在测试执行阶段记录超过30个因素的效率改进[12]。5模型检测辅助测试用例设计在[13]中，我们提出了我们解决方案的一些务实的面向验证的方面：我们展示了基于组件的测试设计是如何在一个基本的（但直观上可以理解的）测试用例片段（测试块）库的顶部引入的，我们还展示了测试设计的正确性和一致性是通过模型检查在ITE中完全自动执行的。这种方法对测试用例设计和文档编制效率的影响在工业应用场景中是显著的。ITE包含基于以下技术的迭代模型检查器[16]：它被优化用于处理大量的约束，以便实时验证。具体地说，该算法验证给定模型是否满足以用户友好的、类似自然语言的宏语言表达的属性。在CTI设置中：• 这些属性表示目标CTI服务或测试用例本身需要遵守的正确性或一致性约束• 这些模型直接是协调图，其中构建块名称对应于原子命题，分支条件对应于动作名称。图2和图5示出了用于说明的典型测试图约束的类别根据应用领域形成，以马加里亚、斯泰芬77图五. ITE环境子系统，以及它们所服务的目的。这样，它就取决于全局测试目的，即哪些约束被绑定到测试用例。35.1逻辑地方限制。在新测试用例的设计过程中，全面的在线验证捕获了局部和全局约束。局部约束指定了对单个SIB的要求，以及它们的可接受的稍后参数化。虽然单个SIB的指定是简单地通过在分类法中表达的谓词上的谓词逻辑来完成的，但是参数化条件是根据相应谓词的库来制定的。局部约束的验证在验证3无法获得出版机密材料的许可，系统各部分的实际实现，包括复杂的测试用例和特定的约束。马加里亚、斯泰芬78∈∈全局约束。全局约束：时间方面。全局约束允许用户指定SIB之间的因果关系、可能性和其他重要关系，这对于保证测试用例的格式良好性、可执行性和其他框架条件是必要的。测试用例属性是全局的，如果它不仅涉及测试用例模型4中SIB的直接邻域，而且还涉及可能是任意距离的并且被任意异质子模型分隔的SIB之间的关系。需要对全局属性进行处理，以便捕获设计人员关于测试用例设计的做和不做的专业知识的本质，例如，哪些SIB是不兼容的，或者哪些可以或不可以在一些其他SIB之前/之后发生。这样的属性很少是直接的，有时它们被记录为厚厚的用户手册中的异常，但更多的时候它们根本没有记录，并且已经被发现为以前开发的测试用例的错误。专家们多年来积累的这种特定领域的知识特别值得以包含在设计环境中进行自动重用。在ITE中，这些属性被收集在一个约束库中，该库可以很容易地更新，并且在验证期间由模型检查器自动访问。全局约束在模态μ演算[9]中内部表达下面的无负语法定义了正范式的μ演算公式。它们与完整的模态μ演算一样富有表现力，但允许更简单的技术开发。Φ：：= A|X|Φ ∧ Φ |Φ ∨ Φ |[a]Φ |⟨a⟩Φ| VX. Φ |µ X。Φ在上面，一个Act和X Var，其中A由SIB分类法给出，Act由分支条件库给出，Var是一组变量。定点运算符νX和μX在通常意义上将公式中X属性由封闭公式指定，即不包含任何自由变量的公式是相对于一个固定的标记的过渡系统解释环境e：Var→2S。形式上，mu演算的语义由下式给出：[[X]]e=e（X）[[Φ1<$ Φ2]]e=[[Φ1]]e<$[[Φ2]]e[[Φ1<$ Φ2]]e=[[Φ1]]e<$[[Φ2]]e[a]Φ]] e={s|J.s→asJ<$S J∈[[Φ]]e}4即，沿着模型中的所有路径的SIB的所有前导/后继的集合马加里亚、斯泰芬79∈ A⟨ ⟩ ⟨ ⟩∨∧[[aΦ]]e={s|J.s→asJ<$S J∈[[Φ]]e}X. Φ]]e={SJ<$S|SJ<$[ [Φ]]e[X <$→SJ]}[[µX.Φ]]e={S}|SJ<$[ [Φ]]e[X <$→SJ]}直观地，语义函数将公式映射到公式为“真”的状态集。因此，如果s在A的赋值中，则状态s满足A，而如果s是在e中与X绑定的集合的元素，则s满足X。命题结构以通常的方式解释：s满足Φ1如果满足Φ i和Φ 1之一，则为Φ 2Φ 2，如果满足他们构造a和[a]是模态算子;s满足aΦ，如果它有一个a-导数满足Φ，而s满足[a]Φ，如果它的每个a-导数满足Φ。注意，v X的语义。（二）① ① ② ③ ④ ④ ⑤。Φ）基于塔斯基定点定理[Tars55]：其含义被定义为状态集的幂集上连续函数的最大（对偶，最小）定点。在这个项目中，我们提供了一个简单的LTL的“糖”版本，它被翻译成模态μ演算用于模型检查。这里，重要的是为时态操作符提供一种自然的语言感觉。正如下面的例子所指出的，标准逻辑连接器被证明是没有问题的。我们省略了next的正式定义，一般来说，最终，直到这里，因为它们是标准的。此外，我们还实现了一个模式驱动的公式编辑器，进一步简化了约束库的扩展。5.2表示测试用例属性约束库还根据约束所解决的主要目的来构造。合法测试用例：此类中的约束定义了正确测试用例的特征，独立于任何特定的测试系统和测试目的。具体而言，测试意味着对运行wrt进行评估。通过判定完成预期观察，通过通过和失败的谓词表示。例如，为了实现结果的自动评估，裁决点应该沿着每条路径以非模糊和非矛盾的方式布置，其表达（以更用户友好的语法）如下：（通过了，失败了）下一个（通常是<$（通过了，失败了））POTS测试用例：这些约束定义了普通老式电话服务（POTS）正确运行的特征，这些特征构建了任何CTI应用程序行为的基础。这一类的具体约束涉及现代电话与最终用户的不同信令和通信通道：通过音调信令，通过显示器发送消息，通过LED发出光信号 例如，它们都必须传达正确和一致的信息。被测系统-特定测试用例：这些约束定义了马加里亚、斯泰芬80被测系统的单个单元（例如单个CTI应用程序或交换机）、相应测试工具及其相互作用的正确初始化和功能。图5示出了这类正确性标准的不匹配的检测。在这里，发现了测试用例定义中的错误配置：在交换机中启动呼叫后，预期出现在呼叫中心代理PC上的窗口的标识符（“标题”）应该在Rational Robot访问之前指定。事实上，Robot（PC呼叫中心应用程序的GUI测试工具）需要此信息，以便检查此窗口是否适当地出现在屏幕上。正如我们在这个例子中看到的，在属性违反的情况下，诊断信息也以用户友好的方式提供：违反的路径是导致突出显示（红色，而不是金色）的Rational Robot测试块的路径，失败属性的口头表述允许测试设计者发现问题，而不需要掌握时间逻辑。6相关工作我们的工作既不同于测试定义和生成的通常方法，也不同于协调社区的通常态度大多数关于电信系统测试自动化的研究集中在基于系统形式模型的测试用例和测试套件的生成上：学术工具，如TORX [21]，TGV [3，7]，Autolink[15]，以及商业工具，如Telelogic Tau [20]，都以自动机或SDL描述的细粒度系统模型的存在为前提，旨在支持生成相应的测试用例和测试集。这种方法以前曾在我们这里考虑的场景中尝试过，但由于不适合当前测试而未能付诸实践 设计实践，特别是因为不存在所涉及系统的任何细粒度形式模型。本文讨论的需求超出了当今商业测试工具的能力。据我们所知，既没有商业工具也没有学术工具为整个系统级测试过程提供全面的支持。我们结合了商业测试工具（在本例中是Rational Robot [14]，Hipermon[6]），这些工具处理所考虑场景的子系统，以捕获全局测试过程。关于协调方法，我们认为最接近我们的是[1]，它提出使用协调契约来促进协调方面的分离，这些协调方面调节对象的交互方式在一个系统中，从对象内部行为的方式。像我们一样，他们主要关心的是支持整个系统的进化方面。在他们的工作中，契约扮演着类似于建筑连接器的角色：它们使这些协调功能成为一等公民，这样就有可能将它们与组件的功能区别对待。合同马加里亚、斯泰芬81基于叠加机制[8]，用于支持系统的动态重构形式。这些机制使契约能够被添加或替换，而无需更改它们所应用的对象。[4]描述了CDE，一个用Java开发协调契约的环境。CDE方法仍然是面向编程的：与我们的协调图不同，契约必须编程，它们（还）不支持宏或层次结构，并且没有合同的自动验证可用。在我们的应用领域，方法的可伸缩性是一个主要的需求！ 它必须适用于具有非常高的回归频率的数百个复杂应用程序的回归测试场景。因此，重要的是，契约（对我们来说，测试用例/协调图是全局契约）• 定义在一个编程自由的方式，• 它们本身在很大程度上是可重复使用的，因为我们协调大的行为，• 等级，以及• 在不同的环境下，通过模型检查验证合同的事实上，测试用例的层次结构和形式验证是ITE环境的重要特征。7结论协调图提供了一种有用的抽象机制，可用于概念建模，因为它们指导开发人员识别和促进作为一等公民的交互，这是驯服系统构建和演化复杂性的先决条件。他们的化身为系统级测试用例的应用程序已经证明了该方法的可行性，更重要的是，它在工业环境中采用的充分性。粗粒度建模对于测试工程师来说是很自然的，他们习惯于系统、测试工具和他们测试的应用程序的面向功能的宏模型。这也与他们先前的做法相吻合。轻量级协调解决了跟踪不断发展的子系统的问题。测试用例的图形化配置被认为是直观的，易于管理的，并首次提供了一种描述系统范围行为的说明性方法。测试用例验证的额外好处是。抽象的需求或约定也被认为是有用的和经济的生产力：它极大地增强了在类似环境中的测试用例的重用，并且它允许快速调试新的测试用例以照顾改变的环境或设置。我们的合作伙伴相信，下一代交换机（将涉及广泛的网络和移动应用）的可扩展性是触手可及的。马加里亚、斯泰芬82确认这是与G的合作Brune，H.-D. Ide，W.格里克湾Hammelmann，以及A. Erochok（SIEMENS ICN Witten），A.Hagerer，O.Niese和M.Nagelmann（METAFrame Technologies GmbH Dortmund）。引用[1] L. Andrade， J. Fiadeiro， J. 古韦 亚 湾 Koutsoukos ， A. 洛 佩 斯 ， M 。Wermelinger：协调技术为基础的系统，出现在集成设计和过程技术，IDPT-2002，帕萨迪纳（CA），2002年6月，社会设计和过程科学。[2] V. Braun，T.马加里亚湾Ste Etien：电子工具集成平台发表在《亚太科技观察》杂志的“基于互联网的技术转移服务”专题特刊上[3] J. - C.Fernandez ， C. Jard ， T. 杰 龙 角 Viho ： AnEx perceptioninAuplomatic Generation of Test Suites for Protocols with VerificationTechnology，Science of Computer Programming，29，1997.[4] J. Gouveia，G.库苏科斯湖Andrade，J. Fiadeiro：基于协调的进化的工具 支 持 ， Proc. TOOLS 38 ， W.Pree （ ed. ） ， IEEE Computer SocietyPress 2001，pp.184-196。[5] A. Hagerer，T.马尔加里亚岛尼斯湾Ste Escheren，G. Brune，H.- D.IDE：CTI系统的有效回归测试：测试复杂的呼叫中心解决方案，已被《通信年度评论》接受出版卷55，国际工程联合会，芝加哥，2001年。[6] Herakom GmbH，德国，http://www.herakom.de。[7] C. Jard，T.陈文荣：TGV：理论、原理与演算法，2002年整合设计与制程技术国际研讨会论文集，帕萨迪纳，2002年6月。[8] S. Katz：分布式系统的叠加控制结构，ACM TOPLAS 15（2），1993，pp.337-356[9] D. Kozen：Results on the Propositional µ-Calculus，Theoretical ComputerScience，Vol. 27，1983，pp. 333-354.[10] 对象管理组：公共对象请求代理：体系结构和规范，修订版2.3，对象管理组，1999年。[11] O. Niese ， T. Margaria ， A. Hagerer ， M. 纳 格 尔 曼 湾 Ste Escheren ， G.Brune，H.- D. IDE：使用工作流程规范和验证概念的CTI系统自动化测试环境，《通信年度评论》，卷54，Int.工程联合会，芝加哥，2000年。马加里亚、斯泰芬83[12] O. Niese，T. Margaria，A.哈格勒湾Ste Escheren，G. Brune，W. Goerigk，H. D. IDE：CTI系统的自动回归测试，在Proc. IEEE欧洲测试研讨会2001，pp.51-57，斯德哥尔摩（S），2001年。[13] O.尼斯湾Ste Escheren，T. Margaria，A. Hagerer，G. Brune，H.- D. IDE：基于库的系统级工业测试用例设计和一致性检查，FASE 2001，软件工程基 本 方 面 国 际 会 议 ， Genova ， LNCS 2029 ， Springer Verlag ， 2001 ，pp.233-248。[14] Rational，Inc.：Rational Suite描述，http://www.rational.com/products。[15] M.施密特湾Koch，J.Grabowski，D. Hogrefe：Autolink -一种根据SDL规范 自 动 和 半 自 动 生 成 测 试 的 工 具 ， 技术报 告 A-98-05 ， 医 科 大 学 。Lubebeck，Germa ny，1998.[16] B. Ste daughen，A.克拉森湾Klein，J.Knoop，T. Margaria：定点分析机，（特邀论文）CONCUR[17] B. Ste Escheren，T. Margaria，V. Braun：电子工具集成平台：概念与设计，Int.J. STTT（1997）1，Springer Verlag，1997，pp. 九点半[18] B. Ste Escheren ， T. Margaria ： METAFrame in Practice ： IntelligentNetwork Service Design，InCorrect System Design390-415[19] Sun：Java远程方法调用。http://java.sun.com/products/jdk/rmi。[Tars55] A. Tarski：A Lattice-Theoretical Fixpoint Theorem and Its Applications，Paci fic Journal of Mathematics，V.1955年5月[20] Telelogic：Telelogic Tau，http://www.telelogic.com。[21] J. Tretmans，A. Belinfante：使用形式化方法进行自动测试，在EuroSTAR