隨著項(xiàng)目版本的快速迭代、APP測試有以下幾個特點(diǎn)：
為節(jié)省成本，保證高效及高質(zhì)量迭代，我們需采用更高效的測試方式，App自動化測試是較高效的手段。
之前自動測試實(shí)踐過程中遇到的諸多問題（代碼復(fù)用率低，Case開發(fā)及數(shù)據(jù)構(gòu)造繁瑣，問題定位困難，學(xué)習(xí)成本高等），為解決相關(guān)痛點(diǎn)問題，我們重新實(shí)現(xiàn)了一套APP自動測試框架。本文將著重介紹技術(shù)選型、設(shè)計(jì)思路及百度外賣App的具體實(shí)踐。
一個項(xiàng)目中自動化測試是否能有效的展開，自動化測試框架是關(guān)鍵所在。因此，如何如何構(gòu)建穩(wěn)定的、易擴(kuò)展的自動化的測試項(xiàng)目對于敏捷測試有重要的意義。在設(shè)計(jì)框架的時(shí)候應(yīng)該盡可能的沿用自動化測試工具已提供的功能，避免重復(fù)開發(fā)，以減少開發(fā)成本。
通過對現(xiàn)有自動化測試工具的原理進(jìn)行深入分析及優(yōu)缺點(diǎn)比較，并基于Appium和TestNG兩類自動化測試框架解決上述自動化測試中遇到的問題。
Testng是一個開源自動化測試框架，引入了許多新的創(chuàng)新功能，如依賴測試，分組概念，使測試更強(qiáng)大，更容易做到。 旨在涵蓋所有類別的測試：單元，功能，端到端，集成等。TestNG框架可以很好地幫我們完成WebDriver java的頁面自動化工作,通過各種注釋的靈活運(yùn)行，可以使你的測試用例更加完美，定制符合要求的測試用例
Appium一個開源、跨平臺的測試框架，可以用來測試原生及混合的移動端應(yīng)用。Appium支持iOS、Android及FirefoxOS平臺測試。Appium使用WebDriver的json wire協(xié)議，來驅(qū)動Apple系統(tǒng)的UIAutomation庫、Android系統(tǒng)的UIAutomator框架。
相比其他的移動自動化測試工具，Appium測試由于調(diào)用了Selenium的client庫使其可以使用任意的語言，包括Python、Ruby、Node.js、Objective-C等。
測試設(shè)計(jì)過程和測試自動化框架必須作為兩個單獨(dú)的實(shí)體來開發(fā)。
測試框架應(yīng)該獨(dú)立于應(yīng)用程序；
測試框架應(yīng)該易于擴(kuò)展 、維護(hù)和增強(qiáng)；
測試策略／設(shè)計(jì)應(yīng)該對測試者隱藏測試框架的復(fù)雜性。
該框架基于Selenium WebDriver開源技術(shù)開發(fā)。本框架使用Maven工具進(jìn)行Project管理，采用TestNG工具組織測試，應(yīng)用CSV文件存儲測試數(shù)據(jù)，實(shí)現(xiàn)測試數(shù)據(jù)與測試用例的分離，方便測試數(shù)據(jù)管理，降低自動化腳本的維護(hù)成本，實(shí)現(xiàn)數(shù)據(jù)驅(qū)動。此外，該框架還封裝了豐富的Selenium方法關(guān)鍵字，借鑒了QTP語法結(jié)構(gòu)，實(shí)現(xiàn)了直觀清晰的結(jié)構(gòu)化代碼語法，如：Page.Item.Operate，降低自動化代碼的冗余與重復(fù)。借助Jenkins 進(jìn)行CI測試，實(shí)現(xiàn)測試任務(wù)的Schedule 和Report功能，通過Jenkins Master/Slave模式管理虛擬機(jī)節(jié)點(diǎn)，實(shí)現(xiàn)多任務(wù)多機(jī)器分布式并發(fā)的執(zhí)行管理，從而提高測試效率。
基于UI測試，我們希望除了支持web測試，還能支持app的測試，可能還需要接口測試，我們就需要考慮分層問題，將測試框架分為三層。上層是管理整個自動化測試的開發(fā)，執(zhí)行以及維護(hù)，在比較龐大的項(xiàng)目中，它體現(xiàn)重要的作用，它可以管理整個自動測試，包括自動化測試用例執(zhí)行的次序、測試腳本的維護(hù)、以及集中管理測試用例、測試報(bào)告和測試任務(wù)等。下層主要是測試腳本的開發(fā)，充分的使用相關(guān)的測試工具，構(gòu)建測試驅(qū)動，并完成測試業(yè)務(wù)邏輯。
第一層：數(shù)據(jù)層
即執(zhí)行用例時(shí)所需要的測試數(shù)據(jù)，如商戶名、空間名、URL等，這些數(shù)據(jù)用來支撐整個腳本的執(zhí)行。針對數(shù)據(jù)層，這里采了用數(shù)據(jù)驅(qū)動的方式。
第二層：驅(qū)動層
這一層主要封裝各種driver。比如我們針對網(wǎng)頁測試，使用selenium-webdriver開發(fā)包，針對app測試，我們使用appium開發(fā)包。我們在這一層進(jìn)行封裝，通過調(diào)用selenium-webdriver，appium提供的原生方法，封裝成可讀性很強(qiáng)的方法且加上容錯機(jī)制。以后就算我們要換用其他的第三方包，我們的測試案例層和支持層的方法也不需要做任何的修改。只需要修改driver層實(shí)現(xiàn)的方式就可以了。在一層，我們主要實(shí)現(xiàn)兩個方面的封裝，一個是driver的封裝，一個是基于基類自然語言函數(shù)的封裝。
driver封裝
我們需要封裝，根據(jù)參數(shù)確實(shí)是基于web測試還是基于app測試。比如：
基類封裝
主要是封裝各種可讀性很很強(qiáng)的方法以及將元素定位標(biāo)識及driver也封裝進(jìn)去。為了支持網(wǎng)頁測試和app測試，我們需要兩個基類，一個是針對網(wǎng)頁操作基類，一個是針對app操作基類。同時(shí)為了web和app操作的一致性，我們要求對外提供的方法，必須要將常用的方法保持一致的名字和一樣的參數(shù)類型及參數(shù)個數(shù)。
APP基類示例如下：
通過對driver和基類的封裝，driver層實(shí)現(xiàn)了對網(wǎng)頁測試和app測試的支持，并且針對兩種測試，都提供了統(tǒng)一的方法，能夠方便使用者，使用相同的方法，測試app和web。
第三層：測試案例層
該層是測試案例的具體實(shí)現(xiàn)，就像上面寫的case那樣，用接近自然語言的方式，來實(shí)現(xiàn)測試案例。
第四層：支持層
該層主要提供workflow，通用工具，元素庫的支持，便于測試案例層直接調(diào)用。
第五層：結(jié)果保存層
將測試腳本的日志和結(jié)果以自定義的方式展示，這里使用了ReportNG,它可以豐富測試結(jié)果的展現(xiàn)形式，幫助團(tuán)隊(duì)更快定位和解決問題。
5.1、PO模式
5.1.1、遇到的問題
使用webdriver做過一段時(shí)間的測試就會發(fā)現(xiàn)一個對某一個頁面的元素進(jìn)行定位的時(shí)候，程序行間充斥著id()、name()、xpath()等方法，這樣會造成測試程序的可讀性較差，不便于后期的維護(hù)以及修改。
雖然我們可以通過添加注釋的方法使程序便于理解，但是還是不可以從根本上解決這種問題。我們可以通過對這些方法進(jìn)行二次封裝來避免每次對這些方法的直接調(diào)用，通過方法的封裝雖然可以實(shí)現(xiàn)復(fù)用。但是我們發(fā)現(xiàn)通過封裝無法實(shí)現(xiàn)頁面元素的邏輯處理和測試數(shù)據(jù)的獨(dú)立。
5.1.2、問題的解決辦法：引入PO
Page Object模式是Selenium中的一種測試設(shè)計(jì)模式，是指UI界面上用于與用戶進(jìn)行交互的對象。主要是將每一個頁面設(shè)計(jì)為一個Class，其中包含頁面中需要測試的元素（按鈕，輸入框，標(biāo)題 等），這樣在Selenium測試頁面中可以通過調(diào)用頁面類來獲取頁面元素，這樣巧妙的避免了當(dāng)頁面元素id或者位置變化時(shí)，需要改測試頁面代碼的情況。 當(dāng)頁面元素id變化時(shí)，只需要更改測試頁Class中頁面的屬性即可。通過對界面元素的封裝減少冗余代碼，提高測試用例的可維護(hù)性。
一般情況下，對于一個Page Objects對象，它有兩個方面的特征：
· 自身元素(WebElement)
· 實(shí)現(xiàn)功能 (Services)
仔細(xì)分析測試場景，抽出UI測試的核心行為，無非就是：
1、檢查點(diǎn)：
頁面元素是否存在；
頁面元素顯示內(nèi)容是否正確；
頁面元素是否可用；
……
2、輔助功能：
等待元素出現(xiàn)；
點(diǎn)擊某頁面元素；
給元素輸入內(nèi)容；
……
分析抽出來的核心行為，發(fā)現(xiàn)這些行為基本都是針對一個個頁面元素進(jìn)行的操作。那么我們就可以做如下的動作：
將頁面元素看成一個對象，封裝成一個類；
將上面分析得到的核心行為都封裝成基類方法。然后確保，任何一個頁面元素都繼承該基類；
該基類提供類似于自然語言的方法名字，調(diào)用這些方法，就能很明確的知道測試案例在做什么檢查，在做什么行為，這樣就能極大的提高測試案例的可讀性。
該基類主要目的是在UI測試中，對元素共性的檢查點(diǎn)和輔助方法進(jìn)行抽取，將它們封裝成一個個非常容易讀懂的方法，且具有異常處理能力。
經(jīng)過上述思路的整理，測試用例可以改寫成如下：
在實(shí)際的使用過程中，可以讓不太熟悉代碼的QA專門負(fù)責(zé)測試案例的實(shí)現(xiàn)，底層的方法包裝可以由經(jīng)驗(yàn)豐富一些的同學(xué)做。
5.2、數(shù)據(jù)驅(qū)動
數(shù)據(jù)驅(qū)動的自動化測試框架是這樣的一個框架，從某個數(shù)據(jù)文件(例如ODBC源文件、Excel文件、Csv文件、ADO對象文件等)中讀取輸入、輸出的測試數(shù)據(jù)，然后通過變量傳入事先錄制好的或手工編寫的測試腳本中。其中，這些變量被用作傳遞(輸入/輸出)用來驗(yàn)證應(yīng)用程序的測試數(shù)據(jù)。在這個過程中，數(shù)據(jù)文件的讀取、測試狀態(tài)和所有測試信息都被編寫進(jìn)測試腳本里;測試數(shù)據(jù)只包含在數(shù)據(jù)文件中，而不是腳本里，測試腳本只是一個“驅(qū)動”，或者說是一個傳送數(shù)據(jù)的機(jī)制。
1、在數(shù)據(jù)文件中填寫測試數(shù)據(jù)：
2、生成Page類：
3、Page類中初始化頁面元素：
基于數(shù)據(jù)驅(qū)動的好處在于：
在應(yīng)用程序開發(fā)的同時(shí)就可以同步建立測試腳本，而且當(dāng)應(yīng)用功能變動時(shí)，只需要修改業(yè)務(wù)功能部分的腳本；
利用模型化的設(shè)計(jì)，避免重復(fù)的腳本，減少建立或維護(hù)腳本的成本。
5.3、失敗重跑與失敗截圖機(jī)制
自動化測試過程中，常常由于網(wǎng)絡(luò)、服務(wù)器響應(yīng)過慢、JS特效及頁面渲染時(shí)間較長，導(dǎo)致自動化測試失敗。針對此類場景，本框架設(shè)計(jì)了一套NRetry機(jī)制，即某個case運(yùn)行失敗后，重跑N次，N可自定義。N次中有一次成功，則繼續(xù)運(yùn)行，若N次均失敗，則截圖、拋錯，停止運(yùn)行。NRetry機(jī)制，一定程度上可以降低由于網(wǎng)絡(luò)、服務(wù)器響應(yīng)過慢導(dǎo)致的自動化執(zhí)行的不穩(wěn)定性。
5.3.1、失敗自動截圖
1、新建一個Java類繼承TestListenerAdapter：
2、重寫onTestFailure、onTestSkipped等方法，在這些方法中加入截圖操作：
3、在testng.xml文件中配置自己編寫的監(jiān)聽器類：
5.3.2、失敗自動重跑
在運(yùn)行自動化測試用例的時(shí)候，經(jīng)常會出現(xiàn)一些異常的情況的情況導(dǎo)致用例失敗的問題。所以我們可能會希望對于失敗的測試用例再重新運(yùn)行一次，框架中我們結(jié)合TestNG來實(shí)現(xiàn)這個功能。
1. 新建TestNGRetry類，實(shí)現(xiàn)用例失敗自動重跑邏輯：
添加用例重跑監(jiān)聽器RetryListener，用例失敗自動重跑功能：
在testng.xml文件中配置自己編寫的監(jiān)聽器：
5.4、ReportNG
TestNG默認(rèn)的HTML報(bào)表，其默認(rèn)的報(bào)表雖然信息全面，但不易于理解。因此，我們利用ReportNG來替代TestNG默認(rèn)的report。
ReportNG提供了一種簡單的方式來查看測試結(jié)果，并能夠?qū)Y(jié)果代碼進(jìn)行著色。還可以通過修改CSS文件來替換默認(rèn)的輸出樣式。此外ReportNG還能夠生成Junit格式的XML輸出。
由于我們使用的是maven，所以我們主要來看看pom.xml的情況：
maven-surefire-plugin 這個插件主要是用于testng的。我們通過該插件，在對應(yīng)的目錄下./target/${timestamp}生成我們的測試報(bào)告目錄。我們可以看到這個目錄的結(jié)構(gòu)。
這里實(shí)際上就是reportng的測試報(bào)告的生成路徑。但是我們想要通過郵件發(fā)送會很難，因?yàn)閔tml的內(nèi)容需要加在額外的css,以及js文件。而郵件實(shí)際上是不支持外部的css以及js文件的。
HTML的生成
1、定義HTML模版
查看indexMain.html.vm：
下面我們看下生成報(bào)告的部分核心代碼：
在使用ReportNG替換TestNG自帶報(bào)告時(shí)如果報(bào)告中含中文，由于ReportNG 里面Log 是不支持中文的，所以通過修改ReportNG.jar源碼來支持報(bào)告內(nèi)中文展示。
生成定制化后的最終報(bào)告，如下圖所示：
5.5、日志收集
日志是軟件開發(fā)的重要組成部分。自動化執(zhí)行過程的日志信息，對于失敗用例的分析定位以及全過程的跟蹤記錄是十分重要的。
相對于簡單的輸出打印，本框架集成了主流的日志收集工具log4j。Log4j是高度可配置的，并可通過在運(yùn)行時(shí)的外部文件配置。通過配置log4j.properties文件，定義日志級別內(nèi)容及日志輸出路徑收集日志信息（諸如：數(shù)據(jù)庫，文件，控制臺，UNIX系統(tǒng)日志等），提供快速的調(diào)試，維護(hù)方便，以及應(yīng)用程序的運(yùn)行時(shí)信息結(jié)構(gòu)化存儲。
配置文件
Log4j可以通過java程序動態(tài)設(shè)置，該方式明顯缺點(diǎn)是：如果需要修改日志輸出級別等信息，則必須修改java文件，然后重新編譯，很是麻煩；log4j也可以通過配置文件的方式進(jìn)行設(shè)置，目前支持兩種格式的配置文件：
xml文件；
properties文件（推薦）。
下面是一個log4j配置文件的完整內(nèi)容：
5.6、郵件發(fā)送
測試報(bào)告的發(fā)送可以結(jié)合Jenkins來實(shí)現(xiàn)，通過簡單的配置即可實(shí)現(xiàn)。可是如果團(tuán)隊(duì)沒有搭建jenkins或者有時(shí)jenkins不可用，我們應(yīng)該如何去處理這部分的內(nèi)容呢？
既然郵件不能夠依賴jenkins,那肯定得自己去實(shí)現(xiàn)這部分的內(nèi)容了。所以我們還是得依賴一些第三方的jar包。我們在pom.xml配置。
具體的發(fā)送郵件的部分代碼如下：
在后續(xù)的版本演進(jìn)中，將把自動化測試、代碼安全掃描、多機(jī)并行測試、持續(xù)發(fā)布都加入了整體過程，真正的做到全過程持續(xù)交付。
6.1、夜間構(gòu)建加入自動化測試
夜間構(gòu)建會按計(jì)劃定期觸發(fā)自動化構(gòu)建過程，但這種構(gòu)建只是簡單的代碼編譯，沒有可靠的或可重復(fù)的功能測試。后續(xù)考慮Appium結(jié)合Jenkins來實(shí)現(xiàn)構(gòu)建后自動化測試工作。
無論任何時(shí)候，只要代碼更新提交到git中，構(gòu)建服務(wù)器就會觸發(fā)一個構(gòu)建，構(gòu)建運(yùn)行腳本去編譯應(yīng)用程序并且運(yùn)行一系列的自動化單元測試和/或集成測試。通過自動化測試結(jié)果能夠清晰的展示出那些功能特性是通過的，哪些是失敗的。不管是有改動提交，還是定期在夜間觸發(fā)構(gòu)建，應(yīng)用程序都會被自動部署到測試環(huán)境當(dāng)中以便QA團(tuán)隊(duì)進(jìn)行測試。
6.2、Jenkins與STF結(jié)合，實(shí)現(xiàn)多機(jī)并行測試
Jenkins構(gòu)建腳本完成后，將沒有安裝stf組件電腦上連接的android設(shè)備，添加映射到裝有stf平臺服務(wù)的機(jī)器上，將集成測試用例push到STF平臺，再由STF分發(fā)到可運(yùn)行設(shè)備上，進(jìn)行多機(jī)并行測試。
STF執(zhí)行APPIUM測試帶來的優(yōu)勢
第一、可以在真機(jī)上執(zhí)行并行的Appium測試。由于最初的Appium使用對象是模擬器上或只是以每次一臺設(shè)備的測試方法執(zhí)行測試，而STF在原有的基礎(chǔ)上擴(kuò)展了Appium，最多可在數(shù)百臺真機(jī)上同時(shí)執(zhí)行測試的能力。
第二，不需要配置任何設(shè)備的Desired Capabilities。這種方式既簡便，且減少了因?yàn)榫庉嬆_本而產(chǎn)生的不同類型的錯誤。
第三，在STF上執(zhí)行測試可以讓用戶即時(shí)瀏覽測試狀況。也就是說，可以查看到測試執(zhí)行的進(jìn)度，即時(shí)的錯誤反饋，以及保留和查閱所有測試項(xiàng)目，測試腳本和測試結(jié)果（測試截圖，測試日志，性能數(shù)據(jù)等）
6.3、代碼質(zhì)量度量
6.3.1、為什么要分析代碼
對代碼質(zhì)量關(guān)注時(shí)，安排人工進(jìn)行code review是需要的，但100%的code review卻需要投入人員，消耗大量的工作量，而工具自動檢查只需少量人工配置。
最主要的原因就是提高代碼質(zhì)量，了解RD在編碼過程中犯過的錯誤可能對功能邏輯產(chǎn)生的影響，同時(shí)也推動RD讓自己的代碼更具有可讀性和維護(hù)性，所以我們借鑒持續(xù)改進(jìn)的流程，希望能夠在這個過程中有所收獲。
6.3.2、Jenkins引入Sonarqube進(jìn)行代碼持續(xù)審查
Sonar是一個用于代碼質(zhì)量管理的開源平臺，用于管理Java源代碼的質(zhì)量。通過插件機(jī)制，Sonar 可以集成不同的測試工具，代碼分析工具，以及持續(xù)集成工具，比如pmd-cpd、checkstyle、findbugs、Jenkins。通過不同的插件對這些結(jié)果進(jìn)行再加工處理，通過量化的方式度量代碼質(zhì)量的變化，從而可以方便地對不同規(guī)模和種類的工程進(jìn)行代碼質(zhì)量管理。
6.4、email-ext實(shí)現(xiàn)Jenkins郵件通知功能
在Jenkins中配置實(shí)現(xiàn)郵件通知，Jenkins提供了兩種方式的配置。
一種是Jenkins內(nèi)置默認(rèn)的郵件通知，但是它本身有很多局限性，比如它的郵件通知無法提供詳細(xì)的郵件內(nèi)容、無法定義發(fā)送郵件的格式、無法定義靈活的郵件接收配置等等。
在這樣的情況下，后續(xù)考慮可以通過Email Extension Plugin來實(shí)現(xiàn)自定義郵件通知的方方面面，比如在發(fā)送郵件的同時(shí)可以自定義發(fā)送給誰，發(fā)送具體什么內(nèi)容等等。
聯(lián)系客服
