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

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

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

日誌是指令碼在執行過程中記錄下來的資訊。對於測試來講，這些指令碼中的錯誤資訊是他們非常需要的。但是如何在龐大的執行日誌中方便地統計出他們需要的報告呢？

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

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

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

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

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

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

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

1. 執行日誌總覽：總數、錯誤數
2. 日誌錯誤分佈：一級模組、二級模組

這個分析是根據一些假設來做的，有人問，萬一使用者不是這樣使用"測試包"的呢？這個問題非常簡單，我們的測試方案的組織和測試結果的分析報告，是一個相輔相成的矛盾體。正是因為測試包已經這樣組織了，所以這樣分析非常好。反過來，因為我們會這樣統計結果，所以也會促使測試人員在編寫指令碼的時候，注意到測試包的應用。所幸的是，測試包可以非常方便地被插入和組織。

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

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

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

Trackback: http://tb.blog.csdn.net/TrackBack.aspx?PostId=1797685