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

[[283756]]

會上，網(wǎng)易傳媒測試總監(jiān)張濤做《網(wǎng)易新聞DevOps實(shí)踐及在AI測試中的應(yīng)用》主題演講。張濤分享了網(wǎng)易新聞在最近一年里在DevOps方面的實(shí)踐，并指出，“DevOps落地的過程也是一個(gè)提升測試價(jià)值的過程，從關(guān)注服務(wù)可用性到關(guān)注系統(tǒng)的可測性和穩(wěn)定性，在研發(fā)、測試和運(yùn)維全流程中發(fā)揮中樞作用。”

以下為張濤演講實(shí)錄：

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

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

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

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

評估時(shí)間樣周期是否合理，通常會看幾個(gè)維度的數(shù)據(jù)，一是整個(gè)研發(fā)的交付周期，從需求發(fā)布后，到進(jìn)入開發(fā)的環(huán)節(jié)，在這個(gè)固定的時(shí)間段之內(nèi)，評估一個(gè)月的時(shí)間。如果這一個(gè)月的時(shí)間有兩個(gè)版本，或者說有1.5個(gè)版本，再評估固定時(shí)間段之內(nèi)研發(fā)產(chǎn)出是什么，真正投入在研發(fā)上的人時(shí)是什么，因?yàn)檠邪l(fā)除了版本迭代投入外，還有很多其它的工作，比如需求評審，Bug修復(fù)，真正研發(fā)投入在需求開發(fā)工作中占了多少，這是我們需要評估的一個(gè)維度。另外一個(gè)維度是真正產(chǎn)出的方面，在一個(gè)固定的時(shí)間段內(nèi)需求交付的數(shù)量，當(dāng)然不能單看數(shù)量，因?yàn)樾枨蟮拇笮〔煌?，耗時(shí)也有不同，通常來說，評估的都是耗時(shí)，一個(gè)需求耗的研發(fā)人力、測試人力，評估固定周期內(nèi)產(chǎn)出多大量的需求。

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

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

我側(cè)重說一下測試的部分，包括客戶端的測試，后臺的測試，推薦的測試，我們都各自有幾個(gè)平臺來支撐測試的工作，以及效率的提升。這里涉及到的客戶端的自動化部分，網(wǎng)易內(nèi)部有一個(gè)易測的平臺，現(xiàn)在也在用iTestin做客戶端UI功能的自動化。關(guān)于后臺的自動化，網(wǎng)易做了一個(gè)叫“GoAPI”的平臺，統(tǒng)一管理后臺所有接口自動化case，實(shí)行統(tǒng)一運(yùn)行。以前大家寫接口，寫case各自管理，各自維護(hù)，不太統(tǒng)一，寫case的規(guī)范也不統(tǒng)一。通過這個(gè)平臺統(tǒng)一管理后，包括后臺的性能測試也都在統(tǒng)一的平臺，測試的環(huán)節(jié)通過幾個(gè)平臺串聯(lián)起來，把自動化的能力全都運(yùn)營起來，這是測試每個(gè)階段所做的工作。

我們現(xiàn)在基于平臺的能力，把TDD的效果做了一個(gè)比較好的實(shí)施和落地，突破了以前做測試開發(fā)方面的局限。TDD能不能做好，最最核心的一個(gè)點(diǎn)就在接口契約上，有了GoAPI平臺，可以統(tǒng)一規(guī)范接口的契約，研發(fā)現(xiàn)在每寫一個(gè)接口，都需要在該平臺上定義接口的所有參數(shù)及每個(gè)參數(shù)的取值范圍。因?yàn)橛辛私涌谄跫s，實(shí)現(xiàn)了在真正寫代碼之前寫自動化的case，這是最本質(zhì)的變化，借此，整個(gè)測試的效率也有了明顯的提升，大概估算了一下，接口功能測試的環(huán)節(jié)大概能節(jié)省三分之一的人力。

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

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

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

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

前面講的是從需求起源開始，到研發(fā)，到測試，如何提升迭代的效率。下面的部分是說產(chǎn)品，或者是版本發(fā)布之后，如何做更多的質(zhì)量保障，這部分更關(guān)注服務(wù)的穩(wěn)定性。在服務(wù)的穩(wěn)定性上，關(guān)注幾個(gè)方面，一是服務(wù)的穩(wěn)定性；第二是全鏈路的監(jiān)控，更多的是把客戶端、服務(wù)端，整個(gè)監(jiān)控打通串聯(lián)起來；第三，故障預(yù)防和演練方面的一些工作，切實(shí)發(fā)現(xiàn)系統(tǒng)里面隱藏的風(fēng)險(xiǎn)。

前面講到提升測試的價(jià)值，在測試的左移方向上如何從需求到研發(fā)，到測試，這個(gè)方面來提升效率。在測試右移的部分，更多的是關(guān)注測試的穩(wěn)定性和測試的風(fēng)險(xiǎn)預(yù)防方面，這方面QA可以發(fā)揮的作用也是非常多的，是重點(diǎn)需要協(xié)作的團(tuán)隊(duì)，一方面是研發(fā)，另外和運(yùn)維協(xié)作得也比較多。

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

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

第三部分說我們的一些測試方法，以及結(jié)合DevOps提升效率。機(jī)器學(xué)習(xí)的測試，其實(shí)和常規(guī)的工程測試有類似的地方。在線工程和我們的常規(guī)后臺測試方法是比較類似的，但是有一部分模型訓(xùn)練的部分，和常規(guī)的測試方法不太一樣。艾老師在這部分也介紹了挺多，測試基礎(chǔ)的覆蓋方面我就不詳細(xì)講了。我們在線服務(wù)的測試，重點(diǎn)是關(guān)注在服務(wù)的穩(wěn)定性上，模型這部分的測試重點(diǎn)是關(guān)注在特征模型準(zhǔn)確性上。我們常規(guī)的測試范疇，包括特征的一致性，是我們關(guān)注比較多的。如何驗(yàn)證特征的一致性，其實(shí)是一個(gè)非常復(fù)雜，龐大的工作，之前在手百工作時(shí)，我們在這方面做了非常大的投入，網(wǎng)易新聞這部分也做了一段時(shí)間。另外，模型訓(xùn)練的部分，最主要的是如何驗(yàn)證模型的有效性以及合理性，這是比較難的一個(gè)部分，首先要去了解、理解模型是如何實(shí)現(xiàn)的，還要找到一套適當(dāng)?shù)姆椒▉碓u估這個(gè)模型的合理性。另外是預(yù)估部分，要看正確性以及分布的情況。

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

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

這就是今天分享的內(nèi)容，謝謝。