您的位置:首頁>互聯網>正文

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

一、序言

隨著項目版本的快速反覆運算、APP測試有以下幾個特點:

首先, 功能點多且細, 測試工作量大, 容易遺漏;其次, 代碼模組常改動, 回歸測試很頻繁, 測試重複低效;最後, 資料環境多樣, 使用者場景複雜, 功能回歸覆蓋難全面。 二、自動化測試框架技術選型首先, 通過利用TestNG結合csv的使用, 將測試用例資料轉化為測試代碼中的資料, 減少了測試人員錄入資料和準備資料的工具;再次, 通過對appium的封裝, 按照物件導向的思想將測試中用到的頁面元素封裝成物件,
增強測試代碼的複用率, 並減輕測試人員對底層代碼實現的負擔, 提高測試代碼編寫效率;最後, 引入失敗重跑、失敗截屏, 並通過reportng生成測試報告的方式, 逐步完善測試過程, 提高定位問題的速度;

TestNG

TestNG是一個設計用來簡化廣泛的測試需求的測試框架, 從單元測試到集成測試。 這個是TestNG設計的出發點, 不僅僅是單元測試, 而且可以用於集成測試。 設計目標的不同, 對比junit的只適合用於單元測試, TestNG無疑走的更遠。 可以用於集成測試, 這個特性是我選擇TestNG的最重要的原因。 測試的過程的三個典型步驟, 和junit(4.0)相比, 多了一個將測試資訊添加到testng.xml文件。 測試資訊尤其是測試資料不再寫死在測試代碼中,
好處就是修改測試資料時不需要修改代碼/編譯了, 從而有助於將測試人員引入單元測試/集成測試。 基本概念, 相比junit的TestCase/TestSuite, TestNG有suite/test/test method三個級別, 即將test/test method明確區分開了。

Appium

Appium一個開源、跨平臺的測試框架, 可以用來測試原生及混合的移動端應用。 Appium支援iOS、Android及FirefoxOS平臺測試。 Appium使用WebDriver的json wire協定, 來驅動Apple系統的UIAutomation庫、Android系統的UIAutomator框架。 相比其他的移動自動化測試工具, Appium測試由於調用了Selenium的client庫使其可以使用任意的語言, 包括Python、Ruby、Node.js、Objective-C等。

三、自動化測試框架的設計思路

測試設計過程和測試自動化框架必須作為兩個單獨的實體來開發。 測試框架應該獨立于應用程式;測試框架應該易於擴展 、維護和增強;測試策略/設計應該對測試者隱藏測試框架的複雜性。

四、自動化框架介紹

該框架基於Selenium WebDriver開源技術開發。

本框架使用Maven工具進行Project管理, 採用TestNG工具組織測試, 應用CSV檔存儲測試資料, 實現測試資料與測試用例的分離, 方便測試資料管理, 降低自動化腳本的維護成本, 實現資料驅動。 此外, 該框架還封裝了豐富的Selenium方法關鍵字, 借鑒了QTP語法結構, 實現了直觀清晰的結構化代碼語法, 如:Page.Item.Operate, 降低自動化代碼的冗餘與重複。 借助Jenkins進行CI測試, 實現測試任務的Schedule和Report功能, 通過Jenkins Master/Slave模式管理虛擬機器節點, 實現多工多機器分散式併發的執行管理, 從而提高測試效率。

該框架的好處在於: 1、構建可複用的、穩定的代碼集。 通過封裝appium實現用例執行與資料調用分離, 參數化配置常用資訊, 並提供統一介面; 2、模組化管理自動化測試用例。
主要根據TestNG工具的支援參數測試和依賴測試的特點實現; 3、測試結果分析和統計。 利用jenkins工具建立持續集成, 定期運行自動化測試專案, 並將測試結果以定制化的形式展現。

測試框架分層

