Rational Functional Tester 是一個基於 GUI 的自動化和回歸測試工具，用於對跨各種組織的許多產品的測試場景執行自動化。測試團隊使用它創建一組自動化腳本。這樣一組腳本也稱為一個自動化套件。然後，測試團隊會使用各種自動化框架運行這些自動化套件。一些人使用在 Rational Functional Tester 中構建的標准框架，另一些人則根據需要創建自己的框架。
在不同框架上工作並使用 Rational Functional Tester 的團隊有時會遇到問題，這些問題要麼是其框架中所獨有的，要麼是大多數框架中普遍存在的。但是，一些問題非常普遍，以至於它們的解決方案可為其他組織的人提供幫助。一個示例是手動合並不同時區和地區的不同成員在自己的工作區依照自己的對象映射創建的自動化腳本。
合並腳本看起來是一個簡單的過程，但在沒有配置管理工具的情況下，它會成為一項困難的工作。您必須讓每個腳本按預期方式運行，並且不需要更改自動化套件的現有文件夾結構。但是，如果您需要更文件夾結構，該怎麼辦？
本文將幫助您了解並克服在手動合並自動化文件夾或調整其結構時會遇到的問題。通過在自動化 Rational Software Architect 產品期間捕獲的真實示例，我們將解釋這些技巧的使用。這是使用 Rational Functional Tester 進行測試的這些場景中所測試的一個應用程序。當 Rational 軟件系統驗證測試 (SVT) 團隊遇到此問題時，他們必須浏覽各種論壇來查找有效的解決方案。本文以解決了該問題的研究結果作為基礎。
通過分析真實的示例，本文將幫助讀者輕松地與其場景相聯系起來，進而幫助他們使用手動合並 Rational Functional Tester 腳本或調整自動化文件夾結構的技巧/訣竅。
本文還將展示如何使用 Rational Functional Tester 應用編程接口 (API)，避免在合並期間攜帶包含腳本的測試對象映射文件的麻煩。
Rational Functional Tester 已成功用於自動化 Rational Software Architect 的開發場景。該自動化套件是在整個測試團隊的幫助下創建的。因為 Rational Software Architect 擁有眾多要測試的功能，所以創建來自動化 UI 場景的測試人員腳本形成了一個包含 250 多個腳本的測試套件。測試團隊中幾乎每個人都有一些功能並完成了自己的部分工作。這增加了覆蓋面，但也增加了腳本格式的不一致性。一些腳本遵循使用某種確定的文件夾結構的規則，而一些腳本稍微進行了更改。
創建 Rational Functional Tester 腳本後，任務很簡單：將新腳本合並到現有的自動化套件中。事實證明，這個看似簡單的任務是最大的挑戰，這激發了我們編寫這個案例分析。現有的自動化套件是在一種預定義的文件夾結構中創建和維護的。當我們嘗試將新腳本與舊套件合並時，出現了許多問題，這迫使我們嘗試了多個解決辦法來讓合並生效。
嚴格的時間限制和工具經驗的缺乏導致我們生成了主要基於對象映射的腳本，只要對象分層結構發生任何變化，這些腳本就很容易出錯。所以我們必須返回去檢查所有腳本，引入 Rational Functional Tester find() API 來查找幾乎所有對象。這成為了我們撰寫本文的第二個動機。
在以下各節中，我將使用我們對 Rational Software Architect 自動化套件的案例分析，介紹如何克服在手動將 Rational Functional Tester 腳本合並到現有的自動互框架中時遇到的任何阻礙。
在本節中，我們介紹每個問題，然後介紹避免該問題的解決方案或途徑。
Rational Software Architect 示例
Rational SVT 團隊有一個文件夾結構，它將所有腳本保存在此分層結構中的 testcases 下： ...\com\ibm\xtools\rsa\testcases\
對於新添加的功能，我們在 Rational Functional Tester 中的同一級別上創建了新的文件夾，我們還嘗試在此級別導入了新創建的腳本。但是，Rational Functional Tester 僅允許在根級別導入腳本，不允許將腳本導入到特定的文件夾中（如圖 1 所示）。
查看本欄目
解決方案
在 workspace/resources/.../destination folder 和 /workspace/.../destination folder 下手動創建一個文件夾。備注：用您自己的信息替換斜體文字。
現在手動將以下文件復制到此路徑下的目標文件夾中：workspace/resources/.../destination folder。
*.rftdef
*.rftxmap
*Helper.class
*.java
類似地，將 *.class 和 *.java 文件復制到目標文件夾中：workspace/.../destination folder
重新啟動 Rational Functional Tester，您可能注意到這些文件夾（以及腳本）現在已在您希望它們所在的位置上（參見圖 2）。
Rational Software Architect 示例
問題 1 的解決方案導致了這個問題。打開腳本後，我們注意到出現了包級別的編譯錯誤，如圖 3 所示。
解決方案
使用快速修復方法將舊包信息替換為新包信息，也就是說，在 Rational Functional Tester 編輯器中選擇 organize imports 選項。
要刪除編譯錯誤，請右鍵單擊項目，然後選擇 reset Java build path（如圖 4 所示）。
查看本欄目
Rational Software Architect 示例
解決問題 2 後，似乎一切正常，直到我們嘗試回放腳本。由於腳本幫助類中使用了舊包信息，所以回放失敗（如圖 5 所示）。在理想情況下，我們應將腳本幫助器連同腳本本身一起更新，但沒有顯示針對腳本幫助器的編譯錯誤，所以我們錯誤地假設腳本幫助已自動更新。
解決方案 打開腳本幫助器類，將舊包信息替換為新包信息，以消除編譯錯誤（如圖 6 所示）。
Rational Software Architect 示例
解決問題 3 後，我們再次回放腳本，結果發現了一個運行時錯誤（如圖 7 所示）。Rational Functional Tester 無法找到腳本定義文件，該軟件仍在根級別上搜索該文件。
解決方案
打開腳本幫助器類並搜索 setScriptName() 函數調用。
現在將腳本名稱參數更新為腳本的完整路徑（如圖 8 中所示）。
這將幫助 Rational Functional Tester 在回放期間找到腳本定義文件。
查看本欄目
Rational Software Architect 示例 解決問題 4 後，我們再次回放腳本，但發現了另一個運行時錯誤（如圖 9 所示）。Rational Functional Tester 無法找到腳本文件、數據池文件和對象映射文件，但它仍在根級別上進行搜索。
解決方案
打開腳本定義文件 (*.rftdef)，更新腳本文件、數據池文件和對象映射文件的路徑（參見圖 10）。這將幫助 Rational Functional Tester 在回放期間找到所需的文件。 更新代碼清單 1、清單 2 和清單 3 中所示的標記，以便應用此解決方案。
清單 1. 更新 ScriptName 標記（示例）
<ScriptName>com.ibm.xtools.rsa.testcases.REST.ClassCreationInPE_Recording</ScriptName>
清單 2. 更新 Map 標記（示例）
<Map>resources/com/ibm/xtools/rsa/testcases/REST/ClassCreationInPE_Recording.rftxmap</Map>
清單 3. 更新 Datapool 標記（示例）
<Datapool />
備注： 驗證點文件 (*.rftvp) 的路徑應保持與新創建的腳本中一樣。
Rational Software Architect 示例 基於各自的 Rational Functional Tester 知識，不同的測試成員向自動化套件貢獻了不同的部分。結果，一些腳本更加依賴於對象映射，而且在對象屬性或分層結構中出現更改時容易出錯。新版 Rational Software Architect 中的 IBM Eclipse Software Development Kit 中發生更改後，這些腳本開始出錯（參見圖 11）。
查看本欄目
解決方案
使用 find() API 找到並操作任何容易出錯的對象，而不是依據對象映射來使用它。
在記錄的腳本上創建一個抽象層，以便處理與容易出錯的腳本的交互。
我們可以通過三個選項完成此任務：
從頭編寫抽象層，找到每個容易出錯的對象，然後對它執行操作。
重用 IBM Business Logic Utilities Environment (BLUE) Test Automation（Blue Package 或 ITCL Framework）的現有類和功能，或者使用 Rational Software Architect 自動化測試團隊創建的類和功能。二者都是使用 Rational Functional Tester 公開的 API 編寫的。
將現有的對象轉換為動態測試對象，然後選擇應用程序的根測試對象作為父節點來定位。
資源缺乏、專業經驗水平，以及第 2 和第 3 個選項的易用性，促使我們使用它們來實現我們的目標。對現有代碼的重用（如圖 12 所示）和動態測試對象轉換（如 圖 13 所示）能幫助我們更快地實現目標。
但是，我們還使用 find() API 的一個變體，編寫了代碼來查找容易出錯的對象。語法如清單 4 所示，示例代碼如清單 5 所示。您可以在 Rational Functional Tester 信息中心找到 find() API 的其他變體（參見 參考資料）。這使得您可以選擇最適合具體情形的解決方案。
public TestObject[] find(Subitem properties)
清單 4 中的代碼會找到所有與給定搜索條件匹配的候選對象。以下是屬性 subitem 的有效值：
atProperty 一個名稱-值對，表示一個 TestObject 屬性。 atChild 包含一個或多個必須與開始的 TestObject 的直系子對象相匹配的屬性。 atDescendant 包含一個或多個可與開始 TestObject 的任何子對象相匹配的屬性。 atList 用於指定將用於匹配操作的一個屬性順序列表。以下 subitem 可用於 atList：
atChild
atDescendant
atProperty
第一個列表項用作一個匹配值來獲取候選對象列表。然後匹配這些候選對象的後輩來獲得下一個列表項。
備注： 在清單 5 中，要查找的對象的識別屬性和它們的值作為參數傳遞，以查找根測試對象的特定自對象。
在手動將 Rational Functional Tester 腳本合並到現有自動化套件中的時候，或者在調整自動化的現有文件夾結構期間，可能出現許多問題，本文幫助您克服其中的大多數問題。通讀這些解決方案後（它們基於一份 Rational Software Architect 案例分析），您就能夠更加實際地發現類似問題並輕松地解決它們。
