記得我剛進趨勢的時候被分派的第一項任務就是把API Test Case　做成自動化測試，那時候光是DVT(Dployment Verification Test) 就多達500支自動化測試案例，後來的光陰之中，發現多年以後部門的自動化始終環繞在API自動化之中，很難做到全面的All Functional Tests for All Systems, 尤其是涉及 E2E 的 Web UI 自動化測試，最終皆因為Test Case Results 的不穩定性而放棄大量實作。

　　上述的經歷其實就是自動化測試的一個典型陷阱：pushing percentage-of-tests-automated metrics, 強調自動化測試的覆蓋率，最終的結果就是：產生巨量的自動化測試開發及維護成本以及低效率的無效益自動化測試集合！

　　而我現在的專案也正巧進入自動化測試的階段，所以我也開始思考怎樣做出一套有用的自動化測試工具，在拜讀 Medium 中的一篇文章 “Don’t Automate Test Cases” 之後我大概了解到要讓自動化測試成功的重點就是：＂避開自動化測試的陷阱，避免開發出膨脹的Test Suite＂。

　　那要如何避開陷阱呢？　首先應該從自動化測試所應該達成的兩樣指標說起：Costs and Benefits,　自然我們是希望自動化測試的結果是幫助我們開發軟體低成本與高效益化( Lower Costs and Higher Benefits)。

[圖片來源]Don’t Automate Test Cases

　　而要達成這個目標，自然需要識別兩樣要素：哪些Test Case 應該被自動化？它們應該被自動化成哪種Level 的 Automation Test Type?　這邊根據前面我們的唯一自動化原則：lower costs and higher benefits, 我們需要把Test Case按照成本分成不同的 Automation Test Type:

[圖片來源]Don’t Automate Test Cases

　　由上圖測試金字塔(Automated Test pyramid)可知最低階的automated test type是 Unit Test,同時它也是Size最小(測試複雜度最小)，成本最低，測試最快的Test type，然後是開始整合的Component Test type到高階整合的 Integration Test Type，最高階的則是 E2E Test Type，由圖中我們也可以知道，愈往上愈高階，當到達E2E Test Type的Level時，Size最大，成本最高，測試最慢。　而這也正巧符合測試金字塔的概念：愈往上層的Test Case將愈少，因為測試成本愈大也愈花時間。

　　所以如果Automated Test Case 太多且都位於高層次Test Type的話，代表Automation維護成本愈大，且執行測試時間愈久，最終造就一個巨大但無效率的Test Suite。

　　因此，我們應該按照測試金字塔結構，將Test Case 盡量在Low Level 處自動化，因為愈低階的Test Type自動化成本愈低，也愈能快速產生效率，愈高階的自動化測試案例則應該盡量減少，一個重要的技巧是：能在API Level驗證的功能就不要在E2E Level測試；能在Unit Test Level驗證的功能就不要在Integration Level(Component/API/SIT Test)測試，永遠保持複雜的測試類別在高層且盡可能地少。

　　然後，在每一次新功能或Feature的迭代版本之中，我們將需要加入新的Test Case，同樣應該保持上述的低階為主的原則，但同時要確保盡量將新的在低階層中實現，高層除非絕對必要，否則對於新功能僅做相關Test Case的Update，與此同時則要同步調整舊的Test Case，包括：調整Test Case 到更適合的測試類別以及刪除不必要的過時的Test Case，避免無效的Test Case使Test Suite膨脹化。

綜上所述，要避免自動化測試失敗，需要在實做Automated Test Case過程中遵守底下原則：

1. 按照測試金字塔結構，將Test Case 盡量在Low Level 處自動化，因為愈低階的Test Type自動化成本愈低，也愈能快速產生效率，愈高階的自動化測試案例則應該盡量減少
2. 能在API Level驗證的功能就不要在E2E Level測試；能在Unit Test Level驗證的功能就不要在Integration Level(Component/API/SIT Test)測試
3. 新功能測試自動化：確保盡量將新功能的Test Case在低階層中實現，高層除非絕對必要，否則對於新功能僅做相關Test Case的Update，同時應該要記住刪除Test Case 跟新增 Test Case 一樣重要。

[Reference]

1. Don’t Automate Test Cases,

https://medium.com/slalom-build/dont-automate-test-cases-58e3b959ce6

2022年12月27日星期二