基於UI測試, 我們希望除了支持web測試, 還能支持app的測試, 可能還需要介面測試, 我們就需要考慮分層問題, 將測試框架分為三層。 上層是管理整個自動化測試的開發, 執行以及維護, 在比較龐大的專案中, 它體現重要的作用, 它可以管理整個自動測試, 包括自動化測試用例執行的次序、測試腳本的維護、以及集中管理測試用例、測試報告和測試任務等。 下層主要是測試腳本的開發, 充分的使用相關的測試工具, 構建測試驅動,

並完成測試業務邏輯。

第一層:資料層

即執行用例時所需要的測試資料, 如商戶名、空間名、URL等, 這些資料用來支撐整個腳本的執行。 針對資料層, 這裡采了用資料驅動的方式。

第二層:驅動層

這一層主要封裝各種driver。 比如我們針對網頁測試, 使用selenium-webdriver開發包, 針對app測試, 我們使用appium開發包。 我們在這一層進行封裝, 通過調用selenium-webdriver, appium提供的原生方法, 封裝成可讀性很強的方法且加上容錯機制。 以後就算我們要換用其他的協力廠商包, 我們的測試案例層和支援層的方法也不需要做任何的修改。 只需要修改driver層實現的方式就可以了。 在一層, 我們主要實現兩個方面的封裝, 一個是driver的封裝, 一個是基於基類自然語言函數的封裝。

driver封裝

我們需要封裝,

根據參數確實是基於web測試還是基於app測試。 比如:

基類封裝

主要是封裝各種可讀性很很強的方法以及將元素定位標識及driver也封裝進去。 為了支援網頁測試和app測試, 我們需要兩個基類, 一個是針對網頁操作基類, 一個是針對app操作基類。 同時為了web和app操作的一致性, 我們要求對外提供的方法, 必須要將常用的方法保持一致的名字和一樣的參數類型及參數個數。 APP基類示例如下:

通過對driver和基類的封裝, driver層實現了對網頁測試和app測試的支持, 並且針對兩種測試, 都提供了統一的方法, 能夠方便使用者, 使用相同的方法, 測試app和web。

第三層:測試案例層

該層是測試案例的具體實現, 就像上面寫的case那樣, 用接近自然語言的方式, 來實現測試案例。

第四層:支援層

該層主要提供workflow,通用工具,元素庫的支援,便於測試案例層直接調用。

Workflow:主要封裝測試專案中需要經常使用的針對專案的公用方法,供測試案例層直接調用。比如用戶登錄,註冊一個用戶,搜索出用戶等等經常使用的動作;通用工具:提供一些通用方法,比如生成指定Page類,檔讀取操作,DB操作,http操作支援等等;元素庫:每一個頁面元素的定位運算式(xpath,id,name,css,link_text等等運算式)。我們的測試案例,都是針對一個個元素進行操作的。將每一個頁面的每一個元素,都看成一個繼承了基類的特定類。所以,我們的第一步,就需要找到這個元素,定位到這個元素。測試專案的所有元素都放到這裡。

第五層:結果保存層將測試腳本的日誌和結果以自訂的方式展示,這裡使用了ReportNG,它可以豐富測試結果的展現形式,幫助團隊更快定位和解決問題。

五、框架技術要點解析

5.1、PO模式

5.1.1、遇到的問題

使用webdriver做過一段時間的測試就會發現一個對某一個頁面的元素進行定位的時候,程式列間充斥著id、name、xpath等方法,這樣會造成測試程式的可讀性較差,不便於後期的維護以及修改。雖然我們可以通過添加注釋的方法使程式便於理解,但是還是不可以從根本上解決這種問題。我們可以通過對這些方法進行二次封裝來避免每次對這些方法的直接調用,通過方法的封裝雖然可以實現複用。但是我們發現通過封裝無法實現頁面元素的邏輯處理和測試資料的獨立。

5.1.2、問題的解決辦法:引入PO

