解決多通道測試的挑戰(2)

　　基于應用程序的框架

　　定義用來描述測試所需操作的抽象業務邏輯類的一個后果是可以將所定義的方法重組成新的流。此外，還可以指定在運行時運行哪個界面。這是一個強大的組合，可以完成幾件事情：

　　針對此應用程序的操作只定義一次

　　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 客戶端。

　　但時過境遷?，F在考慮一個可能開始于 Web 客戶端、穿過一個移動應用程序、然后再回到 Web 的測試場景，甚或是一個針對數據庫后端的獨立驗證已不再符合實際了。

　　考慮這樣一個場景：有人在 eBay 競價。使用一個臺式計算機和瀏覽器(Web 客戶端)對商品進行搜索和研究更容易。一旦決定了想要的商品，就可以進行競價。您可以離開計算機，并在您的智能手機收到一個通知，告知您競價勝出，于是您從手機上更新出價。當贏得競價時，您再回到計算機前，在瀏覽器中輸入付款信息。

　　這是一個測試場景，與其從屏幕上此界面的一個部分(使用屏幕抓取或對象屬性)中驗證交易的成功，還不如直接使用數據庫并檢查記錄。這種獨立于界面的驗證更健壯，也更穩定。我們可以把這種方式稱為 “混合” 測試場景。并且，從理論上來說，當自動化一些產品區域太難(或過于昂貴)時，混合場景應該允許混合進手動測試執行來提高測試覆蓋率。

　　所以，我已經開始幻想如何能實現這樣一個流，于是我將不同的界面和操作實現拼裝成一個能在界面之間無縫移動的復雜流?？梢钥隙ǖ氖?，的確存在挑戰，并且挑戰可能會不可逾越。而了解了當運行時環境受制約時哪些數據在操作間移動則會相對簡單得多。而當跨越界面時，哪些數據可能需要在操作間傳輸則不能立即清晰。使用上面的示例，將需要先登錄到一個 Web 客戶端和移動電話。身份驗證明顯是個問題，但實現這些混合測試場景注定會有很多并發問題。

　　但沒有關系，那不過是一個珠穆朗瑪峰。讓我們出發吧!通過加入 LinkedIn 上的 IBM Rational Functional Tester Network 討論組 參與討論，或對本文提出建議來告訴我們您的想法，或添加您的意見。