工具輔助: 使用 Rational Test RealTime 實作開發人員測試
這個工具輔助說明如何使用 RationalTest RealTime 來實作測試。
工具: Rational Test RealTime
關係
主要說明

概觀

Test RealTime 整合三個測試工具:

  • 單元測試使 C 和 Ada 軟體元件測試自動化。
  • 物件測試是 C++ 程式碼行為測試的物件導向方法。
  • 系統測試是測試訊息式應用程式的強大環境。

您應該在應用程式中使用何種測試工具,其選擇視開發環境及應用程式的本質而定。對於每一個測試工具,您需要開發專用的測試 Script。

在撰寫應用程式的實際測試之前,Test RealTime 需要您建立測試專案,並連結該專案與測試中應用程式。

工具步驟

若要在 Test RealTime 建立測試 Script,請執行下列動作:

  1. 執行元件測試精靈
  2. 輸入測試資料和預期的結果
  3. 修改 Stub 行為

1. 執行元件測試精靈

Test RealTime 提供元件測試精靈,在執行此精靈時,它會分析指定的程式碼,並產生完全可執行的測試控制工具。開發人員要確保目標程式碼如所預期進行測試,唯一需要做的是定義 Stub 行為(請參閱第二個工具步驟),並輸入測試資料和預期的結果(請參閱第三個工具步驟)。

附註:不需要使用元件測試精靈 - 要支援測試所需的所有檔案和程式碼可以手動產生。然而,精靈可以節省很多工夫。不論哪一種方式,測試執行和測試報告都是自動化。

元件測試精靈可以用兩種方式之一存取。任一種方法都假設 Test RealTime 專案已經開啟。

  • 選取 Test RealTime 起始頁左邊的活動鏈結。選取此鏈結會顯示三個主要活動的清單,供開發人員選擇。若要執行元件測試,開發人員現在應該選取元件測試鏈結。

  • 用滑鼠右鍵按一下 Test RealTime 右邊的「專案視窗」的「資產瀏覽器」中的 source file/class/method/function/procedure。選取蹦現功能表中的「測試...」選項會開啟元件測試精靈。

這兩種起始元件測試精靈的方法之間的主要差異在於,第一個選項需要使用者選取包含要測試的 functions/methods/procedures 的程式檔 - 第二個選項已知道要使用的程式檔,因此略過元件測試精靈的起始步驟。

在任一情況下,都會要求開發人員選取測試模式 - 一般或專家。其差異與所要的 Stub 行為有關。提醒您,Stub 是「一個包含測試用途的功能的元件」- 也就是說,一個設計以預先定義的方式運作來促進其他系統元件之測試的元件。在一般模式中,Test RealTime 會自動產生 Stub 範本給在已選取的程式檔中明確參照的任何 function/method/procedure。專家模式可讓您另外選取不在選擇的程式檔中明確參照的元件。不論哪一種方式,這些 Stub 的實際功能會在稍後加以定義 - 請參閱下面的第二個工具步驟。

當精靈執行到最後時,Test RealTime 會在主動式的專案內建立一個節點。這個節點包含對已選取的程式檔的參照,以及對建立測試控制工具所需之檔案的參照。這些其他的檔案需要加以修改,才能:

  • 定義 Stub 行為
  • 指定用來驅動測試中 functions/methods/procedures 的日期
  • 指定每一個輸入資料集的預期結果