Page Object模式是Selenium中的一種測試設計模式,是指UI介面上用於與使用者進行交互的物件。主要是將每一個頁面設計為一個Class,其中包含頁面中需要測試的元素(按鈕,輸入框,標題等),這樣在Selenium測試頁面中可以通過調用頁面類來獲取頁面元素,這樣巧妙的避免了當頁面元素id或者位置變化時,需要改測試頁面代碼的情況。當頁面元素id變化時,只需要更改測試頁Class中頁面的屬性即可。通過對介面元素的封裝減少冗餘碼,提高測試用例的可維護性。

一般情況下,對於一個Page Objects物件,它有兩個方面的特徵:•自身元素(WebElement) •實現功能 (Services)

仔細分析測試場景,抽出UI測試的核心行為,無非就是:1、檢查點:頁面元素是否存在;頁面元素顯示內容是否正確;頁面元素是否可用;……2、協助工具:等待元素出現;點擊某頁面元素;給元素輸入內容;……

分析抽出來的核心行為,發現這些行為基本都是針對一個個頁面元素進行的操作。那麼我們就可以做如下的動作:將頁面元素看成一個物件,封裝成一個類;將上面分析得到的核心行為都封裝成基類方法。然後確保,任何一個頁面元素都繼承該基類;該基類提供類似于自然語言的方法名字,調用這些方法,就能很明確的知道測試案例在做什麼檢查,在做什麼行為,這樣就能極大的提高測試案例的可讀性。該基類主要目的是在UI測試中,對元素共性的檢查點和輔助方法進行抽取,將它們封裝成一個個非常容易讀懂的方法,且具有異常處理能力。經過上述思路的整理,測試用例可以改寫成如下:

在實際的使用過程中,可以讓不太熟悉代碼的QA專門負責測試案例的實現,底層的方法包裝可以由經驗豐富一些的同學做。

5.2、資料驅動

資料驅動的自動化測試框架是這樣的一個框架,從某個資料檔案(例如ODBC原始檔案、Excel檔、Csv檔、ADO目的檔等)中讀取輸入、輸出的測試資料,然後通過變數傳入事先錄製好的或手工編寫的測試腳本中。其中,這些變數被用作傳遞(輸入/輸出)用來驗證應用程式的測試資料。在這個過程中,資料檔案的讀取、測試狀態和所有測試資訊都被編寫進測試腳本裡;測試資料只包含在資料檔案中,而不是腳本裡,測試腳本只是一個“驅動”,或者說是一個傳送資料的機制。1、在資料檔案中填寫測試資料:

2、生成Page類:

3、Page類中初始化頁面元素:

基於資料驅動的好處在於:在應用程式開發的同時就可以同步建立測試腳本,而且當應用功能變動時,只需要修改業務功能部分的腳本;利用模型化的設計,避免重複的腳本,減少建立或維護腳本的成本。

5.3、失敗重跑與失敗截圖機制

自動化測試過程中,常常由於網路、伺服器響應過慢、JS特效及頁面渲染時間較長,導致自動化測試失敗。針對此類場景,本框架設計了一套NRetry機制,即某個case運行失敗後,重跑N次,N可自訂。N次中有一次成功,則繼續運行,若N次均失敗,則截圖、拋錯,停止運行。NRetry機制,一定程度上可以降低由於網路、伺服器回應過慢導致的自動化執行的不穩定性。

5.3.1、失敗自動截圖

1、新建一個Java類繼承TestListenerAdapter:

2、重寫onTestFailure、onTestSkipped等方法,在這些方法中加入截圖操作:

3、在testng.xml檔中配置自己編寫的監聽器類:

5.3.2、失敗自動重跑

在運行自動化測試用例的時候,經常會出現一些異常的情況的情況導致用例失敗的問題。所以我們可能會希望對於失敗的測試用例再重新運行一次,框架中我們結合TestNG來實現這個功能。1.新建TestNGRetry類,實現用例失敗自動重跑邏輯:

添加用例重跑監聽器RetryListener,用例失敗自動重跑功能:

在testng.xml檔中配置自己編寫的監聽器:

5.4、ReportNG

TestNG預設的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的生成

1、定義HTML模版

查看indexMain.html.vm:

下面我們看下生成報告的部分核心代碼:

在使用ReportNG替換TestNG自帶報告時如果報告中含中文,由於ReportNG裡面Log是不支持中文的,所以通過修改ReportNG.jar源碼來支持報告內中文展示。

5.5、日誌收集

日誌是軟體發展的重要組成部分。自動化執行過程的日誌資訊,對於失敗用例的分析定位以及全過程的跟蹤記錄是十分重要的。相對於簡單的輸出列印,本框架組成了主流的日誌收集工具log4j。Log4j是高度可配置的,並可通過在運行時的外部檔配置。通過配置log4j.properties檔,定義日誌級別內容及日誌輸出路徑收集日誌資訊(諸如:資料庫,檔,控制台,UNIX系統日誌等),提供快速的調試,維護方便,以及應用程式的運行時資訊結構化存儲。設定檔Log4j可以通過java程式動態設置,該方式明顯缺點是:如果需要修改日誌輸出級別等資訊,則必須修改java檔,然後重新編譯,很是麻煩;log4j也可以通過設定檔的方式進行設置,目前支援兩種格式的設定檔:xml文件;properties文件(推薦)。

5.6、郵件發送

測試報告的發送可以結合Jenkins來實現,通過簡單的配置即可實現。可是如果團隊沒有搭建jenkins或者有時jenkins不可用,我們應該如何去處理這部分的內容呢?既然郵件不能夠依賴jenkins,那肯定得自己去實現這部分的內容了。所以我們還是得依賴一些協力廠商的jar包。我們在pom.xml配置。

六、後續TODO

在後續的版本演進中,將把自動化測試、代碼安全掃描、多機並行測試、持續發佈都加入了整體過程,真正的做到全過程持續交付。

6.1、夜間構建加入自動化測試

夜間構建會按計劃定期觸發自動化構建過程,但這種構建只是簡單的代碼編譯,沒有可靠的或可重複的功能測試。後續考慮Appium結合Jenkins來實現構建後自動化測試工作。無論任何時候,只要代碼更新提交到git中,構建伺服器就會觸發一個構建,構建運行腳本去編譯應用程式並且運行一系列的自動化單元測試和/或集成測試。通過自動化測試結果能夠清晰的展示出那些功能特性是通過的,哪些是失敗的。不管是有改動提交,還是定期在夜間觸發構建,應用程式都會被自動部署到測試環境當中以便QA團隊進行測試。

6.2、Jenkins與STF結合,實現多機並行測試

Jenkins構建腳本完成後,將沒有安裝stf元件電腦上連接的android設備,添加映射到裝有stf平臺服務的機器上,將集成測試用例push到STF平臺,再由STF分發到可運行設備上,進行多機並行測試。STF執行APPIUM測試帶來的優勢

第一、可以在真機上執行並行的Appium測試。由於最初的Appium使用物件是模擬器上或只是以每次一台設備的測試方法執行測試,而STF在原有的基礎上擴展了Appium,最多可在數百台真機上同時執行測試的能力。第二,不需要配置任何設備的Desired Capabilities。這種方式既簡便,且減少了因為編輯腳本而產生的不同類型的錯誤。第三,在STF上執行測試可以讓用戶即時流覽測試狀況。也就是說,可以查看到測試執行的進度,即時的錯誤回饋,以及保留和查閱所有測試項目,測試腳本和測試結果(測試截圖,測試日誌,性能資料等)

6.3、代碼品質度量

6.3.1、為什麼要分析代碼

對代碼品質關注時,安排人工進行code review是需要的,但100%的code review卻需要投入人員,消耗大量的工作量,而工具自動檢查只需少量人工配置。最主要的原因就是提高代碼品質,瞭解RD在編碼過程中犯過的錯誤可能對功能邏輯產生的影響,同時也推動RD讓自己的代碼更具有可讀性和維護性,所以我們借鑒持續改進的流程,希望能夠在這個過程中有所收穫。

6.3.2、Jenkins引入Sonarqube進行代碼持續審查

