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