測試金字塔這個概念是由 Mike Cohn 所提出, 在敏捷測試圈很流行, 不過大家不太清楚他是什麼, 並且對它有很多誤解. 因此, 簡單整理了一下他的想法, 希望能對大家有幫助.
The Forgotten Layer of the Test Automation Pyramid, Mike Cohn, 2009,12, 17
Mike Cohn 提到, 測試自動化這件事情大家都知道要做, 可是卻發現要花很多時間去做. Mike 認為這是因為大家在錯誤的地方去做自動化, 自然就會事倍功半. Mike 認為自動化可以在三個層次上進行, 如下圖所示分成 UI, Service 和 Unit. 也就是所謂的測試自動化金字塔 (Test Automation Pyramind).
Unit Testing: 是測試自動化的基礎, 可以給開發人員最準確的回饋: 直接說哪一行出錯. 此外, 寫測試的語言, 剛好就是開發的程式語言, 因此對開發人員來說一點都不陌生.
UI: 從受測程式的畫面介面來進行測試. 不過透過 UI 的測試方式, 往往執行時間花費較久, 並且測試程式常常會有問題, 維護的成本很高.
Service: 程式內部通常由一些 service 所組成, 提供一些功能或是基礎建設, 讓畫面或是其他 service 所使用. 因此 Service level 的測試是直接呼叫 service 的介面來進行測試, 而不是透過受測程式的 UI.
很多組織在做測試自動化時, 常常會陷入:
(1) 開發人員不想寫單元測試
(2) 找的測試人員不寫 code, 因此只能用錄製的方式進行 UI 測試自動化
所以這些組織的測試自動化, 執行的時間很長, 測試程式不穩定, 並且要花成本維護. 開發人員無法及時得到回饋, 並且有錯時要花很多時間去找錯在哪.
TestPyramid
Martin 認為測試自動化金字塔是種思考方式, 用來思考如何平衡不同層次測試自動化的投資.
Martin 也說到大部分的測試策略如下如所示: ice cream cone. 絕大多是在進行 手動測試, 然後是利用畫面來進行自動化. 可是在 integration 和 unit 層次的自動化很少. 這是一個錯誤的投資.
所謂的 UI 層次的測試, 並不是指前端開發人員寫都東西都是歸在這類. 有些像是 React 這些複雜的 UI 程式, 會需要 UI unit test, 來測試某些單元或是共用元件.
還有一點, 當你在 UI 層次的測試抓到問題時, 建議要在 unit test 層次加測試. 在這個層次加測試, 才能確保這個錯誤真的被消滅. UI 測試的層次太高了, 很可能無法打到真正的原因
The Practical Test Pyramid
當軟體開發要求快速交付, 並且要處理的環境和版本越多時, 回歸測試變成是很大的負擔. 你不可能靠手動測試, 這樣會來不及, 此外測試人員也會覺得這樣是個無聊的工作.
為了讓 regression testing 成本降低, 並且讓測試人員有空去做更有價值的測試, 測試自動化是個解法.
作者認為 Mike Cohn 的測試金字塔太簡化很多狀況. 但不得不承認, 就是因為簡單, 所以好瞭解好落實. 並且他最重要的概念是
(1) 測試自動化要有不同的粒度
(2) 測試在越 high level 的層次, 所要進行的自動化比例要越少
就如金字塔的形狀, 大量較快較小的的單元測試, 是比較健康的. 然後再加上少量的粗顆粒或 high level 層次的自動化, 來測試受測系統的端到端. 冰淇淋形狀的自動化比例是不健康的, 維護成本高, 並且執行時間也很長.
原先 Mike Cohn 測試金字塔上的名稱不重要. Service 這層大家就不知道他是什麼, 有些人說是 元件測試(component testing), 也有人說是整合測試(integration testing). 另外 UI 也不是指 front end 所開發的程式. 重點在於符合上面說的兩個概念.
測試金字塔的基本觀念就介紹到此. 但是, 他不是僅此於此. 網路上還有很多討論, 以及不同的變形. 之後有機會再跟大家介紹.
全站熱搜
留言列表
