一、背景介紹

本文主要從web類業(yè)務(wù)線系統(tǒng)特點出發(fā)，介紹如何從0到1構(gòu)造智能交付系統(tǒng)， 從而提升業(yè)務(wù)線的交付效能。

二、業(yè)務(wù)線特點及面臨的挑戰(zhàn)

1. 特點

（1）業(yè)務(wù)線特點：幾十條業(yè)務(wù)線（團隊），子系統(tǒng)間交互復(fù)雜，業(yè)務(wù)間相互依賴，單項目往往涉及多團隊協(xié)同開發(fā)；業(yè)務(wù)線多項目并行開發(fā)，單周幾百量級項目上線。高度復(fù)雜的子系統(tǒng)在并行開發(fā)的情況下，經(jīng)常導(dǎo)致項目相互影響，比如環(huán)境穩(wěn)定性，api兼容性，代碼被覆蓋，開發(fā)中代碼誤被帶上線等等。

（2）技術(shù)架構(gòu)特點：Java web技術(shù)棧，微服務(wù)/中臺化/組件化。在高頻迭代的情況下，能否快速搭建一套可用測試環(huán)境？單行代碼改動可能會影響多個第三方接口或前端組件，在實際交付過程中要么全量回歸效率低下，要么只回歸改動的功能點經(jīng)常造成漏評估漏測。

（3）測試特點：web系統(tǒng)，手工黑盒測試仍是主要測試手段，自動化是提高回歸效率主要手段。但手工測試一般無覆蓋度量，完全依賴個人經(jīng)驗和能力，自動化用例隨著不斷的建設(shè)積累，執(zhí)行效率越來越低，維護代價越來越大。

2. 帶來的挑戰(zhàn)

如何在多項目多團隊并行開發(fā)情況下，保證各項目有序、有節(jié)奏交付同時，保證高質(zhì)量高效交付（單周2-3次發(fā)版，高優(yōu)項目可隨時上線，80%項目可在2周內(nèi)交付）？

三、建設(shè)方案

研發(fā)流程規(guī)范化、測試能力極致化、測試過程智能化、實現(xiàn)質(zhì)效合一、交付過程向數(shù)字化、智能化轉(zhuǎn)型（篇幅原因，數(shù)字化在本文不作展開）。

（1）研發(fā)流程規(guī)范化/統(tǒng)一化

一是解決多項目多團隊協(xié)同開發(fā)，代碼、環(huán)境相互影響，代碼漏合回等問題；二是統(tǒng)一流程、工具鏈、技術(shù)棧，使一套能力、快速復(fù)用，才能使數(shù)據(jù)結(jié)構(gòu)化、血緣關(guān)系構(gòu)建成為可能，是后兩項建設(shè)的基礎(chǔ)。

（2）數(shù)據(jù)賦能測試中臺能力——從點到面突破

• 環(huán)境高效自動化搭建：測試環(huán)境可以高效自動化搭建，是一切測試改進的基礎(chǔ)。RD自測需要，排查問題需要，手工，自動化測試需要，是項目倒排期，需求變更頻繁等特殊情況下最低要求，否則人海戰(zhàn)術(shù)也無用武之地。

• 手工測試更加精細化：在web和app類的產(chǎn)品交付過程中，可以預(yù)見手工測試仍是未來長期一段時間內(nèi)主要的測試手段，精細化測試可以提升手工測試的效率，降低對人的經(jīng)驗，能力主觀依賴，降低復(fù)雜系統(tǒng)對測試人員的準入門檻，高效召回。

• 數(shù)據(jù)賦能讓持續(xù)集成的自動化測試更加高效有效：自動化仍然是回歸提效主要手段，但業(yè)務(wù)線往往是被淹沒在無限重復(fù)的維護排查工作里，數(shù)據(jù)賦能讓持續(xù)集成的自動化測試更加高效有效。

（3）測試智能化——讓質(zhì)量風(fēng)險可見

