什麼是回歸測試？如何使用 Playwright 有效率地自動化回歸測試？

引言

「之前可以運行，為什麼現在卻不行了…」

在開發過程中，或許很多人都曾經有過這樣的經驗。

由於新增功能或修正錯誤，現有功能可能會受到影響。為了防止這種情況的發生，我們需要進行 回歸測試。

本文將解釋回歸測試的基本概念，並介紹如何使用 Playwright 進行有效的自動化測試。

什麼是回歸測試

回歸測試是指在代碼更改後，確認「現有功能是否受損」的一種測試。

「回歸（regression）」意指「後退」或「退行」，用於檢驗軟體品質是否出現退步。

為什麼需要回歸測試

在軟體開發過程中，以下類型的更改會經常發生。

新功能的添加
現有功能的修改
錯誤修正
函式庫的升級
重構

這些更改可能會無意中影響到其他現有功能。

例如，修改了登錄功能後，原本不相關的搜尋功能竟然無法運行的情況。

定期執行回歸測試可以及早發現這些問題。

手動測試 vs 自動化測試

回歸測試可以手動執行，但自動化的好處是顯著的。

觀點	手動測試	自動測試
執行速度	較慢	快速
執行成本	每次需要人力成本	初期構建後成本較低
重現性	依責任人而異	每次在相同條件下執行
執行頻率	限制在少數情況	可在 CI/CD 中每次執行

特別是由於回歸測試的性質是「重複執行相同的測試」，因此自動化的效益非常高。

使用 Playwright 的回歸測試實作

下面將解釋如何使用 Playwright 來實作回歸測試。

專案結構

為了提高測試代碼的可維護性，採用頁面物件模型（Page Object Model，POM）模式。

tests/
└── ecsite/
    ├── locators/      # 元素的定位定義
    ├── pages/         # 頁面操作類別
    └── tests/         # 測試文件

Locator 類別的實作

我們將定義各頁面的元素。

// login-page-locators.ts

export class LoginPageLocators {
  static readonly EMAIL_INPUT = 'input[name="email"];'
  static readonly PASSWORD_INPUT = 'input[name="password"];'
  static readonly SIGN_IN_BUTTON = 'button:has-text("Sign In");'
}

Page 類別的實作

將頁面操作實作為方法。

// login-page.ts

import { Page } from '@playwright/test';
import { BasePage } from '../base/base-page';
import { LoginPageLocators } from '../locators/login-page-locators';

export class LoginPage extends BasePage {
  constructor(page: Page) {
    super(page);
  }

  /**
   * 填寫電子郵件欄位
   * @param email - 要輸入的電子郵件地址
   */
  async fillEmail(email: string): Promise<void> {
    await this.page.locator(LoginPageLocators.EMAIL_INPUT).fill(email);
  }

  /**
   * 填寫密碼欄位
   * @param password - 要輸入的密碼
   */
  async fillPassword(password: string): Promise<void> {
    await this.page.locator(LoginPageLocators.PASSWORD_INPUT).fill(password);
  }

  /**
   * 點擊登錄按鈕
   */
  async clickSignIn(): Promise<void> {
    await this.page.locator(LoginPageLocators.SIGN_IN_BUTTON).click();
  }
}

測試類別的實作

我們將編寫實際的測試。

// 01-login.spec.ts

import { test, expect } from '@playwright/test';
import { MainPage } from '../pages/main-page';
import { LoginPage } from '../pages/login-page';
import { MyAccountPage } from '../pages/my-account-page';

test.describe('登錄測試套件', () => {
  test('用戶登錄流程', async ({ page }) => {
    const mainPage = new MainPage(page);
    const loginPage = new LoginPage(page);
    const myAccountPage = new MyAccountPage(page);

    // 測試數據
    const testEmail = '[email protected]';
    const testPassword = 'P@ssw0rd';
    const expectedFullName = '測試用戶';

    // 1. 瀏覽到首頁
    await mainPage.goto();

    // 2. 點擊帳號圖示以導航到登錄頁
    await mainPage.clickAccountIcon();

    // 3. 填寫憑證
    await loginPage.fillEmail(testEmail);
    await loginPage.fillPassword(testPassword);

    // 4. 點擊登錄
    await loginPage.clickSignIn();

    // 5. 驗證是否導向到我的帳號頁
    await mainPage.clickAccountIconMyAccount();
    await expect(myAccountPage.getFullNameValue()).toContainText(expectedFullName);
  });
});

回歸測試的執行策略

每次執行所有測試可能效率不高，因此應根據情況考量執行策略。

根據修改範圍進行判斷

根據修改內容決定測試的執行範圍。
以下是一些示例。

修改內容	測試執行範圍
登錄功能的修改	所有登錄相關測試 + 主要功能的正常情況
搜尋功能的修改	所有搜尋相關測試 + 主要功能的正常情況
函式庫升級	全部測試執行
上線前	全部測試執行