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