QA Skills thực hành, phần 2: Playwright, API và hợp đồng giữa các dịch vụ

Sau khi hiểu yêu cầu và có ca kiểm thử rõ ràng, câu hỏi tiếp theo là nên tự động hóa phần nào. Một luồng trình duyệt có thể xác nhận người dùng thao tác được từ đầu đến cuối, nhưng việc chạy mọi biến thể dữ liệu qua giao diện thường làm phản hồi chậm và khó chẩn đoán. Phần hai của loạt QA Skills thực hành tập trung vào cách chia trách nhiệm giữa kiểm thử giao diện, API và hợp đồng.

Ví dụ xuyên suốt là ứng dụng mẫu cho phép lưu sách vào danh sách đọc sau. Các quy tắc và đoạn mã dưới đây có mục đích minh họa; bạn cần điều chỉnh theo đặc tả và môi trường của ứng dụng thực hành. Không có kết quả chạy hay tỷ lệ bao phủ nào được suy ra chỉ từ những ví dụ này.

Chọn lớp kiểm tra theo câu hỏi

Nếu câu hỏi là “Người dùng có tìm thấy nút lưu và nhận phản hồi rõ ràng không?”, kiểm tra giao diện phù hợp. Nếu câu hỏi là “Yêu cầu lưu trùng được xử lý thế nào?”, lớp API có thể cho kết quả trực tiếp hơn. Còn “Phía giao diện có tiếp tục đọc được phản hồi sau khi backend thay đổi không?” là câu hỏi về hợp đồng giữa bên sử dụng và bên cung cấp dữ liệu.

Automation Tester mô tả quá trình phân tích yêu cầu, đọc cấu trúc mã, thiết kế tình huống, tạo mã kiểm thử rồi rà soát và xác thực. Hãy giữ các bước đó trong thực hành. Việc sinh nhanh nhiều file không thay thế cho quyết định ca nào đáng tự động hóa và kết quả nào cần được khẳng định.

Chọn một hành trình ổn định, có giá trị khi chạy lại, để bắt đầu. Các quy tắc đang thay đổi mỗi ngày có thể cần được làm rõ trước. Một bài kiểm tra tự động cũng có chi phí duy trì, chuẩn bị dữ liệu và xử lý bằng chứng; số lượng test không tự phản ánh chất lượng.

Playwright: diễn đạt ý định của người dùng

Tài liệu mẫu trong nguồn ưu tiên locator theo vai trò, nhãn và nội dung mà người dùng nhận biết. Cách này giúp bài kiểm tra bám vào hành vi giao diện. Một selector dựa trên chuỗi lớp CSS trang trí có thể hỏng khi thiết kế đổi, dù chức năng vẫn hoạt động.

Ví dụ sau giả định ứng dụng mẫu có dữ liệu cố định trong môi trường thử nghiệm, đường dẫn tương ứng và trạng thái đăng nhập đã được chuẩn bị bằng fixture của dự án:

import { test, expect } from '@playwright/test';

test('lưu sách từ trang chi tiết vào danh sách đọc sau', async ({ page }) => {
  await page.goto('/books/cuon-sach-mau');
  await page.getByRole('button', { name: 'Lưu để đọc sau', exact: true }).click();
  await expect(page.getByRole('status')).toContainText('Đã lưu');

  await page.getByRole('link', { name: 'Danh sách đọc sau', exact: true }).click();
  await expect(
    page.getByRole('link', { name: 'Cuốn sách mẫu', exact: true })
  ).toHaveCount(1);
});

Đoạn mã chưa phải bộ kiểm thử có thể dùng nguyên trạng cho mọi ứng dụng. Nó không chứa bước đăng nhập, cách tạo sách hay cấu hình baseURL; các phần này phải do dự án thực hành cung cấp. Cần bảo đảm trạng thái ban đầu chưa lưu sách và dọn dữ liệu sau ca kiểm thử, hoặc dùng dữ liệu riêng để các lần chạy không ảnh hưởng nhau.

