Học Tester ở đâu tốt và thực chiến?

CyberSoft Tester cung cấp lộ trình học kiểm thử phần mềm từ cơ bản đến nâng cao: manual testing, automation với Playwright/Selenium, kiểm thử API, performance và AI testing, bám sát công việc thật của doanh nghiệp.

Người mới, chưa biết gì có học Tester được không?

Được. Lộ trình bắt đầu từ khái niệm test case, bug report rồi nâng dần lên automation và AI testing, kèm luyện phỏng vấn và CV để đi làm được.

AI Testing là gì và học như thế nào?

AI Testing là việc dùng AI (như Claude) để sinh test case, review, tăng độ phủ và tăng tốc kiểm thử. CyberSoft Tester có chuyên mục AI trong Testing và AI Agent trong Testing.

Có luyện thi ISTQB và phỏng vấn không?

Có. Nền tảng có ngân hàng câu hỏi ISTQB tự chấm, luyện phỏng vấn QA và mock interview mô phỏng thực tế.

Kiểm thử API là gì và khác gì với kiểm thử giao diện (UI)?

Kiểm thử API là gọi trực tiếp vào các endpoint của server (ví dụ GET /products/1024) mà không thông qua giao diện, rồi kiểm tra status code và dữ liệu trả về (body) có đúng như mong đợi hay không. Khác với kiểm thử UI phải mở trình duyệt, tải trang, bấm nút rồi mới thấy kết quả, kiểm thử API chạy nhanh hơn nhiều và cho biết chính xác lỗi nằm ở tầng dữ liệu hay tầng hiển thị.

Vì sao nên kiểm thử API bằng Playwright request thay vì chỉ dùng Postman thủ công?

Postman rất tốt để khám phá API và kiểm tra thủ công từng request, nhưng phải bấm tay mỗi lần. Playwright request cho phép viết các request đó thành code, chạy tự động, lặp lại nhiều lần, gắn vào CI/CD, và kết hợp cùng bộ test UI trong cùng một dự án automation — điều Postman thủ công không làm được nếu không cấu hình thêm.

Status code và kiểm tra body/schema khác nhau thế nào khi test API?

Status code cho biết KẾT QUẢ tổng quát của request (thành công, thiếu xác thực, lỗi server...) mà không cần đọc dữ liệu bên trong. Kiểm tra body/schema đi sâu hơn: xác nhận từng trường dữ liệu có tồn tại, đúng kiểu, đúng giá trị mong đợi hay không. Một API vẫn có thể trả status 200 (thành công về mặt kỹ thuật) nhưng body lại sai hoàn toàn về mặt nghiệp vụ — vì vậy cần kiểm cả hai, không chỉ một trong hai.

Trong kiểm thử API, status code 401 thường có nghĩa là gì? A. Yêu cầu thiếu hoặc sai thông tin xác thực (chưa đăng nhập/token sai) B. Server gặp lỗi nội bộ, không xử lý được yêu cầu C. Tài nguyên được yêu cầu không tồn tại D. Yêu cầu thành công và đã tạo dữ liệu mới

✅ Đáp án: A. 401 Unauthorized nghĩa là thiếu/sai xác thực — khác với 403 (đủ xác thực nhưng không đủ quyền) và 404 (không tìm thấy tài nguyên).

Trong Playwright, fixture nào được dùng để gọi API trực tiếp mà không cần mở trình duyệt? A. page B. request C. browser D. context

✅ Đáp án: B. Fixture 'request' trong test callback (async ({ request }) => {...}) cho phép gọi API trực tiếp, độc lập với trình duyệt.

Vì sao chỉ kiểm expect(res.status()).toBe(200) là CHƯA đủ để khẳng định API đúng? A. Vì status code luôn sai trong môi trường staging B. Vì status 200 chỉ cho biết request được xử lý, không đảm bảo dữ liệu trong body đúng nghiệp vụ C. Vì Playwright không hỗ trợ đọc status code D. Vì mọi API đều trả về status 200 bất kể có lỗi hay không

