簡介：隨著移動以及有 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. 抽象類的代碼示例
Query 是一個抽象類，收集創建和執行查詢所需的有趣數據，以及有趣操作，如運行、創建、編輯和重命名。重命名方法需要新名稱的額外參數，但當它成功后，會自動更 新此查詢對象的名稱值。在這個級別對用戶界面沒有假設。用戶界面的細節只在特定于界面的具體類內表達。要在一個給定的界面上執行，需要在運行時為每個界面 實例化一個具體類并調用此操作，具體類似于如下所示：
Query myQuery = (parent_location, findRecords);
myQuery.rename(renamedQuery); |
基于應用程序的框架
定義用來描述測試所需操作的抽象業務邏輯類的一個后果是可以將所定義的方法重組成新的流。此外，還可以指定在運行時運行哪個界面。這是一個強大的組合，可以完成幾件事情：
● 針對此應用程序的操作只定義一次
● GUI元素只被發現和處理一次
● 為一個界面設計的測試場景可以在另一個界面上運行
● 因重用的增加，維護顯著減少
當然，這其中的訣竅是在每個要測試的界面內如何對任何給定的操作進行編碼。這需要面對大量的工作，但在一個界面完成后，有許多測試腳本可用于任何其他的界面。而這就是必須為每個后續界面要實現的全部步驟：
● 添加在該界面上執行操作所需的實際步驟
● 補充此框架來涵蓋其他界面內所沒有的任何功能
該方法的另一個好處是：盡管仍然被表示為代碼，但它在一個足夠高的抽象級別可讀取為偽代碼，這對非編程人員 SME 很有意義。這讓非編程人員能夠創建新的自動化腳本，以及運行和理解自動化團隊所交付的測試腳本。
清單 1 是與 Eclipse 視圖交互的一個示例代碼。
清單 1. 與 Eclipse 視圖交互的代碼
Perspective resource = new Perspective("Resource");
Perspective general = new Perspective("General");
app.start();
EclipseView bookmarks = new EclipseView("Bookmarks", resource);
EclipseView explorer = new EclipseView("Project Explorer",general);
resource.open();
resource.reset();
bookmarks.open();
explorer.open();
bookmarks.switchTo();
explorer.switchTo();
bookmarks.maximize();
bookmarks.restore();
bookmarks.minimize();
bookmarks.restore();
bookmarks.close();
resource.reset();
app.exit(); |
采用這種方法可以降低維護成本，并能確保對于 GUI 的任何部分，在自動化測試代碼內都只需在一個地方進行調整。但這種方法的好處只有在 CLI 上實現了進行業務邏輯的具體步驟之后才會變得真正清晰。
負責測試該特性的團隊已宣布 “完成”，且沒有明顯的缺陷。自動化的實現是為了為未來版本確保一個回歸測試套件。但是當我們運行用來針對此 CLI 實現測試 GUI 的測試腳本時，就會發現 50 多個缺陷！這些都是重要的缺陷，肯定會被我們的客戶發現。
作為測試人員，我們總是很興奮能首先發現缺陷，因為早期發現問題能明顯節約成本。另外，構建不只能驗證產品穩定性的測試自動化也很令人興奮。同樣重要的就是信譽、既有的顧客滿意度，以及此測試自動化所帶來的整體質量改進方面的商業利益。
如今的多通道測試
在上述的項目過程中，我們可以在運行時只選擇一個界面。一個測試腳本必須是完全自動化的，且必須要有為每個需要測試的界面實現的一個完整的業務 邏輯操作集。這種方式在當時是合理的也是可以接受的，這是因為最終用戶一般不會在一組操作期間從一個桌面客戶端切換到一個 Web 客戶端。
但時過境遷。現在考慮一個可能開始于 Web 客戶端、穿過一個移動應用程序、然后再回到 Web 的測試場景，甚或是一個針對數據庫后端的獨立驗證已不再符合實際了。
考慮這樣一個場景：有人在 eBay 競價。使用一個臺式計算機和瀏覽器（Web 客戶端）對商品進行搜索和研究更容易。一旦決定了想要的商品，就可以進行競價。您可以離開計算機，并在您的智能手機收到一個通知，告知您競價勝出，于是您 從手機上更新出價。當贏得競價時，您再回到計算機前，在瀏覽器中輸入付款信息。
這是一個測試場景，與其從屏幕上此界面的一個部分（使用屏幕抓取或對象屬性）中驗證交易的成功，還不如直接使用數據庫并檢查記錄。這種獨立于界 面的驗證更健壯，也更穩定。我們可以把這種方式稱為 “混合” 測試場景。并且，從理論上來說，當自動化一些產品區域太難（或過于昂貴）時，混合場景應該允許混合進手動測試執行來提高測試覆蓋率。
所以，我已經開始幻想如何能實現這樣一個流，于是我將不同的界面和操作實現拼裝成一個能在界面之間無縫移動的復雜流。可以肯定的是，的確存在挑 戰，并且挑戰可能會不可逾越。而了解了當運行時環境受制約時哪些數據在操作間移動則會相對簡單得多。而當跨越界面時，哪些數據可能需要在操作間傳輸則不能 立即清晰。使用上面的示例，將需要先登錄到一個 Web 客戶端和移動電話。身份驗證明顯是個問題，但實現這些混合測試場景注定會有很多并發問題。