從0到1開發自動化測試框架

軟件測試之自動化測試框架介紹一、敘言隨著項目版本的快速迭代、APP測試有以下幾個特點:首先，功能點多且細，測試工作量大，容易遺漏；其次，代碼模塊常改動，回歸測試很頻繁，測試重復低效；最后，數據環境多樣，用戶場景復雜，功能回歸覆蓋難全面。為節省成本，保證高效及高質量迭代，我們需采用更高效的測試方式，App自動化測試是較高效的手段。之前自動測試實踐過程中遇到的諸多問題（代碼復用率低，Case開辟及數據構造繁瑣,問題定位艱難，學習成本高等），為解決相關痛點問題，我們重新實現了一套APP自動測試框架。本文將著重介紹技術選型、設計思路及百度外賣App的具體實踐。二自動化測試睇支術選型一個項目中自動化測試是否能有效的展開，自動化測試框架是關鍵所在。因此，如何如何構建穩定的、易擴展的自動化的測試項目對于敏捷測試有重要的意義。在設計框架的時候應該盡可能的沿用自動化測試工具已提供的功能，避免重復開辟，以減少開辟成本。通過對現有自動化測試工具的原理進行深入分析及優缺點比較，并基于Appium和TestNG兩類自動化測試框架解決上述自動化測試中遇到的問題。首先，通過利用TestNG結合csv的使用，將測試用例數據轉化為測試代碼中的數據,減少了測試人員錄入數據和準備數據的工具；再次，通過對appium的封裝，按照面向對象的思想將測試中用到的頁面元素封裝成對象，增強測試代碼的復用率，并減輕測試人員對底層代碼實現的負擔，提高測試代碼編寫效率；最后，引入失敗重跑、失敗截屏，并通過reportng生成測試報告的方式，逐步完善測試過程，提高定位問題的速度；TestNG夜間構建會按計劃定期觸發自動化構建過程，但這種構建只是簡單的代碼編譯，沒有可靠的或者可重復的功能測試。后續考慮Appium結合Jenkins來實現構建后自動化測試工作。無論任何時候，只要代碼更新提交到git中，構建服務器就會觸發一個構建，構建運行腳本去編譯應用程序并且運行一系列的自動化單元測試和/或者集成測試。通過自動化測試結果能夠清晰的展示出那些功能特性是通過的，哪些是失敗的。不管是有改動提交，還是定期在夜間觸發構建，應用程序都會被自動部署到測試環境之中以便QA團隊進行測試。Jenkins與STF結合，實現多機并行測試Jenkins構建腳本完成后，將沒有安裝stf組件電腦上連接的android設備，添加映射到裝有Stf平臺服務的機器上，將集成測試用例push到STF平臺，再由STF分發到可運行設備上，進行多機并行測試。STF執行APPIUM測試帶來的優勢第一、可以在真機上執行并行的Appium測試。由于最初的Appium使用對象是模擬器上或者只是以每次一臺設備的測試方法執行測試，而STF在原有的基礎上擴展了Appium,最多可在數百臺真機上同時執行測試的能力。第二，不需要配置任何設備的DesiredCapabilitieso這種方式既簡便，且減少了因為編輯腳本而產生的不同類型的錯誤。第三，在STF上執行測試可以讓用戶即時瀏覽測試狀況。也就是說，可以查看到測試執行的進度，即時的錯誤反饋，以及保留和查閱所有測試項目，測試腳本和測試結果（測試截圖，測試日志，性能數據等）代碼質量度量、為什么要分析代碼對代碼質量關注時，安排人工進行codereview是需要的，但100%的codereview卻需要投入人員，消耗大量的工作量，而工具自動檢查只需少量人工配置。最主要的原因就是提高代碼質量，了解RD在編碼過程中犯過的錯誤可能對功能邏輯產生的影響，同時也推動RD讓自己的代碼更具有可讀性和維護性，所以我們借鑒持續改進的流程，希翼能夠在這個過程中有所收獲。XJenkins弓|入Sonarqube進行代碼持續審查Sonar是一個用于代碼質量管理的開源平臺，用于管理Java源代碼的質量。通過插件機制，Sonar可以集成不同的測試工具，代碼分析工具，以及持續集成工具，比如pmd-cpd、checkstyle,findbugs.Jenkinso通過不同的插件對這些結果進行再加工處理，通過量化的方式度量代碼質量的變化，從而可以方便地對不同規模和種類的工程進行代碼質量管理。emailext實現Jenkins郵件通知功能在Jenkins中配置實現郵件通知，Jenkins提供了兩種方式的配置。一種是Jenkins內置默認的郵件通知，但是它本身有不少局限性，比如它的郵件通知無法提供詳細的郵件內容、無法定義發送郵件的格式、無法定義靈便的郵件接收配置等等。在這樣的情況下，后續考慮可以通過EmailExtensionPlugin來實現自定義郵件通知的方方面面，比如在發送郵件的同時可以自定義發送給誰，發送具體什么內容等等。Testng是一個開源自動化測試框架，引入了許多新的創新功能，如依賴測試，分組概念，使測試更強大，更容易做到。旨在涵蓋所有類別的測試：單元，功能，端到端，集成等。TestNG框架可以很好地幫我們完成WebDriver+java的頁面自動化工作，通過各種注釋的靈便運行，可以使你的測試用例更加完美，定制符合要求的測試用例TestNG是一個設計用來簡化廣泛的測試需求的測試框架，從單元測試到集成測試。這個是TestNG設計的出發點，不僅僅是單元測試，而且可以用于集成測試。設計目標的不同，對照junit的只適合用于單元測試，TestNG無疑走的更遠?？梢杂糜诩蓽y試,這個特性是我選擇TestNG的最重要的原因。測試的過程的三個典型步驟，和junit(4.0)相比，多了一個將測試信息添加到testng.xml文件。測試信息特別是測試數據再也不寫死在測試代碼中，好處就是修改測試數據時不需要修改代碼/編譯了，從而有助于將測試人員引入單元測試/集成測試?；靖拍?，相比junit的TestCase/TestSuite,TestNG有suite/test/testmethod三個級別，即將test/testmethod明確區分開了。AppiumAppium一個開源、跨平臺的測試框架，可以用來測試原生及混合的挪移端應用。Appium支持iOS、Android及FirefoxOS平臺測試。Appium使用WebDriver的jsonwire協議，來驅動Apple系統的UIAutomation庫、Android系統的UIAutomator框架。相比其他的挪移自動化測試工具，Appium測試由于調用了Selenium的client庫使其可以使用任意的語言，包括Python、Ruby、Nodejs、Objective-C等。三、自動化測試框架的設計思路測試設計過程和測試自動化框架必須作為兩個單獨的實體來開辟。測試框架應該獨立于應用程序；測試框架應該易于擴展、維護和增強；測試策略/設計應該對測試者隱藏測試框架的復雜性。四、自動化框架介紹該框架基于SeleniumWebDriver開源技術開辟。本框架使用Maven工具進行Project管理，采用TestNG工具組織測試，應用CSV文件存儲測試數據，實現測試數據與測試用例的分離，方便測試數據管理，降低自動化腳本的維護成本，實現數據驅動。此外，該框架還封裝了豐富的Selenium方法關鍵字，借鑒了 語法結構，實現了直觀清晰的結構化代碼語法，如：Pageltem.Operate，降低自動化代碼的冗余與重復。借助Jenkins進行Q測試，實現測試任務的Schedule和Report功能，通過JenkinsMaster/Slave模式管理虛擬機節點，實現多任務多機器分布式并發的執行管理，從而提高測試效率。該框架的好處在于：1、構建可復用的、穩定的代碼集。通過封裝叩pium實現用例執行與數據調用分離，參數化配置常用信息，并提供統一接口；2、模塊化管理自動化測試用例。主要根據TestNG工具的支持參數測試和依賴測試的特點實現；3、測試結果分析和統計。利用jenkins工具建立持續集成，定期運行自動化測試項目，并將測試結果以定制化的形式展現。測試框架分層基于UI測試，我們希翼除了支持web測試，還能支持app的測試，可能還需要朝測試,我們就需要考慮分層問題，將測試框架分為三層。上層是管理整個自動化測試的開發，執行以及維護，在比較龐大的項目中，它體現重要的作用，它可以管理整個自動測試,包括自動化測試用例執行的次序、測試腳本的維護、以及集中管理測試用例、測試報告和測試任務等。下層主要是測試腳本的開辟，充分的使用相關的測試工具，構建測試驅動，并完成測試業務邏輯。第一層：甥居層即執行用例時所需要的測試數據，如商戶名、空間名、URL等，這些數據用來支撐整個腳本的執行。針對數據層，這里采了用數據驅動的方式。第二層：驅動層這一層主要封裝各種driver。比如我們針對網頁測試，使用selenium-webdriver開發包，針對叩p測試，我們使用叩pium開辟包。我們在這一層進行封裝，通過調用selenium-webdriver,叩pium提供的原生方法，封裝成可讀性很強的方法且加之容錯機制。以后就算我們要換用其他的第三方包，我們的測試案例層和支持層的方法也不需要做任何的修改。只需要修改driver層實現的方式就可以了。在一層，我們主要實現兩個方面的封裝，一個是driver的封裝，一個是基于基類自然語言函數的封裝。driver封裝我們需要封裝，根據參數確實是基于web測試還是基于叩p測試。比如：基類封裝主要是封裝各種可讀性很很強的方法以及將元素定位標識及driver也封裝進去。為了支持網頁測試和叩P測試，我們需要兩個基類，一個是針對網頁操作基類，一個是針對叩P操作基類。同時為了web和app操作的一致性，我們要求對外提供的方法，必須要將常用的方法保持一致的名字和一樣的參數類型及參數個數。APP基類示例如下：通過對driver和基類的封裝，driver層實現了對網頁測試和叩p測試的支持，并且針對兩種測試，都提供了統一的方法，能夠方便使用者，使用相同的方法，測試叩p和webo第三層：測試案例層該層是測試案例的具體實現，就像上面寫的case那樣，用接近自然語言的方式，來實現測試案例。第四層：支持層該層主要提供workflow,通用工具,元素庫的支持，便于測試案例層直接調用。Workflow:主要封裝測試項目中需要時常使用的針對項目的公用方法，供測試案例層直接調用。比如用戶登錄，注冊一個用戶，搜索出用戶等等時常使用的動作；通用工具：提供一些通用方法，比如生成指定Page類，文件讀取操作，DB操作，http操作支持等等；元素庫:每一^個頁面元素的定位表達式(xpath,id,name,css,link_text等等表達式)。我們的測試案例，都是針對一個個元素進行操作的。將每一個頁面的每一個元素，都看成一個繼承了基類的特定類。所以，我們的第一步，就需要找到這個元素，定位到這個元素。測試項目的所有元素都放到這里。第五層：結果保存層將測試腳本的日志和結果以自定義的方式展示，這里使用了ReportNG,它可以豐富測試結果的展現形式，匡助團隊更快定位和解決問題。五、框架技術要點解析P0模式遇到的問題使用webdriver做過一段時間的測試就會發現一個對某一個頁面的元素進行定位的時候，程序行間充斥著id()、name。、xpath()等方法，這樣會造成測試程序的可讀性較差，不便于后期的維護以及修改。雖然我們可以通過添加注釋的方法使程序便于理解，但是還是不可以從根本上解決這種問題。我們可以通過對這些方法進行二次封裝來避免每次對這些方法的直接調用，通過方法的封裝雖然可以實現復用。但是我們發現通過封裝無法實現頁面元素的邏輯處理和測試數據的獨立。問題的解決辦法：引入P0PageObject模式是Selenium中的一種測試設計模式，是指UI界面上用于與用戶進行交互的對象。主要是將每一個頁面設計為一個Class,其中包含頁面中需要測試的元素(按鈕，輸入框，標題等)，這樣在Selenium測試頁面中可以通過調用頁面類來獲取頁面元素，這樣巧妙的避免了當頁面元素id或者位置變化時，需要改測試頁面代碼的情況。當頁面元素id變化時，只需要更改測試頁Class中頁面的屬性即可。通過對界面元素的封裝減少冗余代碼，提高測試用例的可維護性。普通情況下，對于一個PageObjects對象，它有兩個方面的特征:自身元素(Web日ement)實現功能(Services)子細分析測試場景，抽出UI測試的核心行為，無非就是：1、檢查點：頁面元素是否存在；頁面元素顯示內容是否正確；頁面元素是否可用；2、輔助功能:等待兀素浮現；點擊某頁面兀素；給元素輸入內容；分析抽出來的核心行為，發現這些行為基本都是針對一個個頁面元素進行的操作。那么我們就可以做如下的動作：將頁面元素看成一個對象，封裝成一個類；將上面分析得到的核心行為都封裝成基類方法。然后確保，任何一個頁面元素都繼承該基類；該基類提供類似于自然語言的方法名字，調用這些方法，就能很明確的知道測試案例在做什么檢查，在做什么行為，這樣就能極大的提高測試案例的可讀性。該基類主要目的是在UI測試中，對元素共性的檢查點和輔助方法進行抽取，將它們封裝成一個個非常容易讀懂的方法，且具有異常處理能力。經過上述思路的整理，測試用例可以改寫成如下：在實際的使用過程中，可以讓不太熟悉代碼的QA專門負責測試案例的實現，底層的方法包裝可以由經驗豐富一些的同學做。數據驅動數據驅動的自動化測試框架是這樣的一個框架，從某個數據文件（例如ODBC源文件、Excel文件、Csv文件、ADO對象文件等）中讀取輸入、輸出的測試數據，然后通過變量傳入事先錄制好的或者手工編寫的測試腳本中。其中，這些變量被用作傳遞（輸入/輸出）用來驗證應用程序的測試數據。在這個過程中，數據文件的讀取、測試狀態和所有測試信息都被編寫進測試腳本里;測試數據只包含在數據文件中，而不是腳本里，測試腳本只是一個“驅動”，或者說是一個傳送數據的機制。L在數據文件中填寫測試數據：2、生成Page類:3、Page類中初始化頁面元素：基于數據驅動的好處在于：在應用程序開辟的同時就可以同步建立測試腳本，而且當應用功能變動時，只需要修改業務功能部份的腳本；利用模型化的設計，避免重復的腳本，減少建立或者維護腳本的成本。失敗重跑與失敗截圖機制自動化測試過程中，往往由于網絡、服務器響應過慢、JS特效及頁面渲染時間較長，導致自動化測試失敗。針對此類場景，本框架設計了一套NRetry機制，即某個case運行失敗后，重跑N次，N可自定義。N次中有一次成功，貝!J繼續運行，若N次均失敗，則截圖、拋錯，住手運行。NRetry機制，一定程度上可以降低由于網絡、服務器響應過慢導致的自動化執行的不穩定性。失敗自動截圖1、新建一個區里類繼承TestListenerAdapter:2、重寫onTestFailure、onTestSkipped等方法，在這些方法中加入截圖操作：3、在testng.xml文件中配置自己編寫的監聽器類：失敗自動重跑在運行自動化測試用例的時候，時常會浮現一些異常的情況的情況導致用例失敗的問題。所以我們可能會希翼對于失敗的測試用例再重新運行一次，框架中我們結合TestNG來實現這個功能。新建TestNGRetry類，實現用例失敗自動重跑邏輯：添加用例重跑監聽器RetryListener,用例失敗自動重跑功能：在testng.xml文件中配置自己編寫的監聽器：ReportNGTestNG默認的HTML報表，其默認的報表雖然信息全面，但不易于理解。因此，我們利用ReportNG來替代TestNG默認的report。ReportNG提供了一種簡單的方式來查看測試結果，并能夠對結果代碼進行著色。還可以通過修改CSS文件來替換默認的輸出樣式。此外ReportNG還能夠生成Junit格式的XML輸出。由于我們使用的是maven,所以我們主要來看看pom.xml的情況：maven-surefire-plugin這個插件主要是用于testng的。我們通過該插件，在對應的目錄下./target/${timestamp}生成我們的測試報告目錄。我們可以看到這個目錄的結構。這里實際上就是reportng的測試報告的生成路徑。但是我們想要通過郵件發送會很難，因為html的內容需要加在額外的css,以及js文件。而郵件實際上是不支持外部的css以及js文件的。HTML的生成L定義HTML模版查看i