創建一個有效的GUI自動化框架(2)

　　以下提供一些可被驗證的項目的簡單列表：

　　•測試腳本的命名

　　•有適當的注釋/描述

　　•業務方法的返回值/參數

　　•解決方案分層 (確認不會有交叉層次訪問沖突在自動化代碼中出現)。

　　自動化測試框架的硬件支持

　　顯然,該框架不能只包括最佳實踐。沒有人能夠在沒有任何基礎設施來支持他們的情況下繼續做下去。以下提供的是一些有助于更好的理解自動化框架實現的指引。

　　首先我們需要以某種方式運行測試。在大多數情況下,單元測試框架是用于運行功能測試和衡量結果。有了各種技術/語言的支持，能夠為功能測試代碼和持續集成(CI)系統完美的結合提供了多種選擇的單元測試框架。

　　為測試運行加載配置

　　測試配置很大程度上取決于SUT域和測試細節。例如,在大多數測試流的所有配置(如參數、遠程連接服務器等)可以只是在測試腳本中寫死的。

　　在數據驅動的測試中, 當相同的測試可以使用不同的配置(例如，輸入參數)多次運行的情況下，單元測試框架還提供從外部存儲設備讀取數據測試腳本。

　　因此，如果需要自定義配置加載的實現你的自動化框架的話，您需要仔細反復檢查。

　　報告測試結果

　　報告測試結果/調試測試信息是自動化框架的最重要的功能之一。

　　有以下幾個原因:

　　﹒報告分析簡化了測試應用程序/故障排除,所以你的報告的信息越多,它提供的支持越好。

　　﹒報告是所有的項目經手人觀察到的結果。

　　如果你想跟蹤測試執行在一段時間內的一些動態變化,你應該運用額外的設備將測試結果永久地保存到數據庫,這樣就可以作比較。

　　別忘了把一些花俏的東西放進報告表示層(xml / html)，如公司標志、結構化輸出等。這些事情能夠極大地改善你的管理。如果你提供一個“時間”報告,圖表也需要高度重視。

　　驗證

　　再者,大多數單元測試框架已經有一套支持在測試腳本中執行Assert/Verify的機制。這是一個很好創建自己的驗證機制的實踐,以便:

　　﹒從一個特定的單元測試框架中抽象用例斷言

　　﹒為你的需求定制一套驗證方法

　　﹒添加特定的邏輯到您的驗證方法，讓您的驗證結果自動寫入報告

　　切面

　　自動化測試解決方案在不同的項目中大多是類似的。所以為現有解決方案增加自動化框架工具應該是個簡單的事情。如果你想為現有項目提供更多實用價值，使用框架來減少遷移工作是很重要的。

　　這方面確實很有幫助。只需添加一個方面屬性定義到一個測試項目,一會兒你就會有一個廣泛的報告機制在您的測試解決方案中激活!當然,它的實現需要一些高級方面,但這絕對是值得的。

　　關鍵詞

　　你可能覺得有趣的是,我們在這篇文章中沒有提及任何關鍵字驅動框架。關鍵字市場另一組可用的解決方案,包括商業的和開源的?？梢钥隙ǖ氖?已經有成百上千的自定義關鍵字驅動框架存在。但是,我們發現他們是并不完整的。原因如下:

　　﹒他們沒有解決測試腳本的可維護性。他們中的大多數介紹是大量重復的。

　　﹒把關鍵字驅動框架緊密地綁定到特定的自動化工具(或者是一個UI自動化工具)的一部分,這使得在解決方案開發沒有變化。

　　結論

　　在本文中,我們描述了我們在自動化框架的實現中的一些經驗。這篇文章強調的一些原則可以提供在深度上分析測試方案的代碼的能力，并被證明在多個自動化項目中是有效的。作為一個例子,其中一個我們已經開發了大約500個業務場景與110個測試用例，每個測試用例平均30步驟(請注意，一步也可以由幾個業務方法調用)。所描述的方法使我們能夠達到每一個業務場景36倍的平均可重用性。

　　這是由你來決定你的自動化項目使用什么框架。也許這將是一個簡單的記錄/回放頁面工具與一群或者是一組關鍵字驅動腳本的表格。但是,當涉及到自動化的一百多的測試用例時,您需要證明較高的成熟度級別來實現您的測試解決方案的可維護性。

　　Oleksandr Reminnyi作為SoftServe Inc的軟件工程師，SoftServe Inc是一家全球領先的外包產品和應用開發公司。Oleksandr Reminnyi負責為新的和現有的客戶建立自動化項目和流程。他認為,成功和失敗是完全取決于自動化建立過程是否設定正確的目標。他目前正在他的博士學位致力于研究自動化。

　　David Krauss擁有超過30年的應用經驗和產品設計和交付,與廣泛的編程和跨多個平臺架構經驗,技術,和語言。精通遺留資產現代化,全球協作開發過程,客戶機/服務器和網絡平臺,測試自動化(一個專利自動化,自動化生成一個專利申請中)。二十多年專業從事自動化測試工具和范例,自動化框架和測試方法。

原文轉自：http://www.testwo.com/article/70