建模系统 [0001] 技术领域。 [0002] 本发明涉及用于在测试特别是软件测试中使用的建模系统和相关方法。 背景技术 [0003] 在系统特别是包括软件的系统的开发中，必须例如针对可能的错误、性能和/或功能进行测试。存在用以开展对应的测试的不同的方法。一种方法被称为基于模型的测试(Model-Based Testing，MBT)，其中对被测试系统(System Under Test，SUT)建模以表示该系统想要的特性。MBT使用系统的一般表示，例如使用统一建模语言(Unified Modeling Language，UML)或另外的一般化表示来开发模型和测试，并且提供相关的信息。另一种方法—行为驱动测试(Behaviour-Driven Testing, BDT)使用域特定的表示来描述特定测试场景的测试规范。这样的域特定的表示与一般表示相比通常是更加人类可读的，但是倾向于关注功能并且不太适合覆盖被测试系统的所有区域。 发明内容 [0004] 本发明的目的是提供允许改进的测试的方法。一般地，建议了将基于MBT的方法与基于BDT的方法的要素进行组合。 [0005] 因此，公开了一种建模系统。建模系统包括测试模型创建器。测试模型创建器适于基于集成建模环境来提供测试模型并且考虑域特定的配置文件。建模系统进一步包括测试场景生成器，该测试场景生成器适于基于测试模型来提供多个测试场景。此外，建模系统包括场景翻译器，场景翻译器适于将测试场景翻译成域特定的语言。可以认为该系统实现了基于MBT的方法和基于BDT的方法的组合。 [0006] 还可以考虑用于提供测试场景的方法。该方法包括基于集成建模环境提供测试模型并且考虑域特定的配置文件。该方法还包括基于测试模型提供多个测试场景，以及将测试场景翻译成域特定的语言。可以认为该方法实现了基于MBT的方法和基于BDT的方法的组合。 [0007] 翻译测试场景可以基于域特定的配置文件。因此，相同的配置文件可以是用于提供测试模型和用于翻译测试场景的基础。因此便于一致和高效地使用配置文件。 [0008] 测试模型可以用统一模型语言(UML)表示。一般地，测试模型可以表示被测试系统(SUT)，被测试系统特别是可以包括或者被实现为软件和/或物理系统，例如发电机或发电厂或自动化系统。可以认为测试模型由UML的扩展或扩展的一般语言表示。该方法允许MBT方面和BDT方面的高效组合。 [0009] 建模系统可以进一步包括一个或多个测试单元以用于基于翻译的测试场景执行被测试系统的测试。可替换地或附加地，方法可以包括这样的执行。更可替换地或另外地，该系统可以适于和/或该方法可以包括对SUT或者利用测试场景开发和测试的系统的监控。 该系统可以适于和/或该方法可以包括监控SUT的开发，和/或更新测试模型以及对应地更新测试场景。 [0010] 在一些变型中，该系统可以包括模型分析器。该方法可以包括和/或模型分析器可以适于分析和/或评估测试模型。 [0011] 建模系统可以包括硬件和/或软件和/或固件。特别地，建模系统可以包括处理电路和/或一个或多个接口。处理电路可以包括集成电路，和/或一个或多个处理器和/或控制器，和/或可以包括和/或被连接到或可连接于存储器，所述存储器用于存储与在此描述的功能相关的指令和/或数据。一般地，系统的各个组件和/或部分和/或方法功能可以被分布在不同的设备和/或单元上。可以提供对应的接口以便于这样的设备和/或单元之间的通信。每个设备或组件或子组件可以被关联于和/或实现为对应的模块，特别是软件模块。建模系统可以是计算机系统，和/或可以包括一个或多个计算机。 [0012] 该方法可以尤其是由计算机系统完全或部分地执行的。为此，该方法可以被表述为具有程序代码部件的计算机程序产品。上面描述的系统可以包括计算机系统。该方法的优点或特征可以应用于方法并且反之亦然。 [0013] 一般而言，可以考虑包括如下指令的程序产品：其引起处理电路和/或计算机系统执行和/或控制如在此描述的方法。可以考虑存储对应的程序产品的存储介质。该存储介质可以包括易失性和/或非易失性存储器，和/或可以包括磁介质或光学介质，例如CD-ROM或DVD，或闪速存储器或随机存取存储器或硬盘或固态器件。 附图说明 [0014] 根据参考在随附各图中示出的示例性实施例的以下讨论，将使得更清楚地并且更好地理解本发明的特性、特征和优点以及实现它们的方式。 [0015] 图1示出示例性的创新建模系统。 具体实施方式 [0016] 图1示出示例性的建模系统10。建模系统10可以包括测试模型创建器12，其可以例如利用建模环境14，该建模环境14可以是包括多个工具的集成建模环境。测试模型创建器 12一般可以适于创建被测试系统(SUT)(特别是软件)的测试模型18。该测试模型18一般可以描述和/或表示SUT的一组特性，特别是想要的特性和/或性能和/或功能和/或行为。测试模型18可以表示SUT的一个或多个物理特性。一般地，测试模型18可以被提供在输入上，例如用户输入和/或描述SUT的特性的一个或多个文件和/或数据集。建模环境14可以适于管理输入和/或基于输入来确定模型。测试模型18可以用一般的表示语言(例如UML)来表示。 测试模型创建器12可以基于域特定的配置文件16来提供测试模型18，域特定的配置文件16可以例如被提供为输入和/或可以表示UML扩展。在一些变型中，可以认为创建器12被利用不同的配置文件16配置或者是利用不同的配置文件16可配置的，配置文件16可以特定于不同的域和/或不同的SUT。域特定的配置文件可以涉及SUT的一个或多个域，例如其涉及的技术领域，和/或业务领域和/或用户界面。域特定的配置文件16可以包括和/或指示域特定的术语和/或语言，例如DSL（域特定语言）。测试模型18可以表示和/或包括SUT的建模部分和/或对应接口之间的多个路径和/或一系列相互作用。路径和/或系列的相互作用可以是有条件的。不同的路径或系列可能涉及如由模型表示的SUT的不同反应和/或行为。 [0017] 系统10的场景生成器20可以接收测试模型18作为输入，并且提供测试场景22作为输出。特别是，场景生成器20可以包括模型分析器24，其可以分析和/或评估测试模型18，例如针对完整性和/或整体性和/或覆盖。场景生成器20可以包括项目生成器26，其适于提供来自测试模型18的单独的测试项目。测试模型18可以独立地在项目生成器26和分析器24中输入。分析或评估和/或项目生成可以基于和/或考虑例如路径覆盖和/或数据覆盖。可以认为测试项目涉及测试模型18的一个路径。 [0018] 项目生成器26可以提供输出，例如被传递到场景工厂28的测试项目。场景工厂28可以适于基于测试项目生成测试场景22，其可以是抽象的BDT场景22。工厂28可以被认为是用于测试项目的抽象层，或者被认为是用于对于抽象的BDT场景的测试项目的翻译层。场景 22可以被单独提供或者被分组地提供或者以它们的组合方式来提供。场景生成器20可以基于生成器配置来操作，该生成器配置可以被提供为到其组件中的一个或多个的输入。 [0019] 场景22可以被提供为对系统10的翻译器30的输入。翻译器30可以包括DSL格式化引擎34，其可以接收测试场景22。引擎34可以以域特定语言将测试场景22翻译成BDT场景，例如通过将它们对应地格式化和/或根据DSL规则对它们进行布置，DSL规则可以由DSL规则引擎36指示。DSL规则检查器38可以针对正确性检查引擎34的输出。翻译器30(特别是规则检查器和/或格式化引擎34)可以提供可实现的BDT场景作为输出，其可以采用DSL(例如Gherkin或另外的语言)。翻译器30可以基于翻译器配置进行操作，翻译器配置可以被提供为用于翻译器和/或其组件中的一个或多个的输入。可以认为翻译器30可替换地或附加地可以基于域特定的配置文件16来操作，域特定的配置文件16特别地可以是DSL配置文件。配置文件可以被提供为对翻译器30的组件中一个或多个的输入。 [0020] 应该注意，已经描述了子组件的示例性布置。然而，可以考虑其中以不同的顺序组合或布置子组件的功能的解决方案。例如，可以组合模型分析器24和项目生成器26，和/或可以组合项目生成器26和工厂28。另外，在一些情况下，可以组合生成器20和翻译器30。每个组件，特别是工厂18和/或其下游的组件，可以包括多个子组件，所述子组件可以是例如针对特定的测试项目或场景或其组合而独立地可操作的。例如，可以认为格式化引擎和/或翻译器包括多个子组件，所述子组件可以是彼此独立地可操作的，和/或可以作用于不同的测试场景。在一些变型中，可以组合格式化引擎34和DSL规则引擎36，和/或可以组合规则检查器38和规则引擎36，和/或可以组合格式化引擎34和规则检查器38。可以考虑子组件的对应的组合。 [0021] 可以例如通过基于BDT场景在SUT上运行测试来实现BDT场景32。 [0022] 在此描述的方法对于例如软件的敏捷开发而言是特别有用的。BDT场景一般可以涉及测试模型的有限子集或方面，特别是涉及路径或子路径，例如路径的分支。BDT可以被认为使用可读业务和域特定语言的测试规范来描述系统的行为而不处理如何实现该行为。 [0023] 测试(例如软件测试)一般可以被认为是如下的处理：在发现测试中的系统或软件中的错误的意图下执行程序或应用。测试也可以被称为如下的处理：查验和验证系统(例如软件程序或应用)满足了技术和业务目标、达成了要求并且如期望那样工作。作为结果，可以改进测试的系统或软件的质量，并且可以显著地最小化致命错误的风险。 [0024] 基于模型的测试(MBT)可以被认为是测试规范技术，它利用(测试)模型以便生成测试和其它与测试相关的产物(如测试代码、测试文档等)。建模环境可以以MBT方法为目标。它可以包括一个或多个专用MBT工具。根据本发明，可以组合高级测试技术MBT和BDT。可以使用域特定的语言来拉近这些技术的间隔并且构建用于在敏捷情形下进行测试的新的系统性方法。 [0025] 本发明通过如下来促进更全面的测试：使用MBT方法在建模环境中设计测试模型，其不考虑所意图的系统行为的单个片段而是将系统(SUT)作为整体来考虑。因此，人们能够在场景规范期间实现更全面的覆盖并且降低跳过对于测试而言重要的场景的可能性。可以考虑非功能的测试(性能、可用性、可伸缩性、可靠性、安全性等)。组合BDT和MBT的方法允许在不改变敏捷开发处理中的任何内容的情况下针对非功能的测试建模BDT场景。为此目的，测试模型可以包括一个或多个消息序列图(MSC)和/或通信图，建模环境可以相应地基于这样的消息序列图(MSC)和/或通信图。 [0026] 一旦创建了测试模型，BDT生成器的场景生成器就获得其来作为输入。与数据覆盖算法(例如两个一起、三个一起、n个一起等)组合地使用路径覆盖算法(例如全路径、全活动、全过渡等)，可以提供许多场景，允许高水平的系统化和自动化。可以例如基于评估(例如通过模型分析器进行)模型和/或测试项目和/或测试场景来提供关于在测试期间的所实现的覆盖的可靠语句。 [0027] 使用模型可以减少用于维护和回顾BDT场景的劳力。如果发生改变，则这必须在模型中仅进行一次。所有受影响的场景然后将被自动生成和更新。 [0028] BDT和MBT的组合不仅拉近了BDT的间隔而且还拉近了MBT的间隔。特别是，它允许容易地集成到敏捷开发方法中。在敏捷开发中，产品所有者对被称为Epics (史诗)和User Stories (用户故事)的项目中的工作的部分负责。这些是在所谓的产品待办列表(Backlog)中收集和管理的并且被用作为用于测试设计的输入。然而，来自Epics 和 User Stories的信息经常不足以用于正确的测试。另一方面，MBT是一种不仅用于测试生成而且还用于澄清要求的技术，但是由于缺失对Epics和User Stories的支持，它在敏捷开发处理中的广泛采用受到了阻碍。为了解决该问题并且最好地利用这两方，本发明提出使用模型来提炼Epics和User Stories并且以BDT兼容的DSL语言自动生成场景。因此，MBT方法不仅可以集成到敏捷开发处理中，而且其甚至可以完成敏捷开发处理。这使得能够在不影响开发处理的其它部分的情况下将MBT集成到敏捷开发中。 [0029] 项目中的不同利益相关方之间的协作被通过使他们牵涉到场景定义项目中而得以促进。使用半正式的DSL语言使得非技术人员也容易阅读、理解和回顾场景。因此，相关的非技术利益相关方能够通过回顾和讨论系统的所意图的用途和所意图的行为而被牵涉到测试处理中。这有助于从一开始就避免疑义和不一致。 [0030] 一般地建议了使用基于BDT的注释(分别为域特定的配置文件或语言)来提供测试模型和场景建模和生成。考虑了使用如UML的标准化建模语言来提供模型以用于生成行为驱动的场景，其中场景可以是以DSL提供的。这可以由BDT场景生成器执行，该BDT场景生成器采用使用特定的DSL注释创建的模型作为输入。该注释基本上可以被添加到支持UML的每个建模环境。建模环境可以提供测试建模所要求的所有要素，这些要素通常是按UML标准定义的，即包要素用例要素、活动要素、过渡要素等。 [0031] 虽然上面已经参考优选实施例详细说明和解释了本发明，但是本发明不应被解释为限制于给出的示例。在不超出本发明的范围的情况下，本领域技术人员可以得到变型或在不同实施例中给出的特征的替换组合。