將離散在研發(fā)過程，各測試環(huán)節(jié)數(shù)據(jù)提取出來，以項目維度聚合構(gòu)建數(shù)據(jù)血緣關(guān)系，用客觀數(shù)據(jù)（特征）精準刻畫項目質(zhì)量風(fēng)險，引入模型輔助用戶做項目分級，風(fēng)險度量和測試裁剪決策?？梢员苊獠煌巧?，不同研發(fā)階段重復(fù)測試問題，同時也為準出提供一個度量標準，精準召回。

1. 研發(fā)流程規(guī)范化

在統(tǒng)一研發(fā)流程之前，筆者所在業(yè)務(wù)線存在三種研發(fā)模式，項目間經(jīng)常相互影響。因為分支管理比較混亂，單周單次上線業(yè)務(wù)線已經(jīng)承受了很大壓力。同樣需求和代碼管理也是各自為戰(zhàn)，無法獲取研發(fā)效能數(shù)據(jù)，都case by case的解決研發(fā)過程中的問題，亦或問題發(fā)現(xiàn)過晚或甚至被掩蓋。筆者認為所有的研發(fā)過程的改進，都需要從研發(fā)流程規(guī)范著手，因為研發(fā)流程規(guī)范是一個團隊的“靈魂”，是團隊高效運轉(zhuǎn)無形的手。

它本身就可以提升交付效率，減少因流程帶來的線上問題。例如如A項目正在提測，修bug后部署環(huán)境，發(fā)現(xiàn)部署失敗，排查發(fā)現(xiàn)B項目RD提交代碼導(dǎo)致，A項目所有同學(xué)要等B項目修復(fù)代碼才能繼續(xù)提測。并行項目開發(fā)過程中，同時混亂的流程經(jīng)常會有代碼覆蓋或誤被帶上線導(dǎo)致線上問題。

同時它也為數(shù)字化和智能化打下良好的數(shù)據(jù)基礎(chǔ)。若研發(fā)流程不規(guī)范化，基礎(chǔ)研發(fā)數(shù)據(jù)獲取的過程會變成適配各業(yè)務(wù)線定制化要求的陷阱里，需求、研發(fā)、測試、上線過程數(shù)據(jù)結(jié)構(gòu)化根本無從談起。

下面從三個方面介紹一下研發(fā)流程規(guī)范化關(guān)鍵點。

1.1 研發(fā)模式選?。ǚ种Ч芾恚?/span>

• 主干開發(fā)分支上線：適合小而精的業(yè)務(wù)團隊或產(chǎn)品起步階段，需要有比較成熟代碼開關(guān)或比較穩(wěn)定持續(xù)集成測試，以保證主干代碼穩(wěn)定。在不滿足上述條件情況下，多項目多團隊并行開發(fā)，往往項目間會相互影響，代碼穩(wěn)定性差，影響交付效率和質(zhì)量。
  

• 分支開發(fā)分支上線：項目基于從主干開出的分支開發(fā)，上線前從主干開出上線分支，將所以開發(fā)分支代碼合到上線分支發(fā)布，上線完成后合回主干。適合多項目多團隊并行開發(fā)，但有一個致命缺陷，單周多次發(fā)版的高頻迭代中，若上線分支漏合回主干，將會帶來災(zāi)難性后果，上次發(fā)版功能會全部被覆蓋。
  

所以我們基于業(yè)務(wù)線特點，制定了FcFlow分支管理模式，即由開發(fā)分支、主干和上線分支三種分支組成。

有以下三個基本規(guī)則：

• 規(guī)則一：開發(fā)時RD從主干拉開發(fā)分支進行開發(fā), 并基于分支或主干測試；

• 規(guī)則二：項目到達上線窗口后，合入主干，并從主干開上線分支（RB）上線；

• 規(guī)則三：Hotfix在最近一次RB分支上做fix，hotfix在上線完成及時合回主干。

這樣即可以保證多項目多團隊并行開發(fā)不會相會影響，對持續(xù)集成穩(wěn)定性要求低，代碼合入主干至少經(jīng)過手工測試。即使在高頻發(fā)布的過程中，上線分支代碼有漏合回主干情況下，最差情況只有該上線分支hotfix bug被覆蓋。

