一、基本資訊

標題：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