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

[[283750]]

會(huì)上，阿里巴巴測試開發(fā)專家潘家騰做《阿里媽媽在線下測試域的智能化建設(shè)》主題演講。潘家騰分享了阿里媽媽在線下測試方面的實(shí)踐，包括業(yè)務(wù)的現(xiàn)狀與挑戰(zhàn)，進(jìn)入智能化的邏輯，以及如何實(shí)現(xiàn)線下測試的智能化。

以下為潘家騰演講實(shí)錄：

大家早上好！Testin做的工作挺有意思，我挺大開眼界的。原來UI能這么測，通過智能化應(yīng)用讓整個(gè)測試更加簡單。以前是我們測試的同學(xué)來做，以后能讓非測試的同學(xué)，開發(fā)、算法、運(yùn)營的都可以來做，普通人都可以來做，甚至讓機(jī)器來做，都是沒有問題的。

我今天分享的是阿里媽媽在線下測試方面的實(shí)踐，我們的業(yè)務(wù)現(xiàn)狀與挑戰(zhàn)，進(jìn)入智能化的邏輯，以及線下測試的智能化。智能化是非常高大上的技術(shù)，而線下測試更多的是比較腳踏實(shí)地的工作，如何將高大上的技術(shù)和腳踏實(shí)地的工作結(jié)合起來，這是我本期要講的重點(diǎn)。

首先，讓我們一起來看一下阿里媽媽在測試中遇到的一些問題。線下功能測試的發(fā)展歷程，分為三個(gè)階段，第一是大航海時(shí)代，特點(diǎn)是以人工測試為主，自動(dòng)化程度不高；第二個(gè)階段是工業(yè)革命時(shí)代，自動(dòng)化程度非常高了，測試的框架也有了，加上持續(xù)集成的工具，比如阿里內(nèi)部的一些平臺(tái)，共同組成了很高的自動(dòng)化方式。但是，由于測試技術(shù)的門檻非常高，開發(fā)無法參與進(jìn)來，大部分工作都由測試來進(jìn)行。在阿里內(nèi)部，有不少團(tuán)隊(duì)還是處于高自動(dòng)化的時(shí)代，但是還沒有進(jìn)入智能化的時(shí)代；第三階段是智能化的時(shí)代，特點(diǎn)是產(chǎn)品化、可視化，以及部分的智能化，大大的提高效率。我們嘗試著讓整個(gè)測試工作更簡單，通過降低門檻，讓開發(fā)、算法或者其他同學(xué)都能夠參與進(jìn)來。這個(gè)階段主要是向測試平臺(tái)或者測試中臺(tái)的演進(jìn)。

這是阿里媽媽遇到的挑戰(zhàn)，廣告部門是非常大的一個(gè)盤子，包括超大規(guī)模的在線系統(tǒng)，鏈路數(shù)據(jù)化，以及非常復(fù)雜、個(gè)性化的商業(yè)場景。進(jìn)行千級(jí)別的線上發(fā)布，有問題的話反饋需要非?？?，否則會(huì)造成非常大的損失，還有性能的極致要求，這對測試同學(xué)的挑戰(zhàn)是非常大的。在剛剛幾大復(fù)雜的場景下，第一個(gè)挑戰(zhàn)是測試開發(fā)比占的非常高，第二個(gè)是迭代頻率已經(jīng)是天級(jí)別了，第三是測試場景超復(fù)雜，復(fù)雜程度呈指數(shù)增高。我們復(fù)盤了原先在阿里媽媽內(nèi)部的方式，之前是保姆式的測試方式，瓶頸都集中在QA上。人就那么多，項(xiàng)目更多之后，無論我們怎么做優(yōu)化，瓶頸都在我們這里，不得不逼著我們進(jìn)入智能化時(shí)代。

方案就是打造協(xié)同化的測試模式，在傳統(tǒng)模式的基礎(chǔ)上開辟一條快速模式，走智能化的方式，打造一個(gè)測試平臺(tái)，主要是低風(fēng)險(xiǎn)和算法的項(xiàng)目，高風(fēng)險(xiǎn)項(xiàng)目仍由測試主要來負(fù)責(zé)。這個(gè)平臺(tái)通過智能化、可視化、產(chǎn)品化的方式，讓開發(fā)、算法的同學(xué)進(jìn)行自動(dòng)化的測試，由系統(tǒng)來判定準(zhǔn)入，判定準(zhǔn)出，如果系統(tǒng)通過了，可以隨時(shí)上線。

