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

會上，餓了么測試開發專家邱化峰做《人工智能在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定位的指標。再看最后一個，運算符的個數，大家也知道功能測試和做中間件測試的，基本上是不一樣的，不一樣在哪兒？基于業務的可能是業務場景的，邏輯，或者是業務場景相對來說比較固定，邏輯的單一化比較好一點，但是作為一個中間件，會考慮很多的不確定因素。當我們去考慮這些不決定因素的時候，其實是變向增加了運算符的操作。