✅ Đáp án: B. Một API có thể 'khoẻ mạnh' về kỹ thuật (luôn trả 200) nhưng vẫn trả sai dữ liệu — như ca lỗi cache trả nhầm sản phẩm ở tình huống trong bài.

Trong ví dụ POST /orders của ShopEasy, mã trạng thái phù hợp khi tạo đơn hàng thành công là gì? A. 200 OK B. 201 Created C. 204 No Content D. 302 Found

✅ Đáp án: B. 201 Created thường dùng khi request tạo mới thành công một tài nguyên — ở đây là đơn hàng mới.

Cách nào ĐÚNG để gửi token xác thực khi gọi request.post() bằng Playwright? A. Viết token trực tiếp vào URL dưới dạng query string B. Thêm vào headers: { Authorization: `Bearer ${token}` } C. Không cần gửi gì, Playwright tự thêm token D. Gửi token trong phần data cùng với productId

✅ Đáp án: B. Token xác thực nên gửi qua header Authorization dạng Bearer, tách biệt khỏi body dữ liệu nghiệp vụ và không lộ trên URL.

Kiểm thử API tự động cơ bản cho người mới: request, response, status code (có code chạy được)

Bài cho người mới: kiểm thử API tự động qua app TMĐT ShopEasy bằng Playwright request. Status code thường gặp, cách viết GET/POST, kiểm body/schema, header & token xác thực, hai tình huống thật (status 200 nhưng dữ liệu sai, script bỏ qua status code khiến bug 500 lọt qua), nhiều mockup giao diện, FAQ và trắc nghiệm 5 câu. Chuẩn SEO, dẫn về khóa Tester CyberSoft.

1. Tóm tắt nhanh & màn hình bạn sẽ test

⭐ TL;DR — Kiểm thử API là gọi trực tiếp vào các endpoint của server (không qua giao diện) để kiểm tra status code, dữ liệu trả về (body) và các trường hợp xác thực (token) có đúng như tài liệu API mô tả hay không. Bài này dùng app TMĐT ShopEasy: API xem chi tiết sản phẩm (GET) và API tạo đơn hàng (POST). Bạn sẽ học các status code thường gặp, cách viết request bằng Playwright request, kiểm body/schema, header/token, và 2 tình huống thực tế khi bug lọt qua vì chỉ kiểm status code mà bỏ qua body. Kiểm thử API tự động thường nhanh hơn kiểm UI hàng chục lần vì không cần tải giao diện.

Chào bạn mới! Nếu bạn từng test bằng cách bấm nút trên giao diện, chờ trang tải, rồi mới nhìn kết quả — kiểm thử API sẽ là một trải nghiệm hoàn toàn khác: bạn gọi thẳng vào 'cửa sau' của hệ thống, nơi giao diện lấy dữ liệu để hiển thị. ShopEasy có hai API tiêu biểu ta sẽ dùng xuyên suốt bài: GET /products/{id} trả chi tiết một sản phẩm, và POST /orders tạo một đơn hàng mới. Cả hai đều trả về một mã trạng thái (status code) và một khối dữ liệu JSON (body). Học cách kiểm cả hai phần này chính là kỹ năng nền tảng đầu tiên của kiểm thử API tự động.

Kết quả gọi GET /products/1024: status 200, thời gian phản hồi 86ms, body JSON trả về chi tiết sản phẩm

📖 API: cách để hai phần mềm 'nói chuyện' với nhau qua các endpoint (địa chỉ) cố định, gửi request và nhận về response, không cần thông qua giao diện người dùng.

CyberSoft Academy dạy kiểm thử API & automation bài bản từ zero tới đi làm — nếu muốn có lộ trình đầy đủ hơn bài viết này, có thể tham khảo khóa Software Testing chuyên nghiệp tại https://cybersoft.edu.vn/software-testing-chuyen-nghiep-tu-zero-toi-duoc-nhan-viec-manual-automation-testing/ .

2. Vấn đề: chỉ kiểm qua giao diện là chưa đủ

