前面一系列的文章有介紹過 UI 測試和 API 測試，普遍來說，因為 UI 的 Automation Test 有界面可見，更接近人手的操作，學習下來比較簡單，所以目前大多數的公司都會取向先導入 UI 的 Automation Test。
然而參看著名的 自動化測試金字塔，會看到取向應該是大量投入 Unit Test，再來是 API Test，最後才是 UI Test。那是因為愈接近底層的測試，愈容易瞄準問題作修正，測試速度亦相對較快。
Unit Test 單元測試：一般由開發人員負責，測試程式邏輯是否正確，屬於白箱測試。需要熟知程式碼的內容，所以一般較少由 SDET 負責開發。當然，若你有能力有權限去檢閱開發程式，也是可以協助開發單元測試的。
然而，Unit Test 的測試內容太細緻，在開發過程同時需要大量投入時間去開發 Unit Test 這件事並不夠 “人性” 。特別是針對迭代速度很快，時程很趕的案子根本是天荒夜談，所以會偏向著重 API Test，所以自動化測試的比例模型都有所改變。而作為自動化測試工程師更適合在這位置切入，協助開發 API Test 測試。
因此，針對從 0 開始作自動化測試的導入，會分為 4 個階段。
對大部分公司目前的理解，大概分 2 種模式：
自動化測試工程師 為一個獨立團隊，作 中央處理 各團隊的自動化測試的工作。
自動化測試工程師會 分散在各個團隊 ，跟著開發流程 為團隊執行 自動化測試的工作。
下圖以 Scrum Team 為例，自動化測試工程師於每個 Sprint 的工作：
靜態測試 Static Testing 開始做起，可以更早發現問題，省去不必要的開發成本。靜態測試 Static Testing
主要是在不執行實際程式碼的情況下，對軟體的設計文件、配置文件、程式碼等進行分析和檢查，以發現潛在的問題、錯誤和不一致性。
在開發前期測試工程師主要可協助檢示需求文件和系統設計以及早發現問題、提高團隊合作，並有助於減少後續測試和維護的成本。
以上 2 種模式較為常見，實際還是會根據公司狀況調整。
到最後才說這個會不會有點太晚？但我相信想要學習自動化測試的你，大概也聽說過它有什麼好處，只是還沒有真正的體悟到。現在學了這麼多，回頭來看，為什麼要做自動化測試？不外乎 2 個重點 降低成本 和 提高測試品質 。
但要做到這 2 個效果，也要有好的測試程式品質，測試的設計流程。
以前常聽說做自動化測試，學學怎樣寫 Script 就好，能跑就好了，但往往因為對整個測試專案的不理解，而產生大量的 Flaky Test，接下來消耗的維運時間，都足以使用手動測試完成了，讓大家對自動化測試產生懷疑，它真的可以降低成本嗎？
所以我非常強調作為自動化測試工程師，都必須要有基本的工程能力。因此在去年在 AppWorks School 設計了一個自動化測試工程師的學習課程，以自動化測試為目標，用最短的時間幫學員們補足作為工程師的基本能力。這次參加鐵人賽剛好作為過去一年的總結，在與學員互動的過程，更了解大家在學習的過程會遇到什麼卡點，整理下來成為這 30 篇文章。
當然這些其實都只是學習的起步，路還很漫長，至少還要學習的有：
然後就是實戰經驗的累積了。
需要有心理準備作為工程師就是要終身學習，技術都發展太快，沒有跟上就落伍了。
自動化測試將會是未來的趨勢，現在就像十多年前開發技術還沒普及化時，要慢慢推行各種的系統化，到現在什麼都已經系統化。同樣，也可預想未來的十年，自動化測試普及，可取代繁複的人手操作，帶來更快的測試周期，更好的產品品質，推進科技的發展。
最後，感謝看到最後一篇的你，第一次寫技術文章，或許會有不足之處，有任何問題都歡迎私訊留言討論，有緣再會～
看影片追技術