2019年10月26日，由Testin主辦的第二屆NCTS中國云測試行業峰會在京召開，此次峰會以“AI+未來”為主題，匯聚來自國內外測試領域的知名專家學者、領先企業決策者、高層技術管理者、媒體從業者等，共同探討高端云測試技術，幫助測試從業者了解最前沿行業趨勢，及最新的行業實踐。

[[283756]]

會上，網易傳媒測試總監張濤做《網易新聞DevOps實踐及在AI測試中的應用》主題演講。張濤分享了網易新聞在最近一年里在DevOps方面的實踐，并指出，“DevOps落地的過程也是一個提升測試價值的過程，從關注服務可用性到關注系統的可測性和穩定性，在研發、測試和運維全流程中發揮中樞作用。”

以下為張濤演講實錄：

我給大家分享一下最近一年網易新聞在DevOps方面所做的實踐和落地，希望能給大家一些好的思路。正式分享之前，先簡單的做一個自我介紹，我目前在網易新聞負責整個測試的質量保障工作，來網易新聞之前，在百度做了大概七、八年，主要負責手百質量保障的工作。在手百工作期間，我就已經在做很多關于CICD，DevOps方面的實踐。近兩年，一些大公司都在做各種各樣的DevOps嘗試和落地，希望能夠打通串聯，研發、運維，以及測試的環節，更好的提升迭代的效率。今天我重點結合網易新聞實踐的經驗，以及之前在手百期間積累的經驗，給大家做一個分享。

首先是通過DevOps提升迭代效率的思路和方法。第二，在DevOps這個范疇里，如何突出測試的價值。前面這兩個部分是講落地實踐的過程中如何提升測試的價值，我會把價值的提升稍微講一下。第三，機器學習測試及DevOps，今年我們在這部分做了著重嘗試，關于如何落地DevOps，尤其是機器學習相關的部分。上午我也聽了一下艾老師的分享，他講了AI測試上的思路和方法，其中有一部分內容跟我所講的有類似的點，比如關于算法、模型、特征，怎么來測。當然，艾老師的分享重點還是偏重在測試的方法上，我們的重點在測試基礎上，把DevOps和機器學習的測試效率做了更好的提升。

先來看第一部分，常規的迭代效率提升。常規的測試方法，在大的版本迭代上有幾種方式，先是收集需求，然后去排期，研發測試，到最終版本的發布，是一個比較長的周期。如何把這個迭代變得更高效？近一兩年我們的業務迭代速度越來越快，不管對于研發還是測試，壓力都越來越大。如何將需求快速的交付，快速的上線，尤其是在研發、提測之后，到測試的階段，其實是壓力最大的階段，如何提升測試在迭代過程中的效率，盡量避免測試的瓶頸問題，也是我們一直在探索的方向。

想提升迭代的效率有很多基礎性的工作，我們之前在基礎的工作上做了很多長期的建設，比如基礎的自動化工作，基礎的CI工作，只要完成這些基礎自動化能力的積累，才可能提升整個迭代的效率。傳統版本的迭代通常來說類似于火車模式，集中需求的收集、評審，集中的研發，集中的測試，類似于我們常規講的模型，這就是整個版本迭代的模式。這里最大的問題是整個需求都特別集中，迭代過程中如果有任何需求的變更，需求的插入，都很難及時響應。另外，產品的交付周期也會特別長。還有一個很大的問題就是研發的環節，長期很多功能同步在開發，在最后的環節會非常容易出問題，而且整個代碼的末值非常耗時。這是火車模式明顯的問題，如何優化該模式，是我們一直在探索的問題。之前在手百，一直在嘗試從火車模式走到班車模式，班車模式改變了集中需求收集和集中的研發測試的方法，有新的需求隨時去提交，隨時去評審，隨時做研發和測試。當然，這個隨時也不是每天都有，也是在一個相對固定的周期里面，比如一周做一次需求的收集和發布，每周有一定需求的提測和測試交付，這需要根據業務的復雜度，業務團隊的構成情況來評定到底設定什么樣的周期比較合理。我們在手百做了很多測試，通常傳統的方式是一個月到一個半月一個版本，開始做火車模式的時候做得比較激進一些，想變成兩周，涉及到的團隊規模都很大，兩周的模式，尤其是對于QA的模式挑戰是非常大的。因為每次發布都要做回歸，灰度發布，驗證過程，對QA的消耗是非常大的。為了應對這個模式，專門成立了一個發布測試小組，這個小組常規的功能測試就不去參與了，就集中在每周發布測試的工作上。這需要投入很大的人力，而且是獨立的人來做，成本非常高。后來也做了一些調整，網易新聞也是固定三周一個迭代的模式。

