2026年01月16日玄貓（BlackCat）

運用頁面物件模型打造可維護的自動化測試架構

頁面物件模型（Page Object Model, POM）是解決網頁自動化測試脆弱且難以維護的關鍵設計模式。此架構將網頁各區塊抽象化為獨立的頁面物件，封裝所有與介面元素的互動邏輯。如此一來，測試腳本僅需呼叫高階方法，無需處理底層定位策略，大幅提升程式碼的可讀性與可維護性。當網頁介面變更時，僅需修改對應的頁面物件，測試案例本身則不受影響。此外，透過繼承建立基礎頁面類別，更能實現共用元件的程式碼重用，打造出彈性且易於擴展的測試框架。

軟體開發測試自動化

頁面物件模型測試自動化 Selenium 物件導向架構設計

在軟體開發生命週期中，自動化測試是確保品質與加速交付的關鍵環節。然而，傳統的腳本式測試寫法常將測試邏輯與使用者介面的實作細節緊密耦合，導致測試碼極度脆弱，只要前端介面稍有調整，便可能引發大規模的測試失敗與維護災難。為了解決此結構性問題，頁面物件模型（Page Object Model, POM）應運而生。它借鑒了物件導向設計中「關注點分離」的核心思想，將網頁視為一系列可互動的物件集合，而非僅是 HTML 元素的堆疊。透過此模式，我們能將繁瑣的元素定位與操作細節封裝起來，讓測試案例回歸其本質——驗證商業邏輯與使用者流程，從而建立一個穩健、可擴展且易於維護的自動化測試體系。

網頁自動化測試的架構思維

在建構複雜的網頁自動化測試時，單純的指令堆疊不僅難以維護，更會隨著應用程式介面的變動而變得脆弱不堪。為了應對此挑戰，我們需要引入結構化的設計模式，其中「頁面物件模型」（Page Object Model, POM）便是關鍵的解決方案。它將網頁的各個獨立區塊或頁面，抽象化為各自的物件，讓測試腳本能夠以更清晰、更易於理解的方式與網頁互動。

封裝網頁互動邏輯

POM 的核心概念在於將與特定網頁元素互動的所有邏輯，封裝在一個獨立的「頁面類別」（Page Class）中。例如，當我們需要搜尋特定書籍時，相關的搜尋欄位定位、輸入文字、按下 Enter 鍵等操作，都應當被歸納到一個代表搜尋頁面的類別裡。這個類別會提供方法，例如 getSearchElement() 來取得搜尋欄位的 WebElement，或是 performSearch(String bookName) 來執行完整的搜尋流程。

如此一來，測試腳本便不再需要直接處理底層的 WebDriver 呼叫或定位策略。它只需呼叫頁面類別所提供的方法，就能夠達成預期的網頁操作。這不僅大幅簡化了測試程式碼的可讀性，更重要的是，當網頁的結構或元素 ID 發生變動時，我們僅需修改對應的頁面類別，而測試腳本本身則幾乎不受影響，無需進行大規模的重寫。

以下是一個簡化的頁面類別範例，展示了如何封裝搜尋功能的互動邏輯：

package com.example.ui.pages;

import org.openqa.selenium.By;
import org.openqa.selenium.Keys;
import org.openqa.selenium.WebDriver;
import org.openqa.selenium.WebElement;
import org.openqa.selenium.support.ui.WebDriverWait;
import org.openqa.selenium.support.ui.ExpectedConditions;
import java.time.Duration;

public class SearchPage {
    private WebDriver browserDriver;
    private WebDriverWait waitDriver;

    // 定義搜尋欄位的定位器
    private final By searchInputLocator = By.id("search-input-field");
    // 定義搜尋結果連結的定位器，通常會包含書名的一部分
    private By bookLinkLocator(String bookName) {
        return By.partialLinkText(bookName);
    }

    public SearchPage(WebDriver driver) {
        this.browserDriver = driver;
        // 設定等待時間，確保元素載入
        this.waitDriver = new WebDriverWait(this.browserDriver, Duration.ofSeconds(30), Duration.ofSeconds(5));
    }

    // 方法：取得搜尋欄位元素
    public WebElement getSearchInput() {
        waitDriver.until(ExpectedConditions.presenceOfElementLocated(searchInputLocator));
        return browserDriver.findElement(searchInputLocator);
    }

