測試用例又雙叒叕失敗了，NLP幫你
摘要：本文將介紹如何使用AI技術實現失敗測試用例的智慧分析。
本文分享自華為雲社群《測試用例又雙叒叕失敗了，啥原因？NLP幫你來分析》，作者： 敏捷的小智 。
隨著軟體行業的快速發展，為了實現高質量的快速迭代，越來越多的公司開始推進測試自動化來縮短測試周期，較成熟的軟體公司開始追求80%甚至更高的測試自動化率。一輪耗時一週的手工測試在自動化後可能一天或更短時間內就能完成全部執行。在每一輪自動化測試中，對失敗用例進行根因分析是一份十分重要的工作，而海量測試日誌的人工分析開始成為瓶頸。本文將介紹如何使用AI技術實現失敗測試用例的智慧分析。
基於日誌分析輔助開發人員發現及定位系統問題早已不是新鮮課題，在過去幾十年裡都有廣泛的研究。隨著資料的持續積累，學術界的研究和工業實踐都有嘗試使用機器學習來求解，包括監督方法和非監督方法。在發現問題方面，2017年的一篇《DeepLog: Anomaly Detection and Diagnosis from System Logs》引起了廣泛的關注。文中介紹了通過多重LSTM模型，學習日誌模板及日誌引數組成的時序資料特徵，對系統行為及系統狀態進行異常檢測，輔助開發人員提前感知系統的潛在風險。本文將從定位問題的角度，介紹如何使用日誌分析的技術在測試場景下輔助失敗用例的根因定位。
本文的使用的演算法簡單很多，但對測試日誌及歷史分析有較高的要求。首先，基於大數定律，樣本量越大越能接近資料的原始分佈，所以要求待分析的失敗用例要有足夠的量級，-否則不僅有殺雞用牛刀之嫌，效果也不會好。其次，要有一定的失敗測試用例分析資料，本文介紹的是有監督學習的解決方案，帶標籤的資料質量將會決定學習效果的上線。
好了，既然上來就揭了謎底：用文字分類模型來實現失敗測試用例的根因定位。就先給大家展示一下完整的解決方案。
圖一：失敗測試日誌分析服務構建流程
如圖一所示，失敗測試日誌分析服務構建流程可以概括為以下步驟：
1. 測試日誌分析資料的準備：確認測試日誌被正確記錄並儲存，對失敗測試日誌的根因分析也被妥善儲存。日誌中應該包含可以用來定位根因的高價值資訊，如系統返回的錯誤碼、報錯資訊等。
2. 模型的訓練：根據已有的分析資料訓練模型。
a) 日誌清洗：在失敗用例的日誌中， 充斥的大量與失敗原因不相關的內容。這些噪音資料會增加模型訓練的不確定性。結合歷史經驗，對日誌資料進行清洗，提取關鍵資訊，在訓練初期是不可缺少的關鍵一步。例如，實踐中發現，幾乎所有失敗用例中都有系統返回的錯誤資訊。如果沒有，需要仔細檢查一下是日誌設計不合理，還是可以直接認定為測試環境問題。測試人員拿到失敗測試用例，看到錯誤資訊基本就能定位大概的失敗原因。所以在日誌清洗時，只擷取錯誤資訊，是目前實踐下來效果較好的一個預處理步驟。
樣例：
Case001 配置問題 引數比對失敗
Case002 環境問題 無法連線*.*.*.*
……
b) 日誌預處理：人蔘與的越少，後期維護的成本越低，所以在日誌預處理階段，只對日誌做簡單預處理，如分詞、去除停用詞等。
c) 模型訓練：將歷史分析資料載入TextCNN文字分類模型。TextCNN最大的優勢是網路結構簡單，在多項資料集上輕鬆超越benchmark。網路結構簡單，引數數目少，計算量少，訓練速度較快。想了解模型細節的同學，可以戳Convolutional Neural Networks for Sentence Classification。
d) 模型調參：通過修改embedding dim長度、調整隨機策略等，嘗試獲得最優的模型。當模型能在實驗室實現train test的準確率在85%左右，可以認為是ready to go的模型。
3. 將步驟2訓練獲得的模型host成線上分析服務。
4. 測試自動化執行中，失敗測試用例的日誌在預處理後，被自動post到預測服務，獲得預測的結果，包括預測的根因和置信度。
測試人員可以在一輪測試執行後立刻得到測試結果分析報告。
首先測試人員結合歷史經驗，對可直觀感知到失敗原因的測試用例及時進行定位並做出處理，比如是測試環境問題則修復環境，重新執行測試用例。
其次，結合模型輸出的置信度，對預測結果做好分級。歷史上大量出現過的的錯誤日誌，一般置信度較高，直接給出根因。置信度較低的失敗用例，可能是新增問題，及時給出警告。
不同的業務場景會生成不同的日誌，隨著業務場景的不斷增加，日誌的特徵空間趨於無限，無法用同一個模型適配所有場景。儘量減少人工參與，針對特定業務場景，使用較輕量級的模型快速訓練迭代，是能夠在工業界落地實現的一個很重要的特性，本文介紹的TextCNN文字分類模型目前實踐來看是能夠滿足以上要求的。在提升模型準確度上，結合主動學習提升資料質量，引入小樣本學習減少人工依賴將是後續重點的探索方向。
參考資料
1. Experience Report: System Log Analysis for Anomaly Detection, 2016.