評估時間樣周期是否合理，通常會看幾個維度的數據，一是整個研發的交付周期，從需求發布后，到進入開發的環節，在這個固定的時間段之內，評估一個月的時間。如果這一個月的時間有兩個版本，或者說有1.5個版本，再評估固定時間段之內研發產出是什么，真正投入在研發上的人時是什么，因為研發除了版本迭代投入外，還有很多其它的工作，比如需求評審，Bug修復，真正研發投入在需求開發工作中占了多少，這是我們需要評估的一個維度。另外一個維度是真正產出的方面，在一個固定的時間段內需求交付的數量，當然不能單看數量，因為需求的大小不同，耗時也有不同，通常來說，評估的都是耗時，一個需求耗的研發人力、測試人力，評估固定周期內產出多大量的需求。

在模式切換過程中，通常會遇到很多的問題，很多我們所依賴的工具、環境，都是非常割裂的。割裂就會導致無法提效，這樣的問題會讓很好的想法做起來很痛苦，這是我們之前業務的形態，各個環節都是割裂、分散的，需求管理有獨立的平臺，研發代碼的管理，分支的管理也是獨立的一套平臺，上線配制通常是運維獨立管理的一套東西，測試自動化的平臺、工具都是測試的團隊來負責的。各個平臺又都各自維護，各自管理，在整個迭代過程中很難非常流暢的打通，這個問題非常影響整體效率的提升。

我們怎么做這個工作？業界也有先行的經驗，之前百度內部就做了一套類似的平臺，在阿里、騰訊，幾個大廠都有類似的平臺，研發效能提效的平臺，比如阿里的云效平臺，騰訊的TAP平臺。在網易，我們是聯合著項目管理的團隊一起來做了OverMind平臺，其最大的作用就是從需求到研發，到上線，到測試，把各個環節常規所需要用到的一些平臺和工具都串聯打通。比如需求的管理，研發所使用的分支管理工具，以及測試的工具，上線的平臺，都進行串聯打通。我們測試也都把iTestin提供的自動化的能力集成到了我們整個的流程里面。

我側重說一下測試的部分，包括客戶端的測試，后臺的測試，推薦的測試，我們都各自有幾個平臺來支撐測試的工作，以及效率的提升。這里涉及到的客戶端的自動化部分，網易內部有一個易測的平臺，現在也在用iTestin做客戶端UI功能的自動化。關于后臺的自動化，網易做了一個叫“GoAPI”的平臺，統一管理后臺所有接口自動化case，實行統一運行。以前大家寫接口，寫case各自管理，各自維護，不太統一，寫case的規范也不統一。通過這個平臺統一管理后，包括后臺的性能測試也都在統一的平臺，測試的環節通過幾個平臺串聯起來，把自動化的能力全都運營起來，這是測試每個階段所做的工作。

我們現在基于平臺的能力，把TDD的效果做了一個比較好的實施和落地，突破了以前做測試開發方面的局限。TDD能不能做好，最最核心的一個點就在接口契約上，有了GoAPI平臺，可以統一規范接口的契約，研發現在每寫一個接口，都需要在該平臺上定義接口的所有參數及每個參數的取值范圍。因為有了接口契約，實現了在真正寫代碼之前寫自動化的case，這是最本質的變化，借此，整個測試的效率也有了明顯的提升，大概估算了一下，接口功能測試的環節大概能節省三分之一的人力。

還有一個環節在測試過程中遇到的非常多，而且是非常頭疼的問題，就是環境管理建設。大家做測試時都是每人建一個環境，建環境的腳本、方法，也都是各不相同，這個成本又比較高，研發每次更新代碼的時都要修改大環境腳本，環境搭建耗時且整個配制都很繁瑣，一個人只能用自己的環境，別人想用你的環境還要來找你，你再幫他去搭一個環境，這是非常耗時和麻煩的過程。而基于OverMind平臺管理環境，實現了自動化的環境搭建，將整個環境創建的過程實現一鍵式自動化。當然，這非常依賴研發的配合，因為很多環境的搭建，一些參數，尤其是環境里面配制的工作，跟研發的代碼是非常相關的，我們要和研發配合做很多很多的聯動和修改，基本上每個業務模塊都要跟研發一起去改配制，才能實現最終的自動化。