Nhiều bạn mới học tester chỉ quen kiểm tra qua giao diện: mở trình duyệt, bấm nút 'Xem sản phẩm', chờ trang tải, rồi nhìn xem giá tiền hiển thị có đúng không. Cách này chạy được, nhưng có hai vấn đề. Thứ nhất, nó CHẬM — mỗi lần kiểm tra phải tải cả trang, hình ảnh, CSS, JavaScript, dù bạn chỉ cần biết đúng một con số: giá sản phẩm. Thứ hai, nó GIÁN TIẾP — nếu giao diện có lỗi hiển thị (ví dụ CSS che mất giá), bạn không phân biệt được lỗi nằm ở API trả sai dữ liệu, hay chỉ do giao diện vẽ sai.

Kết quả một lần chạy bộ test API ShopEasy: 48 request, thời gian trung bình chỉ 92ms — nhanh hơn kiểm qua giao diện rất nhiều

💡 Kiểm thử API không thay thế hoàn toàn kiểm thử UI, mà bổ sung một tầng nhanh và chính xác hơn để bắt lỗi dữ liệu sớm. Nếu muốn học lộ trình automation đầy đủ (UI lẫn API), tham khảo khóa học tại CyberSoft: https://cybersoft.edu.vn/software-testing-chuyen-nghiep-tu-zero-toi-duoc-nhan-viec-manual-automation-testing/

📖 Endpoint: một địa chỉ (URL) cố định trên server, đại diện cho một tài nguyên hoặc hành động cụ thể, ví dụ /products/1024 hay /orders.

3. Request/response cơ bản: method, header, body

Mỗi lần gọi API, bạn gửi đi một REQUEST gồm 4 phần: phương thức (method — GET để lấy dữ liệu, POST để tạo mới, PUT/PATCH để sửa, DELETE để xoá), địa chỉ (URL/endpoint), phần đầu (header — thường chứa thông tin xác thực), và phần thân (body — dữ liệu gửi kèm, chỉ có ở POST/PUT/PATCH). Server xử lý xong sẽ trả về một RESPONSE, cũng gồm 3 phần chính: mã trạng thái (status code) cho biết yêu cầu có thành công không, header, và body chứa dữ liệu trả về (thường là JSON). Kiểm thử API tức là kiểm tra cả request bạn gửi lẫn response bạn nhận có đúng như mong đợi.

💡 GET dùng để LẤY dữ liệu, không nên làm thay đổi gì trên server. Nếu một API GET lại tạo ra đơn hàng mới mỗi lần gọi, đó là dấu hiệu thiết kế sai — hãy báo lại cho đội phát triển.

📖 JSON body: định dạng dữ liệu dạng cặp khoá-giá trị mà hầu hết API hiện đại dùng để gửi/nhận dữ liệu, ví dụ {"id": 1024, "price": 199000}.

4. Status code — mã trạng thái nói gì trước cả khi đọc body

Mã trạng thái (status code) là con số 3 chữ số nằm ngay đầu response, cho bạn biết kết quả tổng quát của request mà chưa cần đọc body. Đây thường là thứ đầu tiên một test API kiểm tra, vì nó rẻ, nhanh và ít gây nhầm lẫn. Nhóm 2xx là thành công, 4xx là lỗi do phía người gửi request (client), 5xx là lỗi phía server.

Bảng các mã trạng thái HTTP thường gặp khi test API sản phẩm & đơn hàng ShopEasy

⚠️ ⚠️ Lỗi người mới hay gặp: Chỉ nhớ '200 là tốt, còn lại là xấu' rồi bỏ qua sự khác biệt giữa 400/401/403/404/500. Mỗi mã kể một câu chuyện khác nhau — 401 là 'chưa xác thực', 403 là 'đã xác thực nhưng không đủ quyền', hoàn toàn khác nhau về cách xử lý.

5. Viết request GET đầu tiên bằng Playwright (thực hành)

Playwright không chỉ điều khiển trình duyệt — nó có sẵn fixture 'request' để gọi thẳng API mà không cần mở trình duyệt, chạy nhanh hơn nhiều so với việc mô phỏng người dùng bấm chuột. Ta sẽ viết test đầu tiên: gọi GET /products/1024 và kiểm cả status code lẫn dữ liệu trả về.