自動化測米樂M6 M6米樂試在京東數(shù)科的實踐與探索

　　米樂M6 M6米樂米樂M6 M6米樂米樂M6 M6米樂DevOps的目標是實現(xiàn)軟件系統(tǒng)的快速交付、并且提升系統(tǒng)穩(wěn)定性和獲得用戶良好的反饋。不知道是不是有些同學(xué)和我一樣，僅僅靠單純概念性的描述比較難以理解什么是DevOps。

　　就好像我們常常說要養(yǎng)成“良好的生活習(xí)慣”，那這個“良好的生活習(xí)慣”可能會包含：早睡早起、健康飲食和合理鍛煉鍛煉等等具體的行為。其實DevOps這個有點抽象的概念也是由一系列具體的行為和軟件工程實踐組成的。包含：基礎(chǔ)設(shè)施即代碼、CI/CD、自動化測試、容器化、服務(wù)編排、自動化部署和軟件度量等。

　　CI/CD流水線是決定系統(tǒng)能否實現(xiàn)快速交付的關(guān)鍵所在，也是DevOps實踐中關(guān)鍵的一環(huán)。

　　而在研發(fā)團隊的實踐過程中，自動化測試往往是一個比較難啃的硬骨頭。我列出其中兩個困難點：

　　在眾多的研發(fā)團隊中，有一些負責(zé)質(zhì)量效能的團隊是自動化測試的先行者。他們能夠抽出專門的資源來編寫自動化測試用例；并通過自己搭建Jenkins來實現(xiàn)自動化測試用例的夜間定時執(zhí)行；還有些團隊自己開發(fā)了測試平臺實現(xiàn)自動化測試用例管理、執(zhí)行和度量等功能。但是這種各自獨立的自動化測試平臺又存在以下問題：

　　按照各自平臺標準開發(fā)的自動化測試用例，由于技術(shù)框架不同等原因，并不能實現(xiàn)資源共享和重用。

　　自動化測試相關(guān)數(shù)據(jù)都是存在各自的平臺中，當(dāng)需要在更大范圍內(nèi)對不同應(yīng)用或系統(tǒng)的自動化測試程序進行度量和評估時，由于標準不統(tǒng)一和數(shù)據(jù)不互通而導(dǎo)致難以實現(xiàn)。

　　自動化測試的機器資源有限，常常由于執(zhí)行資源受限而影響自動化測試的運行效率。而且不時會由于執(zhí)行機器的偶發(fā)性故障影響自動化測試執(zhí)行的穩(wěn)定性。

　　自動化測試常常通過手動觸發(fā)或者定時觸發(fā)執(zhí)行，并沒有與實際的研發(fā)流程結(jié)合起來。研發(fā)在進行日常特性功能開發(fā)、變更的提測、合并主干和發(fā)布上線等操作的時候，并沒有實現(xiàn)實時觸發(fā)自動化測試的執(zhí)行，

　　筆者所在的團隊已經(jīng)為公司內(nèi)部提供了一套完整的DevOps工具方案，從迭代管理、代碼倉庫、分支策略、編譯構(gòu)建、靜態(tài)代碼分析、單元測試、測試環(huán)境部署、自動化測試到線上發(fā)布，貫穿了整個研發(fā)過程。

　　下面重點介紹下自動化測試子系統(tǒng)如何結(jié)合實際業(yè)務(wù)場景來解決研發(fā)過程中的痛點。說起自動化測試的實現(xiàn)方式，筆者以目前通用的實現(xiàn)方案為例，從是否需要寫代碼的角度來分析下其優(yōu)劣：

　　優(yōu)點：靈活性強，可以基于不同的XUnit測試框架（例如基于Java語言的Junit、TestNG；基于Python的Pytest、Unittest等）來實現(xiàn)自動化測試代碼的編寫。對于測試開發(fā)工程師來說，使用原生的框架來通過寫代碼的方式實現(xiàn)自動化測試，有利于自身的技能提升，能夠?qū)W到更多的東西。

　　缺點：有一定門檻，有些測試同學(xué)缺乏編碼能力，要想寫自動化測試代碼，需要首先學(xué)習(xí)基本的編程語言語法，還需要學(xué)習(xí)測試框架的基本使用。

　　優(yōu)點：上手簡單，成本低；測試工程師不需要掌握編程技能，便可以通過頁面配置的方式來編寫一個自動化測試用例（參考Postman等工具）。