    // 方法：執行搜尋操作
    public void performSearch(String bookTitle) {
        WebElement searchField = getSearchInput();
        searchField.sendKeys(bookTitle);
        searchField.sendKeys(Keys.ENTER);
    }

    // 方法：等待並取得特定書籍連結
    public WebElement getBookLink(String bookName) {
        waitDriver.until(ExpectedConditions.presenceOfElementLocated(bookLinkLocator(bookName)));
        return browserDriver.findElement(bookLinkLocator(bookName));
    }

    // 方法：點擊特定書籍連結
    public void clickBookLink(String bookName) {
        getBookLink(bookName).click();
    }
}

看圖說話：

此圖示展示了一個典型的頁面物件模型（POM）架構中的「搜尋頁面」類別。它封裝了與網頁搜尋功能相關的所有互動邏輯。SearchPage 類別接收一個 WebDriver 實例，並初始化一個 WebDriverWait 物件，用於處理元素等待。內部定義了搜尋輸入框的定位器 (searchInputLocator)，以及一個動態生成書籍連結定位器的方法 (bookLinkLocator)。提供的公共方法包括 getSearchInput() 用於獲取搜尋欄位，performSearch(String bookTitle) 用於執行完整的搜尋流程，以及 getBookLink(String bookName) 和 clickBookLink(String bookName) 用於定位和點擊搜尋結果中的書籍連結。這種封裝方式確保了測試腳本與網頁元素之間的解耦，提高了代碼的可維護性和可讀性。

測試腳本的簡化與隔離

藉由 POM，測試腳本的撰寫變得更加直觀。測試人員不再需要關心元素定位的細節，而是專注於驗證業務邏輯。例如，一個測試搜尋功能的腳本，可能僅需幾行程式碼：

package com.example.ui.tests;

import org.openqa.selenium.WebDriver;
import org.openqa.selenium.WebElement;
import org.testng.Assert;
import org.testng.annotations.Test;
import com.example.ui.pages.SearchPage;
import com.example.ui.driver.DriverFactory; // 假設有一個 WebDriver 工廠

public class SearchFunctionalityTest {

    // 假設 DriverFactory 提供 WebDriver 實例
    private WebDriver driver = DriverFactory.getDriver();
    private SearchPage searchPage = new SearchPage(driver);

    @Test
    public void testSuccessfulBookSearch() {
        //Arrange
        String bookToSearch = "The Art of Programming";
        String expectedUrlPart = "/books/"; // 假設搜尋後 URL 會包含此部分

        //Act
        searchPage.performSearch(bookToSearch);
        // 假設點擊搜尋結果中的書籍連結
        searchPage.clickBookLink(bookToSearch);

        //Assert
        // 驗證 URL 是否已更新，表示導向到書籍詳情頁
        Assert.assertTrue(driver.getCurrentUrl().contains(expectedUrlPart),
                          "URL did not change after search and click.");

        // 額外驗證：檢查書籍詳情頁是否包含書籍標題
        // 這裡需要另一個 Page Object 來處理書籍詳情頁
        // 例如: BookDetailsPage bookDetailsPage = new BookDetailsPage(driver);
        // Assert.assertTrue(bookDetailsPage.getPageTitle().contains(bookToSearch));
    }

    // ... 其他測試方法，例如測試無結果搜尋
}

這種結構的最大優勢在於，當網頁的搜尋輸入框 ID 從 search-input-field 變更為其他值時，我們僅需要修改 SearchPage 類別中的 searchInputLocator 定義，而 SearchFunctionalityTest 中的 testSuccessfulBookSearch 方法則無需任何改動。這大大降低了維護成本，並減少了因元素定位變更而引入的測試錯誤。

看圖說話：

此圖示描繪了一個基於頁面物件模型（POM）的測試場景。測試類別 SearchFunctionalityTest 僅需與 SearchPage 物件互動，而無需直接操作 WebDriver。測試流程首先透過 searchPage.performSearch() 執行搜尋操作，接著透過 searchPage.clickBookLink() 點擊搜尋結果中的特定書籍連結。最後，使用 Assert.assertTrue() 來驗證網頁 URL 是否如預期般發生變化，這代表著系統成功導向到書籍詳情頁面。這種抽象化的設計使得測試腳本專注於業務邏輯的驗證，而將底層的網頁元素定位與互動細節封裝在 SearchPage 物件中，顯著提升了測試代碼的可讀性與可維護性。

繼承在 POM 中的應用

