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

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

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

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

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

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

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

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

這裡面最最關鍵的在于回答管理者所謂的“嚴重”的标準。經過和測試人員反複的探讨，他們最關心的是“子產品”的概念，這是和業務非常相近的。我們的系統如何來了解子產品的概念呢？特别是，那些子產品是重要的，那些子產品是不重要的。

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

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

運作日志總覽：總數、錯誤數

日志錯誤分布：一級子產品、二級子產品

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

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

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

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