將調用封裝到 Rational Functional Tester API 中

在諸如 IBM Workplace 的企業環境內執行模擬測試會是一項很重要的任務。本文將介紹如何用 Java 創建封裝器類，這些類將調用封裝到 Rational Functional Tester API 中，以模擬常見的用戶活動。

Rational GUI 自動化工具有很好的記錄器功能，可以記錄用戶的活動，并自動生成代碼來模擬這些活動。然后，無需進一步修改，就可以立即回放這些代碼來執行簡單模擬測試。不過，諸如 IBM WebSphere Portal、IBM Workplace Collaboration Services 或 IBM Workplace Client Technology 之類的大型復雜應用程序通常需要更復雜的測試，這不是未經修改的記錄和回放可以提供的。對于我們自己的 IBM Workplace 產品的內部測試，我們使用 Rational Functional Tester（以前稱為 Rational XDE Tester）為模擬測試手工編寫代碼。在這個過程中，我們已經掌握了多種方法，這些方法使得為這些產品編寫代碼變得更容易、更快。

Rational Functional Tester 以 Java 為基礎，因此可以非常容易地擴展其內置功能。這允許我們用 Java 創建封裝器類，這些類通過將調用封裝到 Rational Functional Tester API 中來執行針對控件的公共操作。在手工編寫和維護用于測試產品的自動化代碼時，這些類極大地提高了我們的生產率。去年，這些類已經傳播到 IBM 的其他許多軟件團隊中。

在本文中，我們將說明如何創建這些封裝器類，我們稱這些類為窗口小部件 類。本文假設您有用 Java 編寫測試腳本的經驗。我們將帶領您編寫窗口小部件的代碼，用這些代碼測試文本字段、列表框和其他標準控件；搜索動態生成的控件；以及擴展這些類來處理定制 Java 控件。如果計劃測試復雜應用程序，比如與 WebSphere Portal、IBM Workplace 或基于 Eclipse 的應用程序集成，以便使用 Workplace Client Technology 的那些應用程序，那么您將發現這些類非常有用，希望本文會激發您創建一些自己的類。

窗口小部件類：TextField

文本字段很好地說明了手工對 Rational Functional Tester 測試腳本編碼時遇到的困難。在記錄設置文本字段的文本的那些操作時，會得到類似下面的代碼：

	Text_name().click(atPoint(35,10));	Browser_htmlBrowser(document_C(),DEFAULT_FLAGS).inputKeys	   ("{ExtHome}+{ExtEnd}{ExtDelete}");	Browser_htmlBrowser(document_C(),DEFAULT_FLAGS).inputKeys("test");

該代碼有些冗長。它使用了三行代碼來完成一項任務：即設置文本。但是，在記錄器中，這是可以理解的行為。因為記錄器不知道您要設置文本（比如說，在沒有單擊文本字段或者沒有先刪除字段中數據的情況下輸入一些文本），所以記錄器不能用一個方法調用替代所有的三行。

不過，如果手工編寫代碼，而不是記錄代碼，那么在所有這些代碼行中輸入信息變得比較麻煩。對于手工編碼，實際需要的是 setText() 方法，以便可以只輸入一行代碼，而不是三行代碼都輸入。要完成這項操作，可以將記錄器生成的三行代碼封裝到測試腳本的某個單獨方法中。

作為首要方法，可以創建類似下面的 setText() 方法：

	void setText(String s) {		Text_name().click();		Browser_htmlBrowser().inputKeys("{ExtHome}+{ExtEnd}{ExtDelete}");		Browser_htmlBrowser().inputKeys(s);	}

當然，這樣做還不夠，因為它將只為對象映射中的一個特定文本字段工作，即 Text_name。最好為所有文本字段生成此代碼。進行這項操作的一種方法是將對象作為參數傳遞給方法，如下所示：

	void setText(String s, GuiTestObject gto) {		gto.click();		Browser_htmlBrowser().inputKeys("{ExtHome}+{ExtEnd}{ExtDelete}");		Browser_htmlBrowser().inputKeys(s);	}

