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

[[283752]]

會上，餓了么測試開發專家邱化峰做《人工智能在Bug定位中的應用》主題演講。邱化峰指出，“企業想獲得人工智能帶來的便利，首先要制訂相對應的標準，如果沒有這個標準，按照固定的算法，則很難實現。”

以下為邱化峰演講實錄：

今天我講的是人工智能在Bug應用中的定位，講這個話題之前，我想先做一下統計，大家用java管理Bug的人員有多少？在修復Bug之后，在代碼里面，想關聯Bug是什么樣的同學請舉手。人工智能定位首先需要有一個數據的基礎，這個數據的來源是什么樣的？測試通過java提交Bug，我們有Bug的描述，Bug的相關信息，以及Bug的重現步驟，會直接提給開發，開發根據這些步驟去執行，看Bug是不是可重現的。如果是可重現的，會要求開發把相關的問題進行關聯，關聯之后作為Bug分析的一個前提，不需要在人工去標注什么樣的樣本，因為把Bug描述的相關信息放上之后，我們就可以通過自然語言或者是人工的處理方式，提取含有Bug相關的字段，比如出現的異常是什么，錯誤是什么，問題是什么樣的。有了這個基礎之后，不需要人去做標注，就可以拿到一些樣本。還有一個是學術界要做的，首先，有些人專門維護了所有關于java的Bug，這些Bug在修復里時會生成一些數據，告訴你哪個方法在第幾層，哪個方法哪一行出現了什么錯誤。如果想使用人工智能帶來的便利，首先要制訂一些相對應的標準，如果沒有這個標準，很難按照固定的算法來得到想要得到的東西。講完了這些前提，我主要講三部分，第一是工具介紹，第二是Bug定位的原理和方法，第三，使用這些工具之后應用從哪些方面做具體的落地。

工具分了八種，這個PPT是之前做的，最近一個月又出來一個新的Bug定位的技術，就是基于行為的Bug定位技術。前面這八種定位技術都是以能拿到相關的樣本來做對應的處理，而且這些東西是通過提取測試用例，編譯測試。這大部分是基于單元測試做的，但是基于行為的已經突破了在單元測試的層面去獲取Bug的樣本，通過基于鏈路去分析是什么樣的情況。第一個是程序頻譜，就是我跑多少測試用例，成功的測試用例覆蓋了哪些行，失敗的覆蓋哪些行。我們計算失敗的測試用例占的行，我們做一個排名，就可以拿到這一行代碼出現BUG的概率是多少。然后是基于變體，程序頻譜的基礎上做了一個改良，變體現在應用的，最實用的一個是衡量測試用例的有效性很重要的一個手段，我寫了那么多測試用例，這些測試用例是不是真的有效，我可以去變體來做衡量。基于變體會生成兩個，有一個變異分數，分數越高的時候，單元的測試用例的質量就比較高。程序切片就是通過程序切片或者場景，生成程序用例的方式，程序切片也可以用于Bug定位，然后是堆棧跟蹤，APP端有用監控的，類似于接了監控系統的同學舉一下手。安卓系統底下的應用，比較多的只發安卓的，不發iOS的同學有多少？大部分都是既發安卓又發iOS。基于堆棧追蹤，堆棧話題要講到好多，比如日志，log，線上的這些東西怎么去拿。堆棧追蹤，不僅僅應用于服務端的Bug的定位，也可以應用于C端的Bug定位，比如界面突然卡掉了，或者突然卡死，我拿到這些對應的堆棧信息，也可以直接來進行Bug的定位，以及做Bug的預測。第五是上下文的切換，這個就不講了。第六是信息檢索，通過一些詞頻，或者去算出現概率比較多的，大家知道熱點覆蓋概念的同學請舉一下手，你能說一下嗎？

聽眾：有個熱點圖，看哪邊用戶點擊更多，哪邊點擊更少。