關(guān)于線下測試平臺(tái)的思考，我們有幾大訴求。第一大訴求是這個(gè)平臺(tái)隨時(shí)可測，開發(fā)的同學(xué)無論何時(shí)何地都能快速的進(jìn)行測試。這需要很方便的case編寫，讓測試想法能夠快速的映射為case，使系統(tǒng)可以高效的做用例管理，測試環(huán)境管理，實(shí)現(xiàn)極致的運(yùn)行效率。整個(gè)平臺(tái)的方向有三個(gè)，第一是極致的測試左移，第二是成為線下測試的基礎(chǔ)設(shè)施，第三是研發(fā)流程的重構(gòu)?；谶@些方向，整個(gè)測試平臺(tái)該怎么做？Markov是我們打造的智能化線下測試平臺(tái)，作為非常強(qiáng)大的基礎(chǔ)設(shè)施，本期會(huì)介紹其中的部分智能化技術(shù)，如智能回歸，用例智能推薦，數(shù)據(jù)智能推薦，冒煙回歸技術(shù)，用例膨脹，智能排查閉環(huán)等，其他如基于docker的分布式容器管理，萬級(jí)別用例管理系統(tǒng)，分布式智能任務(wù)調(diào)度系統(tǒng)，這次就不說了。

智能化技術(shù)非常重要，但是如何結(jié)合測試場景是更重要的事情。功能測試域主要分為三個(gè)部分，第一部分是怎么寫case，就是用例生成，第二是用例回歸，也就是說寫完case之后快速的迭代這些case，第三是一旦case跑失敗之后，怎么做智能排查，這三塊智能化都有所體現(xiàn)。

首先介紹個(gè)概念，即用例畫像，對測試而言，什么是護(hù)城河和資產(chǎn)？那就是用例。我們對阿里媽媽上萬的用例做了精煉提取和組合，最終我們每個(gè)用例都形成了自己的畫像，包括用例名稱，覆蓋的代碼域，業(yè)務(wù)特征，用例失敗歸因，相似用例集，就是說其它用例跟它相似度、關(guān)聯(lián)度是怎樣的，還有衍生的異常用例集，以及運(yùn)行穩(wěn)定性等等?；谡麄€(gè)用例畫像就可以一覽用例的全貌，是一種讓用戶能夠全面感知用例的方式。同樣，用例畫像也是我們實(shí)現(xiàn)智能化的重要基礎(chǔ)。

用例智能推薦的目標(biāo)很簡單，那就是希望傳統(tǒng)標(biāo)準(zhǔn)化的用例編寫能夠升級(jí)為極致體驗(yàn)的case編寫方式。以前從測試名稱開始寫，再寫依賴的測試數(shù)據(jù)，再寫發(fā)送請求和期望，這是最簡單的?；蛘咴谟美龓熘衏opy一個(gè)用例數(shù)據(jù)。因此，傳統(tǒng)的方式就是直接手動(dòng)寫，或者是copy以前的老用例。Markov的智能用例推薦的方式，我們提供了一個(gè)智能框，用戶可以隨便描述一下需要什么樣的用例，甚至把設(shè)計(jì)文檔直接copy進(jìn)去，Markov平臺(tái)就可以把你輸入的描述提取成一個(gè)一個(gè)業(yè)務(wù)特征。同樣的，我們在整個(gè)用例庫中，如果有上千個(gè)用例庫，每個(gè)用例進(jìn)行訓(xùn)練形成特征池。這個(gè)時(shí)候可以用自然語言處理，最后會(huì)提出業(yè)務(wù)特征。通過樸素貝葉斯算法，我們可以獲取到相似度TopN的關(guān)聯(lián)用例列表，最終確定選擇，快速拿到上千個(gè)用例中最相近的用例。這樣省去了搜索的過程，也方便了寫用例的過程。右面這個(gè)圖是用例膨脹，我們寫完一個(gè)正常用例之后要寫異常用例，最基本的過程是調(diào)整參數(shù)，改為極大值，邊界值，異常值，亂碼等等。我們訓(xùn)練了一個(gè)N-wise特征模型，在整個(gè)用例庫中訓(xùn)練出了多因子模型，比如特征有1、2、3、4，我們可以拿到這些數(shù)據(jù)的類型，根據(jù)類型來得到異常值。當(dāng)我們訓(xùn)練出整個(gè)庫中的特征，所有的異常值、邊界值組合之后，這樣就好辦了，將我們剛剛智能推薦找到的一個(gè)用例進(jìn)行組合變異。我們想進(jìn)行某一個(gè)特征的膨脹，就從系統(tǒng)里面推薦出膨脹的組合值，通過最終的叉乘就能組合出異常用例集，最終由用戶進(jìn)行挑選和篩選。通過這種組合，會(huì)碰撞出非常多的用例，就能快速的完成多個(gè)用例的生成。