Sonar是一個用於代碼品質管制的開源平臺,用於管理Java原始程式碼的品質。通過外掛程式機制,Sonar可以集成不同的測試工具,代碼分析工具,以及持續集成工具,比如pmd-cpd、checkstyle、findbugs、Jenkins。通過不同的外掛程式對這些結果進行再加工處理,通過量化的方式度量代碼品質的變化,從而可以方便地對不同規模和種類的工程進行代碼品質管制。

6.4、email-ext實現Jenkins郵件通知功能

在Jenkins中配置實現郵件通知,Jenkins提供了兩種方式的配置。一種是Jenkins內置默認的郵件通知,但是它本身有很多局限性,比如它的郵件通知無法提供詳細的郵件內容、無法定義發送郵件的格式、無法定義靈活的郵件接收配置等等。在這樣的情況下,後續考慮可以通過Email Extension Plugin來實現自訂郵件通知的方方面面,比如在發送郵件的同時可以自訂發送給誰,發送具體什麼內容等等。

第四層:支援層

該層主要提供workflow,通用工具,元素庫的支援,便於測試案例層直接調用。

Workflow:主要封裝測試專案中需要經常使用的針對專案的公用方法,供測試案例層直接調用。比如用戶登錄,註冊一個用戶,搜索出用戶等等經常使用的動作;通用工具:提供一些通用方法,比如生成指定Page類,檔讀取操作,DB操作,http操作支援等等;元素庫:每一個頁面元素的定位運算式(xpath,id,name,css,link_text等等運算式)。我們的測試案例,都是針對一個個元素進行操作的。將每一個頁面的每一個元素,都看成一個繼承了基類的特定類。所以,我們的第一步,就需要找到這個元素,定位到這個元素。測試專案的所有元素都放到這裡。

第五層:結果保存層將測試腳本的日誌和結果以自訂的方式展示,這裡使用了ReportNG,它可以豐富測試結果的展現形式,幫助團隊更快定位和解決問題。

五、框架技術要點解析

5.1、PO模式

5.1.1、遇到的問題

使用webdriver做過一段時間的測試就會發現一個對某一個頁面的元素進行定位的時候,程式列間充斥著id、name、xpath等方法,這樣會造成測試程式的可讀性較差,不便於後期的維護以及修改。雖然我們可以通過添加注釋的方法使程式便於理解,但是還是不可以從根本上解決這種問題。我們可以通過對這些方法進行二次封裝來避免每次對這些方法的直接調用,通過方法的封裝雖然可以實現複用。但是我們發現通過封裝無法實現頁面元素的邏輯處理和測試資料的獨立。

5.1.2、問題的解決辦法:引入PO

Page Object模式是Selenium中的一種測試設計模式,是指UI介面上用於與使用者進行交互的物件。主要是將每一個頁面設計為一個Class,其中包含頁面中需要測試的元素(按鈕,輸入框,標題等),這樣在Selenium測試頁面中可以通過調用頁面類來獲取頁面元素,這樣巧妙的避免了當頁面元素id或者位置變化時,需要改測試頁面代碼的情況。當頁面元素id變化時,只需要更改測試頁Class中頁面的屬性即可。通過對介面元素的封裝減少冗餘碼,提高測試用例的可維護性。

一般情況下,對於一個Page Objects物件,它有兩個方面的特徵:•自身元素(WebElement) •實現功能 (Services)

仔細分析測試場景,抽出UI測試的核心行為,無非就是:1、檢查點:頁面元素是否存在;頁面元素顯示內容是否正確;頁面元素是否可用;……2、協助工具:等待元素出現;點擊某頁面元素;給元素輸入內容;……

