【模型驱动软件设计】「过程和工程」测试

     只有在非常少的情况下才可以完全基于规范验证软件。因为这一点，测试在软件开发中非常重要。

      到目前为止，我们还没有明显地说明测试在软件开发过程中的角色。这不是因为我们相信测试是不重要或次要的，而是因为在MDSD中，它在本质上扮演了和在其他方面中相同的角色。

     测试自动化时如下方面的关键元素：在软件创建期间使其连续和可重复确认。不需要充当测试方面的先驱者，而更应该关注一般的MDSD环境中和特定的体系结构中心MDSD中的细节。

一、测试类型

     对软件系统的哪些方面进行测试，何时进行测试，以及最终结果是什么，这些讨论导致了测试类型的产生。

• 组件测试（也称为单元测试）由开发者在他们每天工作的过程中创建，其作用是确保系统部分的正确机能。
• 系统测试确保系统各个部分的正确相互作用。
• 接受测试显示系统从顾客的观点来看是否有意义并且满足他们的需求。
• GUI测试可以担任接受测试或集成测试的角色。
• 非功能性测试验证目标体系结构的需求，例如安全性、多用户环境中的正确事务管理或面向硬件故障的健壮性。
• 加载测试是非功能性测试的特殊子集。
• 回归测试用于检测是否由于改变了源代码而出现不需要的副作用。通常通过重复其他测试类型来执行回归测试。

       测试自动化是增加测试效率和有效性的非常重要的方法。只有可再生产的、自动化的测试可形成“安全网”，该安全网允许软件保持可变。测试自动化帮助实现回归测试，并且适用于除了人机工程学的所有测试。

二、模型驱动应用程序开发中的测试

       在应用程序开发线程中，与非模型驱动过程中相同的测试类型是相关的。模型是代码的一部分。因为它们是正式的，并且自动通过转换转化为3G L代码。

       模型驱动的方法有许多潜在性，也可以简化测试代码的创建。黑盒测试总是将当前状态和所需状态进行比较：不会区分方法的返回值和副作用。因此，测试保护隐藏在通过句法定义的洁面后面的语义。

1.单元测试

   在常规的软件开发环境中，可以使用小型的但却有用的框架，例如Junit。我们希望在MDSD中继续使用这些工具，并且支持使用模型驱动技术技能有效地创建测试。

1）测试案例和测试数据的分离

2）测试基础结构生成

3）约束检查

4）极端值测试的生成

5）模仿对象

2.接受测试

   必须在与应用程序模型无关的情况下定义这些测试。根据从中生成应用程序的相同模型生成接受测试，这样做没有任何作用因为在这种情况下，只要域体系结构是正确的，它永远都不会失败。

3.加载测试

    原则上，加载测试遵循如下模式：模拟通常运行在大量计算机上的一组客户端。这些客户端运行测试脚本。

   环境的设置（例如服务器、网络、数据库）必须手工创建。必须定义如下方面：

• 测试脚本
• 客户端数量
• 它们的内部并行性，也就是进城和线程的数量。

•        在大多数情况下，通过工具处理后两个方面，这些工具也度量计时行为并监控应用程序。测试脚本很适合于生成。序列图或状态图是良好的基础。

4.非功能性测试

     测试非功能需求，例如可靠性、事务一致性或者死者自由度，不能在简单的环境中完成，例如在Junit中。在这儿需要现实的情况。必须模拟网络或数据库故障，或者强制这些故障实际地发生。类似地，只可以手工指导安全测试。模拟驱动的开发在这儿不提供任何特定的帮助。

5.模型确认

      模型确认是一种测试类型，只在使用MDSD时才可以进行这种测试。它为测试提供了全新的选择。必须区分3种不同的子类型：

• 模型级上的接受测试，用于验证模型的语义
• 良好格式的测试，用于检查是否服从建模规则
• 模拟的模拟

1）模型级上的接受测试

         MDSD模型通过直接与顾客或专家通信队潜在的内容进行验证，特别是在MDSD域和它的DSL是面向业务时。这种方法可以提供额外的确定性，特别是在根据模型创建代码或配置文件时。因此，可以预先在更为抽象的级别上检查这种代码或配置的意义。

2）良好格式测试

      从测试的角度来看，这种建模规则是对DSL的所有实例有效的不变式--也就是说，对于所有模型有效。必须在可以进行实际的MDSD转换之前检查它们，否则转换结果就是不明确的。格式良好的测试可以由建模工具或随后的编译器进行的类编程语言的静态语义检查。

3）模拟的模拟

    如果系统的动态特性已完全在模型中描述，则可以通过模型的模拟验证它们。这种方法在嵌入式系统中非常流行，但只针对特定类型的行为定义，特别是有限状态自动机。UML2.0和动作语义对此也有帮助。在常见的实践中，模拟模拟方法不是经济的或可行的，因为在模型中没有指定动态系统行为。

三、测试域体系结构

    域体系结构也是软件，因此必须充分地进行测试。幸运的是，可以将这种问题分解为单个方面，针对这些方面可以使用众所周知的测试解决方案。

1.测试引用实现和MDSD平台

     引用实现扮演中心的角色---至少在域体系结构的引导阶段如此。因为一般针对这个目标小型的专家团队，灵活的，测试驱动的方法在这儿非常有用。MDSD平台也具有相同的情况，

2.DSL的接受测试

     建模语言（DSL）的验证也非常重要。在引用模型中使用建模语言的过程中进行验证。根据其适用性和人机工程学，后者主要是DSL的测试。因为引用实现和引用模型尽可能最低限度地覆盖DSL的所有构造--完全测试每种特性一次的最小化测试--引用模型应该被视为相当重要的测试。在进行引导后，来自开发线程中的应用程序模型是下一个DSL测试--可以使用真正的应用程序模型作为DSL适用性的测试案例。

3.MDSD转换的测试

     在体系结构开发线程中，实现引用实现各方面的形式化和将它强制转换计算机可处理的形式--主要是生成器模版或绑定DSL元模型的类似转换规则。通常，转换规则构建在一般的MDSD工具上，针对我们的目标假设该工具是正确的。现在只需要测试域特有的和平台特有的转换。

    相当显而易见的测试方法是引导域体系结构的副产品：因为转换规则派生于引用实现和引用模型，它们能够确切地复制由DS L包括的引用实现的某个部分。换句话说，如果将新创建的转换应用于引用模型，可获得--根据体系结构的作用域--完整的引用实现或只是它的实现程序框架。

    在项目过程中，域体系结构的最初测试为测试实际的应用程序而扩展了，因此，创建的应用程序将隐式地验证体系结构--也就是说，由应用程序的测试进行验证。这在实践中特别有效和足够充分。

显示的转换测试 

    当根据模块构造生成器时，这种方法以及各自测试套件的构造是完全可行的。

     测试提供给处于测试的系统特定的刺激源，并且将执行系统的输出或影响域规范进行比较。根据所测试系统的实现进行抽象。