從0到1開(kāi)發(fā)自動(dòng)化測(cè)試框架

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