2023年09月23日 23:30:00
框架做到後期，大量的測試指令碼已經編寫完畢。大家可能會發現，量少和量多是完全不一樣的概念。正如量多的時候你需要考慮執行效能一樣，大量的測試指令碼，必須考慮其組織方式。
在上次重構中，已經和大家交流過，系統中為測試指令碼預留了乙個"測試包"的概念。而最近又正好在設計最後日誌的分析功能，所以很自然地聯絡起來考慮。（測試包是乙個非常簡單的概念，就是允許多個測試步驟或測試包，作為另乙個測試包的子節點存在。）
日誌是指令碼在執行過程中記錄下來的資訊。對於測試來講，這些指令碼中的錯誤資訊是他們非常需要的。但是如何在龐大的執行日誌中方便地統計出他們需要的報告呢？
這裡面必須先回答乙個問題：這個報告給誰看？
給測試看？不，還有專案經理，開發經理，測試經理等等專案負責人。除了負責人，還有我們的開發人員也可能看。事實上，最好的情況是，測試錯誤能自動傳送到相關模組的編碼負責人手裡，只不過由於這點往往需要和開發管理系統相連線，因此暫時不考慮。
回答了這個問題，我們知道統計的報告設計必須考慮到兩方面的需求。對於管理者，他最需要了解的是這個系統執行的大概情況，有多少錯誤發生？這些錯誤嚴重嗎？這些錯誤都是怎麼分布的？如果你是管理者，你可能還能提出更多的要求，總之，你最關心當前這個版本能發版嗎？
這是看上去簡單，但又是很複雜的事情。簡單是因為只是一些簡單的資料而已，複雜的是這些資料的形成。我們知道，資料最關鍵的在於意義。如果不能為我們的統計資料找到合適的形成方式，那麼所謂的報告也只能顯得蒼白無力。
這裡面最最關鍵的在於回答管理者所謂的"嚴重"的標準。經過和測試人員反覆的**，他們最關心的是"模組"的概念，這是和業務非常相近的。我們的系統如何來理解模組的概念呢？特別是，那些模組是重要的，那些模組是不重要的。
正如大家所想到的，解決這個問題的過程中，我們考慮到指令碼中已經頻繁使用到的"測試包"。雖然一開始並沒有對測試包定義明確的意義，但是我們非常驚奇地發現，測試在編寫指令碼的時候，正是按照模組的概念在組織測試指令碼。這對我們自然是乙個非常好的訊息。下面就是如何利用這個特點。測試人員心中想的是模組，因此組織的時候自然也容易按照模組的概念進行。不過包的數量還是很多的，因此我們做了一些假設（這些假設可能會作為配置選項出現），第一層和第二層的包是非常重要的，也是系統應該最優先關注的。
這樣系統的分析報告便有了大概的模型：
執行日誌總覽：總數、錯誤數
日誌錯誤分布：一級模組、二級模組
這個分析是根據一些假設來做的，有人問，萬一使用者不是這樣使用"測試包"的呢？這個問題非常簡單，我們的測試方案的組織和測試結果的分析報告，是乙個相輔相成的矛盾體。正是因為測試包已經這樣組織了，所以這樣分析非常好。反過來，因為我們會這樣統計結果，所以也會促使測試人員在編寫指令碼的時候，注意到測試包的應用。所幸的是，測試包可以非常方便地被插入和組織。
不要忘了我們另乙個目的。測試人員要根據執行日誌詳細檢視。一來分析指令碼執**況，而來確定並定位到具體錯誤所在。這種情況下，出乙個靜態報告，遠不如乙個動態分析軟體更有用。因此這方面我們選擇提供乙個日誌分析模組，可以過濾出所有錯誤項，還可以做一些其他的分析。
前面曾經提到的自動分析模組的錯誤，併發送到開發人員手裡。這個現在並沒有實現，思考時曾經考慮提供乙個模組和開發人員的對應表，這樣可以自動傳送郵件了。不過具體實現的時候可能會遇到其他問題。
在日誌分析基本完成後，自動化測試系統已經進入乙個小結的時間，現在也要開始考慮它的下一步走向了。謝謝一直關心這個系統的人們！
自動化測試框架 日誌的分析
框架做到後期，大量的測試指令碼已經編寫完畢。大家可能會發現，量少和量多是完全不一樣的概念。正如量多的時候你需要考慮執行效能一樣，大量的測試指令碼，必須考慮其組織方式。在上次重構中，已經和大家交流過，系統中為測試指令碼預留了乙個 測試包 的概念。而最近又正好在設計最後日誌的分析功能，所以很自然地聯絡起...
自動化測試框架
可設計為五層 一 測試用例層 主要存放用例的指令碼，分為主指令碼和子指令碼。主指令碼用來控制各個子指令碼，實現指令碼間的資料傳遞。子指令碼是實現各個功能點的指令碼，同時也會提取出一些共用的方法，一般放在提取層中。主指令碼中可使用資料驅動來控制指令碼實現各種場景的流程，如silktest的test s...
自動化測試框架 自動化測試呼喚開發
週末參加了testage 測試時代 組織的乙個專家討論會。主要討論測試自動化。說是專家討論會，我參加實在是慚愧，我對測試的理解實在是太淺薄了。只是因為在部落格上發表了一些謬論才收到邀請。想著可以幫助公司去接受一些新的思想，而自己也可以結識一些朋友，便去了。對於測試時代的會議組織，我以為定位和思路還是...