隨著應用程式的複雜度增加，不同頁面之間可能會共享某些元件，例如導覽列、頁尾或側邊欄。為了避免重複定義這些共享元件的定位器和操作方法，我們可以運用物件導向的「繼承」機制。

我們可以建立一個「基礎頁面類別」（Base Page Class），將所有頁面共有的屬性（如 WebDriver 實例、WebDriverWait 物件）和方法（如等待元素、點擊通用按鈕）定義在其中。然後，各個具體的頁面類別（如 SearchPage, HomePage, CartPage）則繼承自這個基礎頁面類別。這樣，所有子頁面類別都能自動獲得基礎類別的功能，並在此基礎上添加自己獨有的元素和方法。

例如，我們可以有一個 BasePage 類別：

package com.example.ui.pages;

import org.openqa.selenium.WebDriver;
import org.openqa.selenium.WebElement;
import org.openqa.selenium.support.ui.WebDriverWait;
import org.openqa.selenium.support.ui.ExpectedConditions;
import java.time.Duration;

public abstract class BasePage {
    protected WebDriver browserDriver;
    protected WebDriverWait waitDriver;

    public BasePage(WebDriver driver) {
        this.browserDriver = driver;
        this.waitDriver = new WebDriverWait(this.browserDriver, Duration.ofSeconds(30), Duration.ofSeconds(5));
    }

    // 抽象方法，子類別必須實作以定義頁面標題或特定驗證
    public abstract void verifyPageLoaded();

    // 共用方法：等待元素出現
    protected WebElement waitForElement(By locator) {
        waitDriver.until(ExpectedConditions.presenceOfElementLocated(locator));
        return browserDriver.findElement(locator);
    }

    // 共用方法：點擊元素
    protected void clickElement(By locator) {
        WebElement element = waitForElement(locator);
        element.click();
    }

    // 共用方法：輸入文字
    protected void enterText(By locator, String text) {
        WebElement element = waitForElement(locator);
        element.clear(); // 清除現有文字
        element.sendKeys(text);
    }
}

然後，SearchPage 可以繼承自 BasePage：

package com.example.ui.pages;

import org.openqa.selenium.By;
import org.openqa.selenium.Keys;
import org.openqa.selenium.WebDriver;
import org.openqa.selenium.WebElement;

public class SearchPage extends BasePage {

    private final By searchInputLocator = By.id("search-input-field");
    private By bookLinkLocator(String bookName) {
        return By.partialLinkText(bookName);
    }

    public SearchPage(WebDriver driver) {
        super(driver); // 呼叫父類別建構子
    }

    @Override
    public void verifyPageLoaded() {
        // 驗證搜尋頁面是否已正確載入，例如檢查搜尋欄是否存在
        waitForElement(searchInputLocator);
    }

    public void performSearch(String bookTitle) {
        enterText(searchInputLocator, bookTitle); // 使用父類別的 enterText 方法
        browserDriver.findElement(searchInputLocator).sendKeys(Keys.ENTER); // 這裡需要直接操作，因為 ENTER 是特定行為
    }

    public WebElement getBookLink(String bookName) {
        return waitForElement(bookLinkLocator(bookName)); // 使用父類別的 waitForElement 方法
    }

    public void clickBookLink(String bookName) {
        clickElement(bookLinkLocator(bookName)); // 使用父類別的 clickElement 方法
    }
}

透過繼承，我們不僅實現了程式碼的重用，更建立了一個清晰的類別層級結構，使得整個測試框架更具彈性和擴展性。這對於大型、複雜的網頁應用程式尤為重要，能夠有效管理不斷演進的測試需求。

@startuml
!define DISABLE_LINK
!define PLANTUML_FORMAT svg
!theme _none_

skinparam dpi auto
skinparam shadowing false
skinparam linetype ortho
skinparam roundcorner 5
skinparam defaultFontName "Microsoft JhengHei UI"
skinparam defaultFontSize 16
skinparam minClassWidth 100

class BasePage {
  # WebDriver browserDriver
  # WebDriverWait waitDriver
  + BasePage(WebDriver driver)
  + abstract verifyPageLoaded()
  # waitForElement(By locator) : WebElement
  # clickElement(By locator)
  # enterText(By locator, String text)
}

class SearchPage {
  - By searchInputLocator
  - bookLinkLocator(String bookName) : By
  + SearchPage(WebDriver driver)
  + verifyPageLoaded()
  + performSearch(String bookTitle)
  + getBookLink(String bookName) : WebElement
  + clickBookLink(String bookName)
}