邱化峰：我們是變向的熱點覆蓋的方法，映射到修改的方法是最多的。最后是機器學習。如果我們需要知道怎么去定位Bug，通過人工智能的方式，首先要定義各種指標，這些指標就決定了在定位Bug中的準確率有多高。基于java這里列了7個，首先看一下，代碼的有效行數，圈復雜度，包括是否符合javadoc的規范，為什么要把這個作為參考指標？阿里巴巴推出了java編寫規范，不是說憑空無中生有的，是基于掃描了阿里所有的代碼倉庫包括歷史記錄總結出來的，比如空格應該空幾行。我們有人工智能定位的工具，通過統計含有Bug的類型做了一個統計，Bug產生因素最多的就是隨意的命名變量名，這是作為了定位Bug中得出來的最主要的參考指標。Bug的產生大部分是由人的理解或者認知在一定范圍之內造成錯誤的使用的某個變量名，包括函數。代碼編寫規范，第一代是函數式的，第二代是面向對象的，面向對象的是不是萬能的，我們面向對象去寫的時候，是不是易于維護的和易于理解的。最主要的有一個是扇入和👕扇出，我去做Bug定位的時候，如果這個方法被多次引用，也會增加Bug出現的概率。然后是包的設計質量，之前是單體的應用，現在講微服務，又在講中臺，這些是相當于在包的基礎上做了一些變革，之前我們是單體的，把它拆成微服務之后應該怎么做，當把微服務單獨抽出來做中臺，最主要的改變就是Jar包的結構和這些東西也在隨之不斷的發生變化。第四個，用來分析Jar包的升級質量，變量的個數和參數的個數，這也是在Bug中影響Bug定位的主要指標，大家見過的，能知道測試過程中發現變量數最多的同學，有沒有說發現使用了多少參數，或者一個函數能支持多少個函數，有知道的同學嗎？參數的個數，語言多多少少有差異，我在函數傳參的時候，函數的參數名和變量最多只允許有256個，超過256個，程序就跑不起來了。變量的個數和參數也是作為Bug定位的指標。再看最后一個，運算符的個數，大家也知道功能測試和做中間件測試的，基本上是不一樣的，不一樣在哪兒？基于業務的可能是業務場景的，邏輯，或者是業務場景相對來說比較固定，邏輯的單一化比較好一點，但是作為一個中間件，會考慮很多的不確定因素。當我們去考慮這些不決定因素的時候，其實是變向增加了運算符的操作。

第二部分，原理和方法。我們剛才也給大家普及了基礎的東西，這部分的training set，都是來自于實際中編寫的代碼或者是樣例，是作為Bug預防的第一代原形，相對來說比較簡單，只用了一個圈復雜度，知道圈復雜度的同學舉一下手，為什么可以作為預測Bug出現概率的重要指標？就是圈復雜度會根據你寫的代碼，里面有多少分支，走多少流程，跟圈復雜度是對照的。一個函數里面，如果圈復雜度，工業級別上的，好比軍工的軟件，一般檢測出來不超過7，或者更嚴格的，代碼復雜度不能超過5，當圈復雜度越高的時候，就證明寫的函數體越來越長，但是如果在5和7以內，大概40行左右，超過7以上，到20了，代碼行數就有可能變成幾千行了，幾千行的函數，無論是讓原來的開發，還是接手的新開發來去做這個事情，都變得很難維護。既然是我們能知道圈復雜度有這樣的功能，我們可以用圈復雜度來預測提測代碼之后，去掃一下圈復雜度，看是不是在合理的范圍內之內，如果不在合理的范圍之內，可能會有一定的概率出現Bug。

這個圖里面介紹了學術界應用，把加入的代碼出現的Bug解決掉，做了一個樣本，沒有修Bug之前代碼是怎么寫的，修完Bug之后代碼又是如何寫的。

這是基于Bug定位出現的第二個原形，用來預測Bug缺陷。從第一個原形到第二個原形，中間已經多了很多步驟，首先需要有一個dataset。第二是前面說的學術界的獲取dataset的方法。第三是用人工自然語言的去處理，不用java管理的，或者不跟javaBug關聯的，但是有很多開發去直接寫，用英文也好或者用中文注釋也好，會說某某個問題，這是一般開發都會做的。第三個是獲取樣本的方法。將來可能出現Bug的因素有哪些，這是這些因素做了排序和處理，做Bug定位或者預測的時候，首先得知道哪個指標應該占什么樣的比例，用剛才的方法，就去不斷調整各種指標占的比例，然后根據所占的這些比例多少，判斷實際得到的和最終現實發生的真實的Bug匹配度，在人工智能中有一個專業名詞是召回率，來看最終的結果，這是屬于第二代的原形。在這個原形里面，有一個test的樣本，大部分是使用變異測試來做的。