下面是數(shù)據(jù)智能推薦，在case級(jí)別推薦的基礎(chǔ)上，能更精準(zhǔn)的進(jìn)行測試數(shù)據(jù)的推薦，讓case編寫的速率進(jìn)一步演進(jìn)。智能推薦提供了一種解決了快速找到用例的方式，但是找到這個(gè)用例之后還要進(jìn)行修改編寫，數(shù)據(jù)智能推薦就是做這件事情的。在寫測試數(shù)據(jù)的時(shí)候，基于原有的修改用例方式，如果找不到某個(gè)測試數(shù)據(jù)，我們可能是去其他case中找到測試數(shù)據(jù)，然后再copy過來修改。Markov平臺(tái)做的事情就是當(dāng)你想寫測試數(shù)據(jù)的時(shí)候，當(dāng)選中它時(shí)系統(tǒng)就已經(jīng)給你推薦了最適合的一個(gè)測試數(shù)據(jù)。我們有三種推薦方式，第一種是模板推薦，就是用戶可以自定義定制的數(shù)據(jù)源模板的推薦方式。第二種是最長匹配方式，我們將測試數(shù)據(jù)進(jìn)行簡單的推薦，這個(gè)方式很簡單，我們假定了最長的測試數(shù)據(jù)所包含的信息是最全的，也是你最可能需要的。第三是相似用例距離的推薦，就是基于剛剛用例的相似度進(jìn)行推薦，如果這個(gè)用例跟你當(dāng)前編輯的用例是非常相似的，他們使用的數(shù)據(jù)大概率也是你需要的。我們做這個(gè)工作之后，再修改測試數(shù)據(jù)的時(shí)候就是非?？斓氖虑椤?/p>

第三個(gè)是智能冒煙回流技術(shù)，這個(gè)技術(shù)非常有意思，也是我們在做的一個(gè)工作，希望能夠從另外一種方式來生成用例。這個(gè)方式是我們基于生產(chǎn)流量冒煙來進(jìn)行測試，并結(jié)合用例智能推薦技術(shù)，快速回流為線下用例，從而打通線上線下的閉環(huán)。這是什么意思呢？傳統(tǒng)測試的方式，我們找到一個(gè)用例，開始改，然后進(jìn)行測試。這個(gè)冒煙調(diào)試是另外一種方式，借鑒了阿里媽媽內(nèi)部算法同學(xué)的調(diào)試方式。他們會(huì)在線上來冒煙，用線上的數(shù)據(jù)和自己的數(shù)據(jù)和生產(chǎn)的流量來進(jìn)行監(jiān)測，如果沒有問題了，他們就完成了這次工作。我們在想，能不能給他們提供一個(gè)方案，在線上做的時(shí)候，能夠一鍵的將線上流程回放，轉(zhuǎn)化成線下的case，這樣線上調(diào)試完之后，線下庫中就自動(dòng)有case了。這是怎么實(shí)現(xiàn)的？它依賴于比較完善的一個(gè)基礎(chǔ)設(shè)施，阿里媽媽內(nèi)部有非常好的基礎(chǔ)設(shè)施，比如環(huán)境的基礎(chǔ)設(shè)施，我們能夠快速的、一鍵的，拿到跟生產(chǎn)環(huán)境一致的環(huán)境，這就是環(huán)境克隆。我們拿到這個(gè)環(huán)境之后，算法能夠基于我們的數(shù)據(jù)工廠給出的流量來進(jìn)行改造，然后進(jìn)行簡單的線上冒煙，冒完之后我們提供一鍵轉(zhuǎn)換線下流量的模式。這里會(huì)產(chǎn)生兩個(gè)問題，那就是線上線下始終是有g(shù)ap的，數(shù)據(jù)必然是不一樣的。我們做了一些工作，第一個(gè)工作就是對一些比較簡單的模塊，在冒煙的過程，從日志級(jí)別獲取整個(gè)應(yīng)用依賴的測試數(shù)據(jù)，輸入數(shù)據(jù)我們有了，能回流到線下了，實(shí)際輸出的也有了，就能夠以無gap的方式進(jìn)行線下流量的轉(zhuǎn)換。但是這種方式大家發(fā)現(xiàn)了嗎，整個(gè)開發(fā)代碼侵入性是非常大的，它必須要依賴開發(fā)進(jìn)行埋點(diǎn)。于是我們采用另外一種方式，就是推薦技術(shù)，冒煙的輸入請求。我們會(huì)抽取出部分的輸入請求特征，或者是輸出期望特征，然后根據(jù)用例庫中的用例特征來推薦出可能想要的用例。推薦完之后，再將用例進(jìn)行改造，讓系統(tǒng)自動(dòng)做改造的工作，就要就能夠基于改造后的用例來寫用例。