class BookDetailsPage {
  - By pageTitleLocator
  + BookDetailsPage(WebDriver driver)
  + verifyPageLoaded()
  + getPageTitle() : String
}

BasePage <|-- SearchPage
BasePage <|-- BookDetailsPage

@enduml

看圖說話：

此圖示清晰地展示了在頁面物件模型（POM）中使用繼承來組織類別的架構。BasePage 作為一個抽象父類別，定義了所有頁面物件共有的屬性和方法，例如 WebDriver 實例、等待機制以及常用的元素操作（如等待元素、點擊、輸入文字）。它還包含一個抽象方法 verifyPageLoaded()，強制要求子類別實作以定義各自頁面的載入驗證邏輯。SearchPage 和 BookDetailsPage 作為具體的頁面類別，繼承自 BasePage，並各自實作了 verifyPageLoaded() 方法，同時封裝了與自身頁面相關的獨特元素定位器和互動方法。這種繼承關係確保了程式碼的重用性，並建立了一個層次分明的類別結構，使得測試框架更易於擴展和維護。

@startuml
!define DISABLE_LINK
!define PLANTUML_FORMAT svg
!theme _none_

skinparam dpi auto
skinparam shadowing false
skinparam linetype ortho
skinparam roundcorner 5
skinparam defaultFontName "Microsoft JhengHei UI"
skinparam defaultFontSize 16
skinparam minClassWidth 100

package "網頁自動化框架" {
  class "基礎頁面物件" as BasePage {
    + WebDriver driver
    + WebDriverWait waitForElement
    + BasePage(WebDriver driver)
    + WebElement getSearchElement()
  }

  class "主頁面物件" as MainPage {
    + String freeTrial
    + String tryForFreeText
    + MainPage(WebDriver webdriver)
    + WebElement getFreeTrialElement()
    + void waitTrialLoaded()
  }

  class "測試案例類別" as TestCaseClass {
    + MainPage page
    + WebDriver driver
    + String bookName
    + void initPages()
    + void beforeMethod()
    + void afterMethod()
    + void testSearch()
  }
}

BasePage <|-- MainPage
MainPage ..> TestCaseClass : 使用

@enduml

看圖說話：

此圖示描繪了一個網頁自動化測試框架中的物件導向設計模式。核心概念是利用「繼承」來共享程式碼，以提升效率與可維護性。「基礎頁面物件」（BasePage）扮演著基底角色，封裝了所有網頁操作共有的元素與驅動程式的初始化邏輯，例如 WebDriver 實例以及等待元素出現的機制。接著，「主頁面物件」（MainPage）繼承自「基礎頁面物件」，這意味著它自動獲得了所有基礎頁面物件的功能，並在此之上增加了專屬於主頁面的特定互動元素，例如「免費試用」按鈕的定位與操作。最後，「測試案例類別」（TestCaseClass）則是實際執行自動化測試的載體，它會實例化「主頁面物件」，並透過該物件來呼叫基礎頁面物件和主頁面物件所提供的所有方法，進而執行搜尋、驗證等測試步驟。這種結構化的設計，使得測試程式碼更加清晰、模組化，並能有效避免重複編寫相同邏輯。

好的，這是一篇關於網頁自動化測試架構思維的文章，我將為您撰寫一篇符合玄貓風格的結論。

發展視角： 創新與突破視角 結論：

縱觀現代軟體開發的複雜生態，自動化測試的價值已不僅止於功能驗證，更在於其作為品質保障體系的可持續性與韌性。頁面物件模型（POM）的引入，正是從「指令式腳本」到「物件導向設計」的思維突破。它不僅是技術上的解耦，更是將軟體工程的封裝與繼承原則，深度整合至測試領域的實踐。傳統方法將測試視為一次性的線性任務，而 POM 則將其提升為建構一個可維護、可擴展的測試「資產」。其真正的挑戰並非語法掌握，而是從單點的元素定位，轉向對整體應用程式結構的抽象化理解與架構能力。

未來，衡量一位測試專家的價值，將愈發側重於其建構穩固測試框架的架構能力，而非僅僅是撰寫測試案例的數量。這種從「執行者」到「設計者」的角色演進，將是測試專業領域不可逆的趨勢。玄貓認為，採納頁面物件模型不僅是技術選擇，更是專業思維的躍遷。它代表了一種對長期品質與效率的投資，是區分資深測試架構師與初階自動化工程師的關鍵分水嶺。