他們缺乏靈活性,再使用昂貴的第三方産品——或者,添加一個單純的現有使用者界面技術,但不提供額外的價值。
作為底層自動化技術,設計和實作自動化的解決方案都應該是相同的。我們選擇去建議和實施的範式和模式是任何開發項目的最佳實踐,但他們對于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擴充名
·編寫一個機制，可以驗證測試是否包含預期的屬性在運作，如果有什麼不正确的在運作，它将因描述性的錯誤而失敗。
以下提供一些可被驗證的項目的簡單清單：
·測試腳本的命名
·有适當的注釋/描述
·業務方法的傳回值/參數
·解決方案分層 (确認不會有交叉層次通路沖突在自動化代碼中出現)。
·自動化測試架構的硬體支援
顯然,該架構不能隻包括最佳實踐。沒有人能夠在沒有任何基礎設施來支援他們的情況下繼續做下去。以下提供的是一些有助于更好的了解自動化架構實作的指引。
首先我們需要以某種方式運作測試。在大多數情況下,單元測試架構是用于運作功能測試和衡量結果。有了各種技術/語言的支援，能夠為功能測試代碼和持續內建（ci）系統完美的結合提供了多種選擇的單元測試架構。
為測試運作加載配置
測試配置很大程度上取決于sut域和測試細節。例如,在大多數測試流的所有配置(如參數、遠端連接配接伺服器等)可以隻是在測試腳本中寫死的。
在資料驅動的測試中, 當相同的測試可以使用不同的配置（例如，輸入參數）多次運作的情況下，單元測試架構還提供從外部儲存設備讀取資料測試腳本。
是以，如果需要自定義配置加載的實作你的自動化架構的話，您需要仔細反複檢查。
報告測試結果
報告測試結果/調試測試資訊是自動化架構的最重要的功能之一。
有以下幾個原因:
﹒報告分析簡化了測試應用程式/故障排除,是以你的報告的資訊越多,它提供的支援越好。
﹒報告是所有的項目經手人觀察到的結果。
如果你想跟蹤測試執行在一段時間内的一些動态變化,你應該運用額外的裝置将測試結果永久地儲存到資料庫,這樣就可以作比較。
别忘了把一些花俏的東西放進報告表示層(xml / html)，如公司标志、結構化輸出等。這些事情能夠極大地改善你的管理。如果你提供一個“時間”報告,圖表也需要高度重視。
驗證
再者,大多數單元測試架構已經有一套支援在測試腳本中執行assert/verify的機制。這是一個很好建立自己的驗證機制的實踐,以便:
﹒從一個特定的單元測試架構中抽象用例斷言
﹒為你的需求定制一套驗證方法
﹒添加特定的邏輯到您的驗證方法，讓您的驗證結果自動寫入報告
切面
自動化測試解決方案在不同的項目中大多是類似的。是以為現有解決方案增加自動化架構工具應該是個簡單的事情。如果你想為現有項目提供更多實用價值，使用架構來減少遷移工作是很重要的。
這方面确實很有幫助。隻需添加一個方面屬性定義到一個測試項目,一會兒你就會有一個廣泛的報告機制在您的測試解決方案中激活!當然,它的實作需要一些進階方面,但這絕對是值得的。
關鍵詞
你可能覺得有趣的是,我們在這篇文章中沒有提及任何關鍵字驅動架構。關鍵字市場另一組可用的解決方案,包括商業的和開源的。可以肯定的是,已經有成百上千的自定義關鍵字驅動架構存在。但是,我們發現他們是并不完整的。原因如下:
﹒他們沒有解決測試腳本的可維護性。他們中的大多數介紹是大量重複的。
﹒把關鍵字驅動架構緊密地綁定到特定的自動化工具(或者是一個ui自動化工具)的一部分,這使得在解決方案開發沒有變化。
結論
在本文中,我們描述了我們在自動化架構的實作中的一些經驗。這篇文章強調的一些原則可以提供在深度上分析測試方案的代碼的能力，并被證明在多個自動化項目中是有效的。作為一個例子,其中一個我們已經開發了大約500個業務場景與110個測試用例，每個測試用例平均30步驟（請注意，一步也可以由幾個業務方法調用）。所描述的方法使我們能夠達到每一個業務場景36倍的平均可重用性。
這是由你來決定你的自動化項目使用什麼架構。也許這将是一個簡單的記錄/回放頁面工具與一群或者是一組關鍵字驅動腳本的表格。但是,當涉及到自動化的一百多的測試用例時,您需要證明較高的成熟度級别來實作您的測試解決方案的可維護性。
oleksandr reminnyi作為softserve inc的軟體工程師，softserve inc是一家全球領先的外包産品和應用開發公司。oleksandr reminnyi負責為新的和現有的客戶建立自動化項目和流程。他認為,成功和失敗是完全取決于自動化建立過程是否設定正确的目标。他目前正在他的博士學位緻力于研究自動化。
david krauss擁有超過30年的應用經驗和産品設計和傳遞,與廣泛的程式設計和跨多個平台架構經驗,技術,和語言。精通遺留資産現代化,全球協作開發過程,客戶機/伺服器和網絡平台,測試自動化(一個專利自動化,自動化生成一個專利申請中)。二十多年專業從事自動化測試工具和範例,自動化架構和測試方法。
最新内容請見作者的github頁：http://qaseven.github.io/