解決多通道測試的挑戰

　　簡介： 隨著移動以及有 Web 功能的應用程序的飛速傳播，多通道測試出現了新的挑戰，或是單個測試場景跨幾個界面交叉。業務流程以及這些流程內的任務在更為多樣的平臺上執行，這就要求能夠在界面間無縫移動，尤其是從移動到 Web 以及反向移動。過去曾經有效的那些舉措導致了應對未來的討論。

　　多通道 描述的是具有多個界面的應用程序。隨著我們從桌面發展到基于 Web 的計算甚至是移動計算，多通道越來越常見。由于設備(平板、手機、筆記本電腦、臺式計算機)以及與設備交互方式(特定于設備的 “應用程序”、瀏覽器和傳統的客戶端應用程序)的組合，同一個應用程序的界面越來越多。比如，使用相同業務邏輯的面向 Web 應用程序、移動應用程序甚至是一個 CLI(命令行界面)的銀行應用程序。由于面向服務的架構 (SOA) 和 Web 服務日益流行，在很多情況下，集成者要做的工作就是把服務與新的前端重新組合。但業務邏輯(亦稱服務)則保持相同。

　　以開發團隊重用代碼來減少維護成本并提高生產效率相同的方式，要跟上開發團隊，測試團隊就需要一些方法來重用測試場景并實現自動化。

　　應對多通道測試的挑戰

　　幾年前，我是一名自動化測試架構師，負責為具有多個界面的兩個(而不是一個)應用程序構建所有的自動化。二者都有遺留的 “本地” 用戶界面，使用的是 Microsoft Windows 32 位 MFC (Microsoft Foundation Class) 控件、一個使用了 JavaScript 的 Web 界面、ASP 和 JSP(Active Server Pages 和 JavaServer Pages)、一個新的(更新的)Eclipse SWT (Standard Widget Toolkit) 界面以及一個命令行界面。當然，不可能找到對所有這些界面均有效的自動化工具，但我們可以暫時將其放到一邊。

　　編程時，您往往會專注于通過促進重用減少需要維護的代碼量。有了面向對象的編程和重構，很少有理由需要在多個地方具有相同的代碼了。但是需要設計一個架構，這樣我就可以考慮如何從一個單一的測試自動化代碼庫解決多個界面的測試。首先，盡管它們是同一個應用程序的所有界面，但并不是所有的界面都會浮現相同的功能，更不用說使用同樣的方式了。但也有許多以客戶為中心的場景(用例)，這對跨所有界面進行測試很有意義。

　　然而，負責設計測試用例和測試計劃的測試團隊沒有以這種方式考慮他們的測試。事實上，他們是分離的，并根據他們所要處理的界面以豎井方式分離。構建并測試了該 CLI 的團隊認為他們只需要少量的客戶場景測試。他們主要集中于單元測試，并沒有真正考慮通過 CLI 的一個客戶流。負責 Eclipse UI 的測試團隊想要大量的 UI 特性和自動化的功能。他們有一長串需要執行的測試用例，要實現這個目標，需要完全專注于客戶流。但是，我們為什么就不能使用由主題專家 (SME) 為應用程序煞費苦心完成的用來測試所有界面的這些信息呢?

　　一種層次結構方式

　　使用面向對象的編程 (OOP) 的典型測試自動化框架一般會抽象化控制集的實現細節，而不是通過控件表達的概念性操作。這實際上是許多商業 GUI 自動化工具使用的方式。例如，所有文本字段會接受文本，用 setText(string) 方法定義一個文本字段類，并在此應用程序的所有版本上使用它。但這并不適用于跨界面構建自動化測試的所有情況。當一個 GUI 使用單選按鈕而另一個使用復選框時會發生什么呢?您實際上不能對于相同操作依靠于同一界面。以下顯示了這種傳統的 OOP 方式。

　　圖 1. GUI 控制層次結構

　　在我們的示例中，界面的差異很大，但所代表的操作和業務流程則實質上相同。為了最大化重用，我們選定了一個業務邏輯層次結構(參見圖 2)以跨多個界面重用測試場景。這不僅能最大化我們的代碼重用，還意味著將會依賴測試工具來管理 GUI 界面，而這正是他們的設計初衷。圖 2 顯示了此方式，您可能已經識別出了這個抽象工廠模式。

　　圖 2. 業務邏輯層次結構

　　通過采用業務邏輯的方式，通過應用程序的每個流都可以表示成操作集，而操作又被定義為抽象類上的方法。雖然每個界面都可能在操作內具有一些不同的步驟，但它們都允許、理解和需要這些相同的操作。這就相當于為了測試而構建一個特定于應用程序的測試框架來代表測試業務任務下的這個應用程序。這種方法意味著要定義一組對象，在應用程序中執行操作所需的數據和信息就可以封裝在對象之中。然后，我們需要在這些對象內定義一組方法來描述操作，并收集操作專門需要的任何額外的數據，如圖 3 中的代碼片段所定義的。

　　圖 3. 抽象類的代碼示例

　　以文本表單格式查看圖 3 的代碼

　　Query 是一個抽象類，收集創建和執行查詢所需的有趣數據，以及有趣操作，如運行、創建、編輯和重命名。重命名方法需要新名稱的額外參數，但當它成功后，會自動更新此查詢對象的名稱值。在這個級別對用戶界面沒有假設。用戶界面的細節只在特定于界面的具體類內表達。要在一個給定的界面上執行，需要在運行時為每個界面實例化一個具體類并調用此操作，具體類似于如下所示：

Query myQuery = (parent_location, findRecords);
myQuery.rename(renamedQuery); 

原文轉自：http://www.ibm.com/developerworks/cn/rational/multichannel-testing-challenge/index.html