一個良好的自動化測試框架應該具備靈活的,與應用程序無關的,與技術無關和不過時的特點。本文強調的準則可以幫助開發者深層分析測試方案中的代碼。這種能力已經被證明在多個自動化項目上是有效的。
“自動化框架”這個術語已經為軟件測試領域所熟知。盡管很多人都把它與應用在基于UI自動化的技術聯系起來,但是它幾乎總是被濫用于那些參與測試領域。這大部分的原因是由于大家對自動化框架的應用領域有誤解。它應該不僅僅像Coded UI那樣,只是一個單純的UI技術。
現在,市場上有很多商業性的和開源的測試自動化框架。使用這些框架的主要問題在于調整他們的學習曲線和滿足自動化項目的要求的困難性。雖然有一些廣泛應用的遺留框架,但是他們還是有很多缺點。
他們缺乏靈活性,再使用昂貴的第三方產品——或者,添加一個單純的現有用戶界面技術,但不提供額外的價值。
一個良好的自動化測試框架應該具備靈活的,與應用程序無關的,與技術無關和不過時的特點。它應該支持一個易于安裝和使用的結構化和模塊化的編程模型。說“易于使用”,我們是假設和期望用戶是有經驗的軟件開發人員。自動化是發展和正確的軟件工程技能,對于計劃和成功得實施一套自動化是有需要的。
開發一個基于UI功能自動化系統背后的想法是,運用這一框架來提高代碼的可重用性、穩定性和可維護性。該代碼應該是容易編寫、調試、部署和運行,發生失敗應該易于分析。不管你使用Ranorex,Coded UI,Telerik或Selenium
作為底層自動化技術,設計和實現自動化的解決方案都應該是相同的。我們選擇去建議和實施的范式和模式是任何開發項目的最佳實踐,但他們對于UI自動化尤其有用。
我們已經在外面公司對幾個不同的項目創建了自動化框架。在一些類似的模式中,我們可以提取其中的相同之處。這些項目的主要問題與方法和可重用性的不同相關。除此之外,不同的團隊通過使用不同的自動化工具來測試應用程序功能,這也導致了整體的難度。
一般來說,一個自動化框架可以被定義為一套可以為自動化軟件測試提供支持的假設、概念和工具。它有以下的功能:
﹒定義自動化測試腳本的方法
﹒提供建立聯系機制SUT(測試系統)
﹒執行測試和報告結果
﹒減少自動化項目啟動時間
﹒建立一個共同的標準
基本原則
讓我們假設我們有一個具有豐富的用戶界面和大量的控制的復雜的應用程序,但它只有兩個屏幕。應用程序是復雜的事實可能意味著它可以有幾十個手動功能測試例子。所有這些使用相同的兩個屏幕。那么,我們怎樣才能增加這樣的測試解決方案的可維護性?
分層架構模式
把軟件系統體系結構分解為單獨的一層的想法是非常普遍的。第一個是邏輯展示層面,,第二個是業務邏輯層面,第三個層次是負責數據存儲。使用這種模式可以降低應用程序的維護成本從每一層內的組件可以改變而不影響其他的水平。同樣的方法可以應用于測試系統。
測試代碼可以分為三層:
•為UI自動化工具訪問被測系統的接口層
•邏輯功能層
每一層執行某項任務時都有一個降低測試的費用維護和促進創造一個新的測試的共同的目標。
圖1:架構原型,測試系統的多層體系結構
Page Object
根據每個單獨的測試案例來創建單獨的測試邏輯、業務庫和UI Map,為我們提供了特殊能力來修改當前測試用例。
讓我們假設我們的應用程序是web郵件服務Gmail,并且兩個屏幕之一是登錄屏幕。登錄流程被所有測試用例中所使用。(例如,為了得到第二個屏幕,您需要執行首先登錄到應用程序)。
圖2:谷歌郵件登錄
讓我們假定UI中有一些東西改變了,但是不合邏輯的。在我們的特定情況下,每個登錄進入Gmail的現在需要輸入驗證碼。
圖3:谷歌郵件登錄與驗證碼
這意味著每個測試案例現在應該更新為新的登錄流程。但是一般來說,這只符合邏輯地更新一段代碼。此時Page Object和功能方法模式的作用就顯而易見。如果只有一個頁面對象宣布登錄屏幕和一個登錄方法,只需要兩個參數(即登錄名和密碼),然后只有身體的登錄功能方法需要更新,以涵蓋所有情況下與這種變化有關。
頁面的無縫銜接
頁面的無縫銜接的實現背后的想法是,在頁面對象的所有方法返回另一個頁面對象類實例(下一個SUT上下文頁面)。例如,登錄方法在我們的樣例返回主應用程序默認的屏幕。它使一系列步驟的功能測試用例編寫一個接一個,使這種用方法去鏈接。因此,業務方法本身就能夠通過IDE的智能感知,為測試腳本的開發人員的代碼提出建議。
面向切面編程
面向切面編程實現方面似乎是很有價值的,特別是如果你需要用特定方法到try-catch塊,或寫報告日志條目進入/退出方法。這種方式,包含面向切面實現方面有助于提高自動化代碼,使它更具可讀性和可以理解的。
構建/運行時驗證
自動化框架也經常建議企業標準。大多數開發人員常將同樣的自動化方案應用在不同的項目上,這是一個十分棘手的問題。所以,自動化框架可以提供一系列設施,去驗證在商業程序庫或者功能測試中的方法是否是最佳方案。
有不同的方法可進行驗證:
• 使用IDE擴展/插件等可能設置自定義構建的規則(例如:ReSharper, StyleCop for Visual Studio)
•編寫自己的ID擴展名
•編寫一個機制,可以驗證測試是否包含預期的屬性在運行,如果有什么不正確的在運行,它將因描述性的錯誤而失敗。
原文轉自:http://www.testwo.com/article/70