基于模型的测试及抽象层次选择

理论计算机科学电子笔记116（2005）59-71www.elsevier.com/locate/entcs基于模型的测试的抽象1Wolfgang Prenninger和Alexander Pretschner2在这一点上，TechnischeUiversitMunchenBoltzmannstr.3，85748 Garching，德国摘要基于模型的测试的思想是将显式行为模型的I/O行为与被测系统的I/O行为进行比较。这就要求模型是有效的。 如果模型是SUT的简化，那么检查模型并将其用于随后的测试用例生成比直接检查SUT更容易。在这种情况下，不同的抽象层次必须被桥接。毫不奇怪，经验表明，选择正确的抽象级别对于基于模型的测试的成功至关重要。我们认为，用于指定目的的模型，用于测试生成的模型和用于完整代码生成的模型可能是不同的。本文对不同的抽象进行了分类和讨论。它旨在为那些构建行为模型到测试结束的人提供指导方针。保留字：基于模型的测试、SUT、验证、规范1介绍验证的基本思想是将抽象规范与具体实现进行比较。如果这两个系统是通过形式化的转换系统给出的该规范也可以作为一组属性给出。在这种情况下，形式验证相当于检查实现是否满足这些属性。如果规范和实现1由DFG在优先计划Softspez（SPP 1064），项目InTime内提供支持。2Email：{prenning，prets ch n}@in. 你好。电话：+4989289173071571-0661 © 2005由Elsevier B. V.出版，CC BY-NC-ND许可下开放获取。doi：10.1016/j.entcs.2004.02.08660W. Prenninger，A.Pretschner/Electronic Notes in Theoretical Computer Science 116（2005）59除了技术上的挑战，这引起了两个意见。首先，不清楚一个规范应该有多细。 显然，它必须足够详细，以便在与实现进行比较时产生有意义的结果。此外，它必须尊重客户的要求，即，它必须是有效的。在下文中，我们坚持这样的术语，即验证关注的是根据客户头脑中的需求检查工件，而验证关注的是比较两个或多或少正式的工件。这与比较是否通过数学严谨性实现无关。第二，模型检查和定理证明等技术是在抽象上进行的。这些是以某种形式的形式化的转换系统，或者更一般的行为模型给出的。[3]然后，假设要检查的软件嵌入到一个正确运行的环境中，满足模型中的默认假设。现在，环境可能非常复杂，正式的验证技术无法确保环境是否按照待检查系统中预期的方式运行关键是，像模型检查或演绎定理证明这样的验证技术(Our测试的概念）在实际环境中的实际设备上操作，并且这两种活动都是必要的。基本问题归结为抽象：如果环境没有得到很好的理解，检查系统的抽象是不够的，抽象必须小心使用，以便提供有用的规范。请注意，我们在两种意义上使用术语“抽象”。 一个表示简化的工件或模型。另一个用途是关于建立这种简化的活动。我们在基于模型的测试的背景下解决这些问题。我们对基于模型的测试的理解是，我们使用一个抽象的概念或模型来测试一个具体的实现。抽象模型是简化的，因此它们更容易掌握。因此，验证这样一个抽象模型似乎比验证具体实现本身更容易。一旦模型被认为是有效的，我们使用它自动生成测试用例。这意味着模型的某些轨迹（可能不止一个人可以手动绘制）是自动生成的。必要的选择标准由测试用例规范给出，它与功能、结构和随机测试有关（图1，左;参见[11]）。作为不同抽象层次的结果，这些测试用例不能直接应用于实现。轨迹的输入部分被具体化并应用于实现。实现3在某些情况下，这些抽象可以从代码中自动提取W. Prenninger，A.Pretschner/Electronic Notes in Theoretical Computer Science 116（2005）5961系统环境行为模型测试用例规范验证测试用例复杂性分布验证投入的具体化康尼？产出的抽象系统环境Fig. 1. 基于模型的测试过程然后与迹线给出的模型输出进行比较（图1，底部）。因此，复杂性分布在抽象模型和负责具体化和抽象化信号的组件之间（图1，右）。我们在第二节中引用和讨论的一些案例研究。3符合上述方法。在本文中，我们解决的问题，其中的抽象（在结构化和简化系统的意义上）可以选择到测试结束。这个想法是向基于模型的测试的工程学科迈出的第一步。虽然我们相信测试的抽象类似于代码生成的抽象，但我们认为测试的行为模型不同于代码生成和规范的贡献和组织本文的贡献是一个目录和讨论适用于基于模型的测试抽象。我们还将用于测试目的的模型与开发过程中的其他模型相关联。秒2揭示了基于模型的开发和基于模型的测试的背景下的抽象的性质。秒3篇综述了文献中使用的测试摘要。秒4讨论了不同抽象的局限性，和SEC。5结束相关的工作在各自的背景下引用。62W. Prenninger，A.Pretschner/Electronic Notes in Theoretical Computer Science 116（2005）592抽象可以说，抽象是计算机工程师拥有的最重要的工具。它的目的是简化一个复杂的问题或系统。简化发生在w.r.t.一定的目标，无论是分析，生成，或通信的基础。同样，我们在这个意义上，Stachowiak [13，p.131-132]确定了模型的三个特征：映射模型是某个东西的模型，简化模型并不捕捉它们所代表的原始属性，实用模型并不是在一个独特的意义上与相应的原始模型相关，而是满足某些目标。模型是图像或原型。在下一节的测试中，在转向一些具体的抽象之前，我们以更一般的方式讨论抽象的作用。在本文中，我们可以自动抽象模型层次的系统描述比详细实现层次的系统描述包含的信息少得多今天最成功的抽象技术是基于编译器或库，它们通过依赖某种形式的宏机制来支持模型到实现的自动转换。比如说，• 过程从编程语言中的具体堆栈框架中抽象出来，• Java中的Swing-API从以前编程GUI所必需的过多指令中抽象出来，• ISO-OSI模型从通信细节中抽象出来--较高层上的指令对应于较低层上的复杂交互，• J2EE和Corba是从各自的编译器插入的通信细节中抽象的进一步示例。域名规格可由编译器和链接器解决的抽象间隙或多或少特定于域。虽然过程的概念对所有编程语言都是通用的，但Swing API仅限于GUI编程领域，ISO-OSI堆栈适用于通信，MDA可以说是与商业信息系统而不是嵌入式实时系统有关。开发抽象技术无疑是最具挑战性和要求最高的任务之一，这些技术或多或少是特定于领域的，并且可以使用编译器、链接器等自动转换到具体级别。W. Prenninger，A.Pretschner/Electronic Notes in Theoretical Computer Science 116（2005）5963实际上缺少信息在模型中有一些抽象不能被编译器自动解析，但仍然是有用的。 在系统中有一种固有的复杂性，它不能仅仅通过语言/编译器来简化和抽象--这是布鲁克斯流行的说法的一种变体，复杂性是一种本质而不是偶然的属性[3]。很明显，从结构化抽象（架构）中不可能生成完整的代码，这也适用于许多已经构建到定义明确的目的的行为抽象。例如，Philipps和Pretschner [11]描述的芯片卡模型集中于协议流和文件内容的摘要以及操作对它们的影响。为了保持模型的可管理性，这些信息并没有包含在模型中。如果没有进一步的信息，静态编译器就不能将抽象文件实例化为具体文件，并随时间动态演化。显然，这并不意味着领域特定语言不能存在，其中实际上缺失信息的另一个例子是，一些模型从具体的时间行为中抽象出来。编译器的静态翻译通常不能在具体级别上实例化实现的最多样化的定时行为。目的总之，抽象以两种形式出现。它们可以是可以自动插入缺失信息的简化，也可以是故意缺失信息以保持模型简单的简化。简化往往是特定于领域的，基于模型的开发的最终目标似乎在于找到适用于给定领域的所有系统的抽象。从某些细节中抽象出来只有在心中有一个给定的目的才有意义。不同的抽象用于不同的目的。抽象的目的是（a）获得或增强系统的知识-这需要对模型及其环境进行经由库调用或与外部组件或服务的绑定），（d）开发者之间的通信，（e）代码的生成，以及（f）测试系统。基于模型的测试基于模型的测试利用了两种抽象，一种涉及实际的信息丢失，另一种不涉及。如果一个（行为）模型在测试结束时使用，那么它必须是有效的。也就是说64W. Prenninger，A.Pretschner/Electronic Notes in Theoretical Computer Science 116（2005）59必须是忠实形象的要求。现在，如果模型包含足够的（生产）代码生成信息，那么验证模型很可能与直接验证没有模型的实现一样消耗资源。原因是在这些条件下，建模语言实际上是编程语言。当模型能够被智力掌握或自动分析时，它们就变得有用了，如果它们没有系统那么复杂--如果它们是实际的抽象的话--通常就是这种情况。如果只想测试系统的某些部分，那么可以从模型中忽略其他部分。例如，这是上述芯片卡的文件系统的情况。然而，并不是所有的简化都是通过省略系统功能的整个部分来定义的在芯片卡的例子中相反，它们是以一种外部驱动程序组件可以插入缺失信息的方式进行抽象的。因此，模型很简单，但它太简单了，不能直接用于测试。 在这种情况下，丢失的信息因此不是由编译器或链接器插入，而是由驱动程序组件插入。测试模型和规格模型开发中的系统往往由规范文档描述，这些文档是全面的，但非正式的、不完整的，有时是模糊的。从理论上讲，人们希望有一个-可能是可执行的-和完整的规范模型，全面，精确和完整地规范系统。该规范模型可以作为测试用例生成的基础，最终验证规范和实现之间的一致性。现在，现实世界的规格变得非常大，以至于构建和维护包含所有规格方面的规格模型的成本太高-这些模型已经构成了原型实现。为了解决这个难题，除了非正式和不完整的规范之外，还建立了测试模型。测试模型将全面的规范简化为抽象、完整、明确地实现的关键部分。究竟哪些部件或方面对测试至关重要，这取决于工程经验。通过抽象地指定关键部分，例如，对于那些经验上容易出错的模型，在相当小的测试模型中，人们可以获得小的和可管理的模型的优点。另一方面，可用于完整产品代码生成的模型可以被视为实现，并且从同一模型中提取代码和测试用例是一种可疑的努力W. Prenninger，A.Pretschner/Electronic Notes in Theoretical Computer Science 116（2005）59653应用在本节中，我们将介绍应用于基于模型测试的文献中的不同抽象原则。我们回顾了处理器[5，12，7]，智能卡[11，4]，协议[9，1]，Java和POSIX [6]基于模型的测试案例研究，并考虑了相关工作[2，10，8]。 我们发现五个原则：功能、数据、通信和时间抽象。这些原则并不总是能清晰地区分开来，因此它们常常被结合起来应用。下面的概述可以作为建模者的参考，他们面临着寻找足够的抽象的挑战性任务，这些抽象反映了SUT模型的关键部分，反过来，这些抽象又可以作为验证SUT行为的参考。用于测试时，以下所有抽象都涉及信息丢失，因此只能测试指定的部分。3.1功能抽象功能（或行为）抽象的目的是集中于必须验证的SUT的“主要”功能。这导致模型中省略了不属于验证任务重点的繁琐细节。4通过这样做，模型通常只实现规范文档中确定的完整行为的一部分，即，该模型并未完全定义SUT的预期行为，而仅对重要方面进行建模换句话说，该模型指定了受约束环境下SUT的行为此外，功能抽象支持基于模型的测试过程：如果SUT函数抽象[11]中描述的案例研究集中于测试智能卡与其环境（终端）之间的协议。因此，该模型从智能卡实现的所有密码功能的复杂实现中抽象出来。这些函数和它们的响应只是通过在发出命令encrypt（data）时产生类型为data_tedData的数据来象征性地表示。在模型中不执行密码计算。相反，这些计算是在驱动程序组件级别执行的（见上文）。4这并不一定意味着特殊情况被忽略-如果这些情况必须被测试，它们必须被建模。66W. Prenninger，A.Pretschner/Electronic Notes in Theoretical Computer Science 116（2005）59[6]中描述的方法使用单独的模型来测试POSIX标准的不同功能。第一个模型是为了测试字节范围锁定接口fcntl而开发的。该接口提供对打开文件的控制，以便处理正在访问文件的进程该模型通过只允许一次文件扩展来限制POSIX 标准。本文提到了第二个模型， 它是为测试POSIXfork（）操作而开发的。SUT行为的部分建模的其他示例是，模型不确定其在某些输入值的某些状态下的行为，或者模型完全从异常处理中抽象出来。3.2数据抽象数据抽象的思想是将具体的数据类型映射到逻辑或抽象的数据类型，以便在抽象级别上实现紧凑的表示或降低数据复杂性。一个经常被引用的数据抽象的例子是在抽象层用整数表示二进制数。然而，这个例子只改变了数字的表示，但不会导致抽象层次之间的任何信息丢失。一种常见的信息丢失数据抽象技术是在模型中只表示具体数据值的等价类。涉及信息丢失的示例如下所述如上所述，数据抽象的关键由于抽象数据类型用于指定模型的对象，因此一个测试目标是SUT对具体值执行的操作相对于模型中抽象值的（抽象）操作正确实现。数据抽象在 [5] 中 ， SUT 是 数 字 信 号 处 理 器 （ DSP ） 的 存 储 数 据 单 元（SDU）DSP的行为很大程度上取决于SDU队列的填充级别因此，队列的状态在模型中由抽象数据类型空、有效、准满或满表示。然后测试发现了SUT中的一个性能错误，因为原来SDU只将其队列填充到准满状态，而没有利用队列的全部容量智能卡测试文件的根本抽象[11]如上所数据抽象的另一个例子可以在[12，11]中找到。在那里，操作数的数据类型被抽象为模型中使用的等价类。对于测试用例实例化，这些符号操作数被替换W. Prenninger，A.Pretschner/Electronic Notes in Theoretical Computer Science 116（2005）5967随机选择或通过配置文件确定的具体值。数据抽象通常是由函数抽象驱动的。Hudak等人描述了一个网络系统[8]。在具体层次上，网络包由目的地址、源地址、消息体、校验和等组成。功能抽象由验证路由机制的目标决定。因此，通过忽略包的其他内容，网络包的内容被简化为抽象级别的目的地地址和校验和。3.3通信抽象通信抽象原则最突出的应用是ISO-OSI参考模型。在这里，具体级别上的复杂交互被抽象为更抽象级别上的一个操作或消息。在抽象层次上，这个操作被原子地处理。这是即使在一般情况下，在具体级别的相应操作可以与其他操作交织。使用这种抽象原则，可以将握手交互或因果相关操作序列聚合为抽象级别上的一个操作。对于测试用例实例化，这些抽象操作可以简单地由相应的交互来代替。对于构建模型，通信抽象通常与功能抽象相结合通信抽象在硬件验证[2]和处理器测试[5]中，引脚值的具体聚合、不同总线的几个连续信号或处理器指令的循环序列被抽象为模型中的一个符号操作。在协议测试[9]中，关于同一事务的因果相关操作被折叠成模型中的一个原子操作，尽管具体表示可以被其他操作中断有时通信抽象与数据抽象相结合：在[11]中，智能卡的具体字节串命令（由十六进制数序列表示）被抽象为智能卡模型中的符号和人类可读消息。3.4时态抽取时间抽象的思想是，只有事件的排序与建模有关，即，在具体层面上，68W. Prenninger，A.Pretschner/Electronic Notes in Theoretical Computer Science 116（2005）59被视为无关。我们认为抽象的某些事件的顺序是不相关的，作为通信抽象的偏序约简一种时间抽象是模型和SUT使用不同的离散时间粒度。那么抽象层次上的时间粒度要比具体层次上的时间粒度粗。理想情况下，给出抽象时间步和较低级别时间步的对应间隔之间的映射。这可能是一项具有挑战性的任务，因为在许多情况下，一个抽象的步骤并不总是对应于具体层面上的恒定或可预测的时间间隔。这种形式的时间抽象通常用于硬件验证和测试[5，12，2，10]，通过将模型中的一个时钟周期与实现级别的许多时钟周期相关联。时间抽象可以有效地与通信或/和功能抽象相结合时间抽象的另一种形式是模型从物理时间中抽象出来。例如，具体实现可以取决于使用250 ms持续时间的定时器。该定时器在模型中被抽象通过引入两个符号事件一个用于启动定时器，一个用于指示定时器的期满。通过这样做，即使某些定时器的持续时间在具体级别上随运行时而变化，也可以抽象出定时器的物理持续时间。有人可能会说，这种抽象是更一般的抽象的特殊情况，即从服务质量的抽象。4限制在本节中，我们将阐明在模型中使用抽象来测试SUT行为的局限性和后果。建模者必须意识到这些限制，因此在构建适当的模型来测试SUT的关键方面时，必须在抽象和精确之间做出正确的权衡如第2节所述，真实系统中存在固有的复杂性。 如果它们中的一些在模型中被抽象，则没有直接的方法来检测关于这些抽象的SUT中的故障。在下文中，我们提到一些限制和后果。通常情况下，模型或多或少地依赖于一个不同的和隐含的一个典型的例子是，模型假设输入消息或输入操作的参数在允许的范围内，或者具有允许的长度或数量。在这些模型的帮助下，如果SUT接收到带有非法参数的消息，则不可能测试SUT的行为。例如，在智能卡中，W. Prenninger，A.Pretschner/Electronic Notes in Theoretical Computer Science 116（2005）5969在main中，包含操作数的操作由具体级别的字节串表示在模型中，操作及其操作数方便地由字符串（名称）符号化。利用这种模型，如果智能体接收到例如分别太短或太长的字节串，则不能直接测试由测试工程师决定是在模型级别还是在驱动程序组件级别处理这种非法输入。密集的数据抽象可能导致信息丢失，无法应对测试用例生成。例如，我们回想一下从文件内容中抽象的智能卡模型[11]，已经在第二节中讨论过了。二、在这个模型中，只有像文件长度这样的静态属性，而不是文件内容的动态演变可以被验证。当应用功能抽象来构建用于测试不同功能的单独模型时，例如，在[6]中，使用单独的模型来测试POSIX标准的不同操作这些模型有助于以独立的方式验证这些操作的正确功能，但对这些操作的功能交互引起的无意行为的检测保持开放。最后，如果在模型中大量使用时间抽象，可能会出现问题显然，在分布式实时系统的领域中，严格使用时间抽象可以禁止检测源于单独组件的复杂交错时序行为的故障。作为一个反例，在[5]中，时态抽象显式地不用于测试处理器。为了跟踪生成的测试用例并检查预期性能，模型中的时钟周期与实际处理器设计中的时钟周期完全对应。不管怎样，w.r.t.尽管存在这些局限性，我们相信基于模型的测试是最有前途的方法之一，它将在不久的将来扩大复杂系统的验证规模，并为提高硬件和软件系统的质量提供一个结构良好的请注意，有些人认为测试是基于模型的定义：测试总是以或多或少明确定义的预期行为进行，即，模特5结论软件工程的许多活动都涉及抽象。今天，抽象主要用作语言结构（例如，过程），被转移到运行时环境（垃圾收集器），以库、组件或通信基础设施的接口的形式使用，以及作为体系结构使用。与系统70W. Prenninger，A.Pretschner/Electronic Notes in Theoretical Computer Science 116（2005）59当使用明确的模型时，开始发挥更突出的作用。信息的丢失有时可以用合适的代码生成器或连接器来补偿。对于许多目的，有意识地丢弃不能自动插入的信息也是必要的。对于相当全面的测试，模型通常过于模糊，因为它们只指定部分行为。如果它们更精确，则可以使用到测试结束。如果这些测试模型足够具体，可以从它们生成（生产）代码，那么人们必须问为什么验证模型并从它生成测试用例比直接验证SUT更可取。因此，测试模型的抽象级别介于规范和完整代码生成的模型之间（即，实现本身的忠实一方面，规范以抽象和全面的方式描述了正在开发的系统这通常以非正式和不完整的方式进行。首先需要非正式和不完整的规范来构建测试模型：测试模型是规范的细化。另一方面，测试模型抽象地只实现了更全面的规范的一部分，但这些部分是完全和明确地实现的（功能抽象，参见。秒3）。测试模型可以被视为规范文档的补充，规范文档完全指定了系统的关键部分以进行验证。原则上，规格和测试模型可以在相同的抽象、完整和精确级别上构建，但必须解决是供应商还是OEM构建模型的例如，汽车行业的情况就是如此。我们在文献中提供了一个用于基于模型的测试结束的抽象列表。它们可以概括为与功能、数据、通信和时间（或更一般的服务质量）有关。这个目录的目的是为基于模型的测试人员在构建他们的模型时提供一些指导。我们没有解决选择哪些跟踪（测试用例）的难题，即，测试套件的质量问题。构建适当的模型和识别相关属性似乎是基于模型的测试的是否使用专用的显式测试模型支付经济似乎是可能的，但经验证据仍然缺乏。引用[1] A. Belinfante，J. Feenstra，R.G. de Vries，J. Tretmans，N.戈加湖 Feijs，S. 毛，和L.海林克 正式测试自动化：一个简单的实验。 In G. Csopaki，S. 迪布兹，K.第12届通信系统测试国际研讨会，第179W. Prenninger，A.Pretschner/Electronic Notes in Theoretical Computer Science 116（2005）5971Kluwer Academic Publishers，1999.[2] D. Brahme，S.Cox，J.加洛，M。格拉瑟，W.格伦德曼角Ip，W.Paulsen，J.Pierce，J.罗斯D. Shea和K.怀汀基于交易的核查方法。技术报告，Cadence设计系统公司，2000年8月[3] F.布鲁克斯没有银弹。在Proc.10th IFIP World Computing Conference，第1069- 1076页[4] D. Clarke，T. 我是V。 Rusu，and dE. 我不知道。智能卡应用程序的通用测试和操作系统。在Proc. E-smart，pages 58[5] J. Dushina，M. Benjamin和D. 盖斯特使用Genevieve的半形式化测试生成。在2001年发援会会议[6] E. Farchi，A. Hartman和S.品特使用基于模型的测试生成器来测试标准一致性。IBM SystemsJournal，41（1）：89[7] L. Fournier，A. Koyfman和M.莱温杰开发架构验证套件-PowerPC架构的应用。第36届ACMDesign Automation Conf. 第189-194页[8] John Hudak，Santiago Comella-Dorda，David P. Gluch，Grace Lewis和Chuck Weinstock。基于模型的验证：抽象指南。技术报告CMU/SEI-2002-TN-011，卡内基梅隆大学，2002年10月。[9] H.卡卢什角Viho和M.曾德里高速缓存一致性协议可执行测试套件自动生成的工业实验。以.Petrenko和N. Yevtushenko，编辑，IFIPTC6第11届通信系统测试国际研讨会。查普曼厅，1998年9月。[10] T. 梅尔汉姆用于硬件验证的抽象机制。In G. Birtwistle和P. Subrahmanyam，editors，VLSI Specification，Verification，and Synthesis，pages 129-157，Boston，1988. Kluwer Academic Publishers.[11] J. Philipps，A.普雷施纳岛Slotosch，E. Aiglstorfer，S. Kriebel和K. Scholl. 基于模型的智能卡测试用例生成。第八届工业关键系统形式化方法国际研讨会论文集（FMICS 03），2003年。出现。[12] J. Shen和J. Abraham。一种用于处理器微结构验证和测试生成的RTL抽象技术。J.电子测试：理论应用，16（1-2）：67[13] H.斯塔乔维克 一般模型理论斯普林格，1973年。