這是基于java的，參考各種因素和指標，能得到一些樣例結果的展示。每種定位技術，得到的能定位的結果差異也是有很多的，如果大家想去看具體的實現，在這個底下有一個連接，把種種技術，包括方法，源碼，結果，都生成一個統計結果，可以到里面看具體的執行情況是什么樣的。

這是堆棧，現在的堆棧拋出，一般情況下，無論是前端也好，還是后端也好，都要求封裝。Exception，堆棧有多個方法，異常的會提示說屬于什么樣的異常，既有基于系統級別的，也有中間件定義的，也有用戶行為定義出來的，這個時候我們不能單純的說用它做缺陷預防，我們首先要把三個分層，不能直接簡單拿過來用，基于堆棧去預測這種情況，這樣就會更加準確。這個里面會告訴你某一個類，某一個方法，底下具體是哪一行到哪一行，我們基于熱點覆蓋的時候經常會提一個概念，拿到修改的行，通過修改的行去匹配，這個行的代碼就會明確的告訴你我在這行拋了，開發去解決問題的時候，就有經驗的開發，會做一件事情，永遠去看0或者1的，不去看后面的，后面再拋出來的跟現在是完全不一樣的。既然開發都能夠通過這個來做，我們可以轉化為一個缺陷預防，或者是判斷的技術手段，這個時候我們就可以去針對這些拋出來的Exception，再做一個排名，需要收集線上所有的日志里面，把所有日志里面無論這類也好，還是這個方法也好，只要在里面出現一次，我將排名就加“1”，會首先看全局的哪類哪個方法，即使行數不一樣，我要統計到這個方法底下服務端的排名情況。

我剛才所說的都是為如何建立我的缺陷預防的指標的參考依據，大家可以看到這些指標，比如有多少個鏈路的調用，總共有多少函數處在這個破拋出來的這些堆棧的異常相關信息，十前面的ST作為基礎數據，我們發現只是用基礎數據去預測Bug出現Stack Trace概率并不是很準確，到底出現Bug的概率是什么樣的，我們相當于做了一個類似于加權平均，或者統計學里面應該叫取一個均值，把參數做一個綜合，舉個簡單的例子，如果這個項目中只有兩個文件，如果拋出來一個堆棧異常，兩個類里面有多少個，和我有10個文件，但是每個類里面的代碼行數對應的行數不同，如果想全面的了解到Bug出現的概率，就不能簡單的以其中一個指標作為參考。做了一個組合之后，就相當于把出現Bug的概率和情況做了一個更加詳細的指標定義。我們有了這個指標的定義，就更容易預測Bug出現的概率。

這是堆棧信息人工智能預測的模型，把Stack Trace和錯誤的代碼進行了關聯，做了一個提取和模型的建立，并且自動的把它打標，第二個階段，我已經有了線上這么多出現的異常，我們新來一個，能不能直接定位到某一類某一行的方法上。為什么要做這個事情？現在測試不是左移就是右移，對于我們來說，跟開發合作的時候，他認為比較理想的測試是說不用給那么多步驟，不用那么多方法，能不能寫一個單元測試，能不能直接告訴我問題出在哪兒。有很多的方法是希望測試做到這樣的，并不是說測試做不到，測試也是可以做到的，但是需要很多的工具，包括歷史數據的積累才能做到。而且有很多的情況，測試對于場景，包括業務了解得更多，這里只寫了模塊的一小部分，如果把測試的這些反饋到開發身上，就可以做到這一點。

這是第三代的技術，會把靜態分析和動態分析做整合，把代碼的覆蓋率，方法的覆蓋率，包括分支的覆蓋率，統一放到矩陣里面，在這個矩陣相對應的，可以認為原生的第一代是一維的，只有一個東西幫我們做判定，這個是一個二維的，到了第三代其實是做了更多維度的，但是這個維度里面既包含了靜態，又把動態的也放進來了，同時也把覆蓋的行這些東西也都做到統一的PageRank Matrix里，從多個角度去看能不能預測這個Bug出現的概率。