1.2 需求、開發(fā)、測試統(tǒng)一管理

借助百度內(nèi)部高效的需求、代碼、流水線管理工具鏈，將需求、開發(fā)（代碼）、測試（構(gòu)建）階段用極低的成本關(guān)聯(lián)起來，為基礎(chǔ)數(shù)據(jù)獲取打下堅實基礎(chǔ)。

具體來說：

• 將卡片類型分為2種，需求和任務(wù)卡片，需求卡片管理需求，PM管理；

• 任務(wù)卡片由RD拆分，必須關(guān)聯(lián)需求為父卡片，且rd提交代碼時必須包含任務(wù)卡片id， 這樣就將代碼與需求關(guān)聯(lián)起來。

有上面的基礎(chǔ)，代碼提交時自動觸發(fā)構(gòu)建，就可以根據(jù)規(guī)范自動獲取項目升級涉及模塊、分支、commit等信息自動搭建子系統(tǒng)環(huán)境為持續(xù)集成提供匹配的測試環(huán)境。

1.3 雙周迭代 有節(jié)奏RB

在項目迭代交付過程中，項目需求評審?fù)请S來隨評，從感覺上給人帶來感覺是很快，但實際情況并非如此。

RD項目的開發(fā)中夾雜著項目的評審、溝通&線上問題處理，精力不集中，效率低。QA同樣會導(dǎo)致測試的過程中bug，風(fēng)險后置發(fā)現(xiàn)，效率低下。PM需協(xié)調(diào)UE、依賴方，需求沒完全確認、無前期溝通、人力資源固定性下項目優(yōu)先級如何處理等問題。每個角色的精力都被打散、碎片化。

所以我們制定雙周迭代、單周兩RB迭代交付機制，即雙周做一次需求排期、單周2RB窗口、項目隨測完隨發(fā)車上線、最大限度減少時間等等。需要注意的是只是雙周需求排期的概念，并不是雙周內(nèi)進入迭代需求都要完成上線，小需求快上線、大項目按實際情況上線、流程保證緊急需求可隨時高優(yōu)插入隨時上線。

2. 數(shù)據(jù)賦能使測試中臺能力極致化

有了上面流程基礎(chǔ)（項目迭代高效有序推進，且可以提供脈絡(luò)清晰的項目、團隊等維度基礎(chǔ)數(shù)據(jù)），下面再來看如何基于這些基礎(chǔ)建設(shè)極致的測試中臺能力。

2.1 環(huán)境高效的自動化搭建是一切測試改進的基礎(chǔ)

當前Web類系統(tǒng)的技術(shù)架構(gòu)是高度的微服務(wù)化、中臺化、容器化，RDQA想搭建一套可用的子系統(tǒng)環(huán)境出來，往往涉及到幾十個模塊實例，這些實例容器資源申請、基礎(chǔ)依賴服務(wù)、版本匹配、配置管理、系統(tǒng)拓撲等若都是人工維護，可想而知會大大降低項目的交付效率。對于任何項目測試來說，高效穩(wěn)定的測試環(huán)境永遠是測試改進的起點，否則自動化測試無從談起，連基本的手工測試、研發(fā)都會受影響。Web業(yè)務(wù)類業(yè)務(wù)系統(tǒng)當然也不例外。在微服務(wù)化、中臺化、容器化的大趨勢下，都給環(huán)境部署帶來了更大的挑戰(zhàn)，所以環(huán)境部署效率、穩(wěn)定性、易用性都是影響交付提效的關(guān)鍵因素。

• Base環(huán)境

  
  

業(yè)界常見的環(huán)境解決方案，是在容器化基礎(chǔ)搭建沙盒環(huán)境，但這種方案需要部署子系統(tǒng)所有模塊，消耗大量資源，當子系統(tǒng)模塊越多時也越影響部署效率和成功率。