然后是智能回歸技術(shù)，我們研發(fā)了一個(gè)用例動(dòng)態(tài)編排算法，提升了2到10倍的回歸效率，打破回歸時(shí)長隨著用例數(shù)線性增長的曲線?；貧w測試就是把用例庫中的用例批量跑一遍，但是即使這么簡單，它仍然是一個(gè)阻礙我們研發(fā)效率的重要環(huán)節(jié)。傳統(tǒng)模式下，由于很多原因，我們只能進(jìn)行case by case的執(zhí)行，依賴的數(shù)據(jù)會(huì)有重啟和數(shù)據(jù)沖突。Markov平臺(tái)希望能在整個(gè)用例編排的過程中實(shí)現(xiàn)最高效的編排，讓整個(gè)回歸效率成倍的增長，最終打破增長曲線。我們有幾十個(gè)用例的時(shí)候回歸一次還好，但是有幾百上千用例的時(shí)候怎么辦呢？可能有些同學(xué)是進(jìn)行精準(zhǔn)測試，只跑一些代碼不影響的用例，另外一種方式是多幾套環(huán)境并行跑，這其實(shí)是犧牲資源來換時(shí)間的方式，因?yàn)橘Y源總是有限的。Markov希望通過編排的算法，只要打破增長曲線就完了。我們在單環(huán)境的回歸上，如果打破了這個(gè)曲線，整個(gè)多環(huán)境回歸的情況下就好做很多。多環(huán)境指的是并行多套環(huán)境，傳統(tǒng)的方式是非常簡單的，用例總數(shù)跟環(huán)境數(shù)進(jìn)行平分，Markov的方式，因?yàn)槲覀兎e累了用例時(shí)間對回歸的影響，就能反作用來進(jìn)行用例的動(dòng)態(tài)分配，通過預(yù)估回歸方差來實(shí)現(xiàn)全局最優(yōu)，盡可能讓每個(gè)環(huán)境的用例時(shí)間進(jìn)行均勻化，因?yàn)樵u(píng)價(jià)一次回歸是否完成了，最后一個(gè)環(huán)境跑完才是回歸過程，怎么讓時(shí)間均勻化，讓每套回歸的時(shí)間差不多，就能實(shí)現(xiàn)全局最優(yōu)。

我們第一個(gè)是在整個(gè)回歸算法上進(jìn)行解決，第二是在環(huán)境上來進(jìn)行解決。我們看一下動(dòng)態(tài)編排算法，算法的核心在于測試數(shù)據(jù)，如果一次準(zhǔn)備很多數(shù)據(jù)，整個(gè)過程就會(huì)非?？?，節(jié)省的時(shí)間非常多。如果用例沒有任何數(shù)據(jù)依賴，這些用例都能進(jìn)行并行的運(yùn)行。我們可以看一下右邊的圖，這是一個(gè)曲線，代表著數(shù)據(jù)冗余率，可以看到曲線隨著用例數(shù)增多，運(yùn)行時(shí)長是非指數(shù)的增長，當(dāng)冗余度為零，即不冗余的極端情況下，每個(gè)用例都要準(zhǔn)備一次數(shù)據(jù)，數(shù)據(jù)準(zhǔn)備的時(shí)間是消耗非常多的。我們這邊采用的方式，基于最大公共數(shù)據(jù)集遞歸創(chuàng)建二叉用例樹，當(dāng)建好這個(gè)樹之后，第二步就是希望對這些測試數(shù)據(jù)進(jìn)行聚合，我們采用了一個(gè)分層聚類的方式，對不同的文本數(shù)據(jù)，對數(shù)據(jù)進(jìn)行聚合，減少數(shù)據(jù)準(zhǔn)備的時(shí)間。第三步，基于深度優(yōu)先建立快速執(zhí)行樹，整個(gè)執(zhí)行過程都會(huì)變成串行中有并行的高效方式。

這是我們實(shí)驗(yàn)室的數(shù)據(jù)，在整個(gè)過程中我們分為四個(gè)階段，第一是數(shù)據(jù)準(zhǔn)備階段，第二是分層數(shù)據(jù)準(zhǔn)備階段，第三是快速執(zhí)行階段，第四是失敗重試階段。這里有600多個(gè)數(shù)據(jù)，冗余度已經(jīng)達(dá)到了500個(gè)，可以省掉黑色的時(shí)間，因?yàn)閿?shù)據(jù)已經(jīng)準(zhǔn)備好了，能夠快速的執(zhí)行，實(shí)驗(yàn)室里面數(shù)據(jù)準(zhǔn)備階段效率提升了500%多，由于并行化，時(shí)間節(jié)約了50%左右。

