自動化測試框架：日志的分析

框架做到后期，大量的測試腳本已經編寫完畢。大家可能會發現，量少和量多是完全不一樣的概念。正如量多的時候你需要考慮運行性能一樣，大量的測試腳本，必須考慮其組織方式。

　　在上次重構中，已經和大家交流過，系統中為測試腳本預留了一個“測試包”的概念。而最近又正好在設計最后日志的分析功能，所以很自然地聯系起來考慮。（測試包是一個非常簡單的概念，就是允許多個測試步驟或測試包，作為另一個測試包的子節點存在。）

　　日志是腳本在運行過程中記錄下來的信息。對于測試來講，這些腳本中的錯誤信息是他們非常需要的。但是如何在龐大的運行日志中方便地統計出他們需要的報告呢？

　　這里面必須先回答一個問題：這個報告給誰看？

　　給測試看？不，還有項目經理，開發經理，測試經理等等項目負責人。除了負責人，還有我們的開發人員也可能看。事實上，最好的情況是，測試錯誤能自動發送到相關模塊的編碼負責人手里，只不過由于這點往往需要和開發管理系統相連接，因此暫時不考慮。

　　回答了這個問題，我們知道統計的報告設計必須考慮到兩方面的需求。對于管理者，他最需要了解的是這個系統運行的大概情況，有多少錯誤發生？這些錯誤嚴重嗎？這些錯誤都是怎么分布的？如果你是管理者，你可能還能提出更多的要求，總之，你最關心當前這個版本能發版嗎？

　　這是看上去簡單，但又是很復雜的事情。簡單是因為只是一些簡單的數據而已，復雜的是這些數據的形成。我們知道，數據最關鍵的在于意義。如果不能為我們的統計數據找到合適的形成方式，那么所謂的報告也只能顯得蒼白無力。

　　這里面最最關鍵的在于回答管理者所謂的“嚴重”的標準。經過和測試人員反復的探討，他們最關心的是“模塊”的概念，這是和業務非常相近的。我們的系統如何來理解模塊的概念呢？特別是，那些模塊是重要的，那些模塊是不重要的。

　　正如大家所想到的，解決這個問題的過程中，我們考慮到腳本中已經頻繁使用到的“測試包”。雖然一開始并沒有對測試包定義明確的意義，但是我們非常驚奇地發現，測試在編寫腳本的時候，正是按照模塊的概念在組織測試腳本。這對我們自然是一個非常好的消息。下面就是如何利用這個特點。測試人員心中想的是模塊，因此組織的時候自然也容易按照模塊的概念進行。不過包的數量還是很多的，因此我們做了一些假設（這些假設可能會作為配置選項出現），第一層和第二層的包是非常重要的，也是系統應該最優先關注的。

　　這樣系統的分析報告便有了大概的模型：

　　運行日志總覽：總數、錯誤數
　　日志錯誤分布：一級模塊、二級模塊
　　這個分析是根據一些假設來做的，有人問，萬一用戶不是這樣使用“測試包”的呢？這個問題非常簡單，我們的測試方案的組織和測試結果的分析報告，是一個相輔相成的矛盾體。正是因為測試包已經這樣組織了，所以這樣分析非常好。反過來，因為我們會這樣統計結果，所以也會促使測試人員在編寫腳本的時候，注意到測試包的應用。所幸的是，測試包可以非常方便地被插入和組織。

　　不要忘了我們另一個目的。測試人員要根據運行日志詳細查看。一來分析腳本執行情況，而來確定并定位到具體錯誤所在。這種情況下，出一個靜態報告，遠不如一個動態分析軟件更有用。因此這方面我們選擇提供一個日志分析模塊，可以過濾出所有錯誤項，還可以做一些其他的分析。

　　前面曾經提到的自動分析模塊的錯誤，并發送到開發人員手里。這個現在并沒有實現，思考時曾經考慮提供一個模塊和開發人員的對應表，這樣可以自動發送郵件了。不過具體實現的時候可能會遇到其他問題。

　　在日志分析基本完成后，自動化測試系統已經進入一個小結的時間，現在也要開始考慮它的下一步走向了。謝謝一直關心這個系統的人們！

原文轉自：http://www.anti-gravitydesign.com