《攜程酒店自動化360度質(zhì)量保障體系》要點:
本文介紹了攜程酒店自動化360度質(zhì)量保障體系,希望對您有用。如果有疑問,可以聯(lián)系我們。
作者:王幸福
編輯:雨多田光
攜程目前很多的框架和項目都在往 Java 技術(shù)棧上進行遷移.在這個過程中我們遇到很多的挑戰(zhàn)和困難,為此我們在原有測試體系的基礎(chǔ)上做了大量的工作,構(gòu)建了一整套卓有成效的質(zhì)量保障體系.本文的開始部分會給大家介紹下目前酒店測試體系的一些情況,后面則會詳細地介紹下這個體系的一部分——Java 覆蓋率統(tǒng)計平臺.
我們常見的測試體系一般如下圖所示:
功能測試、自動化測試等這些測試階段和行為都是圍繞著被測系統(tǒng)進行的,所以我們可以形象地把它們的關(guān)系看作一個 360 度的環(huán),而被測系統(tǒng)則被圍在了環(huán)的中央,就像被保鏢保護起來的重要人物一般.
那很容易想到的是,這個環(huán)上的保鏢越多,圍得越密,被保護的人當然就越安全.當然,保鏢也是需要成本的,如果被保護的人不是那么重要,當然也就用不了那么多的保安.所以,根據(jù)被測系統(tǒng)的重要性以及成本的考慮,不同的公司對質(zhì)量保障體系有著不同考量
攜程酒店的 360 度質(zhì)量保障體系的核心就是 自動化,該體系在傳統(tǒng)的質(zhì)量體系中增加了一些“保鏢”,特別的是,其中一部分“保鏢”是機器人.這么做既增加了被測系統(tǒng)的安全性,也適當?shù)亟档土顺杀?同時,利用自動化,持續(xù)集成、API 測試與監(jiān)控預(yù)警的質(zhì)量和效率都得到了更好的保障.
單元測試
單元測試作為代碼級別的質(zhì)量保障手段,有其不可替代的作用.雖然,攜程酒店的敏捷開發(fā)中并沒有強制進行 TDD 或 BDD 這類的實踐.但作為自動化測試之外有利的補充,也是要求對于自動化測試或者手工測試無法有效測試的部分,編寫單元測試用例進行測試.
持續(xù)集成
目前酒店測試自動化平臺和攜程發(fā)布系統(tǒng)進行整合,每次應(yīng)用在發(fā)布系統(tǒng)中發(fā)布,自動化測試平臺都會進行測試用例的執(zhí)行,并發(fā)送測試報告給測試人員.
測試人員收到報告后會對失敗的用例進行分析,如果有問題就記入 Bug,如果是用例本身的問題,則修改測試用例.
目前酒店測試持續(xù)集成包含了 API、UI 以及 Job 這幾種自動化測試,且除了 UI 自動化之外都實現(xiàn)了無碼測試用例的編寫,測試人員可以很便捷地編寫和維護相應(yīng)的測試用例
集成測試
在此階段,測試人員主要進行的是功能測試,為了給測試人員工作提供便利,我們構(gòu)建了三個平臺:
回歸測試
在回歸測試中,持續(xù)集成依然會繼續(xù)進行,而且通過在早期對測試用例執(zhí)行已經(jīng)進行的分析,此時測試用例的質(zhì)量已經(jīng)得到了加強.測試自動化的實施效果應(yīng)該會更顯著.
性能測試
我們提供了兩種性能測試方式,場景簡單的性能測試,測試人員可以通過性能測試平臺自助的完成性能測試;而對于場景復(fù)雜的性能測試,測試人員可以在性能測試平臺中申請常規(guī)性能測試,由專業(yè)的性能測試人員完成性能測試.
監(jiān)控預(yù)警
產(chǎn)品上線的時候,大家都是如履薄冰,為了能盡早盡快地發(fā)現(xiàn)發(fā)布后的問題,及時快速地定位問題,我們開發(fā)了監(jiān)控預(yù)警平臺,其中包括日志預(yù)警,性能預(yù)警,機器預(yù)警以及報表監(jiān)控.
前面我們介紹酒店目前的質(zhì)量保障體系,那么大家可能會注意到,在整個測試周期內(nèi)會產(chǎn)生大量的測試用例,單元測試用例、API 測試用例、UI 測試用例、Job 測試用例、功能測試用例等等.
那么就面臨著一個問題:如何量化這些測試用例的質(zhì)量,如何衡量測試的完整度和有效性?
自然而然地,我們想到了 覆蓋率,覆蓋率表示的是測試需求和測試用例的執(zhí)行進度,是度量測試完整性的一個手段,是測試有效性的一個度量,覆蓋率有兩種評測方法:基于需求的覆蓋率和 基于代碼 的覆蓋率.
基于需求的覆蓋率
基于需求的覆蓋率比較的直觀,被測系統(tǒng)一共有多少功能,我們編寫的測試用例,測試了多少功能,一目了然,所以平常我們測試最多使用的是基于需求覆蓋的方式,但是基于需求覆蓋的方式很大程度上依賴于需求文檔的完整性,測試人員的設(shè)計測試用例的水平,覆蓋的完整度差異還是比較大的.
基于代碼的覆蓋率
基于需求的覆蓋率是一種黑盒測試的手段,適用于功能測試,但對于白盒測試 (比如單元測試),或者你需要知道你的測試到底覆蓋了多少的代碼、多少的分支,那么它就不適用了.
這時,我們就需要使用基于代碼的覆蓋率,通過基于代碼的覆蓋率統(tǒng)計,你可以很清楚地了解你到底覆蓋了哪些代碼,沒覆蓋哪些代碼,從而可以得到一個具體的量化指標.
同時,在執(zhí)行測試用例后,可以通過代碼覆蓋率了解自己還有哪些功能沒覆蓋,補充測試用例后,代碼覆蓋率自然也會提高.通過代碼覆蓋率去完善測試用例是代碼覆蓋率的重要作用之一.
在開發(fā)覆蓋率統(tǒng)計平臺之前,我們也嘗試過不同的覆蓋率統(tǒng)計的方法,但是都不太能滿足我們的需求.
IDE 中集成的覆蓋率統(tǒng)計工具
Ant、Maven 等 Java 構(gòu)建工具
Jenkins 等持續(xù)集成工具
在設(shè)計 Java 覆蓋率統(tǒng)計平臺之初,我們就設(shè)定了以下幾個目標:
針對設(shè)定的這些目標,我們對現(xiàn)有的發(fā)布系統(tǒng)、自動化測試平臺、Jacoco、Sonar、Gitlab 進行了整合.
Java 覆蓋率統(tǒng)計平臺的網(wǎng)絡(luò)部署圖如下:
Java 覆蓋率統(tǒng)計平臺架構(gòu)圖如下:
Java 覆蓋率統(tǒng)計平臺分為兩部分:部署在應(yīng)用服務(wù)器上的 覆蓋率統(tǒng)計服務(wù) 和 Java 覆蓋率統(tǒng)計站點.
覆蓋率統(tǒng)計服務(wù)
覆蓋率統(tǒng)計服務(wù)是 Python 編寫的 WSGI 服務(wù),為什么需要這個服務(wù)呢?主要是因為 Java 覆蓋率統(tǒng)計平臺通過 Jacoco 的 Agent 技術(shù)監(jiān)控并收集應(yīng)用程序的覆蓋率數(shù)據(jù).
JacocoAgent 有兩種 dump 覆蓋率數(shù)據(jù)的方式,tcpclient 和 file,Java 覆蓋率統(tǒng)計平臺采用的是 file 方式,這種方式需要關(guān)閉應(yīng)用程序的進程后才會 Dump 數(shù)據(jù)到本地.基于這些需求,覆蓋率統(tǒng)計服務(wù)主要實現(xiàn)了以下幾個功能:
Java 覆蓋率統(tǒng)計平臺站點
CDPortal 是攜程內(nèi)部研發(fā)的持續(xù)集成和發(fā)布系統(tǒng),覆蓋率統(tǒng)計平臺可以通過用戶設(shè)置的 Appid 和環(huán)境,調(diào)用 CDPortal 的接口獲取應(yīng)用部署機器的信息以及發(fā)布的版本信息.
當用戶開啟應(yīng)用的覆蓋率統(tǒng)計后,覆蓋率統(tǒng)計平臺會發(fā)送命令給覆蓋率統(tǒng)計服務(wù)配置 JAVA_OPTS,啟動 Tomcat 以開始 Jacoco 的數(shù)據(jù)收集.
用戶開啟 Jacoco 數(shù)據(jù)收集后,可以進行自己需要執(zhí)行的測試,比如 API 測試、UI 自動化、手工測試等等.
當測試完成后,用戶在覆蓋率統(tǒng)計平臺關(guān)閉應(yīng)用的覆蓋率統(tǒng)計,覆蓋率統(tǒng)計平臺會發(fā)送命令給覆蓋率統(tǒng)計服務(wù)重啟 Tomcat,Jacoco 就會把收集到的數(shù)據(jù) dump 到服務(wù)器本地.
然后覆蓋率統(tǒng)計平臺通過覆覆蓋率統(tǒng)計服務(wù)的 Jacoco 文件下載接口把 jacoco 文件下載到覆蓋率統(tǒng)計平臺.當 jacoco 文件下載完畢后,覆蓋率統(tǒng)計平臺會從 Gitlab 中拉取應(yīng)用代碼并進行編譯.
編譯完成后,使用 SonarQube 對下載的 jacoco 文件進行分析.SonarQube 分析完畢后,覆蓋率統(tǒng)計平臺會通過 SonarQube 的 Web 接口獲取覆蓋率統(tǒng)計信息并保存到平臺的數(shù)據(jù)庫中.
最后,用戶在平臺中可以查看覆蓋率統(tǒng)計的報告 (最新的覆蓋率信息、與上次覆蓋率的對比、覆蓋率趨勢圖等等).
統(tǒng)計測試各個階段的代碼覆蓋率
從單元測試到系統(tǒng)測試,整個測試生命周期內(nèi)都可以進行代碼覆蓋率的統(tǒng)計.
代碼覆蓋率黑白名單設(shè)置
在很多情況下,我們可能只需要統(tǒng)計某一部分代碼的覆蓋率情況.Java 覆蓋率平臺提供了黑白名單設(shè)置功能來實現(xiàn)該功能.
靜態(tài)代碼掃描
因為平臺整合了 Sonar,所以也支持代碼掃描功能.使用 Sonar 掃描,可以檢查開發(fā)代碼中潛在的缺陷和不良的編碼習(xí)慣.
一鍵統(tǒng)計
覆蓋率平臺與我們現(xiàn)有的自動化測試平臺進行了整合,我們在開啟覆蓋率統(tǒng)計后,調(diào)用自動化測試平臺的接口進行測試用例的執(zhí)行,測試用例執(zhí)行完畢后進行覆蓋率分析,最后得到覆蓋率統(tǒng)計報告.
覆蓋率統(tǒng)計數(shù)據(jù)查看
覆蓋率統(tǒng)計完畢后,可以通過在 Sonar 中進行代碼覆蓋率數(shù)據(jù)的查看.我們也會通過 Sonar 的 Api 把覆蓋率數(shù)據(jù)落地到服務(wù)器的數(shù)據(jù)庫中.這樣我們就可以知道每次覆蓋率統(tǒng)計的數(shù)據(jù),進而進行覆蓋率數(shù)據(jù)深入的分析.
定時任務(wù)設(shè)置
用戶也可以通過設(shè)置定時任務(wù),設(shè)置某個時刻執(zhí)行哪些應(yīng)用的覆蓋率統(tǒng)計,在定時任務(wù)執(zhí)行完畢后,用戶會得到覆蓋率統(tǒng)計數(shù)據(jù)的報告.
攜程酒店的 360 度質(zhì)量保障體系依然在演化著,朝著更全面,更智能,更效率的方向在努力.在這個提倡數(shù)據(jù)化、智能化、國際化的互聯(lián)網(wǎng)時代,傳統(tǒng)的測試實踐已經(jīng)在經(jīng)受著考驗.如何能在這些挑戰(zhàn)面前保障軟件的質(zhì)量,如何能利用創(chuàng)新來提高效率和質(zhì)量,這是擺在所有測試人面前的問題.
作者介紹
王幸福,攜程酒店研發(fā)部資深測試開發(fā)工程師,負責(zé)酒店測試框架和測試工具的研發(fā).技術(shù)狂熱者,熱衷于開源項目,利用創(chuàng)新去提高測試工作的效率.本文來自王幸福“攜程技術(shù)沙龍——移動互聯(lián)背景下的測試技術(shù)創(chuàng)新”上的分享.
文章來自微信公眾號:聊聊架構(gòu)
轉(zhuǎn)載請注明本頁網(wǎng)址:
http://www.fzlkiss.com/jiaocheng/1979.html