背景 背景 自動化是持續集成生態中必不可少的一環，起到了一個推動力的作用。因此對於自動化用例報表體現錯誤時候，就會有一個十分麻煩的工作“查錯”或者“問題定位”。如果您是業務專家同時又是十分熟悉自動化平臺，那麼憑藉經驗和技術能力也很快能定位出問題。但是對於開發和測試人員只看到“您提交的代碼，導致什麼錯 ...
-
背景
自動化是持續集成生態中必不可少的一環，起到了一個推動力的作用。因此對於自動化用例報表體現錯誤時候，就會有一個十分麻煩的工作“查錯”或者“問題定位”。如果您是業務專家同時又是十分熟悉自動化平臺，那麼憑藉經驗和技術能力也很快能定位出問題。但是對於開發和測試人員只看到“您提交的代碼，導致什麼錯誤”、“您輸入的測試數據，產生了什麼錯誤”。他們肯定會一臉蒙逼，那些錯誤鬼知道是哪裡的，心裡肯定不爽提出了對於自動化的質疑“什麼玩意兒？自動化的錯誤吧”。不好意思，這樣的抱怨我覺得沒毛病，因為只有自動化用例開發者可能瞭解那些報錯返回信息。那麼對於被測業務系統報錯還是自動化本身錯誤，這個問題該怎麼去解決呢？
-
解決方案
對於上述問題解決方法，我想出了一個基於數據分析的方案。這個系統架構圖如下：
第一 由於被測業務系統日誌和自動化平臺日誌都是可以收集到的，那麼我們分別對兩個日誌做區分。這裡技術框架用到了消息流式處理，簡單說一下：zk這裡是管理kafka和redis集群的，保證依附這可以健康運行。kafka用來存取和實時傳輸業務日誌和自動化日誌，redis用來存取從kafka獲取（消費）日誌時候的偏移量。再介入正題，加入topic1用來存取業務系統日誌，topic2用來存取自動化平臺日誌，那麼兩個數據源可以保證實時輸入到我們搭建的流式系統中。【簡單說一下選擇流式處理理由：持續集成要求實時性高，用例量比較大，如果採用傳統處理方式效率太低且開發代價很大。】
第二 接下來就是最關鍵的部分，數據分析與處理模塊設計。首先是對於原始數據（原始日誌）做預處理，方法是一個基於python的re模塊，將正則表達式作為一個靈活可變的配置文件，然後通過基於re開發解析公共能力模塊支撐。每次運行載入正則表達式文件，然後得到模板化結構數據，此時的數據都是我們想要的內容與格式。接下來我們根據業務系統日誌特點和自動化日誌特點，設計一個自己的模型，可能就是一堆簡單if else的的堆砌，那也沒關係！只要能達到目的，後續可以在做優化，但是前提這部分要解耦做成一個單獨的模塊。此時在不同的分支就會形成不同的結果，此時就可以區分出不同的錯誤，不用在面對他們的“甩鍋”！這裡將結果存入到mysql中。
第三 接下來就是展示我們分析出來的結果，採用的是django，寫幾個簡單的頁面就可以了。
上邊扔出了磚頭，您是否已經有了自己的答案呢？那請在評論區留下，相互學習。熱枕期待您的寶貴想法與經驗~
-
寫在最後
最後寫一點優化點吧，也就是體現標題“智能”二字，目前這是架構設計不是那麼的智能。後期引入NLP，打算在【第二】步驟中加入基於nltk的自然語言處理技術。目的是達到對我們篩選出來的重點日誌通過這個評估系統智能識別出是消極的還是積極的，根據實際情況設置評估區間，當然需要大量的訓練才可以得到這個區間。
再一次期待您的分享與交流~