分析抽出來的核心行為,發現這些行為基本都是針對一個個頁面元素進行的操作。那麼我們就可以做如下的動作:將頁面元素看成一個物件,封裝成一個類;將上面分析得到的核心行為都封裝成基類方法。然後確保,任何一個頁面元素都繼承該基類;該基類提供類似于自然語言的方法名字,調用這些方法,就能很明確的知道測試案例在做什麼檢查,在做什麼行為,這樣就能極大的提高測試案例的可讀性。該基類主要目的是在UI測試中,對元素共性的檢查點和輔助方法進行抽取,將它們封裝成一個個非常容易讀懂的方法,且具有異常處理能力。經過上述思路的整理,測試用例可以改寫成如下:

在實際的使用過程中,可以讓不太熟悉代碼的QA專門負責測試案例的實現,底層的方法包裝可以由經驗豐富一些的同學做。

5.2、資料驅動

資料驅動的自動化測試框架是這樣的一個框架,從某個資料檔案(例如ODBC原始檔案、Excel檔、Csv檔、ADO目的檔等)中讀取輸入、輸出的測試資料,然後通過變數傳入事先錄製好的或手工編寫的測試腳本中。其中,這些變數被用作傳遞(輸入/輸出)用來驗證應用程式的測試資料。在這個過程中,資料檔案的讀取、測試狀態和所有測試資訊都被編寫進測試腳本裡;測試資料只包含在資料檔案中,而不是腳本裡,測試腳本只是一個“驅動”,或者說是一個傳送資料的機制。1、在資料檔案中填寫測試資料:

2、生成Page類:

3、Page類中初始化頁面元素:

基於資料驅動的好處在於:在應用程式開發的同時就可以同步建立測試腳本,而且當應用功能變動時,只需要修改業務功能部分的腳本;利用模型化的設計,避免重複的腳本,減少建立或維護腳本的成本。

5.3、失敗重跑與失敗截圖機制

自動化測試過程中,常常由於網路、伺服器響應過慢、JS特效及頁面渲染時間較長,導致自動化測試失敗。針對此類場景,本框架設計了一套NRetry機制,即某個case運行失敗後,重跑N次,N可自訂。N次中有一次成功,則繼續運行,若N次均失敗,則截圖、拋錯,停止運行。NRetry機制,一定程度上可以降低由於網路、伺服器回應過慢導致的自動化執行的不穩定性。

5.3.1、失敗自動截圖

1、新建一個Java類繼承TestListenerAdapter:

2、重寫onTestFailure、onTestSkipped等方法,在這些方法中加入截圖操作:

3、在testng.xml檔中配置自己編寫的監聽器類:

5.3.2、失敗自動重跑

在運行自動化測試用例的時候,經常會出現一些異常的情況的情況導致用例失敗的問題。所以我們可能會希望對於失敗的測試用例再重新運行一次,框架中我們結合TestNG來實現這個功能。1.新建TestNGRetry類,實現用例失敗自動重跑邏輯:

添加用例重跑監聽器RetryListener,用例失敗自動重跑功能:

在testng.xml檔中配置自己編寫的監聽器:

5.4、ReportNG

TestNG預設的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的生成

1、定義HTML模版

查看indexMain.html.vm:

下面我們看下生成報告的部分核心代碼:

在使用ReportNG替換TestNG自帶報告時如果報告中含中文,由於ReportNG裡面Log是不支持中文的,所以通過修改ReportNG.jar源碼來支持報告內中文展示。

5.5、日誌收集

日誌是軟體發展的重要組成部分。自動化執行過程的日誌資訊,對於失敗用例的分析定位以及全過程的跟蹤記錄是十分重要的。相對於簡單的輸出列印,本框架組成了主流的日誌收集工具log4j。Log4j是高度可配置的,並可通過在運行時的外部檔配置。通過配置log4j.properties檔,定義日誌級別內容及日誌輸出路徑收集日誌資訊(諸如:資料庫,檔,控制台,UNIX系統日誌等),提供快速的調試,維護方便,以及應用程式的運行時資訊結構化存儲。設定檔Log4j可以通過java程式動態設置,該方式明顯缺點是:如果需要修改日誌輸出級別等資訊,則必須修改java檔,然後重新編譯,很是麻煩;log4j也可以通過設定檔的方式進行設置,目前支援兩種格式的設定檔:xml文件;properties文件(推薦)。