為解決這個問題，我們設(shè)計base環(huán)境，每個業(yè)務(wù)線子系統(tǒng)只維護一套與線上一致的base環(huán)境，當項目需要搭建環(huán)境時只部署與項目代碼升級的模塊，然后通過路由配置與base環(huán)境未升級的模塊相連通，這樣環(huán)境搭建時只需要搭建2到3個升級模塊，不僅大大提升環(huán)境部署效率，將部署成功率從原來85%提升到95%，同時也將機器資源節(jié)省50+%以上。

• 環(huán)境一鍵搭建
  

雖然base環(huán)境緩解部署效率和資源問題，但部署往往涉及多個模塊配置更新，無論是環(huán)境工具命令行還是提供web操作頁面，需要在平臺做復(fù)雜的配置拓撲才能保證連通性，誤操作導(dǎo)致排查和學(xué)習(xí)成本很大，對RD和新人來說上手成本更大。

于是我們在流程規(guī)范和base環(huán)境基礎(chǔ)上，通過流水線實時獲取項目升級涉及模塊、分支及代碼提交記錄，將拓撲信息和升級數(shù)據(jù)在DB中緩存起來，將環(huán)境的配置、拓撲維護這些復(fù)雜操作對最終用戶透明。當RD、QA甚至PM需要搭建該項目子系統(tǒng)環(huán)境時，只需要“傻瓜式”一鍵點擊便可以快速完成環(huán)境搭建，極大降低環(huán)境學(xué)習(xí)使用門檻，并進一步提升部署效率，單套環(huán)境部署降低20分鐘。

2.2 手工測試：精細化測試 提升測試效率和精準召回的利器

手工測試在未來很長一段時間內(nèi)仍是web類系統(tǒng)最主要的測試手段，但長期以來手工測試主要以黑盒測試為主，完全依賴測試人員的個人能力、經(jīng)驗，基本靠“天”吃飯。比如中臺/微服務(wù)架構(gòu)下，一個底層接口或前端公共組件改動，對上層業(yè)務(wù)影響如何確定，是需要“全都回歸一遍”還是只測試改動功能就可以？如果再遇到新人呢？這就更難應(yīng)對了。

針對上面問題，我們思路是通過離線挖掘代碼間調(diào)用關(guān)系，引入精準測試，在全流程提供數(shù)據(jù)報告輔助一線同學(xué)進行針對性的測試，從而大幅提升測試效率和召回。

• 范圍評估報告

為了解決中臺化和組件化代碼變更帶來影響面難以準確評估的問題，我們通過動態(tài)獲取模塊間接口和離線方式獲取模塊內(nèi)方法調(diào)用關(guān)系，生成任意方法和接口及第三方的映射關(guān)系。當RD提代碼時，實時獲取變更方法查知識庫生成范圍評估報告，可以精準縮小測試范圍、提升交付效率，同時也可以防止漏評漏測、提升交付質(zhì)量。

具體影響面評估報告如下圖所示：

• 增量覆蓋率報告

為了解決測試覆蓋無法度量以及測試過程中無客觀數(shù)據(jù)報告讓QA可以針對性提升測試覆蓋的問題，我們對jacoco覆蓋框架進行改造，可以單次快速生成只顯示變更代碼增量覆蓋率報告。同時與環(huán)境打通，更是可以做到無感知自動收集覆蓋率，并提供實時代碼染色能力，指導(dǎo)RDQA針對性做測試覆蓋提升，降低漏測風(fēng)險。

增量覆蓋率報告如下圖：

2.3 持續(xù)集成：自化用例篩選+智能流水線 只做有效構(gòu)建

隨著自動化用例積累，單業(yè)務(wù)線用例量級突破萬級，若每次都觸發(fā)或每次都執(zhí)行全部用例，任務(wù)成功的概率幾乎為零，會帶來很高的維護和排查成本，同時也會帶來資源浪費。

• 宏觀觸發(fā)層面

引入智能流水線和項目級CI，以項目維度代替模塊級觸發(fā)，跳過不必要或無diff觸發(fā)。比如變更代碼只是加了注釋或日志調(diào)試信息，在識別變更代碼便可以引入策略來決定是否要觸發(fā)流水線構(gòu)建。甚至，可以基于對變更代碼解析，針對性對流水線做智能編排，靜態(tài)代碼分析、單測、接口自動化、UI自動化這些分層測試手段不需要每次都全量執(zhí)行，做到持續(xù)集成的“千人千面”。

