Các bài kiểm thử Playwright của bạn đã vượt qua. Nút đăng nhập nhấp được, bảng điều khiển hiển thị, biểu đồ vẽ được. Sau đó, một khách hàng báo lỗi: các số liệu trên biểu đồ bị sai. Bạn tìm hiểu và phát hiện ra rằng API đã trả về trạng thái 200 với một payload bị lỗi, và bộ kiểm thử end-to-end của bạn không bao giờ nhận ra điều đó vì nó chỉ kiểm tra xem các pixel có xuất hiện trên màn hình hay không. Đây là khoảng trống mà các bài kiểm thử trình duyệt đơn thuần không thể lấp đầy, và đây là lúc các khẳng định API trở nên không thể thiếu. Các công cụ như Apidog cung cấp cho bạn cách để xác thực các hợp đồng, lược đồ và ngữ nghĩa phản hồi của API với sự chặt chẽ tương tự như cách bạn kiểm thử luồng UI, sau đó chạy cả hai bộ kiểm thử cùng lúc trong CI.
TL;DR (Tóm tắt)
Bạn có thể xác thực API trong các bài kiểm thử Playwright bằng cách kết hợp fixture request và bộ chặn page.route của Playwright với các kịch bản Apidog nhắm vào cùng một đặc tả OpenAPI. Chia sẻ các fixture thông qua một tệp đặc tả duy nhất, khẳng định lược đồ phản hồi ở cả hai lớp, và chạy cả hai bộ kiểm thử trong một công việc CI để một thay đổi hợp đồng sẽ nhanh chóng bị phát hiện ở một trong hai nơi.
Giới thiệu
Playwright là framework tự động hóa trình duyệt mặc định cho nhiều nhóm vào năm 2026, và tài liệu Playwright làm cho việc kiểm thử API có vẻ dễ dàng: vài lệnh gọi request.get, một expect(response.status()).toBe(200), và bạn đã hoàn thành. Vấn đề bắt đầu khi bạn mở rộng nó. Bạn sẽ có hàng trăm bài kiểm thử chỉ kiểm tra mã trạng thái mà không kiểm tra hình dạng phản hồi, không có nguồn thông tin đáng tin cậy chung giữa các luồng trình duyệt và luồng API của bạn, và không có cách nào để mô phỏng API ngoại tuyến khi hệ thống phụ trợ chậm hoặc bị hỏng.
Cách khắc phục rất đơn giản. Coi đặc tả OpenAPI của bạn như một hợp đồng, điều khiển các lệnh gọi request của Playwright và bộ chặn page.route từ hợp đồng đó, và chạy một bộ kịch bản Apidog đối với cùng một đặc tả để xác thực lược đồ chuyên sâu, logic nghiệp vụ và các yêu cầu được nối tiếp. Bạn nhận được phản hồi nhanh chóng trong CI, ranh giới sở hữu rõ ràng giữa các bài kiểm thử frontend và backend, và không có fixture trùng lặp nào. Nếu bạn muốn cài đặt công cụ trước, Tải Apidog và quay lại; các bước dưới đây giả định rằng nó đã có sẵn cục bộ.
Đây là những gì bạn sẽ nhận được từ bài viết này: một mô hình tư duy rõ ràng về vị trí của các khẳng định API trong một bộ Playwright, một mẫu request.fixture hoạt động, thiết lập từng bước để chia sẻ các fixture giữa Playwright và Apidog, các mẹo nâng cao cho CI và mocking, và một bảng so sánh các lựa chọn thay thế chính. Để có cái nhìn rộng hơn về các lựa chọn công cụ kiểm thử, hãy xem quan điểm của chúng tôi về các công cụ kiểm thử API dành cho kỹ sư QA.
Khoảng cách giữa các bài kiểm thử Playwright và các khẳng định API
Một bài kiểm thử Playwright điển hình sẽ đăng nhập, điều hướng đến một trang và khẳng định rằng một số phần tử UI hiển thị được. Điều đó cho bạn biết luồng hiển thị cho người dùng hoạt động. Nó không cho bạn biết gì về API phía sau. Ba chế độ lỗi sau đây có thể bị bỏ qua:
Đầu tiên, suy giảm hình dạng payload. Endpoint trả về 200 với một trường được đổi tên từ total_count thành totalCount. UI có thể tự động ép kiểu hoặc hiển thị số không một cách lặng lẽ. Bài kiểm thử Playwright của bạn thấy một con số trên màn hình và vượt qua.
Thứ hai, sai lệch logic nghiệp vụ. Một endpoint giảm giá áp dụng mức giảm 10 phần trăm thay vì 15 phần trăm như hợp đồng. UI hiển thị bất cứ thứ gì API trả về, vì vậy bài kiểm thử vượt qua. Chỉ có nhóm tài chính mới nhận ra, vài tuần sau đó.
Thứ ba, phạm vi đường dẫn lỗi. Các bài kiểm thử Playwright hầu như luôn chạy theo kịch bản 'happy path' (đường dẫn thành công). API của bạn có hàng tá nhánh 4xx và 5xx: giới hạn tần suất, token hết hạn, lỗi một phần, xung đột idempotency. Không có lỗi nào trong số đó được kiểm tra trừ khi bạn viết một bộ kiểm thử API riêng biệt.
Bạn có thể khắc phục một phần điều này bằng cách thêm các lệnh gọi request.get vào bên trong các đặc tả Playwright của bạn và khẳng định nội dung phản hồi. Điều đó hiệu quả cho một số ít endpoint. Nó sẽ thất bại khi bạn có 200 endpoint và muốn các kịch bản được nối tiếp như “tạo đơn hàng, lấy đơn hàng, hủy đơn hàng, xác minh webhook hoàn tiền.” Playwright trước hết là một framework tự động hóa trình duyệt; nó không được xây dựng cho các luồng công việc API có trạng thái hoặc tính dễ sử dụng của các khẳng định cấp độ lược đồ. Đó là lúc một công cụ kiểm thử API chuyên dụng phát huy giá trị.
Cách phân chia hợp lý là:
- Các bài kiểm thử Playwright xác minh luồng UI, chặn mạng và một lớp mỏng các kiểm tra API smoke test tại ranh giới của một hành động người dùng.
- Các kịch bản Apidog xác minh sự tuân thủ lược đồ, luồng công việc API nối tiếp, tuân thủ hợp đồng và các đường dẫn lỗi một cách chuyên sâu.
Cả hai bộ kiểm thử đều sử dụng cùng một đặc tả OpenAPI để bạn không bao giờ có hai phiên bản sự thật. Để có cái nhìn sâu hơn về cách tiếp cận hợp đồng-trước (contract-first), bài viết của chúng tôi về công cụ phát triển API thiết kế-trước sẽ giải thích lý do tại sao đặc tả phải là yếu tố dẫn đầu.
Đối với các nhóm đã sử dụng Postman và đang cân nhắc chuyển đổi, các lựa chọn thay thế Postman tự lưu trữ sẽ đề cập đến cơ chế di chuyển.
Cách chia sẻ fixture giữa Playwright và Apidog
Nguồn thông tin đáng tin cậy duy nhất là đặc tả OpenAPI của bạn, thường là openapi.yaml hoặc openapi.json tại thư mục gốc của kho lưu trữ. Playwright đọc nó để có các helper yêu cầu được đánh máy và các payload ví dụ; Apidog nhập trực tiếp nó để điền vào các bước kịch bản. Bất cứ khi nào backend có sự thay đổi hợp đồng, cả hai bộ kiểm thử sẽ nhận diện được.
Bắt đầu với một thư mục fixtures/ chứa dữ liệu kiểm thử có thể tái sử dụng: người dùng, token, payload mẫu. Xây dựng một tệp fixture Playwright tải chúng và hiển thị chúng cho các bài kiểm thử:
// tests/fixtures/api.ts
import { test as base, APIRequestContext, expect } from '@playwright/test';
import { readFileSync } from 'fs';
import path from 'path';
type ApiFixtures = {
apiRequest: APIRequestContext;
authToken: string;
sampleOrder: Record<string, unknown>;
};
export const test = base.extend<ApiFixtures>({
apiRequest: async ({ playwright }, use) => {
const ctx = await playwright.request.newContext({
baseURL: process.env.API_BASE_URL ?? 'https://api.staging.example.com',
extraHTTPHeaders: {
'Accept': 'application/json',
'Content-Type': 'application/json',
},
});
await use(ctx);
await ctx.dispose();
},
authToken: async ({ apiRequest }, use) => {
const res = await apiRequest.post('/auth/token', {
data: { email: 'qa@example.com', password: process.env.QA_PASSWORD },
});
expect(res.status()).toBe(200);
const body = await res.json();
await use(body.access_token);
},
sampleOrder: async ({}, use) => {
const raw = readFileSync(
path.join(__dirname, '..', '..', 'fixtures', 'order.json'),
'utf8',
);
await use(JSON.parse(raw));
},
});
export { expect };
Bây giờ bạn nhập test từ tệp fixture này thay vì @playwright/test trong mỗi đặc tả, và bạn có một `apiRequest` đã được định kiểu, một `authToken` mới, và dữ liệu `sampleOrder` sẵn sàng sử dụng. Tệp order.json là payload tương tự mà Apidog sử dụng làm nội dung ví dụ cho POST /orders trong các kịch bản của bạn. Chỉnh sửa một lần, cả hai bộ kiểm thử đều thay đổi.
Về phía Apidog, mở dự án, nhấp vào “Import” (Nhập), và trỏ nó đến cùng tệp openapi.yaml. Apidog tạo các endpoint, ví dụ yêu cầu và lược đồ tham số trong vài giây. Sau đó, lưu các payload fixture của bạn dưới dạng “Biến môi trường” (Environment Variables) hoặc “Tập dữ liệu” (Data Sets) của Apidog:
// tests/orders.spec.ts
import { test, expect } from './fixtures/api';
test('POST /orders returns a valid order with 15 percent discount', async ({
apiRequest,
authToken,
sampleOrder,
}) => {
const res = await apiRequest.post('/orders', {
headers: { Authorization: `Bearer ${authToken}` },
data: { ...sampleOrder, coupon: 'SAVE15' },
});
expect(res.status()).toBe(201);
const body = await res.json();
expect(body).toMatchObject({
id: expect.any(String),
status: 'pending',
discount_pct: 15,
total_cents: expect.any(Number),
});
expect(body.total_cents).toBeLessThan(sampleOrder.subtotal_cents);
});
Trong Apidog, bước kịch bản tương ứng sẽ gửi cùng một payload, sau đó chạy kiểm tra Lược đồ JSON tích hợp đối với thành phần Order trong openapi.yaml. Điều đó mang lại cho bạn sự chuyên sâu: mọi trường đều được kiểm tra kiểu, các trường bắt buộc được xác minh, các giá trị enum được thực thi. Playwright bắt các khẳng định ngữ nghĩa có giá trị cao (discount_pct: 15); Apidog bắt mọi trường bị sai lệch, ngay cả những trường bạn quên khẳng định thủ công. Nếu bạn mới làm quen với kiểm thử dựa trên đặc tả, hướng dẫn của chúng tôi về luồng công việc API thiết kế-trước sẽ cho thấy mô hình tổng thể.
Đối với các nhóm đã sử dụng Postman và đang cân nhắc chuyển đổi, các lựa chọn thay thế Postman tự lưu trữ sẽ đề cập đến cơ chế di chuyển.
Thiết lập quy trình làm việc Apidog + Playwright
Đây là một thiết lập sạch sẽ, có thể lặp lại giúp bạn từ con số không đến CI với hai bộ kiểm thử chỉ trong khoảng một giờ.
Bước 1: Một đặc tả để kiểm soát tất cả. Đặt openapi.yaml tại thư mục gốc của kho lưu trữ. Coi nó như mã: yêu cầu đánh giá PR, các thay đổi gây phá vỡ yêu cầu tăng phiên bản chính. Nếu bạn chưa có, hãy tạo một bản nháp từ các tuyến hiện có của bạn bằng cách sử dụng một plugin framework (FastAPI, NestJS và các framework khác phát ra OpenAPI nguyên bản), sau đó chỉnh sửa thủ công. Apidog cũng có thể thiết kế ngược một đặc tả từ lưu lượng truy cập nếu bạn nhập một tệp HAR.
Bước 2: Kết nối Playwright. Cài đặt Playwright (npm init playwright@latest) và thêm tệp fixture đã được hiển thị ở trên. Thêm một script npm run test:e2e và một tệp playwright.config.ts trỏ đến môi trường staging của bạn. Giữ các bài kiểm thử nhỏ gọn; một kịch bản cho mỗi đặc tả.
Bước 3: Thêm lớp kịch bản Apidog. Bên trong dự án Apidog của bạn, nhập openapi.yaml, sau đó xây dựng một kịch bản cho mỗi hành trình người dùng quan trọng: đăng ký, thanh toán, hoàn tiền, gửi webhook, v.v. Mỗi kịch bản là một chuỗi các lệnh gọi API với các khẳng định được nối tiếp nhau. Apidog hỗ trợ các biến môi trường, script tiền yêu cầu và khẳng định hậu phản hồi. Xuất kịch bản dưới dạng JSON có thể chạy bằng CLI thông qua Apidog CLI (apidog-cli run scenario.json).
Bước 4: Chặn mạng trong Playwright. Khi UI tìm nạp dữ liệu mà bạn không muốn truy cập trực tiếp, hãy sử dụng page.route để chặn và giả lập. Các phản hồi giả lập đến từ cùng các tệp fixture, vì vậy hợp đồng vẫn nhất quán:
test('dashboard renders cached order list when offline', async ({
page,
sampleOrder,
}) => {
await page.route('**/api/orders', async (route) => {
await route.fulfill({
status: 200,
contentType: 'application/json',
body: JSON.stringify({ orders: [sampleOrder] }),
});
});
await page.goto('/dashboard');
await expect(page.getByTestId('order-row')).toHaveCount(1);
});
Sau đó trong Apidog, chạy cùng kịch bản GET /orders đối với backend thực tế của bạn hoặc đối với máy chủ mock của Apidog. Cùng một fixture, hai lớp xác minh.
Bước 5: Tích hợp CI. Thêm một quy trình làm việc GitHub Actions chạy cả hai bộ kiểm thử song song:
name: tests
on: [push, pull_request]
jobs:
playwright:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v4
- uses: actions/setup-node@v4
with: { node-version: '20' }
- run: npm ci
- run: npx playwright install --with-deps
- run: npx playwright test
apidog:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v4
- uses: actions/setup-node@v4
with: { node-version: '20' }
- run: npm i -g apidog-cli
- run: apidog-cli run ./apidog/scenarios/checkout.json --reporters cli,junit
Nếu một trong hai công việc thất bại sẽ chặn việc hợp nhất (merge). Sử dụng --reporters junit để GitHub chú thích các khẳng định thất bại ngay trên PR. Tài liệu GitHub Actions bao gồm các bản dựng ma trận và bộ nhớ đệm nếu bạn muốn mở rộng quy mô này. Đối với các nhóm không có chức năng QA chuyên trách, hướng dẫn về công cụ kiểm thử API dành cho kỹ sư QA giải thích cách gán quyền sở hữu cho mỗi bộ kiểm thử.
Bước 6: Phát hiện sai lệch. Lên lịch một công việc hàng ngày để so sánh tệp openapi.yaml trực tiếp của bạn với phiên bản mà các bài kiểm thử của bạn đã chạy gần đây nhất. Nếu một trường thay đổi kiểu, việc so sánh sẽ làm lỗi bản dựng trước khi bất kỳ bài kiểm thử nào được chạy. Điều này bắt lỗi thuộc loại “200 OK với payload sai” mà chúng ta đã mở đầu bài viết.
Các kỹ thuật nâng cao và mẹo chuyên nghiệp
Một vài động thái mang lại lợi ích sau khi thiết lập cơ bản đang hoạt động.
Ghim trình xem dấu vết Playwright. Đặt trace: 'on-first-retry' trong playwright.config.ts. Khi một bài kiểm thử không ổn định (flaky test) thất bại trong CI, bạn sẽ có một dòng thời gian đầy đủ của các lệnh gọi mạng, ảnh chụp nhanh DOM và nhật ký console. Kết hợp nó với apidog-cli --report html cho phía API. Cùng nhau, chúng cho bạn biết liệu UI bị lỗi trước hay API bị sai lệch.
Sử dụng máy chủ mock Apidog cho các lần chạy ngoại tuyến. Apidog có thể khởi động một máy chủ mock từ đặc tả OpenAPI của bạn chỉ với một cú nhấp chuột. Trỏ môi trường phát triển cục bộ của bạn vào nó khi nhóm backend đang triển khai hoặc cơ sở dữ liệu staging đang được thiết lập lại. Bộ Playwright của bạn chạy thành công với mock, và các kịch bản Apidog của bạn xác minh backend thực tế song song. Để biết thêm về mô hình này, hãy xem bài viết của chúng tôi về tạo kiểm thử API có hỗ trợ AI, nơi các mock đóng vai trò trung tâm.
Giới hạn số lần thử lại là hai. retries: 2 trong playwright.config.ts. Nếu một bài kiểm thử cần ba lần thử lại để vượt qua, nó không ổn định và bạn đang gặp vấn đề thực sự. Đừng che đậy nó bằng retries: 5. Điều tương tự cũng áp dụng cho các kịch bản Apidog: đặt retry: 1 cho mỗi yêu cầu, tối đa.
Thất bại nếu có sự sai lệch lược đồ. Khi Apidog phát hiện sự không khớp lược đồ, mặc định hãy thoát với mã lỗi khác 0. Đừng để một cảnh báo bị bỏ qua. Nếu bạn phải cho phép một khoảng thời gian thất bại mềm, hãy kiểm soát nó bằng một biến môi trường như ALLOW_SCHEMA_DRIFT=true và yêu cầu một bình luận trên PR giải thích lý do.
Gắn thẻ các bài kiểm thử theo mức độ ưu tiên. Sử dụng test.describe.configure({ mode: 'serial' }) của Playwright cho các luồng có trạng thái và gắn thẻ các luồng khác bằng @smoke, @regression, @nightly. Chạy smoke test trên mỗi lần đẩy mã, regression test trên các PR vào nhánh chính, nightly test trên toàn bộ bộ kịch bản Apidog. Tiết kiệm thời gian CI mà không mất đi độ bao phủ.
Những sai lầm phổ biến cần tránh:
- Chỉ khẳng định
status === 200. Hãy thêm ít nhất một kiểm tra trường body. - Mã hóa cứng các bearer token trong fixture. Sử dụng
beforeAllđể lấy token mới. - Để Playwright và Apidog nhập các tệp fixture khác nhau. Chỉ một nguồn duy nhất, chấm hết.
- Bỏ qua Apidog CLI trong CI vì “công cụ UI là đủ tốt.” Không phải vậy; CLI mới là thứ làm lỗi bản dựng.
- Coi các giả lập
page.routenhư một sự thay thế cho các bài kiểm thử API thực tế. Chúng dùng để cách ly, không phải để bao phủ.
Đối với các nhóm tạo kiểm thử bằng AI, hướng dẫn cách kiểm thử API của tác nhân AI đề cập đến các trường hợp không xác định cần được chú ý đặc biệt.
Các lựa chọn thay thế và so sánh công cụ
Một số sự kết hợp công cụ có thể xác thực API cùng với các bài kiểm thử trình duyệt. Dưới đây là cách các lựa chọn chính được so sánh.
| Stack | Điểm mạnh | Điểm yếu | Tốt nhất cho |
|---|---|---|---|
Playwright một mình (fixture request) |
Một công cụ, nhanh, tích hợp với bộ kiểm thử | Xác thực lược đồ hời hợt, không có kịch bản nối tiếp, độ bao phủ đường dẫn lỗi yếu | Các nhóm nhỏ, API đơn giản |
| Playwright + Postman | Hệ sinh thái Postman trưởng thành, Newman CLI | Hai nguồn thông tin đáng tin cậy, các collection Postman có thể sai lệch so với OpenAPI, trả phí cho cộng tác | Các nhóm đã quen thuộc với Postman |
| Playwright + Apidog | Một nguồn OpenAPI duy nhất, xác thực lược đồ, mock, CLI cho CI, quy trình làm việc thiết kế-trước | Hai công cụ cần học, đòi hỏi kỷ luật đặc tả | Các nhóm muốn kiểm thử dựa trên đặc tả, độ bao phủ đầy đủ |
| Cypress + plugin cy-api | Quen thuộc với các nhóm dùng Cypress | Cypress chỉ chạy trong trình duyệt; kiểm thử API bị hạn chế; plugin kém hoàn thiện hơn | Các codebase Cypress hiện có |
| Pact (hợp đồng định hướng người tiêu dùng) | Đảm bảo hợp đồng mạnh mẽ giữa các dịch vụ | Đường cong học tập dốc, hạ tầng broker, không tập trung vào UI | Tổ chức microservice có nhiều người tiêu dùng API nội bộ |
Nếu bạn đến từ các công cụ thời SOAP cũ hơn, các bài viết của chúng tôi về các lựa chọn thay thế script Groovy của SoapUI và các lựa chọn thay thế ReadyAPI sẽ đề cập đến lộ trình di chuyển. Đối với các luồng công việc ưu tiên cục bộ, các tiện ích mở rộng VSCode dành cho REST client rất đáng đọc.
Sự kết hợp Playwright + Apidog là lựa chọn hàng đầu cho các nhóm có đặc tả OpenAPI, triển khai nhiều dịch vụ và muốn một pipeline CI duy nhất bắt được cả lỗi hồi quy UI và API mà không phải trả tiền cho hai tài khoản SaaS cho mỗi kỹ sư.
Các trường hợp sử dụng thực tế
Thanh toán thương mại điện tử. Một nhóm bán lẻ chạy các bài kiểm thử Playwright cho luồng từ giỏ hàng đến xác nhận và các kịch bản Apidog cho chuỗi API ý định thanh toán, kiểm tra gian lận và giảm hàng tồn kho. Khi cổng thanh toán chuyển đổi một trường phản hồi từ error_code sang errorCode, Apidog đã phát hiện ra trong 90 giây; Playwright sẽ chỉ hiển thị màn hình “thanh toán thất bại” chung chung và mất hàng giờ để phân loại.
Bảng điều khiển SaaS với dữ liệu biểu đồ. Một sản phẩm phân tích B2B xác thực việc hiển thị UI bằng Playwright snapshots và sử dụng Apidog để khẳng định rằng các endpoint tổng hợp trả về tổng, phần trăm và chuỗi theo khung thời gian chính xác. Một lỗi khi endpoint độ trễ p99 lặng lẽ bỏ qua các giá trị ngoại lệ đã được phát hiện ở lớp API; biểu đồ trông vẫn ổn.
Quy trình làm việc dựa trên Webhook. Một nhóm fintech sử dụng Playwright cho cổng thông tin hướng người dùng và các kịch bản Apidog cho việc gửi webhook, logic thử lại và tính bất biến (idempotency). Scripting của Apidog xác minh rằng các ID webhook trùng lặp bị từ chối, chữ ký được xác thực và cửa sổ nhất quán cuối cùng nằm dưới 30 giây.
Kết luận
Playwright rất xuất sắc trong các luồng trình duyệt. Nó không được xây dựng để kiểm thử API chuyên sâu. Kết hợp nó với Apidog mang lại cho bạn:
- Một đặc tả OpenAPI làm hợp đồng giữa cả hai bộ kiểm thử.
- Các fixture được chia sẻ để dữ liệu kiểm thử không bao giờ bị sai lệch.
- Xác thực cấp độ lược đồ trên mọi endpoint, vượt xa chỉ mã trạng thái.
- Máy chủ mock cho phát triển ngoại tuyến.
- Một pipeline CI duy nhất thất bại nếu có lỗi hồi quy UI hoặc API.
- Chặn mạng trong Playwright, chuỗi kịch bản chuyên sâu trong Apidog.
- Sở hữu rõ ràng: kỹ sư UI sở hữu các đặc tả Playwright, kỹ sư API sở hữu các kịch bản Apidog.
Bắt đầu với một hành trình quan trọng, như thanh toán hoặc đăng ký. Kết nối fixture Playwright, xây dựng kịch bản Apidog tương ứng, chạy cả hai trong CI. Phát triển từ đó. Tải Apidog, nhập đặc tả OpenAPI của bạn, và bạn có thể chạy kịch bản đầu tiên ngay hôm nay.
Câu hỏi thường gặp (FAQ)
Tôi có thể xác thực API trong các bài kiểm thử Playwright mà không cần Apidog không? Có, bằng cách sử dụng fixture request của Playwright và các lệnh gọi expect thủ công. Bạn sẽ bao phủ mã trạng thái và một vài trường body. Để xác thực lược đồ, các kịch bản nối tiếp, mock và độ bao phủ đường dẫn lỗi ở quy mô lớn, một công cụ chuyên dụng như Apidog nhanh hơn và tạo ra ít kết quả dương tính giả hơn. Xem so sánh công cụ kiểm thử API dành cho kỹ sư QA của chúng tôi để biết các đánh đổi.
Tôi có cần đặc tả OpenAPI để sử dụng thiết lập này không? Bạn cần một cái để có được lợi ích đầy đủ. Nếu không có đặc tả, bạn vẫn có thể chạy Playwright và Apidog song song, nhưng bạn sẽ mất đi nguồn thông tin đáng tin cậy chung và phải duy trì các payload ví dụ ở hai nơi. Việc tạo một đặc tả từ các tuyến hiện có mất một hoặc hai ngày.
Tôi xử lý xác thực giữa cả hai công cụ như thế nào? Sử dụng bước beforeAll để tìm nạp một token mới từ endpoint xác thực của bạn, sau đó lưu trữ nó trong một fixture Playwright và một biến môi trường Apidog. Xoay vòng token theo mỗi lần chạy kiểm thử để các token cũ không bao giờ gây ra lỗi không ổn định.
Các kịch bản Apidog có thể thay thế hoàn toàn Playwright không? Không. Apidog rất xuất sắc trong các luồng công việc API nhưng không hiển thị trình duyệt. Đối với các khẳng định UI (văn bản hiển thị, bố cục, luồng nhấp chuột) bạn vẫn cần Playwright. Hai công cụ này bao phủ các bề mặt khác nhau.
Điều gì sẽ xảy ra nếu backend của tôi không có môi trường staging ổn định? Sử dụng máy chủ mock tích hợp của Apidog. Nó khởi động một mock có trạng thái từ đặc tả OpenAPI của bạn chỉ với một cú nhấp chuột, trả về các phản hồi ví dụ được định nghĩa trong đặc tả. Bộ Playwright và các kịch bản Apidog của bạn đều chạy thành công với mock, và bạn chuyển lại sang backend thực tế khi staging ổn định.
Làm thế nào để tôi giữ CI nhanh chóng khi bộ kiểm thử phát triển? Gắn thẻ các bài kiểm thử theo mức độ ưu tiên và chỉ chạy @smoke trên mỗi lần đẩy mã. Chạy toàn bộ bộ kiểm thử regression và kịch bản Apidog trên các PR vào nhánh chính và theo lịch trình hàng đêm. Song song hóa Playwright với workers: 4 và các kịch bản Apidog với cờ --parallel của CLI.
Tôi có cần gói Apidog trả phí cho CI không? Apidog CLI chạy cục bộ và trong CI mà không cần cấp phép người dùng cho việc thực thi kịch bản. Kiểm tra trang giá hiện tại trước khi triển khai ở quy mô lớn. Gói miễn phí bao gồm hầu hết các nhóm nhỏ.