如果您所擔心的只是當前處理的測試腳本，那么該代碼就可以解除您的顧慮。但是從長遠角度來看，您實際想要的是一種可以從編寫的所有測試腳本進行訪問的方法。支持這一點的一種方式是將該方法放入 Super Helper，然后讓所有測試腳本繼承 Super Helper。（有關 Super Helper 的詳細信息，請參閱 developerWorks：Rational 中的“Creating a super helper class in Rational XDE Tester”一文。）為所有不同種類的控件（文本字段、列表框等）創建所需的方法后，會產生巨大的、難處理的 Super Helper。更好的方法是創建單獨的 Java 類，與每種控件相對應，然后將用來操作每個控件的方法放入相應的類中。

為了創建 TextField 窗口小部件類，可以通過在 Rational Functional Tester 開發環境中調用向導，在 Eclipse 中創建一個新的 Java 類。

1. 在 Rational Functional Tester IDE 中，選擇 File - New - Other。（不要選擇 File - New - XDE Tester Script。）
2. 選擇 Java and Class 并單擊 Next 按鈕。
3. 在 Name 字段中輸入類 TextField 的名稱。其余字段保持默認值，然后單擊 Finish。

創建新的 Java 類后，可以將下列修改的 setText() 方法放入該類中：

public class TextField {	public static void setText(String s, GuiTestObject gto) {		gto.click();		TopLevelTestObject app = (TopLevelTestObject) gto.getTopParent();		app.inputKeys("{ExtHome}+{ExtEnd}{ExtDelete}");  		app.inputKeys(s);		app.unregister();	}}

現在可以從測試腳本中用簡單的一行代碼調用該方法：

正如您可以看到的，手工編碼要比通過記錄器創建代碼的方式進入每個操作容易得多。

此時，您可能希望向 TextField 類添加其他方法。至少應該向該類添加另一個方法，以獲取文本字段的文本，如下所示：

用這種方式可以非常容易地封裝從控件獲取信息的方法。記住那些直接從 GuiTestObject 獲取信息的所需的屬性值非常困難，但是記住類似 getText() 的方法則非常容易，所以您將發現，封裝與此類似的 getProperty() 調用將非常有用。

不過，您可能并不想封裝 Rational Functional Tester 為操作文本字段提供的每一個 方法。如果某些人因為某些原因想跨文本字段實現拖動操作，或在這些字段上盤旋，您當然想也讓他們這樣做，但是為 GuiTestObject 中的每個方法編寫封裝器方法會很枯燥乏味，每個方法都要調用 Rational Functional Tester 已經提供的相應方法。相反，可以將 Rational Functional Tester 的 GuiTestObject 繼承到您的類中。然后該類的用戶可以使用 GuiTestObject 中的現有方法，您不必重新編寫所有方法。

然而，如果繼承 GuiTestObject，則需要編寫構造函數。完成該操作后，將現有方法更改為不再保持靜態�？梢詫� GuiTestObject 只傳遞到構造函數中一次，然后將設置和獲取文本的方法用作實例方法，而不是用作類方法。（另外，如果有人擴展類，因為無法正確覆蓋這些方法，靜態方法可能會引發問題。）這使調用該方法變得不太直觀。因此，不使用以下代碼：

而必須使用：

或者如果這個特定文本字段在腳本中只使用一次，那么可以將這個代碼合并到一個語句中：

雖然這也不太直觀（特別是對那些不熟悉 Java 的人），但它極大地改善了整個設計。

繼承 GuiTestObject 后，最終的 TextField 類與下面的代碼類似：

public class TextField extends GuiTestObject {	public TextField(GuiTestObject textfield) {		super(textfield);	}	public void setText(String s) {			this.click();  		TopLevelTestObject app = (TopLevelTestObject) gto.getTopParent();		app.inputKeys("{ExtHome}+{ExtEnd}{ExtDelete}");  		app.inputKeys(s);		app.unregister();	}	public String getText() {		return this.getProperty(".value").toString();	}}

