從0到1開發自動化測試框架
一、序言
隨著專案版本的快速迭代、APP測試有以下幾個特點：
首先，功能點多且細，測試工作量大，容易遺漏；
其次，程式碼模組常改動，迴歸測試很頻繁，測試重複低效；
最後，資料環境多樣，使用者場景複雜，功能迴歸覆蓋難全面。
為節省成本，保證高效及高質量迭代，我們需採用更高效的測試方式，App自動化測試是較高效的手段。
之前自動測試實踐過程中遇到的諸多問題（程式碼複用率低，Case開發及資料構造繁瑣，問題定位困難，學習成本高等），為解決相關痛點問題，我們重新實現了一套APP自動測試框架。本文將著重介紹技術選型、設計思路及百度外賣App的具體實踐。
二、自動化測試框架技術選型一個專案中自動化測試是否能有效的展開，自動化測試框架是關鍵所在。因此，如何如何構建穩定的、易擴充套件的自動化的測試專案對於敏捷測試有重要的意義。在設計框架的時候應該儘可能的沿用自動化測試工具已提供的功能，避免重複開發，以減少開發成本。
通過對現有自動化測試工具的原理進行深入分析及優缺點比較，並基於Appium和TestNG兩類自動化測試框架解決上述自動化測試中遇到的問題。
首先，通過利用TestNG結合csv的使用，將測試用例資料轉化為測試程式碼中的資料，減少了測試人員錄入資料和準備資料的工具；
再次，通過對appium的封裝，按照面向物件的思想將測試中用到的頁面元素封裝成物件，增強測試程式碼的複用率，並減輕測試人員對底層程式碼實現的負擔，提高測試程式碼編寫效率；
最後，引入失敗重跑、失敗截圖，並通過reportng生成測試報告的方式，逐步完善測試過程，提高定位問題的速度；
TestNG
Testng是一個開源自動化測試框架，引入了許多新的創新功能，如依賴測試，分組概念，使測試更強大，更容易做到。 旨在涵蓋所有類別的測試：單元，功能，端到端，整合等。TestNG框架可以很好地幫我們完成WebDriver+java的頁面自動化工作,通過各種註釋的靈活執行，可以使你的測試用例更加完美，定製符合要求的測試用例
1. 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物件，它有兩個方面的特徵：
1. 自身元素(WebElement)
2. 實現功能 (Services)
仔細分析測試場景，抽出UI測試的核心行為，無非就是：
1、檢查點：
頁面元素是否存在；
頁面元素顯示內容是否正確；
頁面元素是否可用；
……
2、輔助功能：
等待元素出現；
點選某頁面元素；
給元素輸入內容；
……
分析抽出來的核心行為，發現這些行為基本都是針對一個個頁面元素進行的操作。那麼我們就可以做如下的動作：
將頁面元素看成一個物件，封裝成一個類；
將上面分析得到的核心行為都封裝成基類方法。然後確保，任何一個頁面元素都繼承該基類；
該基類提供類似於自然語言的方法名字，呼叫這些方法，就能很明確的知道測試案例在做什檢查，在做什麼行為，這樣就能極大的提高測試案例的可讀性。
該基類主要目的是在UI測試中，對元素共性的檢查點和輔助方法進行抽取，將它們封裝成一個個非常容易讀懂的方法，且具有異常處理能力。
經過上述思路的整理，測試用例可以改寫成如下：
在實際的使用過程中，可以讓不太熟悉程式碼的QA專門負責測試案例的實現，底層的方法包裝可以由經驗豐富一些的同學做。
5.2、資料驅動
資料驅動的自動化測試框架是這樣的一個框架，從某個資料檔案(例如ODBC原始檔、Excel檔案、Csv檔案、ADO物件檔案等)中讀取輸入、輸出的測試資料，然後通過變數傳入事先錄製好的或手工編寫的測試指令碼中。其中，這些變數被用作傳遞(輸入/輸出)用來驗證應用程式的測試資料。在這個過程中，資料檔案的讀取、測試狀態和所有測試資訊都被編寫進測試腳本里;測試資料只包含在資料檔案中，而不是腳本里，測試指令碼只是一個“驅動”，或者說是一個傳送資料的機制。
在資料檔案中填寫測試資料：
生成Page類：
Page類中初始化頁面元素：
基於資料驅動的好處在於：
在應用程式開發的同時就可以同步建立測試指令碼，而且當應用功能變動時，只需要修改業務功能部分的指令碼；
利用模型化的設計，避免重複的指令碼，減少建立或維護指令碼的成本。
5.3、失敗重跑與失敗截圖機制
自動化測試過程中，常常由於網路、伺服器響應過慢、JS特效及頁面渲染時間較長，導致自動化測試失敗。針對此類場景，本框架設計了一套NRetry機制，即某個case執行失敗後，重跑N次，N可自定義。N次中有一次成功，則繼續執行，若N次均失敗，則截圖、拋錯，停止執行。NRetry機制，一定程度上可以降低由於網路、伺服器響應過慢導致的自動化執行的不穩定性。
5.3.1、失敗自動截圖
新建一個Java類繼承TestListenerAdapter：
重寫onTestFailure、onTestSkipped等方法，在這些方法中加入截圖操作：
在testng.xml檔案中配置自己編寫的監聽器類：
5.3.2、失敗自動重跑
在執行自動化測試用例的時候，經常會出現一些異常的情況的情況導致用例失敗的問題。所以我們可能會希望對於失敗的測試用例再重新執行一次，框架中我們結合TestNG來實現這個功能。
新建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來實現自定義郵件通知的方方面面，比如在傳送郵件的同時可以自定義傳送給誰，傳送具體什麼內容等等。