這是實現環境自動化之后的效果，一個業務模塊變更了，只需要更新這一個業務模塊的環境。我們有一個集成回歸的環境，在整個大的環境里面，如果有服務調用，就可以去調回歸環境另外依賴的服務。如果兩個業務模塊都有變更，需要調變更的模塊，就需要通過回歸的環境把另外一個依賴環境的代碼同步過來。我們在OverMind平臺上實現了環境的管理，每一個模塊環境的部署情況，都可以在這里直觀的展示。最終，環境搭建的整體效率提升了240倍，以前搭一個環境需要幾個小時，兩三個小時是常規的情況，如果遇到非常復雜的業務，這個過程可能需要小半天。我們現在有了這樣一套在OverMind上做環境管理的工具之后，環境基本上分分鐘就搭起來了。另外，環境的數量也提升了非常多，以前只能有自己的一套環境，現在隨時想用哪個環境都可以快速的去搭建了。

另外，我們把CI的整個環節在OverMind平臺里做了打通，通過該平臺做CI的觸發和功能的調用，在流水線里把所有自動化的能力集成起來。除了代碼的CI之外，還有一個需求的CI，都能夠在我們平臺里有一個非常直觀的展現。

前面所講的這些部分重點還是關注在測試的可測性上，從大的DevOps范疇來講，重點關注在測試左移，也就是說如何從測試自身的范疇里往研發，往需求的方向做更多的擴展，更多關注的是可測性和需求的合理性。除了剛才提到的自動化工具，平臺工具之外，另外要做的一些工作，比如說單測，以及Code Review的工作，我們在日常工作中也會做一些投入，這要求我們和研發、產品，有非常密切的配合。

前面講的是從需求起源開始，到研發，到測試，如何提升迭代的效率。下面的部分是說產品，或者是版本發布之后，如何做更多的質量保障，這部分更關注服務的穩定性。在服務的穩定性上，關注幾個方面，一是服務的穩定性；第二是全鏈路的監控，更多的是把客戶端、服務端，整個監控打通串聯起來；第三，故障預防和演練方面的一些工作，切實發現系統里面隱藏的風險。

前面講到提升測試的價值，在測試的左移方向上如何從需求到研發，到測試，這個方面來提升效率。在測試右移的部分，更多的是關注測試的穩定性和測試的風險預防方面，這方面QA可以發揮的作用也是非常多的，是重點需要協作的團隊，一方面是研發，另外和運維協作得也比較多。

分別講一下兩個方面的工作，一是全鏈路的監控，我們已經做了有一段時間，全鏈路監控概念的方面，大家都有了基本的了解，如何梳理服務的依賴關系，做鏈路的追蹤，把整個請求的鏈路串聯起來。另外還有鏈路調用的性能，每一個請求的性能是怎樣的，能夠快速的發現性能上的一些瓶頸，這是全鏈路監控整體的思路。核心是做鏈路的監控，最核心的是要有一個監控的ID，比如在網易新聞里面刷新一次，或者點了某一條新聞，點擊的操作就會有一個請求，在這個客戶端給服務端發請求的時候，要自動生成ID，一直帶到服務端，服務端再把ID一直帶到最終請求的服務最終的節點上。服務端的調用涉及比較多調用的層級，每個調用層級又有一個核心的點，就是SpanID。它能夠記錄一個服務到另外一個服務請求的關系，最終整個全鏈路的調用過程會生成一個記錄，這樣就可以在追查問題的時候，根據一個請求快速查找到最終調了哪些服務，中間在哪里出問題了，這是全鏈路監控的思路。

