Automated generation of test oracles using a model-driven approach

一、基本信息

标题：Automated generation of test oracles using a model-driven approach
时间：2013
出版源：Information and Software Technology
领域分类：软件测试；自动化测试oracle；模型驱动的测试；UML状态机；模型到文本转换

二、研究背景

问题定义：模型驱动的方法生成Oracle的测试
难点：元模型的建立，模型之间的转换
相关工作：模型到模型转换（M2M），模型到文本转换（M2T），使用三个元模型。

三、创新方法

1.
2.

四、实验

实验1：Oracle自动化

要探究的问题:Oracle自动化问题
结论：自动化oracle意味着测试系统必须能够在测试用例中包含一个机制，以便自己给出一致的通过/失败判定，这必须取决于输入测试数据和预期结果。然后，给定测试功能和输入测试数据，自动计算预期结果。使用基于模型的方法解决了oracle自动化问题，其中UML状态机增加了特定的信息，以便使用UML Profile for oracles进行测试。之后，使用模型驱动的方法转换这些模型，以获取返回预期结果的oracle类。

实验2：MDT框架通过测试得到加强

要探究的问题：运行事例；测试模型生成；测试代码生成；测试Oracle的动机；
结论：获得测试用例判定：一旦在SUT中执行操作，下一步是比较预期结果（预期 _ 状态）和从SUT（状态）实际获得的结果是否相等。这在验证操作中用句子{ expected _ state == state }表示。
MOFScript转换将测试模型作为输入，并且对于定型为«TestCase的每个UML Interaction（即序列图），将其转换为xUnit测试方法。为了说明这种转换，我们使用Java及其相应的测试语言JUnit。
此时需要注意的是，预期结果由测试人员手动计算并存储在dataPool中。在UML-TP之后，对应于执行场景的每个测试用例过程（即序列图）在DataPool中具有一个或多个相关联的元组以便对其进行测试。除输入测试数据外，这些元组也具有预期值。以返回簿作为测试场景，测试输入是借方和副本。结果是借款人的州和支付金额。如果oracle未自动化，则必须由测试人员手动计算预期结果并将其存储在DataPool中。而手动计算每个测试用例的预期结果是一项繁琐且容易出错的任务。为了处理大量的情况，可以为UML状态机提供获得预期结果的功能。注意，UML分类器的状态可以被描述为其属性的函数，并且因此，根据相应的状态机，交互图中表示的消息序列修改场景中涉及的对象的状态。

实验3：自动化测试Oracle实现

要探究的问题：用于oracle确定的UML配置文件；转换获取oracle方法；实际与预期结果比较。
结论：UML状态机使用guard和effect子句中的变量。我们需要知道如何从dataPool获取这些变量以生成oracle。UML状态机中缺少此信息，这是获取测试oracle所必需的。TestPrecondition在UML注释中定义，该注释被定型为«TestPrecondition，它附加到UML状态机。标注为«TestPrecondition的UML注释可以具有不同的标记以获得用于oracle的数据。
Oracle方法的实现是通过模型到文本转换（M2T）来执行的。作为输入，它将一个UML状态机定型为«TestOracle，并使用两个oracle方法以与SUT相同的语言返回一个类，对于定型为«Precondition的每个状态，生成相应的效果作为该方法的文本代码结果。
没有oracle的JUnit代码的UML序列图。还需要更改从测试模型到xUnit代码的MOFScript转换。现在，转换已经考虑到有一个与UML序列图相关的UML状态机定型的TestOracle。
在SUT中调用每个操作以获得实际结果，最后，使用JUnit中的断言句子完成预期和实际结果之间的比较，测试人员可以使用带来xUnit框架的功能来管理缺陷并重新执行测试用例。如果缺陷是由于oracle过程中的错误，测试人员或设计人员只需要更改UML状态机，再次执行获取测试oracle过程的模型转换，并使用xUnit框架再次重新执行测试用例。

五、结论

作者的总结：在本文中，我们提出了一种允许测试oracle生成的方法，自动化测试oracle中的两个重要步骤：预期输出及其与实际输出的比较。我们描述了一个支持测试用例自动化的自动化测试框架。该框架使用UML表示法将描述系统的模型作为输入，并根据模型驱动的方法从中导出测试模型，然后导出测试代码。因此，获得了完整的可执行测试用例，其中包含以下信息：
参数化输入测试数据：测试仪将输入测试数据存储在dataPool中，测试用例自动检索它。dataPool中的操作返回测试用例的所有测试输入，并为每组输入执行测试用例。
以自动方式获得预期结果：测试oracle的这部分是从UML状态机自动获得的。结果，获得两种方法以产生预期结果和预期状态。
测试用例过程：测试用例过程从序列图自动生成，该序列图表示要测试的功能，并使用有关测试输入和预期结果的信息。测试用例程序侧重于功能测试。然后，测试系统和演员之间的交互。因此，在xUnit中获取一个方法，该方法调用dataPool中的测试输入，使用测试输入调用在SUT中测试的操作，使用oracle方法计算预期结果，最后验证预期结果是否相等使用xUnit中的Assert语句到实际的一个。
自己的评价：在模型驱动工程（MDE）中，模型被视为用于自动生成代码的第一类实体。在维护阶段，当需要更改请求时，将修改模型并自动重新生成代码。

参考文献：
【1】S.R. Dalal, A. Jain, N. Karunanithi, J.M. Leaton, C.M. Lott, G.C. Patton, B.M. Horowitz, Model-based testing in practice, in: Proceedings of the International Conference on Software Engineering, 1999, pp. 285–294.
【2】IEEE, IEEE Standard Glossary of Software Engineering Terminology, Tech. rep., IEEE, 1990. Google Scholar
【3】T. Mens, P. Van CorpA taxonomy of model transformation Electronic Notes in Theoretical Computer Sciences, 152 (2006), pp. 125-142
【4】B. Pérez Lamancha, P. Reales Mateo, I. García, M. Polo Usaola, M. Piattini, Automated model-based testing using the uml testing profile and qvt, in: International Workshop on Model-DriveEngineering, Verification and Validation, ACM, Denver, Colorado, 2009, pp. 1–10.
【5】B. Pérez Lamancha, M. Polo, M. Piattini An automated model-driven testing framework for model-driven development and software product lines International Conference on Evaluation of Novel Approaches to Software Engineering, SciTePress, Athens, Greece (2010), pp. 112-121