Ưu tiên chờ điều kiện quan sát được, chẳng hạn thông báo xuất hiện hay dữ liệu được hiển thị. Việc chờ một khoảng thời gian cố định chỉ vì test đôi khi chậm thường che giấu nguyên nhân bất ổn. Khi có lỗi, xem trace và thông tin mạng để phân biệt lỗi sản phẩm, lỗi chuẩn bị dữ liệu và lỗi của bài kiểm tra. Tránh tăng retry như cách mặc định để biến mọi lần chạy thành màu xanh.

API: kiểm tra cả ý nghĩa của phản hồi

API Tester tổ chức nội dung quanh OpenAPI, GraphQL, collection, xác thực schema và sinh kiểm tra. Một đặc tả API tốt là điểm bắt đầu, nhưng vẫn cần xác định quy tắc nghiệp vụ. Phản hồi có đúng dạng JSON chưa đủ chứng minh sách được lưu cho đúng tài khoản.

Với API mẫu, hãy lập bảng tình huống trước khi viết mã:

Tình huống	Câu hỏi cần được đặc tả trả lời
Yêu cầu hợp lệ	Mã trạng thái, cấu trúc phản hồi và trạng thái lưu là gì?
Dữ liệu thiếu hoặc sai kiểu	Có thông báo lỗi nhất quán và không tạo dữ liệu dở dang không?
Sách không tồn tại	API phân biệt được trường hợp này với lỗi hệ thống không?
Yêu cầu lặp lại	Thiết kế cho phép trùng, bỏ qua hay trả lỗi?
Người dùng khác	Có đọc hoặc sửa được danh sách không thuộc quyền của mình không?

Không tự áp một mã trạng thái cho mọi sản phẩm. Mã phản hồi, hành vi lặp lại và quy tắc truy cập phải dựa trên hợp đồng đã thống nhất. Khi dùng schema, kiểm tra cả kiểu, trường bắt buộc và ý nghĩa của giá trị. Một chuỗi rỗng có thể hợp lệ về kiểu nhưng vi phạm quy tắc nghiệp vụ.

Đặt token của môi trường thử nghiệm trong cơ chế quản lý bí mật của dự án, không ghi trực tiếp vào mã hoặc báo cáo. Chỉ gọi endpoint thuộc phạm vi được cấp phép, chuẩn bị dữ liệu tổng hợp và ghi lại cách dọn dẹp. Các ví dụ đường dẫn trong bài là tình huống học tập, không phải mục tiêu để gửi yêu cầu ra ngoài.

Hợp đồng: kiểm tra điều bên sử dụng thật sự cần

Contract Tester đề cập hợp đồng hướng từ consumer, trạng thái provider, Pact và kiểm tra tính tương thích khi schema thay đổi. Hình dung giao diện đang cần mã sách và tiêu đề để hiển thị danh sách. Nếu backend đổi tên trường mà không có lộ trình tương thích, từng dịch vụ có thể vượt qua kiểm thử riêng nhưng tính năng chung vẫn hỏng.

Consumer nên ghi rõ phần phản hồi mà mình phụ thuộc, với dữ liệu mẫu và matcher phù hợp. Provider phải xác minh hợp đồng trong trạng thái dữ liệu có thể tái tạo. Chỉ chạy consumer với mock chưa chứng minh backend thật đáp ứng hợp đồng; mock do chính consumer dựng lên có thể phản ánh một giả định sai.

Khi schema mới thêm trường tùy chọn, hãy xét cách consumer xử lý trường lạ. Khi xóa trường, thay kiểu hoặc thay ý nghĩa, cần xem các consumer hiện có và chính sách tương thích. Đừng kết luận chỉ bằng việc so sánh hai file rồi bỏ qua những quy tắc nghiệp vụ nằm ngoài schema.

Bài thực hành và bằng chứng cần giữ

Lấy một luồng manual từ phần đầu, viết một bài kiểm tra giao diện cho hành trình chính, một nhóm tình huống API cho quy tắc dữ liệu và một bản mô tả hợp đồng consumer cần. Ghi phiên bản ứng dụng, môi trường, lệnh thực tế đã dùng, dữ liệu ban đầu và kết quả quan sát được. Nếu phần hợp đồng mới dừng ở thiết kế, đánh dấu rõ là chưa thực thi.

Chủ đề tham khảo từ bộ AI Tester Skills. Nội dung được biên soạn lại thành hướng dẫn thực hành cho người đọc.