註冊表单是你產品的門面。它也是用户流失最多的地方，并隱藏着最隱蔽的 bug。在本教學中，你将学到一套可复用的工作流程，使用假用户資料——產生的姓名、地址、電話號碼與信箱——来測試註冊與結算表单。目標是在用户之前發現每一個邊界情况，而绝不触碰真實個人資料。

為什么假資料胜過“John Doe”

像 john@example.com 这样的硬编碼測試值是 QA 虚假信心的最大来源。它们掩盖了整整三大类 bug：

  • 重复键錯誤——同一個信箱插入两次，你才能發現唯一约束與錯誤提示是否真的触發。静态資料永远测不到。
  • 格式邊界情况——带撇号的名字（O'Brien）、带連字符的名字（Jean-Luc）、带重音的名字（Renée）。带 9 位扩展的郵遞區號（12345-6789）。带国家代碼的電話。
  • 特定州逻辑——銷售稅逻辑、地址校驗、区号长度。如果每個測試都用加利福尼亚，你就会给關岛發版一個 bug。

假資料让你在一個測試套件里跑数十种变体，而無需手写数十個夹具。

你要搭建的夹具栈

我们将組装三個协同工作的層：

  1. 資料源：真實感的假記錄。我们用 USA Data Tools 地址產生器来產生美國地址與電話，因為郵遞區號-州配對在地理上是一致的。信箱用 Faker.js 即可。
  2. 測試框架：Playwright（或 Cypress）腳本来驱动表单。
  3. 变体矩阵：一份 CSV/JSON 邊界情况記錄列表，由框架迭代执行。

第 1 步——產生一份夹具语料

打開地址產生器，選一個州（或選“任意州”覆蓋全国），批量產生 100–200 條記錄并匯出 JSON。如果你有 Pro 密钥，也可以直接从 REST API 拉取同样的資料：

curl "https://vic999.com/us-address/api/v1/address?state=CA&count=100" \
  -H "Authorization: Bearer YOUR_API_KEY" \
  -o fixtures/ca-users.JSON

有目的地混搭資料集——给每個主要州加至少一條記錄，再加几個屬地（PR、GU、VI）以抓住配送逻辑的 bug。免稅州產生器就很方便地產生德拉瓦、蒙大拿、新罕布什爾和奧勒岡的地址，让你能驗證結算里的零銷售稅分支。

第 2 步——补全信箱與密碼变体

只有地址不足以覆蓋信箱輸入的邊界情况。在你的測試配置中加入 Faker：

import { faker } from "@faker-js/faker";

function buildUser(addr) {
  return {
    ...addr,
    email: faker.internet.email({
      firstName: addr.name.split(" ")[0],
      lastName: addr.name.split(" ")[1] || "x",
    }).toLowerCase(),
    password: faker.internet.password({ length: 14 }),
  };
}

import caUsers from "./fixtures/ca-users.JSON";
export const fixtures = caUsers.map(buildUser);

現在每條記錄都有唯一信箱、强隨機密碼以及真實感的州專屬地址——註冊表单所需的一切都齐了。

第 3 步——用 Playwright 驱动表单

一個最小可用的 Playwright 用例会遍历夹具并断言成功状态：

import { test, expect } from "@playwright/test";
import { fixtures } from "./fixtures.js";

for (const user of fixtures.slice(0, 25)) {
  test(`signup accepts: ${user.zip} ${user.email}`, async ({ page }) => {
    await page.goto("/signup");

    await page.fill("#name", user.name);
    await page.fill("#email", user.email);
    await page.fill("#street", user.street);
    await page.fill("#city", user.city);
    await page.fill("#state", user.state);
    await page.fill("#zip", user.zip);
    await page.fill("#phone", user.phone);
    await page.fill("#password", user.password);

    await page.click("button[type=submit]");

    await expect(page).toHaveURL(/\/welcome/);
    await expect(page.locator(".welcome-name"))
      .toContainText(user.name.split(" ")[0]);
  });
}

測試用例標题里那個小细节很關键：它包含郵遞區號和信箱，因此当 CI 中某個用例失败时，你能直接看出表单拒绝了哪個輸入。

第 4 步——跑邊界情况矩阵

真實用户会打錯字。建一個小的、人工挑選的“异常清单”，让它走同一套框架：

場景輸入预期
9 位郵遞區號90210-1234接受并归一化為 90210
带括号的電話(415) 555-0148接受
名字带撇号O'Brien接受，并在資料函式庫中轉義
美國屬地PR + 006xx 郵遞區號按业务规则允许或拒绝配送
免稅州DE + 197xx 郵遞區號购物车合计不含銷售稅行
重复信箱已存在的一行表单显示“已註冊”行内錯誤

这個矩阵正是大多数团隊跳過的部分。它是“表单能用”與“表单可上線”之间的差别。

第 5 步——交叉驗證下游影响

表单提交成功只是開始。另一半是之后会發生什么：

  • 邮件可送達性模拟：使用 Mailtrap 等服务或一個 SMTP 接收端，让註冊邮件不会真的發到真實收件箱。
  • 校驗一致性：前端接受的同一個郵遞區號，也必须被你的地址校驗后端接受。州配對的假郵遞區號能抓住前后端不一致。
  • 账单：配合真實感地址和 測試卡号，端到端走通支付閘道沙箱流程。

矩阵能發現的常见 bug

  • 郵遞區號欄位 maxlength 設為 5，結果每個 9 位郵遞區號被移动键盘自动填充时都静默拒绝。
  • 電話欄位拒绝 +1 国际前綴，而你的宣傳文案却宣称全球可用。
  • 德拉瓦订单出現銷售稅行——因為税务引擎在比對一份過时的州列表。
  • 框架升级后簡洁的重复信箱錯誤提示消失——在用户看见前就已修好。

在 CI 里自动化

把变体矩阵接到每日建構。資料集足够小，几分鐘跑完，但价值巨大：註冊欄位中的任何回归都会以一個红测名 signup accepts: 90210-1234 user@example.com 出現，这正是凌晨两點你最想要的線索。

jobs:
  signup-matrix:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - run: npm ci
      - run: npx playwright install --with-deps
      - run: npx playwright test signup-matrix
      - uses: actions/upload-artifact@v4
        if: failure()
        with:
          name: playwright-report
          path: playwright-report/

总結

用假資料測試註冊表单不在于產生更多測試——而在于產生對的測試。一份地理一致的假資料集加上人工挑選的邊界情况矩阵，能發現任何顺景測試都發現不了的缺陷。从地址產生器匯出 100 條記錄開始，把它们丢進一個 Playwright 循环，每夜運行。第一周它就能帮你拦下一個本会上線的 bug。此后，它会持续為你回本。