這是排查領(lǐng)域，用例運(yùn)行失敗之后到底怎么排查呢？這個(gè)排查是非常有意思的，我們做這個(gè)是基于用例畫像有記憶的排查系統(tǒng)，有兩個(gè)目標(biāo)，第一是失敗排查效率從分鐘級(jí)提升到秒級(jí)，第二是排查經(jīng)驗(yàn)?zāi)軌虺恋淼较乱淮闻挪?。傳統(tǒng)排查系統(tǒng)實(shí)現(xiàn)的是左半環(huán)，即重放失敗的流量，然后在執(zhí)行的過程中由整個(gè)系統(tǒng)來進(jìn)行鏈路數(shù)據(jù)的收集。比如我們收集執(zhí)行過程中的日志，主干情況是怎樣的，測試環(huán)境是不是正常啟動(dòng)的，或者是一些基礎(chǔ)的配置檢測之類的，我們通過這種方式來進(jìn)行，最終由系統(tǒng)給出一個(gè)失敗的原因，這是非常正常的一個(gè)排查思路，即系統(tǒng)自查。在此之上，我們實(shí)現(xiàn)的另外一環(huán)，就是右半環(huán)，增加了一個(gè)用戶反饋體系，這是什么意思呢？左半環(huán)是自查非常初級(jí)的方式，沒有辦法對復(fù)雜場景進(jìn)行排查，整個(gè)排查的方式就變成了可以由用戶來進(jìn)行人工的排查，把排查的失敗信息輸入到系統(tǒng)里面去，系統(tǒng)來進(jìn)行記錄，并最終將整個(gè)排查失敗歸因的特征抽出來，和歷史的失敗原因進(jìn)行比對，每次進(jìn)行排查的時(shí)候都會(huì)推出系統(tǒng)自查的原因，以及歷史上可能出現(xiàn)的人工排查原因。

我們將整個(gè)智能排查反饋，以及整個(gè)智能回歸，聯(lián)動(dòng)起來就變成了回歸反饋閉環(huán)。簡單來說，能夠快速的執(zhí)行一次回歸，由系統(tǒng)自動(dòng)的觸發(fā)自動(dòng)排查，反饋給用戶原因，用戶運(yùn)行一次之后就可以知道是什么原因，可以達(dá)到最高效的反饋速度。

再說一下測試左移，智能化場景解決了一些高效性，或者是能夠讓開發(fā)做測試的極簡方式，但提升效率仍然是其中一個(gè)環(huán)節(jié)。而我們想提升整個(gè)研發(fā)流程的效率勢必要進(jìn)行左移，才能從線和面上解決研發(fā)效率問題，第一個(gè)是可編排的pipeline技術(shù)，這個(gè)過程原先需要是5天時(shí)間，我們做了UT自動(dòng)化一站式服務(wù)，功能測試，功能AB，性能AB。我們將基礎(chǔ)設(shè)施打造好，提測代碼的時(shí)候可以一鍵提交整個(gè)流程，將整個(gè)流程提升到4個(gè)小時(shí)之內(nèi)。如果是改動(dòng)量不影響老功能的情況下，只要提測通過了四個(gè)環(huán)節(jié)，我們認(rèn)為覆蓋率就能逼近百分之百。

功能A/B Test，跟線上的環(huán)境進(jìn)行對比，整個(gè)過程都需要強(qiáng)大的基礎(chǔ)設(shè)施。需要的核心能力包括環(huán)境克隆，基于數(shù)據(jù)工廠的流量精準(zhǔn)抽取與改造，對比流量高發(fā)執(zhí)行等等。同樣，性能A/B Test也是這樣的思路，追求性能，比如說這個(gè)版本上線之后穩(wěn)定性到底怎么樣，CPU的狀態(tài)怎么樣，內(nèi)存到底怎么樣，能夠追求整個(gè)最短的反饋的時(shí)效，就能夠做到這個(gè)版本性能跟測試報(bào)告到底怎么樣，這些都非常依賴強(qiáng)大的基礎(chǔ)設(shè)施。第三是CLI觸發(fā)運(yùn)行，是基于git的工作方式，用命令行的方式來進(jìn)行代碼的修改，能夠用Markov git的方式，讓它無縫的嵌入到研發(fā)模式中。以上幾種能力，共同組建了阿里媽媽極致左移的流程。

謝謝大家！