作為底層自動化技術(shù),設(shè)計和實(shí)現(xiàn)自動化的解決方案都應(yīng)該是相同的。我們選擇去建議和實(shí)施的范式和模式是任何開發(fā)項(xiàng)目的最佳實(shí)踐,但他們對于UI自動化尤其有用。
我們已經(jīng)在外面公司對幾個不同的項(xiàng)目創(chuàng)建了自動化框架。在一些類似的模式中,我們可以提取其中的相同之處。這些項(xiàng)目的主要問題與方法和可重用性的不同相關(guān)。除此之外,不同的團(tuán)隊(duì)通過使用不同的自動化工具來測試應(yīng)用程序功能,這也導(dǎo)致了整體的難度。
把軟件系統(tǒng)體系結(jié)構(gòu)分解為單獨(dú)的一層的想法是非常普遍的。第一個是邏輯展示層面，,第二個是業(yè)務(wù)邏輯層面,第三個層次是負(fù)責(zé)數(shù)據(jù)存儲。使用這種模式可以降低應(yīng)用程序的維護(hù)成本從每一層內(nèi)的組件可以改變而不影響其他的水平。同樣的方法可以應(yīng)用于測試系統(tǒng)。
每一層執(zhí)行某項(xiàng)任務(wù)時都有一個降低測試的費(fèi)用維護(hù)和促進(jìn)創(chuàng)造一個新的測試的共同的目標(biāo)。
圖1:架構(gòu)原型,測試系統(tǒng)的多層體系結(jié)構(gòu)
Page Object
根據(jù)每個單獨(dú)的測試案例來創(chuàng)建單獨(dú)的測試邏輯、業(yè)務(wù)庫和UI Map，為我們提供了特殊能力來修改當(dāng)前測試用例。
讓我們假設(shè)我們的應(yīng)用程序是web郵件服務(wù)Gmail，并且兩個屏幕之一是登錄屏幕。登錄流程被所有測試用例中所使用。(例如,為了得到第二個屏幕,您需要執(zhí)行首先登錄到應(yīng)用程序)。
圖2:谷歌郵件登錄
讓我們假定UI中有一些東西改變了,但是不合邏輯的。在我們的特定情況下,每個登錄進(jìn)入Gmail的現(xiàn)在需要輸入驗(yàn)證碼。
圖3:谷歌郵件登錄與驗(yàn)證碼
這意味著每個測試案例現(xiàn)在應(yīng)該更新為新的登錄流程。但是一般來說,這只符合邏輯地更新一段代碼。此時Page Object和功能方法模式的作用就顯而易見。如果只有一個頁面對象宣布登錄屏幕和一個登錄方法,只需要兩個參數(shù)(即登錄名和密碼),然后只有身體的登錄功能方法需要更新,以涵蓋所有情況下與這種變化有關(guān)。
頁面的無縫銜接
頁面的無縫銜接的實(shí)現(xiàn)背后的想法是,在頁面對象的所有方法返回另一個頁面對象類實(shí)例(下一個SUT上下文頁面)。例如,登錄方法在我們的樣例返回主應(yīng)用程序默認(rèn)的屏幕。它使一系列步驟的功能測試用例編寫一個接一個,使這種用方法去鏈接。因此，業(yè)務(wù)方法本身就能夠通過IDE的智能感知，為測試腳本的開發(fā)人員的代碼提出建議。
面向切面編程
面向切面編程實(shí)現(xiàn)方面似乎是很有價值的,特別是如果你需要用特定方法到try-catch塊,或?qū)憟蟾嫒罩緱l目進(jìn)入/退出方法。這種方式,包含面向切面實(shí)現(xiàn)方面有助于提高自動化代碼,使它更具可讀性和可以理解的。
構(gòu)建/運(yùn)行時驗(yàn)證
自動化框架也經(jīng)常建議企業(yè)標(biāo)準(zhǔn)。大多數(shù)開發(fā)人員常將同樣的自動化方案應(yīng)用在不同的項(xiàng)目上，這是一個十分棘手的問題。所以，自動化框架可以提供一系列設(shè)施，去驗(yàn)證在商業(yè)程序庫或者功能測試中的方法是否是最佳方案。
有不同的方法可進(jìn)行驗(yàn)證：
·使用IDE擴(kuò)展/插件等可能設(shè)置自定義構(gòu)建的規(guī)則(例如：ReSharper, StyleCop for Visual Studio)
·編寫自己的ID擴(kuò)展名
·編寫一個機(jī)制，可以驗(yàn)證測試是否包含預(yù)期的屬性在運(yùn)行，如果有什么不正確的在運(yùn)行，它將因描述性的錯誤而失敗。
以下提供一些可被驗(yàn)證的項(xiàng)目的簡單列表：
·測試腳本的命名
·有適當(dāng)?shù)淖⑨?描述
·業(yè)務(wù)方法的返回值/參數(shù)
·解決方案分層 (確認(rèn)不會有交叉層次訪問沖突在自動化代碼中出現(xiàn))。
·自動化測試框架的硬件支持
顯然,該框架不能只包括最佳實(shí)踐。沒有人能夠在沒有任何基礎(chǔ)設(shè)施來支持他們的情況下繼續(xù)做下去。以下提供的是一些有助于更好的理解自動化框架實(shí)現(xiàn)的指引。
首先我們需要以某種方式運(yùn)行測試。在大多數(shù)情況下,單元測試框架是用于運(yùn)行功能測試和衡量結(jié)果。有了各種技術(shù)/語言的支持，能夠?yàn)楣δ軠y試代碼和持續(xù)集成（CI）系統(tǒng)完美的結(jié)合提供了多種選擇的單元測試框架。
為測試運(yùn)行加載配置
測試配置很大程度上取決于SUT域和測試細(xì)節(jié)。例如,在大多數(shù)測試流的所有配置(如參數(shù)、遠(yuǎn)程連接服務(wù)器等)可以只是在測試腳本中寫死的。
在數(shù)據(jù)驅(qū)動的測試中, 當(dāng)相同的測試可以使用不同的配置（例如，輸入?yún)?shù)）多次運(yùn)行的情況下，單元測試框架還提供從外部存儲設(shè)備讀取數(shù)據(jù)測試腳本。
因此，如果需要自定義配置加載的實(shí)現(xiàn)你的自動化框架的話，您需要仔細(xì)反復(fù)檢查。
報告測試結(jié)果
報告測試結(jié)果/調(diào)試測試信息是自動化框架的最重要的功能之一。
有以下幾個原因:
﹒報告分析簡化了測試應(yīng)用程序/故障排除,所以你的報告的信息越多,它提供的支持越好。
﹒報告是所有的項(xiàng)目經(jīng)手人觀察到的結(jié)果。
如果你想跟蹤測試執(zhí)行在一段時間內(nèi)的一些動態(tài)變化,你應(yīng)該運(yùn)用額外的設(shè)備將測試結(jié)果永久地保存到數(shù)據(jù)庫,這樣就可以作比較。
別忘了把一些花俏的東西放進(jìn)報告表示層(xml / html)，如公司標(biāo)志、結(jié)構(gòu)化輸出等。這些事情能夠極大地改善你的管理。如果你提供一個“時間”報告,圖表也需要高度重視。
驗(yàn)證
再者,大多數(shù)單元測試框架已經(jīng)有一套支持在測試腳本中執(zhí)行Assert/Verify的機(jī)制。這是一個很好創(chuàng)建自己的驗(yàn)證機(jī)制的實(shí)踐,以便:
﹒從一個特定的單元測試框架中抽象用例斷言
﹒為你的需求定制一套驗(yàn)證方法
﹒添加特定的邏輯到您的驗(yàn)證方法，讓您的驗(yàn)證結(jié)果自動寫入報告
切面
自動化測試解決方案在不同的項(xiàng)目中大多是類似的。所以為現(xiàn)有解決方案增加自動化框架工具應(yīng)該是個簡單的事情。如果你想為現(xiàn)有項(xiàng)目提供更多實(shí)用價值，使用框架來減少遷移工作是很重要的。
這方面確實(shí)很有幫助。只需添加一個方面屬性定義到一個測試項(xiàng)目,一會兒你就會有一個廣泛的報告機(jī)制在您的測試解決方案中激活!當(dāng)然,它的實(shí)現(xiàn)需要一些高級方面,但這絕對是值得的。
關(guān)鍵詞
你可能覺得有趣的是,我們在這篇文章中沒有提及任何關(guān)鍵字驅(qū)動框架。關(guān)鍵字市場另一組可用的解決方案,包括商業(yè)的和開源的。可以肯定的是,已經(jīng)有成百上千的自定義關(guān)鍵字驅(qū)動框架存在。但是,我們發(fā)現(xiàn)他們是并不完整的。原因如下:
﹒他們沒有解決測試腳本的可維護(hù)性。他們中的大多數(shù)介紹是大量重復(fù)的。
﹒把關(guān)鍵字驅(qū)動框架緊密地綁定到特定的自動化工具(或者是一個UI自動化工具)的一部分,這使得在解決方案開發(fā)沒有變化。
結(jié)論
在本文中,我們描述了我們在自動化框架的實(shí)現(xiàn)中的一些經(jīng)驗(yàn)。這篇文章強(qiáng)調(diào)的一些原則可以提供在深度上分析測試方案的代碼的能力，并被證明在多個自動化項(xiàng)目中是有效的。作為一個例子,其中一個我們已經(jīng)開發(fā)了大約500個業(yè)務(wù)場景與110個測試用例，每個測試用例平均30步驟（請注意，一步也可以由幾個業(yè)務(wù)方法調(diào)用）。所描述的方法使我們能夠達(dá)到每一個業(yè)務(wù)場景36倍的平均可重用性。
這是由你來決定你的自動化項(xiàng)目使用什么框架。也許這將是一個簡單的記錄/回放頁面工具與一群或者是一組關(guān)鍵字驅(qū)動腳本的表格。但是,當(dāng)涉及到自動化的一百多的測試用例時,您需要證明較高的成熟度級別來實(shí)現(xiàn)您的測試解決方案的可維護(hù)性。
Oleksandr Reminnyi作為SoftServe Inc的軟件工程師，SoftServe Inc是一家全球領(lǐng)先的外包產(chǎn)品和應(yīng)用開發(fā)公司。Oleksandr Reminnyi負(fù)責(zé)為新的和現(xiàn)有的客戶建立自動化項(xiàng)目和流程。他認(rèn)為,成功和失敗是完全取決于自動化建立過程是否設(shè)定正確的目標(biāo)。他目前正在他的博士學(xué)位致力于研究自動化。
David Krauss擁有超過30年的應(yīng)用經(jīng)驗(yàn)和產(chǎn)品設(shè)計和交付,與廣泛的編程和跨多個平臺架構(gòu)經(jīng)驗(yàn),技術(shù),和語言。精通遺留資產(chǎn)現(xiàn)代化,全球協(xié)作開發(fā)過程,客戶機(jī)/服務(wù)器和網(wǎng)絡(luò)平臺,測試自動化(一個專利自動化,自動化生成一個專利申請中)。二十多年專業(yè)從事自動化測試工具和范例,自動化框架和測試方法。