　　缺點：擴展能力較差，操作步驟和配置項較繁瑣。不像基于代碼來實現(xiàn)自動化測試有強大的擴展能力，而且一般有較多的配置項，需要通過較多的步驟和配置來實現(xiàn)復(fù)雜業(yè)務(wù)場景。

　　另外還有智能化的自動化測試，既不需要寫測試代碼/腳本，又不需要繁瑣配置，一般可基于線上流量或者業(yè)務(wù)代碼自動生成自動化測試；不過目前來看，智能化測試和基于流量錄制的Diff測試等等覆蓋的場景有限，仍然不能完全替代傳統(tǒng)的自動化測試。

　　而筆者目前所在團隊開發(fā)的JAT自動化測試子系統(tǒng)，支持以上兩種方式來實現(xiàn)自動化測試。用戶既可以通過編寫Java代碼的方式，也可以通過頁面配置化的方式來實現(xiàn)自動化測試。

　　JAT自動化測試平臺致力于解決研發(fā)過程的測試痛點，其目標是為各業(yè)務(wù)研發(fā)團隊提供自動化測試的基礎(chǔ)能力，包含測試生成、測試執(zhí)行和測試度量等。通過與持續(xù)集成流水線的集成和在研發(fā)過程中的內(nèi)嵌，在保障系統(tǒng)高質(zhì)量的前提下，使用自動化的手段逐步提升研發(fā)團隊的交付效率，從而實現(xiàn)DevOps的落地。

　　由原來直接拉取測試工程代碼通過Maven命令執(zhí)行，改為打包服務(wù)和執(zhí)行服務(wù)分離，采用先構(gòu)建測試包，再發(fā)到測試區(qū)執(zhí)行的方式。這種把測試代碼管理和執(zhí)行服務(wù)分開的方式，能夠滿足對測試代碼管理比較嚴格的訴求，可以避免把測試代碼直接拉到測試執(zhí)行環(huán)境，從而一定程度上控制測試代碼的擴散和外漏風(fēng)險。

　　如果是手動觸發(fā)或者定時執(zhí)行的自動化測試計劃，那么只需要在JAT平臺上創(chuàng)建相應(yīng)的測試計劃就可以了。

　　而想要實現(xiàn)一個持續(xù)集成流水線，也就是當(dāng)代碼變更時，能觸發(fā)拉取代碼、編譯構(gòu)建、環(huán)境部署和自動化測試執(zhí)行一連串的操作。就需要在JCI系統(tǒng)里配置一個自定義流水線來實現(xiàn)。

　　目前是通過測試套件（TestNG測試套件）的方式與流水線集成，后續(xù)還會支持通過測試計劃的方式與流水線集成，也就是在流水線中可以選擇該產(chǎn)品/應(yīng)用下屬的自動化測試計劃。

　　為了更好的支持研發(fā)團隊的DevOps實踐落地，JAT自動化測試平臺后續(xù)計劃在以下幾點繼續(xù)豐富功能：

　　接口自動化測試用例的自動生成：能夠進一步簡化編寫自動化用例的成本；基于被測應(yīng)用服務(wù)的源碼和配置等信息，自動生成門檻覆蓋率的自動化測試用例，并一鍵創(chuàng)建測試計劃，從而滿足最基本的基本功能回歸測試需求。

　　自動化測試的精準度量：在目前接口覆蓋率和代碼覆蓋率的基礎(chǔ)上，實現(xiàn)產(chǎn)品/應(yīng)用代碼覆蓋率及變更代碼覆蓋多維度的度量。給研發(fā)提測、部署和發(fā)布等操作提供更加精確和可參考的自動化測試數(shù)據(jù) 。

　　進一步豐富持續(xù)測試功能：在目前對接自定義流水線的基礎(chǔ)上，進一步增加流水線觸發(fā)自動化測試執(zhí)行的場景；并且能夠?qū)崿F(xiàn)自動化測試結(jié)果數(shù)據(jù)與CI/CD流水線系統(tǒng)（JCI）上的其他研發(fā)過程數(shù)據(jù)的深度整合，比如自動化測試覆蓋率與功能測試覆蓋率的數(shù)據(jù)合并計算等。

　　互動討論：你在日常工作中都遇到哪些自動化測試的痛點？又使用了哪些自動化測試的工具？你眼中一個好的自動化測試工具是什么樣子的呢？歡迎在留言區(qū)分享你的困惑或你的見解。