對於 C、C++ 和 Ada,Rational Software 會建立測試控制工具、測試 Stub 和 測試 Script 語言來容納那些語言的錯綜複雜之處。 對於 Java,Test RealTime 使用 Java 作為測試 Script 語言,並以 JUnit 架構作為其測試控制工具和測試 Stub 架構的基礎 (http://www.junit.org)。

book 圖示如需詳細資訊,請參閱 Rational Test RealTime 使用手冊 的「圖形使用者介面->活動精靈->元件測試精靈」這一章。

2. 輸入測試資料和預期的結果

元件測試精靈產生的測試 Script 可立即執行。然而,在開發人員指定實際資料來驅動測試中元件 - 以及預期的輸出值 - 之前,測試既無用處,也無參考價值。

Test RealTime 支援的每一種語言以不同方式促進測試的建立;每一個方法已針對每一種語言的唯一特性而最佳化。C++ 更是與眾不同,因為它不僅可以產生和執行標準測試,也可以進行選用性的合約檢查。合約檢查的作用類似確認 - 它們是用來驗證像前置/後置條件和不變量之類的項目。

book 圖示 如需 C 和 Ada 的相關資訊,請參閱 Rational Test RealTime 使用手冊的下面這一章:

  • 自動化測試->C 和 Ada 的元件測試->C 和 Ada 測試 Script->概觀->測試 Script 結構
  • 自動化測試->C 和 Ada 的元件測試->C 和 Ada 測試 Script->Ada

    book 圖示,並參閱 Rational Test RealTime 參考手冊的下列各章

  • 元件測試 Script 語言->C 測試 Script 語言->C 測試 Script 語言關鍵字->ELEMENT...END ELEMENT
  • 元件測試 Script 語言->C 測試 Script 語言->C 測試 Script 語言關鍵字->ENVIRONMENT...END ENVIRONMENT
  • 元件測試 Script 語言->Ada 測試 Script 語言->Ada 測試 Script 語言關鍵字->ELEMENT...END ELEMENT
  • 元件測試 Script 語言->Ada 測試 Script 語言->Ada 測試 Script 語言關鍵字->ENVIRONMENT...END ENVIRONMENT

book 圖示如需 C++ 的相關資訊,請參閱 Rational Test RealTime 使用手冊的下列各章:

  • 自動化測試->C++ 的元件測試->C++ 測試概觀

    book 圖示,並參閱 Rational Test RealTime 參考手冊的下列各章

  • 元件測試 Script 語言->C++ 測試 Script 語言->C++ 測試驅動程式 Script

book 圖示如需 Java 的相關資訊,請參閱 Rational Test RealTime 使用手冊的下列各章:

  • 自動化測試->Java 的元件測試->Java 測試概觀->關於 JUnit

    book 圖示,並參閱 Rational Test RealTime 參考手冊的下列各章

  • 元件測試 Script 語言->Java 測試基本元素

3. 修改 Stub 行為

元件是設計來以特定方式作用。這些元件無論精度等級,應該以可預先定義的特定輸出集來回應給定的輸入集。「可預先定義的」表示可在測試執行之前明確地或以演算法方式指定結果。

元件常常需要系統內其他元件的協助來執行其功能。這些其他元件可以和其他的功能一樣簡單,也可以和系統其他地方的整個子系統一樣那麼宏偉壯觀。不論哪一種,開發人員都普遍發現,他們在元件測試上所下的工夫受到一件事實的牽制,即程式碼所依賴的元件並不存在,或至少還無法可靠地發揮作用。Stub 的作用補償了這個難題。(事實上,Stub 可用來保證適當的發揮作用,因為它避免完全依賴第三方程式碼)。

開發人員有責任適當地模擬測試中元件所依賴的元件。 適當的模擬表示 Stub 功能必須夠精確,以確保測試中元件的成功或失敗一定都可以追蹤到元件本身,而不是到 Stub 產生的不正確資訊。

Rational Test RealTime 透過支援的測試 Script 來促進 Stub 的建立。尤其,如需建立測試 Stub 的相關資訊;

book 圖示 如需 C 和 Ada 的相關資訊,請參閱 Rational Test RealTime 使用手冊的下面這一章:

  • 自動化測試->C 和 Ada 的元件測試->C 和 Ada 測試 Script->模擬->Stub 模擬概觀

    book 圖示,並參閱 Rational Test RealTime 參考手冊的下列各章

  • 元件測試 Script 語言->C 測試 Script 語言->C 測試 Script 語言關鍵字->STUB
  • 元件測試 Script 語言->Ada 測試 Script 語言->Ada 測試 Script 語言關鍵字->STUB

book 圖示如需 C++ 的相關資訊,請參閱 Rational Test RealTime 使用手冊的下列各章:

  • 自動化測試->C++ 的元件測試->C++ 測試概觀->C++ 測試驅動程式 Script

    book 圖示,並參閱 Rational Test RealTime 參考手冊的下列各章

  • 元件測試 Script 語言->C++ 測試 Script 語言->C++ 測試 Script 關鍵字->STUB

book 圖示如需 Java 的相關資訊,請參閱 Rational Test RealTime 使用手冊的下列各章:

  • 自動化測試->Java 的元件測試->Java 測試概觀->Java Stub 控制工具

如需相關資訊

如需如何執行測試活動的詳細資訊,請參閱工具輔助:使用 Rational Test RealTime 執行測試