27 Jan 2025

實戰分享：如何用 Robot Framework 建立自動化測試流程

回到 2019 年，那時的我們對 Robot Framework 的了解還不夠深入，導致許多測試案例無法平行執行；再加上測試資料管理的不足，進一步加大了測試的複雜度。然而，經過這些年的實踐，我們逐漸找到了應對之道。在撰寫新的自動化測試框架時，我們特別考慮了這些問題，並融入了解決方案。與五年前相比，現在的測試流程更加效率且穩定。

前言

在 2019 年初，隨著產品迭代的速度變得越來越快，對於快速釋出新功能變得越來越不容易。當時團隊負責的產品已經是第八版 (2019)，已經累積將近 8000 多個測試案例。

如果要釋出一項新功能，必須花費將近數個禮拜的時間做迴歸測試 (Regression Testing)，除了原本的新功能，還必須重複地執行可能會被影響的舊功能的測試案例，以確保舊功能沒有任何的影響。

於是透過自動化測試保護重要的功能和新功能。最後花費將近一年的時間，將大部分的 RAT 的測試案例自動化，即使整體自動化的比例還是偏低，但還是減輕了不少測試上的壓力。

組織架構

康威定律指出，產品的架構會反映出組織的溝通結構。在我們的團隊中，產品團隊分為開發團隊和測試團隊，因此我們的自動化測試設計依賴於開發團隊出完 Build 後，再將 Build 安裝到測試環境中進行測試。

雖然這樣的分工能讓兩個團隊專注於各自的核心工作，但也帶來一些挑戰，例如 Build 交付的延遲會直接影響測試進度，因此我們想透過 CI/CD 來作些驗證與測試。

CI/CD

我們的自動化測試重點放在 Build Verification Testing (BVT) 和 Regression Testing (回歸測試)，部分的 API 測試則是在舊有的自動化測試框架執行，這裡就先不提及了：

Build Verification Testing (BVT) 或 Smoke Testing (煙霧測試)

目標是快速驗證 Build 是否穩定可用，包括安裝過程是否成功，以及基本功能（例如：各頁面是否可以正常點擊。
在工具上面使用 Robot Framework 和 Selenium 實作自動化點擊每個頁面，自動化之後，開發團隊和測試團隊能夠在 10 分鐘發現 Build 是否有問題，如果有問題則可以馬上修復。

Regression Testing

針對所有功能進行完整的 Test Suite 測試，目標是確保新功能不會影響舊功能。迴歸測試案例執行時間，使用多開機器，分散式執行測試，能夠縮短 40% 的時間，但由於 RAT 測試案例的涵蓋越來越高，測試團隊就可以將專於於新功能的測試上，而不需要太過於擔心原有的功能是否因為程式碼變動而改壞。

Robot Framework

我們採用 Robot Framework 作為測試框架，因為它提供了關鍵字驅動（keyword-driven）的測試方法，能讓測試腳本更具可讀性，降低非技術人員的學習門檻。框架本身提供了許多很好用的函式庫，基本上都可以用這些關鍵字時做出測試步驟，而不需要撰寫額外的程式碼，但因為產品需求還是有本身的邏輯，所以還是需要有人實作產品相關的關鍵字和函式。

自動化框架

我們的測試框架主要分為下列幾個部分：

測試資料：使用 csv 準備測試需要
測試案例：執行測試案例的 feature 檔案
測試報告：robot framework 產生出的結果與後續的處理。
自動化測試視覺化：將測試結果顯示在團隊可以看到的地方。
為了加速測試案例執行，我們也有嘗試下列幾種方案

Selenium Grid：曾經嘗試過的方案，但因為測試案例並沒有與測試資料獨立，執行 Test 的順序必須要依照順序。
pabot https://pabot.org/ : Robot Framework 函式庫，透過多 Process 的方式平行執行測試案例，以我們應用在 BVT 裡面，如果是比較單 CPU 和多 CPU 的機器執行的時間，最後能節省 40% 的執行時間，當然有部分取決你的測試案例執行的方式。
headless (無頭模式) : 對某些 UI 的測試案例會加快執行時間，但對於測試案例的分散式執行效果會更明顯。

結論

經過一年的努力，我們將自動化測試融入到開發流程中，提升了測試效率和產品穩定性。然而，我們仍有一些改進空間：

測試案例使用 CSV 當作測試資料來源，造成測試案例之間的依賴關係，也是無法提升測試案例執行速度，目前解法只能增加執行測試的機器數量，但成本相對用多執行緒或是多 worker 高很多，這個問題通常要在設計初期就考慮進去，不然很難有時間能夠重新建置測試資料管理方式。
執行 Regression Testing 通常都是所有測試案例都會執行，但在開發前期只需要針對程式碼改動部分測試，等合併至開發分支再執行就好，可以節省測試時間卻不會遺漏本來要找到的問題。

前言