Cody Blog

Software development

自動化軟體測試的金字塔

Automation pyramid

測試的重點

軟體測試在敏捷化開發一定會遇到的問題,就是原本很可能都是以“週”為單位完成的Task。如果在一個三週Sprint的情況下,測試工作很可能都要變成以“天“為單位完成的Task,我們要如何能把大部份的測試活動都在短的時間區間完成!?如同 Scrum 大師 Mike Cohn 所說的,我們需要一個健康測試金字塔。把時間投資在的測試活動上。

金字塔有三層,由下而上分別是 Unit Test ,Acceptance Test, GUI Tests。最上面不一定大小的 Manual Tests。這邊傳達的最重要的概念就是,我們應該盡可能地把時間投資在 Unit test 上,理由很簡單,因為 Unit Test 穩定度是最高的,而且最容易被執行。如果一個測試目標能在 Unit tests level 被處理掉的話,我們應該要盡量讓它們在 Unit test level 就發生。而當測試的 Scope 愈來愈大,測試的成本就會愈來愈貴,可能會由白箱測試變黑箱測試,所需要的測試文件就需要更多來傳達資訊。

很可惜地,大部份的測試團隊,剛好相反。投入了大量人力在 Manual tests 之上。也因為有大量的 Tester 在執行 GUI Test、Manual Test 所以 Developer 在相對少的資源下,就只能把大部份可以在 unit test level 就處理掉的任務直接讓給 tester 來完成。

金字塔 與 三隻小豬的故事

三隻小豬

Patrick Wilson-Welsh 把這個金字塔比喻成三隻小豬的故事。有做過 GUI test 的人應該都知道,我們應該最後才做 GUI test,因為他最 brittle,最容易因為一點點的改變而讓測試不通過。所以 Patrick 把它比喻成豬大哥的茅草屋。而 Acceptance test 則是豬二哥的木頭屋,因為在 API Lelvel,去掉最難測的GUI,理論上變化的頻率就變少了,會比較堅固。而最後就是豬小弟的 Unit test 磚頭屋。unit test 我們的測試目標scope是最小的,去除最多的 dependency ,讓不穩定的因子降到最低,這個故事也暗示了一點,磚頭屋是最難蓋的,需要最多的人手來幫忙完成。就跟三隻小豬的故事一樣,我們要像豬小弟一樣,長期的耕耘建設,才不會大野狼(Change)一吹,就倒光光。

Related Posts

Comments