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

[[283750]]

會上，阿里巴巴測試開發專家潘家騰做《阿里媽媽在線下測試域的智能化建設》主題演講。潘家騰分享了阿里媽媽在線下測試方面的實踐，包括業務的現狀與挑戰，進入智能化的邏輯，以及如何實現線下測試的智能化。

以下為潘家騰演講實錄：

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

我今天分享的是阿里媽媽在線下測試方面的實踐，我們的業務現狀與挑戰，進入智能化的邏輯，以及線下測試的智能化。智能化是非常高大上的技術，而線下測試更多的是比較腳踏實地的工作，如何將高大上的技術和腳踏實地的工作結合起來，這是我本期要講的重點。

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

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

方案就是打造協同化的測試模式，在傳統模式的基礎上開辟一條快速模式，走智能化的方式，打造一個測試平臺，主要是低風險和算法的項目，高風險項目仍由測試主要來負責。這個平臺通過智能化、可視化、產品化的方式，讓開發、算法的同學進行自動化的測試，由系統來判定準入，判定準出，如果系統通過了，可以隨時上線。

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

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

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

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

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

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

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

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

這是我們實驗室的數據，在整個過程中我們分為四個階段，第一是數據準備階段，第二是分層數據準備階段，第三是快速執行階段，第四是失敗重試階段。這里有600多個數據，冗余度已經達到了500個，可以省掉黑色的時間，因為數據已經準備好了，能夠快速的執行，實驗室里面數據準備階段效率提升了500%多，由于并行化，時間節約了50%左右。

這是排查領域，用例運行失敗之后到底怎么排查呢？這個排查是非常有意思的，我們做這個是基于用例畫像有記憶的排查系統，有兩個目標，第一是失敗排查效率從分鐘級提升到秒級，第二是排查經驗能夠沉淀到下一次排查。傳統排查系統實現的是左半環，即重放失敗的流量，然后在執行的過程中由整個系統來進行鏈路數據的收集。比如我們收集執行過程中的日志，主干情況是怎樣的，測試環境是不是正常啟動的，或者是一些基礎的配置檢測之類的，我們通過這種方式來進行，最終由系統給出一個失敗的原因，這是非常正常的一個排查思路，即系統自查。在此之上，我們實現的另外一環，就是右半環，增加了一個用戶反饋體系，這是什么意思呢？左半環是自查非常初級的方式，沒有辦法對復雜場景進行排查，整個排查的方式就變成了可以由用戶來進行人工的排查，把排查的失敗信息輸入到系統里面去，系統來進行記錄，并最終將整個排查失敗歸因的特征抽出來，和歷史的失敗原因進行比對，每次進行排查的時候都會推出系統自查的原因，以及歷史上可能出現的人工排查原因。

我們將整個智能排查反饋，以及整個智能回歸，聯動起來就變成了回歸反饋閉環。簡單來說，能夠快速的執行一次回歸，由系統自動的觸發自動排查，反饋給用戶原因，用戶運行一次之后就可以知道是什么原因，可以達到最高效的反饋速度。

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

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

謝謝大家！