從開發的角度看，GUI 通常都是基於某一 GUI 開發庫（SWT/SWING/AWT），這些庫通常是按照面向對象的方式進行建模的，它將每一個 GUI 元素映射成該庫中某一個類的對象。
從測試的角度看，所有的 GUI 元素，無論基於何種 GUI 庫，都被 RFT 映射成對象，RFT 提供一個對象模型框架管理各種 GUI 元素。
圖 1 是一個典型的基於 SWT 開發的 GUI，對於其中的一個按鈕，在開發者看來，它就是 SWT 庫中 Button 類的一個對象；但是 RFT 並不區分這是 SWT 庫中的按鈕，或者是其他 GUI 庫的按鈕，它都被映射成 RFT 對象模型中 GuiTestObject 對象。
在用 RFT 提供的 Inspector 工具獲取 GUI 元素時，需要用到開發模型。而進行 RFT 腳本開發時，又需要用到 RFT 對象模型。熟練掌握兩種對象模型，對提高 RFT 自動化測試效率非常有幫助。
基於 RFT 的自動化測試，都會採用 IBM 推薦的 ITCL 框架。在這個框架下，所有的腳本被劃分爲三個層次：對象層，任務層，用例層。對象識別就是在 RFT 的對象模型框架下，得到被測程序的 GUI 對象。它是對象層開發中最核心的任務。
常用的 RFT 的對象識別技術可以分爲兩大類：靜態識別與動態識別。動態和靜態方法各有優缺點，靜態方法識別效率高、開發成本比較低，但是腳本的可維護性比較差；而動態方法剛好相反。
採用常用的對象識別技術，可以識別出大部分的 GUI 元素，但有時也會遇到 RFT 無法識別的 GUI 元素，事實上識別這類用常用對象識別技術無法識別的 GUI 元素佔用了 RFT 腳本開發的大部分時間。
RFT 中一個非常重要的根接口是 IGraphical 接口，它定義了針對 GUI 元素的所有標準操作（click,doubleclick,drag 等）。另外一個非常重要的根類是 GuiTestObject，它繼承自 TestObject 並實現了 IGraphical 接口。常用對象識別技術中 GUI 元素都是被映射爲 GuiTestObject 對象。它們在 RFT 對象模型中的位置如圖 2 所示。靈活運用這些類、接口及其方法，能夠極大地擴展 RFT 對象識別的功能。
- 問題描述
使用 RFT 經常聽到的一個謬論就是 RFT 只能測試基於 java 的 GUI 程序，對於 C/C++ 或者 windows 標準控件，RFT 無法識別。事實上，RFT 提供了 IWindow 接口用於識別平臺相關的控件。
- IWindow 接口介紹
從圖 2 中可以看出，IWindow 接口也繼承自 IGraphical 接口，從這點看，IWindow 接口具有與 GuiTestObject 類似的功能。
使用 IWindow 接口能夠識別平臺相關的 GUI 控件，但是其接口函數的具體實現與平臺相關，windows 與 linux 上的實現就不一樣，可以通過下述方法判斷具體的平臺，本文將主要分析 windows 上的應用。
- 典型應用
圖 3 是記事本的“頁面設置”對話框，是一個 windows 原始窗體。如何識別這個窗體，並點擊“確定”按鈕呢？基於 RFT 的實現方法如下：
確定對象識別的起始點。通常選取最上層窗體作爲對象識別的起始點，具體方法如下所示：
這些方法都返回一個 IWindow 接口的數組，每一個數組元素代表一個頂層窗口，並且這些窗口之間是互相獨立的。
識別符合要求的頂層窗口，即“頁面設置”對話框。IWindow 接口提供了兩個方法：getText() 與 getWindowClassName() 來實現。對於窗體，getText() 返回窗體的標題；對於控件，getText() 返回控件的文本。getWindowClassName() 返回 win32 標準控件名。如何知道被測程序的標準控件名呢？在 windows 上有許多工具，例如下文中將提到的 AutoIt 以及 Visual Studio 提供的 Spy++。圖 4 是用 AutoIt 得到的 GUI 元素的屬性。
對頂層窗體數組根據文本值和標準控件名進行匹配，則可以識別出符合要求的頂層窗體。這兩個方法均返回字符串，爲了提高識別的效率，通常對這些字符串進行正則表達式匹配。具體用法如下，參數 sCaption 表示窗體的標題，sWindowClassName 表示窗體的 Win32 標準類名。
識別窗體內的控件，即“確定”按鈕。以頂層窗口爲起點，通過 IWindow 提供的 getChildren() 函數可以得到內嵌在頂層窗體的 GUI 控件（如 button，label 等），該方法返回 IWindow 接口的數組，對數組元素根據文本值和標準控件名進行匹配，即可識別出內嵌的控件。識別內嵌控件的方法如下，參數 iTopwin 表示頂層窗體，sCtrlText 表示控件的文本值，sCtrlClassName 表示控件的 Win32 標準類名。
IWindow 還提供了 getOwned() 方法，可以得到出頂層窗體擁有的子窗體（如模式對話框等）。
完成點擊“頁面設置”窗體中“確定”按鈕的 RFT 腳本如下。
- 問題描述
在進行 GUI 自動化測試時，一個經常遇到的問題就是如何測試開發者定製的控件？通常一組定製的控件，是作爲一個整體被 RFT 識別出來，你可以對這個整體作一些操作，但是如何識別出每一個具體的定製控件呢？可以使用 TestObject 類提供的方法：Invoke 函數。
- Invoke 方法介紹
Invoke 方法類似於 java 中的反射機制，它可以在運行時而不是編譯時調用函數。通俗地說，在 RFT 中，它可以根據字符串來調用相應的函數。這使得不僅可以調用某些確定的方法（如 GuiTestObject 的方法），還可以主動查詢定製控件本身提供的方法，大大加強了對象識別能力。
- 典型應用
使用 Invoke 函數的一個典型例子就是測試 Notes 8 的 tab 項。Notes 8 的 tab 項是一個定製的 java 控件。RFT 會將多個 tab 項識別爲一個 GuiTestObject 對象，如何識別出每一個 tab 項呢？並執行關閉 tab 項的操作呢？
首先採用 Object map 方法識別出 RFT 能夠識別出的最小的定製控件的集合。如下圖 2 紅色方框所示的 GUI 元素是 RFT 所能識別出的最小的對象。在本例中它被識別爲 GuiTestObject 的對象：sTabFolderObject。
圖 5 Notes 8 中定製控件
確定需要調用的方法。調用 Invoke 方法需要事先知道方法的名稱，TestObject 提供了另外一個方法：getMethods 它能夠返回控件所有的方法，你可以按照如下的方式調用它。
按照這種方式，能夠在控制檯打印該控件所有可用的方法，從中分析出需要的方法。在本例中發現 getItems 能夠返回所有的 tab 項。
調用 Invoke 方法識別出具體的定製控件。完整的用法如下所示，參數 name 表示希望識別的 tab 項的文本值，sTabFolderObject 爲上述紅色方框表示的對象。
完成關閉 tab 項操作。利用 Invoke 可以很便捷的操作 GUI 對象，但是一定要避免使用用戶所不能操作的方式來操作控件，因爲這違背了測試的原則。從 getMethods 返回的方法中發現 dispose 方法也可以關閉 tab 項，但很顯然用戶不能這樣操作，而用戶關閉 tab 項的操作就是點擊 tab 項的“X”。因此在 RFT 腳本中，可以首先得到“X”的座標，然後在該點執行單擊操作。具體的方法如下所示。
- 問題描述
使用 RFT 進行自動化測試時，經常遇到這樣的尷尬，一方面 RFT 在識別某些對象時遇到一些問題，比如無法識別，識別效率低，開發識別腳本代價很高。另一方面又有大量的第三方 GUI 自動化工具對某些特定的領域有很好的性能。如果能夠結合 RFT 與其他自動化工具，就能夠極大地提高自動化測試的效率，更加適應敏捷開發與測試。
- AutoIt 介紹
AutoIt 是一種在 windows 平臺上，針對 C/C++ 以及 windows 標準控件的，免費、開源的自動化管理工具。AutoIt 本身有一種非常簡單的腳本語言，這種腳本語言類於 Basic，並且其腳本可以直接轉化爲可執行程序且不依賴於任何庫。事實上，AutoIt 的這些功能，RFT 提供的 IWindow 接口也能夠完成，但 AutoIt 具有更高的效率。
- 典型應用一
仍然以 IWindow 接口中點擊“頁面設置”對話框中的“確定”按鈕爲例。介紹如何結合 RFT 與 AutoIt 完成上述操作。
- 開發 AutoIt 腳本。AutoIt 對 GUI 對象的識別區分 windows 和 controls。對於 windows 是通過 title/text 方式進行對象識別；對於 controls 是通過 title/text/controlID 方式進行識別。ControlID 是 AutoIt 中特有的概念，它不是一個特定的值，可以是：內部 ID，text，class，instance，classmn 以及它們的組合。在本例中，最終需要識別的對象是“確定”按鈕，同時它又位於“頁面設置”窗體中。具體的 AutoIt 腳本如下。
- 在 RFT 中調用 AutoIt 腳本。RFT 提供了多種啓動其它進程的方法，其中類 RationalTestScript 提供的 startApp 和 Run 方法比較常用。使用 startApp 需要事先在 IDE 中進行配置，而 Run 方法具有更多的普遍性，具體的調用方法如下。
- 典型應用二
在 RFT 中一類經常遇到的問題就是如何處理那些非預期的活動窗體。例如，點擊安全網頁上的 link，而這個 link 所指向的卻是一個非安全的網頁，如果瀏覽器對安全性要求較高的話，就會彈出一個對話框詢問你是否仍然打開這個頁面，如果選擇“是”則下次重複這樣的操作將不再會彈出對話框進行詢問，否則下次仍然會詢問。因此是否會出現這個窗體取決於是否建立了信任關係，而在腳本開發時是無法預見的。
採用常用的對象識別技術，其典型的處理方法如下所示。
上述處理方法採用了常用的對象識別技術識別那些非預期的窗體，如果這些窗體無法用常用方法識別，如何來處理這類問題呢？
圖 6 是打開網頁前，系統彈出的一個對話框，它是一個 windows 原始窗體，無法採用常用方法識別（當然可以用 IWindow 來識別），以下結合 RFT 和 AutoIt 來處理。
- 開發 AutoIt 腳本。AutoIt 腳本的任務是點擊“Security Alert”對話框中的“Yes”按鈕。這可以分爲兩步，第一步判斷對話框是否已經存在；第二步點擊“Yes”按鈕。具體的 AutoIt 腳本如下所示。
- 開發 RFT 腳本。RFT 腳本有三個任務，第一是點擊安全網頁上的 link 使得“Security Alert”對話框出現。第二是調用 AutoIt 腳本關閉彈出的對話框。第三是判斷非安全網頁是否已經打開。具體的 RFT 腳本如下所示。
從以上可以看出，相比單純使用 RFT，基於 RFT 與 AutoIt 的混合解決方案需要的腳本顯著減少，大大提高了腳本開發效率。當然這種混合解決方案需要你對 AutoIt 有一定的瞭解，增加了學習的負擔，但是一旦掌握，對於提高自動化測試效率是很明顯的。
本文闡述了各種不同的對象識別技術，其中 IWindow 接口用於識別 windows 標準控件；Invoke 方法用於識別應用程序定製的 GUI 控件；此外還介紹了 windows 平臺上一款優秀的自動化工具 AutoIt 以及如何與 RFT 結合進行自動化測試。將 RFT 常用的對象識別技術與這些特定條件下的對象識別技術相結合，能夠使得 GUI 自動化測試更加敏捷。
轉載:http://www.ibm.com/developerworks/cn/rational/r-cn-extendsrftobj/index.html