在 IBM 使用的 TextField 類中，有其他一些方法，其中包括清除文本的方法，以及輸入 escape 鍵的方法，這兩種方法都通過 setText() 方法使用。在本文中，我們使用簡單的代碼來表達這種策略的要點。您可以根據需要添加其他方法。

回頁首

窗口小部件類：Listbox

在 Rational Functional Tester 中，對列表框進行手工編碼要比文本字段難得多。經常需要對列表框執行無數操作，比如按名稱或整數選擇某些項、獲取所選項的名稱或索引、獲取可選擇的數目，以及獲取所有選擇名稱的列表。但是這些操作需要在 Rational Functional Tester 中輸入多行難記的代碼。

例如，每次在列表框中選擇項時，您都會發現，輸入代碼

要比輸入下列代碼麻煩得多：

另外，如果想使用 Rational Functional Tester 的 API 選擇某個項，則需要確保選擇這個項之前存在該項，因此必須進行類似下面的操作：

	ITestDataList dataList =          (ITestDataList)this.getTestData("list");	ITestDataElementList elementList = 	   (ITestDataElementList)dataList.getElements();	for(int i = 0; i<elementList.getLength(); i++) {		if (elementList.getElement(i).getElement().toString().		   equals("Computer Related")) {			List_category().click();			List_category().click(atText("Computer Related"));		}	}

使用窗口小部件類要容易得多，可以將這項功能封裝到易于記住的方法中，如下所示：

	ListBox lb = new ListBox(List_category());	if (lb.doesItemExist("Computer Related")  {		lb.select("Computer Related"));	}

要完成這項操作，需要創建 ListBox 窗口小部件類，創建過程與前面創建 TextField 的相似，然后將 select() 和 find() 方法添加到該類中。select() 方法很簡單，但是實現 find() 方法時，該方法要使用我們在該類中已經公布的其他方法。我們向您顯示了完整的 ListBox 窗口小部件類（當然，為了便于顯示，這些類已經清除了），這使您可以了解我們已經發現的對操作列表框有用的許多方法。正如您將看到的，這類方法有很多，因此，ListBox 窗口小部件類顯示了從創建窗口小部件類中可以獲得的一些實際的好處。要查看 ListBox 窗口小部件類，請參閱 this sidefile。

回頁首

窗口小部件類：其他通用控件

您可能認為沒有太大必要為文本字段和列表框之外的控件創建窗口小部件類。諸如鏈接、按鈕、復選框和單選鈕之類的其他通用部件的確不是很難處理。大多數時間，使用 click() 就足以解決問題。除了要與已經創建的窗口小部件一致之外，為什么還要為其他控件創建單獨的類呢？

答案涉及兩個方面。首先，經常需要從特定控件獲取屬性。正如前面所討論的，調用 getText() 方法要比調用 getProperty(".value") 直觀得多。除了文本字段和列表框之外，最明顯地體現了這一點的控件是復選框和單選鈕。

例如，您不僅經常要選擇復選框，而且通常還想知道該復選框是否選中。我們在 CheckBox 窗口小部件類中提供了 isChecked() 方法來執行這項操作。我們發現記住如何編寫下列代碼：

要比記住如何編寫以下代碼容易得多：

而且，該代碼允許創建 check() 和 uncheck() 方法，這些方法可以在執行操作前查詢對象的狀態。同樣地，每次選中復選框時，我們發現，記住如何編寫下列代碼：

要比記住如何編寫以下代碼容易得多：

