最近的心得 : 
系統架構師與測試架構師雖然一個為建設性角度, 一個為破壞性角度
但回歸初衷, 堅守同樣的產品價值是不變的, 何來兩者相違之說?

規劃測試架構迄今進展還算順利,
之前有提到由於團隊的測試工作幾乎手動操作
而且在進行完一連串的手動測試後還必須人工整合測試結果,
將文字檔整理成 EXCEL 寄出,
每天進行這樣重複的工作, 我光聽就覺得時間都被浪費掉了
所以自動化在現階段絕對是必要工作

現況

由於先前已經有一套寫好的測試腳本
所以在 Jenkins 上設定完任務, 便可以按時間自動運行
但是, 如何呈現測試結果才是重點
目前的測試結果是用文字檔的方式呈現, 如下圖 A :

再看看另一張圖 B :

有發現到問題嗎?

  1. 圖 A 中測項全過>被判定為成功執行, 圖 B 中有失敗測項>仍被判定為成功.
  2. 結果是否不太直覺? 因為測試工程師們必須從這些文字內確認測試結果.

第一個狀況主要因為測試腳本成功結束執行
故 Jenkins 判定任務為成功
所以在這點, 真正的做法係必須針對輸出 LOG 的內容去判斷

而第二個狀況則必須針對測試結果做進一步的視覺化處理工作

Jenkins 套件法力無邊

針對前述問題一, 可以安裝下列套件做處理

  1. Log Parser Plugin

Log Parser可以在 Jenkins 運行結束後,
根據使用者設定的關鍵字去分析 LOG 內容, 並且整合統計結果

設定 :

測項結果走勢示意圖 :

設定後, 運行測試看看使用成果, 發現 FAIL 測項果然被高亮了,
而且任務如預期被判定為失敗

現在自動化測試的運行行為已經正常了, 但這樣仍然不夠,
因為若有測項失敗, 工程師仍得花一些時間檢查 LOG 釐清原因, 示意圖

如果可以一眼就看到失敗原因, 想必會省下不少時間!
這時可以搭配 Build Failure Analyzer Plugin
Build Failure Analyzer 這個套件可以根據使用者設定的字串分析 LOG,
當建置失敗, 便會分析 LOG 尋找關鍵字串, 找到後會在 LOG 高亮顯示結果,
並且直接於建置頁面顯示

設定

做完設定後, 若運行任務失敗便會主動進行 Failure Cause 偵測,
現在再次運行測試, 發現任務建置頁面出現了 Identified problems 告知失敗原因

點選Indication 1檢視失敗原因, LOG 被高亮了!

可視化工作

使用 Pipeline 讓測項可視化

上述的工作設定都還偏向文字呈現, 若要友善閱讀還是要有圖呈現較好
以各測項為例, 可以使用Pipeline來設定測試工作
成功失敗會直接以紅綠顏色呈現
在圖上也能看到每個測項所花費的時間, 還有平均時間, 整體來說方便很多

Pipeline script 示意圖 :

測試結果報表可視化

解決完前述運行測試過程的相關工作, 來到最後一步
要寄出給整個團隊的測試結果報表該如何處理?
之前有提到, 測試工程師根據測試的結果文字檔整理出一份 EXCEL 表寄出給團隊,
這些作法有那些問題?
其一 : 每次都要用對照文字檔和 EXCEL 表來整理, 時間太多? 何況人工實在太容易出錯
其二 : 這份 EXCEL 表為 local file, 只具備兩個生命週期
一為測試工程師將 EXCEL 表存放於本地端, 一為 Email 內的附件
沒有一個統一管理的地方, 當要調閱某次的測試結果都得撈很久

所以就目前的狀況, 採用了 TXT 轉 XML 的處理方式
XML 可以轉為 HTML 套用 CCS 樣式呈現於網頁, 也能轉為 EXCEL 表寄出
當測試結束後, 便會自動運行 TXT > XML > HTML 的工作
然後將 HTML 嵌入 EMail 直接寄給團隊, 完全省略人工處理

HTML 所呈現的測試結果 :

也可發布於建置頁面 (採用HTML Publisher Plugin)

設定

採用上述方式, 是我目前能想到較為方便的做法
由於團隊所使用的測試腳本是由PERL所撰寫
(還是極度舊版的 PERL, 所以沒什麼套件可用)
跟用 JUnit撰寫單元測試時, 只要做些簡單設定便有圖表可看真的是兩回事 (泣)

Share


↙↙↙阅读原文可查看相关链接,并与作者交流