在前面的章節中，我們學習了如何使用 Robot Framework 結合 Playwright 進行 Web UI 自動化測試。然而，在這些示例中，我們只使用了單一的 .robot 檔案來進行測試。在實際工作中，產品的測試往往不可能僅依賴一個檔案完成所有測試。因此在本章節中，將會向大家介紹如何規劃測試框架，以便提升自動化測試的可維護性與可擴展性，並使測試腳本的撰寫更加高效。

為什麼需要一個好的專案架構？

在自動化測試專案中，擁有一個良好的架構至關重要，這不僅能提高測試的效率和可維護性，還能確保專案的可擴展性和靈活性。以下是一些關於為什麼需要一個好的架構的關鍵點：

1. 提高可維護性：隨著專案規模的擴大，測試案例的數量和複雜度也會增加。如果沒有清晰的架構，管理和維護測試程式碼會變得非常困難。通過將不同功能模塊的程式碼解耦、關鍵字重用可以使測試腳本更易於理解和修改，從而減少維護成本。
2. 提升程式碼的重用性：一個良好的專案架構會鼓勵程式碼的重用，避免重複編寫相同的測試邏輯。將常用的操作或測試場景提取為通用的關鍵字或函數庫，可以在不同的測試案例中重複使用，從而提高開發效率，並降低錯誤風險。
3. 促進團隊協作：在多人的團隊中工作時，一個清晰的專案架構能夠促進團隊成員之間的協作。每個人都能夠明確知道程式碼應該放置在哪個目錄下，這不僅減少了程式碼衝突的風險，也使得團隊成員之間的協作更加順暢。

專案架構範例

下面我們將介紹專案架構的範例，實際情況大家可以根據產品的特性進行調整，在這個範例框架中的特性是，我們將 test script、keyword、element 三者解耦，拆成三個部分，如此一來當今天 element 有改動時，我們不需要到每個測試案例中修改 element 的參數，只許要修改一個即可，如此一來大大的降低我們的修復成本，在這邊筆者也在這邊將這個專案的框架做開源，https://github.com/max-tsai-qa/rf-playwright-example 大家如果有興趣的話可以 clone 下來執行，或是對於整體框架有想瞭解更多的話也可以到專案中查看。

.
├── README.md
├── init.robot
├── library
│   ├── integration
│   │   └── fake_data.py
│   └── keywords
│       └── keywords-common.robot
├── requirements.txt
├── resource
│   ├── location
│   │   └── element-common.py
│   └── src
├── setting.py
└── test
    ├── test_add_todo.robot
    └── test_mark_todo.robot

這個專案結構分為幾個主要部分，各自負責不同的功能模塊：

• README.md: 專案的簡介和使用說明。
• init.robot： 初始化腳本，通常用於設置全局變量或配置，我們將需要 import 的 Library、Variables、Resource 都放在同一個檔案，這個每個 .robot 在 Setting 中只需要匯入這個檔案即可
• library： 包含自定義的函數庫和關鍵字。這裡的 integration/ 中放的會是 python 撰寫的擴充 keyword。而 keywords/ 底下則是放的則是透過 Robot Framework 撰寫的 keyword
• requirements.txt： 記錄了專案所需的 Python 依賴包。
• resource： 存放測試資源，如元素定位信息和其他資源文件。location/ 底下放的是元件的定位，而 src 則是放其他與測試相關的資源，像是測試中需要用到的圖片。
• setting.py： 在這個檔案中我們放置全域變數。
• test： 存放測試案例的地方

Page Object Model

談到自動化測試的框架設計時，大家肯定都會聽到 Page Object Model，至於什麼是 Page Object Model 呢？ Page Object Model 是一種將網頁中的各個元素抽象成物件的設計模式。每一個網頁頁面或是應用程式的視圖，會對應到一個獨立的 "Page Object"。這些物件負責封裝網頁上的元素及其操作，像是按鈕點擊、文字輸入等。測試腳本不直接與這些元素互動，而是透過 Page Object 來進行操作，這樣當頁面發生變更時，只需要修改對應的 Page Object，而不用改動測試腳本中的每一個測試案例。

Page Object Model 的好處

1. 高可維護性：當網頁佈局或元素發生變動時，只需修改對應的 Page Object，而不是所有相關測試，減少了大規模修改測試腳本的需求。
2. 提高可讀性：測試腳本只需描述具體的操作流程，而不需要關注頁面細節，讓測試更加直觀和易於理解。
3. 減少重複程式碼：將重複的元素操作抽取到 Page Object 中，可以減少測試案例中的重複程式碼，讓程式碼更加乾淨整潔。
4. 隔離頁面邏輯與測試邏輯：頁面元素的操作邏輯與測試邏輯被分離，使得測試腳本不會因為頁面細節變更而頻繁調整。

在上方我們介紹的 Robot Framework 專案架構中，已經有些 Page Object Model 的影子存在了，我們將通用的 keyword 包好放在 keywords-common.robot 中，這時我們也可以根據登入頁面的測試在 keywords 中新增一個 login-keywords.robot 的檔案，根據不同的頁面創造出不同的 keywords，讓我們在撰寫及維護測試腳本上更加便利。

結語

在閱讀本篇後大家對於 Robot Framework 的自動化測試專案架構可以有更多的想像，除了會撰寫測試腳本外，我們也需要具備設計測試架構的能力，讓我們的測試更加的彈性且具備高維護性，並且在閱讀這幾篇關於 Robot Framework 與 Playwright 結合的文章後，我們可以構建一個強大且靈活的 Web 自動化測試框架。這種方法不僅提升了測試的穩定性和效率，也使得測試案例的編寫和維護變得更加輕鬆。隨著專案的擴展，您可以不斷地增加自定義關鍵字和測試案例，以滿足不同的測試需求。