• 微觀用例執(zhí)行層面

自動化框架有大量的用例執(zhí)行數(shù)據(jù)也可以用來為測試提效，比如根據(jù)用例歷史執(zhí)行時間和用例執(zhí)行數(shù)量動態(tài)分組和分配并發(fā)任務(wù)數(shù)，解決用例最長執(zhí)行路徑問題，效率提升50%以上。

微觀用例執(zhí)行層面還可以從離線收集用例與代碼，用例穩(wěn)定性數(shù)據(jù)入手，引入用例生命周期，用例覆蓋相似度精簡不穩(wěn)定和重復(fù)用例，通過用例和代碼映射關(guān)系，將代碼變更無關(guān)的用例剔除，形成篩選漏斗，將執(zhí)行時有效用例集合降低到最小，構(gòu)建穩(wěn)定性從70%提升87%，執(zhí)行時間降為原來的50%。

3. 測試智能化：減少重復(fù)測試 讓質(zhì)量風(fēng)險可見

項目質(zhì)量度：精準刻畫項目質(zhì)量 避免重復(fù)測試讓風(fēng)險可見

在高速的項目迭代過程，會有70%左右的項目是小優(yōu)化升級或bugfix，為了項目快速交付會有一大部分項目通過RD自測流程上線。

但這個流程存在一個很大bug，就是項目交付都是按計劃排期，項目是否要走自測試流程上線的時間點，往往是需求排期或緊急插入需求。此時RD并發(fā)開發(fā)一行代碼，完全靠人的經(jīng)驗評估，但人工經(jīng)驗是否靠譜呢？若一行代碼改動影響了很多第三方呢？另外RD自測得怎么樣、QA跟進測試的質(zhì)量風(fēng)險怎樣，能否有量化評估？

• 項目質(zhì)量度
  

研發(fā)規(guī)范統(tǒng)一和極致測試中臺能力，使高效穩(wěn)定獲取各階段各維度數(shù)據(jù)成為可能。質(zhì)量度就是以項目維度為出發(fā)點，收集從需求、研發(fā)、測試等環(huán)節(jié)研發(fā)質(zhì)量和風(fēng)險數(shù)據(jù)，刻畫質(zhì)量風(fēng)險，建立質(zhì)量度模型模擬人的決策，為增量項目測試分級和裁剪提供決策支撐。

比如RDPM靠譜，變更小且沒有影響第三方，自測覆蓋很高，質(zhì)量風(fēng)險很小，就可以走自測流程。反之，則需較高的覆蓋才能準出?；蛘撸陧椖繑?shù)據(jù)畫像分析，風(fēng)險較小，基于增量覆蓋率報告做部分場景補充后，很快達到準出標準，可以裁剪不必要測試，避免重復(fù)、提前交付，從而避免不同角度、不同階段間重復(fù)測試，提升交付吞吐量并大幅降低交付周期。

四、總結(jié)

（1）制定適合產(chǎn)品線特點的研發(fā)流程規(guī)范， 是一切效能提升的基礎(chǔ)；

（2）高效穩(wěn)定環(huán)境自動化搭建能力是所有測試改進的基礎(chǔ)；

（3）將質(zhì)效數(shù)據(jù)+策略有機計劃，形成智能化解決方案，是提升交付系統(tǒng)效能的關(guān)鍵手段；

（4）制定適合產(chǎn)品線和其發(fā)展階段的測試分層攔截體系，做高效的有效構(gòu)建。

整體效果

• 從原來的單周1次發(fā)版，RB周期2天提升到單周2次發(fā)版，RB周期1天；

• 通過質(zhì)量度大幅提升自主測試項目占比，從原來25提升到60%，80分位交付周期下降30%。
  

不過，智能化和數(shù)字化是交付提效大趨勢，但還在起步階段，還有很多場景需要去探索。