其次，更重要的是，我們發現經常需要動態查找特定類型的控件，因為這些控件是在運行時生成的，或者因為每次構建的時候，它們的位置會發生變化。這項功能常常用于鏈接、靜態文本、圖形和按鈕，所以我們在這些窗口小部件中添加了特殊方法來動態查找它們，如下例所示，該例根據鏈接的文本屬性來查找鏈接：

	public static Link findHtmlLinkFromTextProp(Regex linkText,          TestObject parent)	{				TestObject to = ObjectFactory.findTestObject(linkText, ".text", "Html.A", parent);				//Make sure the object exists		if (to == null)			throw new ObjectNotFoundException("Link with text '" + 	   	   linkText + "' not found");				return new Link(to);	}

該方法在名為 ObjectFactory 的類中調用了另一個方法，以完成所有動態搜索。我們發現動態搜索非常有用，所以值得詳細研究一下 ObjectFactory 類。

回頁首

ObjectFactory：搜索控件

在一些 Web 應用程序中，經常在運行時動態生成控件。例如，IBM Workplace Messaging 等標準基于 Web 電子郵件應用程序在 Inbox 中以鏈接形式列出消息。

每個進入 Inbox 的新消息都將創建一個新的動態生成的鏈接。對于 Rational Functional Tester 的對象模型，這樣做會存在問題。如果按圖 1 中顯示的方式映射鏈接，那么再次運新測試時，隨著其他郵件發送到 Inbox，鏈接的順序可能會變化。隨著順序變化，鏈接的重新配置屬性也將變化，這可能會導致自動化失敗。因此，您所需的是一種在運行時識別鏈接的方法，換句話說，需要一種動態查找鏈接的方法。這就是 ObjectFactory 類所要做的。

理解這個問題的最簡單的方法是考慮這樣一種情況：要在動態 Web 應用程序中為鏈接隨機生成惟一名稱。在 WebSphere Portal 自動化中，我們將進行這項操作。創建新的 Collaborative Space 或 Place 時，WebSphere Portal 提供下列 Web 頁面表單：

需要為運行的每個測試創建新的位置，所以需要輸入隨機生成的名稱來惟一標識每個位置。單擊 Creat 按鈕后，會生成新的、惟一 命名的位置，該位置的鏈接現在顯示在位置列表中，如圖 3 所示。

不過，如果不能動態訪問這個新生成的、惟一命名的鏈接，就不能繼續自動測試。因為運行之前 不知道位置的名稱，所以記錄測試情況時，不能將得到的鏈接添加到對象映射。相反，需要在運行時動態訪問鏈接。

ObjectFactory 類用動態對象識別方法解決了這個問題。這些方法幫助自動化開發人員輕松地找到動態生成的 GUI 對象，并對其進行操作，這些 GUI 對象是在運行時生成的。通過在 ObjectFactory 類中使用 findTestObject() 方法，自動化開發人員可以利用以下調用輕松訪問以前動態創建的位置鏈接：

該方法將搜索所有頁面內容，查找包含文本 AAAAPlace_721134315 的 Link 類對象，然后返回要執行操作的對象。

在 ObjectFactory 類中，findTestObject() 方法調用名為 findTestObjectRF() 的遞歸方法，下列代碼中顯示了該方法。該方法接受 4 個參數：屬性、屬性值、類和父測試對象。利用這些信息，該方法可以在父 TestObject 的派生項中搜索包含給定屬性值的對象。

public TestObject findTestObjectRF(String sProperty, String sValue, 			String sClassID, TestObject t)	{		//check if object was found. If yes return it.	if (gbKill)		return t;	else		gbKill = false;	//declare array of TestObjects	TestObject[] objList;				//get top level children	if (sClassID.equals(gsTextRef))		{		objList = t.getChildren();		}	else		{		objList = t.getMappableChildren();		}		//Find dynamic web object	for (int x = 0; x < objList.length; x++)		{		if (gbKill)			return t;		//try to find specified object		try			{			//check for specified class			if (objList[x].getProperty(gsClassProp).toString() != null)				{				//check for specified property				if (objList[x].getProperty(gsClassProp).toString()				   .indexOf(sClassID) != -1)					{					//check for specified property value						if (objList[x].getProperty(sProperty)					   .toString().indexOf(sValue) != -1)						{						gbKill = true;  //if test object 						   is found set to true						gtoTestObj = objList[x];  //set global 						   test object holder to appropriate 						   test object						return gtoTestObj;  //return found 						   test object						}					}				}			}    	catch (Exception e)			{			//continue;			}		//get child objects		if (sClassID.equals(gsTextRef))			{			if (objList[x].getChildren().length > 0)				{				findTestObjectRF(sProperty, sValue, sClassID, 				   objList[x] );				}			}			else			{			if (objList[x].getMappableChildren().length > 0)				{				findTestObjectRF(sProperty, sValue, sClassID, 				   objList[x] );				}				}				}  //end loop	return gtoTestObj;	}

該方法在給定父測試對象（通常是瀏覽器頁面）內搜索指定類的對象，例如，Link、TextField、Listbox 等。找到指定類的對象后，它檢查該對象的指定屬性值是否等于搜索值。如果屬性值與搜索值匹配，那么該方法就成功地找到預期的測試對象，并返回該對象。這樣，可以在應用程序內動態搜索具有任何給定屬性值的任何對象。

注意：在本文發表時，Rational Functional Tester 6.1 的新發行版本將動態搜索功能內置到了名為 find() 的 TestObject 方法中。獲得新版本后，我們將調用這個 find() 方法，替代前面介紹的遞歸函數，您也應該如此。這里需要重點了解的是 find() 方法如何有用。

動態搜索功能非常有用的另一種情況是：隨著每次進行新的構建，應用程序都會發生很大的變化。我們常常發現，在測試中，每次構建新的應用程序，對象識別屬性的更改都很大，以致于破壞了自動化。進行每日構建意味著需要頻繁更新對象映射。限制經常管理和更新對象映射的一個方法是使用 ObjectFactory 類的動態對象搜索功能。我們不記錄（映射）經常變化的應用程序中的所有對象，而是僅映射最主要的對象，并使用 findTestObject() 動態搜索方法查找其他對象。

因為任何類型的控件都存在這個問題，而不僅僅是鏈接存在這個問題，所以我們給所有窗口小部件都添加了構造函數，該構造函數可以動態查找控件，然后構造窗口小部件。例如，TextField 窗口小部件具有如下所示的構造函數：

	public TextField(String sTextField, String sProperty, 			   String sClass, TestObject parent) {		super(ObjectFactory.findTestObject(sTextField, sProperty, 		   sClass, parent));	}

其他所有窗口小部件中都有相似的構造函數，以便動態查找和構造任何類型的窗口小部件。

最后要提到的是我們創建了 StaticText 窗口小部件類。在 Rational Functional Tester 中，不能映射 HTML 靜態文本。不過，查找 Web 頁面上的靜態文本通常非常有用，例如，用來驗證 HTML 表或文檔中顯示的文本。因此，我們創建了可以動態構建的 StaticText 窗口小部件，還有靜動態 find() 方法，這些方法與為 Link 窗口小部件創建的那些方法類似。

正如您可以看到的，內置到 ObjectFactory 類中的動態搜索功能對操作運行時生成的對象非常有用，同時，該功能在為經常變化的 GUI 對象映射提供穩定性方面也非常有用。我們已經將主要動態搜索方法的其他許多變體構建到了 ObjectFactory 類中，其中包括基于正則表達式進行搜索的變體、搜索具有特定屬性的控件的第 n 次出現的變體，等等。我們在窗口小部件類中調用了其中多種方法，使窗口小部件類功能更加強大。

回頁首

擴展窗口小部件

到目前為止，我們主要從 HTML 測試角度講述了窗口小部件類。然而，只要對這些窗口小部件類進行很少的更改，就可以將它們用于測試 Java 應用程序。為 Java 應用程序修改這些類時，需要更改使用 getProperty() 從這些方法中查詢到的值，因為這些值經常不同，甚至對于相同類型的控件也是如此。還有其他一些小的差別，但是都很容易通過編碼解決。

為了使窗口小部件類適用于測試 HTML 和 Java 應用程序，我們在 ObjectFactory 類中創建了下列方法：

	public static boolean isHTML(TestObject to) {		String sClass = to.getObjectClassName();		return sClass.indexOf("Html.") != -1;	}

當某一個方法必須調用不同的 Rational Functional Tester API 代碼在 Java 和 HTML 上執行同一操作時，可以使用這個方法測試當前處理的對象是 Java，還是 HTML，然后根據答案調用適當的代碼。這樣，我們可以使用窗口小部件類測試 Java 或 HTML 應用程序。

您可能發現您所擁有的 Java 控件可以擴展本文前面所述標準控件功能。在出現這種情況時，可以創建新的窗口小部件類，該類繼承控件所基于的標準窗口小部件的功能，然后添加新的控件所需的額外功能。例如，在 Java 中，有一些合并了列表框和文本字段功能的實際的組合框。為處理這些組合框，我們創建了 ComboBox 窗口小部件類，該類將繼承 ListBox 并添加 setText() 方法。

此外，您還可能發現應用程序在使用一些定制控件，這些控件提供更廣泛的功能。也就是說，開發人員可能在內部創建原始控件。有時可以使用 Rational Functional Tester's GuiTestObject 提供的基本方法（例如，click()、getChildren() 等）操作這類控件。在這種情況下，可以創建封裝器方法來調用這些 GuiTestObject 方法。

然而，為了有效地操作定制控件，常常需要獲得 Java 控件的內容信息，通過該控件的公共方法就可以訪問這些信息。幸運的是，Rational Functional Tester 提供了接口，通過該接口可以調用某個 Java 控件的任何公共方法，這個控件就是 TestObject 的 invoke() 方法。遇到這種情況時，可以將定制控件封裝到其自己的窗口小部件類中，根據需要繼承其他標準窗口小部件，然后將 invoke() 調用封裝到該類的方法中。

為了使用簡單的例子進行說明，我們的開發人員創建了 Java applet，向用戶提供了一個富文本字段。在該字段中，用戶不僅可以輸入文本，而且還可以使文本顯示為粗體、斜體或為文本加上下劃線，并使用不同的顏色和字體，等等。該控件如下所示：

測試此控件時，我們不但希望使控件內的文本成為斜體或粗體（這可以通過單擊一個按鈕來完成），而且還希望查詢控件當前是否設為使文本成為斜體、粗體或其他任何形式。要實現這項操作，需要訪問該控件內部的 Java 方法。我們請開發人員將需要調用的方法變為公共性質，以便公開這些方法，然后我們可以使用 Rational Functional Tester 的 invoke() 方法來訪問它們，如下所示：

	public boolean isBold()	{		return ((Boolean)getBoldButton().invoke("getSelected"))		   .booleanValue();	}

當然，這個類中還有許多其他方法，它們對控件內的公共方法使用相似的調用，對于應用程序中的其他所有 Java applet 控件，都有匹配的窗口小部件類。此外，這個簡單的例子顯示了如何將 invoke() 調用封裝到窗口小部件類的方法內，使腳本代碼更易于編寫和維護。

我們的一個同事使用這項技術創建了用于測試 SWT (Standard Widget Toolkit 控件的窗口小部件類，這些控件是 IBM 創建的一組特殊的 Java GUI 控件，應用于 Eclipse 應用程序中。通過使用將 invoke() 調用封裝到窗口小部件類的方法中這項技術，可以更容易地對這些 SWT 控件的自動化操作進行編碼。因為 IBM 對 SWT 控件的使用非常廣泛，所以這些窗口小部件使我們受益匪淺。

回頁首

對比擁有窗口小部件和沒有窗口小部件的 Rational Functional Tester 代碼

一切都已就緒，現在，我們可以通過一個簡單的例子，說明使用窗口小部件類可以獲得的效率。假設您想對在下列 IBM Workplace 頁面中創建 Team Space 的操作進行自動化，那么需要執行以下步驟：

要使用 Rational Functional Tester 的記錄機制，請執行下列步驟：

1. 在 Name 字段中單擊鼠標并輸入名稱。
2. 通過單擊選擇 Template。
3. 在 Description 文本字段輸入描述文本。
4. 單擊 OK 按鈕來創建 Team Space。

然后需要添加多行代碼，進行正確的測試驗證和結果記錄。完成上述操作后，Rational Functional Tester 記錄的代碼將如下所示：

browser_htmlBrowser(document_ibmWorkplace(),DEFAULT_FLAGS)			   .click(atPoint(452,14));button_newButton().click();text_cdoName().click(atPoint(85,10));browser_htmlBrowser(document_ibmWorkplace2(),DEFAULT_FLAGS)   .inputChars("TestSpace1");text_cdoName_textVP().performTest();logInfo("Enter text:  TestSpace1");list_templates().click(atText("Discussion"));list_templatesVP().performTest();logInfo("Selected Discussion Template");text_nDescription().click(atPoint(33,13));browser_htmlBrowser(document_ibmWorkplace2(),DEFAULT_FLAGS).inputChars   ("This is a test space");text_nDescription_textVP().performTest();logInfo("Enter text: This is a test space into the Description text area");button_oKbutton().click();

另一方面，要使用窗口小部件封裝器類生成相同的測試自動化，只需輸入下列五行代碼即可：

new Button(button_newButton()).click();new TextField(text_cdoName()).setText("TestSpace1");new ListBox(list_templates()).select("Discussion");new TextField(text_nDescription()).setText("This is a test space");new Button(button_oKbutton()).click();

后面的代碼示例使用了窗口小部件封裝器類，看上去要直觀得多，并且生成相同測試案例所需的編碼要少得多。在 IBM，我們已經將驗證和記錄直接構建到窗口小部件類中，所以在使用我們的窗口小部件類版本時，不需要那些額外的代碼。

當然，這是非常簡單的例子，僅涉及一個非常簡單的測試案例。請想像一下，如果正在編寫數百個測試案例，用它們來測試整個 IBM Workplace 特征區域，或者編寫數千個測試案例來測試整個產品系列，將會獲得怎樣的生產效率和可維護性！

回頁首

結束語

通過將復雜的 Rational Functional Tester API 代碼封裝到窗口小部件類的方法中，我們使腳本的手工編碼更加容易。對于文本字段和列表框，這些益處是顯而易見的。即使對于其他控件，也有一些雖然輕微但很重要的益處。首先，它使獲取控件的屬性變得容易得多。其次，它可以用簡單的方法動態構造對象，對于測試動態 Web 應用程序（比如 IBM Workplace Collaboration Services），以及對于確保隨著屬性發生變化，自動化代碼不會因為每次的構建操作而遭到破壞，這種構造方式可以使它們從中受益。第三，它提供了基礎設施，基于該基礎設施可以擴展窗口小部件類來包括定制控件。

因為所有這些原因，我們的窗口小部件類在 IBM 中非常流行。10 多個國家/地區的不同團隊中的成百上千的人都在使用這些類。它們已經極大地提高了快速創建更有效的自動測試的能力。如果您像我們一樣發現某些應用程序需要大量手工編碼，那么我們建議您創建自己的窗口小部件類集合，以簡化編寫的代碼。

參考資料

• 您可以參閱本文在 developerWorks 全球站點上的 英文原文 。
  
  
• 有關 Rational Functional Tester 的詳細信息，請參閱其 產品頁。
  
  
• 有關 Super Helpers 的信息，請參閱 developerWorks：Rational 中的“Creating a super helper class in Rational XDE Tester”一文。
  
  
• 要查看 ListBox 窗口小部件類，請參閱 this sidefile。
  
  
• 通過參與 developerWorks blogs 加入 developerWorks 社區。
  
  
• 在 Developer Bookstore 的 Lotus 專區中購買 打折出售的 Lotus 書籍。
  

作者簡介

		Tim Snow 領導 Notes 客戶機的 Automation Services 團隊。自從 2003 年，他已經率先轉換到 Rational Functional Tester。Tim 具有豐富的知識背景，從 Java 和 C++ 編程，到設計專家系統，再到分析哲學的博士學位。

		Tony Venditti 是 IBM Workplace 的 GUI 自動化架構師。自從 1989 年以來，Tony 一直在從事軟件自動化工作和開發工具，工作過的公司有 Lotus Development Corporation、Iris Associates、Fidelity Investments、Avid Technology 和 IBM。最近，Tony 率先開始在 IBM 內實現和使用 Rational Functional Tester。

文章來源于領測軟件測試網 http://www.k11sc111.com/

TAG: functional rational tester api