故障演練核心關注兩個層面，一個是服務依賴，如何把強依賴轉成弱依賴。第二是把無損降級轉成有損降級。可以看到右側的兩個圖，比如網易新聞里面最常用的發帖，發評論，我們以前是第一個調用的方式，后來把依賴的關系都隔離了，轉成右側調用的關系，把一個強依賴轉成了弱依賴。比如后臺的服務，跟貼排行榜出問題了，但不會影響發帖的過程。故障演練更多關注的一個故障類型有幾類，一是硬件層面的問題，另外是中間件方面關注得比較多，比如數據庫的問題，緩存的問題，另外就是服務依賴，有自身的內部服務依賴，還有調用第三方的服務會有一些依賴。自身應用部分，重點關注現成的一些情況，這是常規關注的故障類型。故障演練的方法主要是有幾個方面，一是要有數據的積累，數據積累后如何定義故障的規則以及故障注入，相當于是故障的case，和寫常規的case是類似的，最終是怎么做結果的校驗，看有沒有逾期的報警。現在故障演練也都逐步做平臺化，做平臺化需要很多基礎的積累，需要數據和規則，如果沒有，也很難實現平臺化。目前做了一段時間，發現了幾方面的典型問題，一是數據庫方面，數據庫和緩存這兩類的問題都比較多。另外一方面是服務依賴的問題，就是剛才提到的有自身服務的依賴，還有第三方服務的依賴，還有是硬件方面的問題。

第三部分說我們的一些測試方法，以及結合DevOps提升效率。機器學習的測試，其實和常規的工程測試有類似的地方。在線工程和我們的常規后臺測試方法是比較類似的，但是有一部分模型訓練的部分，和常規的測試方法不太一樣。艾老師在這部分也介紹了挺多，測試基礎的覆蓋方面我就不詳細講了。我們在線服務的測試，重點是關注在服務的穩定性上，模型這部分的測試重點是關注在特征模型準確性上。我們常規的測試范疇，包括特征的一致性，是我們關注比較多的。如何驗證特征的一致性，其實是一個非常復雜，龐大的工作，之前在手百工作時，我們在這方面做了非常大的投入，網易新聞這部分也做了一段時間。另外，模型訓練的部分，最主要的是如何驗證模型的有效性以及合理性，這是比較難的一個部分，首先要去了解、理解模型是如何實現的，還要找到一套適當的方法來評估這個模型的合理性。另外是預估部分，要看正確性以及分布的情況。

這里可以簡單看一下我們模型訓練的整個流程，從線上所有的用戶日志行為開始，我們拿到這些日志之后，做數據的處理，特征的計算，然后做模型的訓練，以及在線的預估，這是整個模型訓練的流程。在這個流程里面，最核心的兩個部分，當然日志的收集和數據處理部分還是跟常規做業務測試，做后臺服務，測試的方法是類似的，最主要的差別還是在特征和模型部分。特征的有效性以及模型的有效性，如何驗證？這其實是最核心的。另外，我們如何配合研發，把這部分的工作能夠做得更有效率一些。之前遇到很大的一個問題，一個模型從訓練到上線，耗時是非常長的，長的時候要一周，如果到傳統行業里面，一個新的模型上線要經歷更長的時間，半個月，甚至一個月的時間，如何提升模型訓練的效率，這其實也是我們和研發配合做的一個機器學習的服務平臺。這里面所做的核心工作，是把研發日常線下所做的很多工作，比如需要的日志，物料，所有特征的結果，以及模型訓練的結果，通過這個平臺直觀展示出來，在這個平臺上查詢日志總體的分布，物料都有哪些，模型的更新情況，都可以在這個平臺上快速的實現自動化。我們做這個平臺最主要的目的是把特征訓練和模型訓練方面的工作做平臺化和服務化，也是結合著前面做迭代效率提升的方式是類似的，通過OverMind平臺把整個客戶端和服務后臺的測試都實現平臺化和服務化。當然，機器學習的研發測試和產品介入的比較少，類似于需求管理部分相對不會涉及太多。

這是我們的一個效果，在平臺上把整個特征工程的訓練結果，以及所有配制修改上線，全都服務化了，這里能列出來當前在使用的特征都有哪些，這些特征的狀態是不是在線上，是什么時候上線的，如果有問題，需要在這里做一些配制，修改，然后再重新做上線的操作，一次性的都可以自動化的完成了。模型的部分也是，模型的實驗和上線也是類似的方式，我們把整個模型訓練的效果，以及它所依賴的一些特征，特征的關聯關系，都在這里展示出來，在平臺上可以做配制的修改和上線。輔助研發，把整個模型的訓練效果和周期做一個有效的提升。

這就是今天分享的內容，謝謝。