5.6、郵件發送

測試報告的發送可以結合Jenkins來實現,通過簡單的配置即可實現。可是如果團隊沒有搭建jenkins或者有時jenkins不可用,我們應該如何去處理這部分的內容呢?既然郵件不能夠依賴jenkins,那肯定得自己去實現這部分的內容了。所以我們還是得依賴一些協力廠商的jar包。我們在pom.xml配置。

六、後續TODO

在後續的版本演進中,將把自動化測試、代碼安全掃描、多機並行測試、持續發佈都加入了整體過程,真正的做到全過程持續交付。

6.1、夜間構建加入自動化測試

夜間構建會按計劃定期觸發自動化構建過程,但這種構建只是簡單的代碼編譯,沒有可靠的或可重複的功能測試。後續考慮Appium結合Jenkins來實現構建後自動化測試工作。無論任何時候,只要代碼更新提交到git中,構建伺服器就會觸發一個構建,構建運行腳本去編譯應用程式並且運行一系列的自動化單元測試和/或集成測試。通過自動化測試結果能夠清晰的展示出那些功能特性是通過的,哪些是失敗的。不管是有改動提交,還是定期在夜間觸發構建,應用程式都會被自動部署到測試環境當中以便QA團隊進行測試。

6.2、Jenkins與STF結合,實現多機並行測試

Jenkins構建腳本完成後,將沒有安裝stf元件電腦上連接的android設備,添加映射到裝有stf平臺服務的機器上,將集成測試用例push到STF平臺,再由STF分發到可運行設備上,進行多機並行測試。STF執行APPIUM測試帶來的優勢

第一、可以在真機上執行並行的Appium測試。由於最初的Appium使用物件是模擬器上或只是以每次一台設備的測試方法執行測試,而STF在原有的基礎上擴展了Appium,最多可在數百台真機上同時執行測試的能力。第二,不需要配置任何設備的Desired Capabilities。這種方式既簡便,且減少了因為編輯腳本而產生的不同類型的錯誤。第三,在STF上執行測試可以讓用戶即時流覽測試狀況。也就是說,可以查看到測試執行的進度,即時的錯誤回饋,以及保留和查閱所有測試項目,測試腳本和測試結果(測試截圖,測試日誌,性能資料等)

6.3、代碼品質度量

6.3.1、為什麼要分析代碼

對代碼品質關注時,安排人工進行code review是需要的,但100%的code review卻需要投入人員,消耗大量的工作量,而工具自動檢查只需少量人工配置。最主要的原因就是提高代碼品質,瞭解RD在編碼過程中犯過的錯誤可能對功能邏輯產生的影響,同時也推動RD讓自己的代碼更具有可讀性和維護性,所以我們借鑒持續改進的流程,希望能夠在這個過程中有所收穫。

6.3.2、Jenkins引入Sonarqube進行代碼持續審查

Sonar是一個用於代碼品質管制的開源平臺,用於管理Java原始程式碼的品質。通過外掛程式機制,Sonar可以集成不同的測試工具,代碼分析工具,以及持續集成工具,比如pmd-cpd、checkstyle、findbugs、Jenkins。通過不同的外掛程式對這些結果進行再加工處理,通過量化的方式度量代碼品質的變化,從而可以方便地對不同規模和種類的工程進行代碼品質管制。

6.4、email-ext實現Jenkins郵件通知功能

在Jenkins中配置實現郵件通知,Jenkins提供了兩種方式的配置。一種是Jenkins內置默認的郵件通知,但是它本身有很多局限性,比如它的郵件通知無法提供詳細的郵件內容、無法定義發送郵件的格式、無法定義靈活的郵件接收配置等等。在這樣的情況下,後續考慮可以通過Email Extension Plugin來實現自訂郵件通知的方方面面,比如在發送郵件的同時可以自訂發送給誰,發送具體什麼內容等等。

喜欢就按个赞吧!!!
点击关闭提示