最終，我們會得到一個Rank List，我們統一做各種排序，再去看預測Bug出現的概率就會比之前更加準確。

還有一個是基于行為的，也是最近剛剛出現的用來定位Bug的，就不展開描述了。

然后我們說一下怎么應用，程序頻譜是一種有效的Bug定位的方法，作為卡殼的時候，首先不能單純的說以指標來衡量，需要把它作為綜合的指標去看整體的提測質量之后，就會發現之間是有正相關的，或者呈線性的數據的指標，代碼寫得越爛，出現的Bug概率就會越高，這是毋庸置疑的。第二，Stack Trace對于Crash的定位是很有效的，現在手機經常運行著的時候就不動的，或者響應比較慢，我們去拿到堆棧的錯誤異常，上報上來，這個時候對于去定位這些異常是很有效的，用它來提高安卓端的響應，包括出現什么樣的錯誤，這是十分有效的手段。第三，錯誤的樣本集目前仍然不夠大，剛才說的三種方式，還漏掉很多沒有按照規范和固定操作制度，中間有很多開發沒有按照這個去做，有一個叫全樣本，這也是息息相關的因素。還有一個，算法的多樣性，我們用靜態和動態的調用，里面的算法也是多樣性的，目前有20多個算法，算法也決定了預測Bug出現概率的重要參考因素。很顯然，第一代的不如第二代的，第二代的不如第三代的，但是這些迭代的版本、方法多了之后，原來簡單的算法也不適應了，每增加一個因素，或者每增加一個參考的因子，模型也要做相對應的處理，這樣才能預測Bug出現的情況。

現場視頻（下）

通過這些Bug定位的技術和方法，我們拿到最直接、最有效的方式。把它作為實地落地的情況，通過這些能夠對我的企業產生直接收益，一般情況下，前面分析了那么多，但是這些東西都不能落地，或者都不能提高協同的效率，推廣和應用是很困難的，我們通過它可以做到的有這四個場景，能夠提高大家的效率，輔助開發來定位Bug。阿里內部有一個可視化的質量分，分了四個維度，第一是圈復雜度，第二是面向對象的指標，第三個我忘記了，每個指標里面都有因子，每個方面給一個權重，提測完代碼之后進行開發，跟代碼的質量分是不是有直接關聯。 指標定義好，就可以發現問題，指標定義不好就會出笑話。

Bug的重復檢測，如果我們做交叉，或者是比較大的，比如我們使用外包，免費的從網上公開共測的東西，他們提過的Bug之后，我們也可以去做去重，來決定將來判定一個重要的指標。Bug的自動assign，每個開發提交的，根據這個場景涉及到的case，或者提交分支版本，可以將Bug和這個產生者直接做一個關聯，出現了Bug就可以不需要判定是哪個開發要做的事情，可以告訴是這個東西出了問題。然后是case的等級分類，相信大家在做第四個的時候，都應該會做，如果不做case的等級分類，就是測試連入門都沒有做到。為什么要把它提出來？因為我們發現現在有很多的工具也可以幫我們生成單元測試的代碼，但是這些單元測試的代碼和這個之間并沒有作為強關聯。大家都知道“8020”法則，80%的Bug來自于20%的代碼，我們所有case也不應該在同一個級別，可以針對這個理論，對這些20%的代碼做case等級的分類。迭代的版本越多，開發和測試不斷在維護自己自動化的腳本，包括單元測試的腳本，這些東西會慢慢的越積越多，這個時候之前第一個版本跑了10分鐘就能跑完，但是運行了半年，或者是一年以上，這個項目沒有死，你會發現測試用例一直往上堆，之前跑10分鐘，半個小時就能跑完，現在是用空間換時間看case執行的情況。我們除了用空間換時間之外，還可以用等級分類的方法把這些case標志出來，可以用少一些的空間，或者是少一些的時間。

這是四篇論文，同學可以自己去網上找，研究一下哪些對你們來說是可以直接落地的。

今天的分享就到這兒。