Đang tải...

Lửng Lọc Lõi

Đeo kính để soi Bug cho rõ, nhíu mày để nhắc Dev sửa cho kỹ. Với tôi, 'chạy được' thôi là chưa đủ! 🧐💻


0

API Testing Với Postman: Từ Request Đơn Giản Đến Test Collection

Lửng Lọc Lõi
Lửng Lọc Lõi

6 tháng trước · 12 phút đọc

Tại sao tester phải biết test API?

Mình nhớ hồi mới học testing, cứ nghĩ tester chỉ cần click giao diện, điền form, kiểm tra màu sắc. Cho đến buổi phỏng vấn đầu tiên, người ta hỏi: "Em đã test API bao giờ chưa?" - và mình ngồi im.

Thực tế, phần lớn job description tester tại Việt Nam hiện nay yêu cầu kinh nghiệm hoặc kỹ năng API testing. Lý do đơn giản: app ngày nay đều chạy trên kiến trúc client-server, giao tiếp qua API. Giao diện đẹp nhưng API sai thì app vẫn lỗi - và tester cần bắt được lỗi đó trước khi người dùng gặp phải.

Postman là công cụ phổ biến nhất để test API, miễn phí, không cần cài server, không cần biết code. Bài này mình hướng dẫn từ đầu: cài Postman, gửi request đầu tiên, đến build một collection test case hoàn chỉnh.

Bạn không cần biết lập trình để học phần này. Chỉ cần logic và tỉ mỉ - hai thứ tester nào cũng cần.

342833 API testing bắt cầu nối giữa backend và frontend - tester cần đứng ở giữa

Nếu bạn muốn hiểu sâu hơn về cách backend và API hoạt động, khóa Node & ExpressJS có phần giải thích RESTful API khá chi tiết, hữu ích để tester hiểu được hệ thống mình đang test.


Cài Postman và gửi request GET đầu tiên

Tải Postman tại trang chủ Postman - có bản desktop cho Windows/Mac/Linux và bản web. Mình khuyên dùng bản desktop vì dễ quản lý file hơn.

Sau khi cài xong, bạn sẽ thấy màn hình chính. Đừng sợ - phần cần dùng chỉ là thanh URL ở trên và tab ở dưới.

Thực hành request GET đầu tiên với API tỉnh thành Việt Nam:

API công khai provinces.open-api.vn cho phép lấy danh sách tỉnh/thành, quận/huyện, xã/phường của Việt Nam - không cần đăng ký, không cần token. Đây là API thực tế, không phải demo.

GET https://provinces.open-api.vn/api/

Các bước thực hiện:

  1. Mở Postman, click NewHTTP
  2. Chọn method GET (dropdown bên trái thanh URL)
  3. Dán URL trên vào thanh địa chỉ
  4. Click Send

342834 Giao diện Postman sau khi nhận response - chú ý status code và thời gian phản hồi

Bạn sẽ thấy response hiện ra bên dưới. Nhìn vào 3 thứ này trước:

  • Status code: 200 OK nghĩa là request thành công. 404 là không tìm thấy. 500 là lỗi server.
  • Time: thời gian server phản hồi, tính bằng milliseconds
  • Size: dung lượng response

Response trả về là dạng JSON - một danh sách 63 tỉnh thành với tên, mã, và tên đơn vị hành chính. Đây chính là dữ liệu mà frontend dùng để hiển thị dropdown địa chỉ trên app.

Thấy dữ liệu hiện ra là bạn đã gửi request API thành công rồi. Bước tiếp theo mới là việc của tester: kiểm tra xem data đó có đúng không.


Validation response - công việc thật sự của tester

Gửi request và nhận 200 OK chưa phải là xong. Lỗi nghiêm trọng nhất thường ẩn bên trong response - dữ liệu sai, thiếu field, sai kiểu dữ liệu.

Mình từng gặp case: API trả về 200 OK nhưng field price trong response là chuỗi "15000" thay vì số 15000. Frontend hiển thị đúng, nhưng khi tính tổng giỏ hàng thì kết quả thành "15000" + "20000" = "1500020000". Bug nổ production mà cả team không ai bắt được ở môi trường test vì chỉ nhìn giao diện.

3 thứ cần validate trong mỗi response:

1. Status code đúng với tình huống

  • Request hợp lệ → 200 OK hoặc 201 Created
  • Tham số sai → 400 Bad Request
  • Không có quyền → 401 hoặc 403
  • Không tìm thấy → 404 Not Found

2. Cấu trúc dữ liệu đúng

Test với endpoint lấy tỉnh theo mã:

GET https://provinces.open-api.vn/api/p/01

Response trả về:

{
  "code": "01",
  "name": "Thành phố Hà Nội",
  "codename": "thanh_pho_ha_noi",
  "division_type": "thành phố trung ương",
  "phone_code": 24
}

Kiểm tra: code có phải string không? phone_code có phải number không? name có đúng tên tỉnh không?

3. Edge case - nơi bug hay ẩn nhất

Thử gửi mã tỉnh không tồn tại:

GET https://provinces.open-api.vn/api/p/99

Server trả về gì? 404? 200 với data rỗng? Hay 500? Câu trả lời đúng tuỳ theo spec, nhưng tester phải test và ghi lại.

342835 3 điểm cần kiểm tra trong mỗi response - bỏ sót bất kỳ điểm nào đều có thể bỏ sót bug

Viết test case ngay vào một file ghi chú:

Test Case URL Expected Actual Pass/Fail
Lấy danh sách tỉnh GET /api/ 200, array 63 items ... ...
Lấy tỉnh hợp lệ GET /api/p/01 200, name = Hà Nội ... ...
Mã tỉnh không tồn tại GET /api/p/99 404 ... ...

Tải template test case này về để dùng luôn: Template test case API


Gửi POST request và test với body

GET chỉ là lấy dữ liệu. Phần lớn bug thật sự ẩn trong POST - nơi người dùng gửi dữ liệu lên server: đăng ký, đăng nhập, tạo đơn hàng.

Vì API tỉnh thành không có endpoint POST công khai, mình dùng https://reqres.in - một API giả lập miễn phí chuẩn để học. Không cần đăng ký.

Thực hành: POST đăng ký user

POST https://reqres.in/api/register

Trong Postman:

  1. Chọn method POST
  2. Nhập URL trên
  3. Click tab Body → chọn raw → chọn JSON (dropdown bên phải)
  4. Nhập body:
{
  "email": "[email protected]",
  "password": "pistol"
}
  1. Click Send

342836 Cài đặt Body tab trong Postman - chọn raw + JSON trước khi nhập data

Response trả về:

{
  "id": 4,
  "token": "QpwL5tpe83ilfN2"
}

Status 200 OK, có idtoken. Đây là happy path - trường hợp đúng.

Bây giờ mới là phần tester cần làm: test các trường hợp sai.

Test thiếu field:

{
  "email": "[email protected]"
}

(Bỏ password) → Expected: 400 Bad Request kèm message lỗi rõ ràng

Test email không hợp lệ:

{
  "email": "khong-phai-email",
  "password": "123456"
}

→ Expected: 400 với message giải thích email sai format

Test body rỗng:

{}

→ Expected: 400, không phải 500 (nếu server crash với body rỗng thì đó là bug)

Mỗi lần test, ghi lại kết quả actual vào template. Nếu expected khác actual → báo bug. Đơn giản vậy thôi.


Build Collection - gom test case thành bộ có tổ chức

Gửi từng request rời rạc ổn cho việc khám phá API. Nhưng khi đi làm, bạn cần bộ test case có thể chạy lại mỗi khi có build mới - đó gọi là Collection trong Postman.

Collection giống như một thư mục chứa tất cả test case của bạn, phân loại theo tính năng, có thể share cho team, và chạy tự động bằng một click.

Tạo Collection từ đầu:

Trong Postman, click icon Collections (cột trái) → New Collection → Đặt tên [Project Name] - API Tests.

Tạo folder bên trong collection theo tính năng:

  • Tỉnh Thành (chứa test GET tỉnh/huyện/xã)
  • Authentication (chứa test đăng ký, đăng nhập)
  • Error Cases (chứa test với input sai)

Thêm request vào collection:

Sau mỗi lần gửi request, click Save (Ctrl+S) → chọn collection và folder muốn lưu vào. Đặt tên rõ ràng: GET - Danh sách tỉnh thành, POST - Đăng ký thành công, POST - Đăng ký thiếu password.

342837 Cấu trúc Collection tổ chức theo tính năng - team member mới nhìn vào hiểu ngay

Viết test script tự động trong Postman:

Postman cho phép viết script để tự validate response. Click tab Tests trong request, dán đoạn này:

// Kiểm tra status code = 200
pm.test("Status code phải là 200", function () {
    pm.response.to.have.status(200);
});

// Kiểm tra response có field 'name'
pm.test("Response phải có field name", function () {
    const json = pm.response.json();
    pm.expect(json).to.have.property("name");
});

// Kiểm tra thời gian phản hồi < 2 giây
pm.test("Thời gian phản hồi dưới 2 giây", function () {
    pm.expect(pm.response.responseTime).to.be.below(2000);
});

Sau khi Save và Send lại, Postman chạy 3 test tự động và hiện kết quả Pass/Fail trong tab Test Results. Nếu bất kỳ test nào fail - bạn biết ngay có gì đó sai mà không cần nhìn từng dòng response.

Không cần biết code sâu để viết script này. Copy-paste rồi sửa tên field và giá trị expected là đủ.


Chạy toàn bộ collection và đọc kết quả

Sau khi build xong collection, đây là lúc chạy tất cả test case cùng lúc.

Click vào tên collection → Run collection (nút tam giác). Postman mở Collection Runner - cho phép chọn folder muốn chạy, số lần lặp, và delay giữa các request.

Giữ mặc định và click Run [tên collection].

342838 Collection Runner chạy xong - đọc số Pass/Fail trước, rồi mới vào chi tiết từng request

Kết quả hiện theo từng test:

  • PASS - màu xanh: test passed
  • FAIL - màu đỏ: test failed, kèm message giải thích lỗi gì

Đọc kết quả như thế nào?

Nhìn tổng số trước: "15 passed, 2 failed". Sau đó click vào request bị fail để xem chi tiết. Message lỗi thường rất cụ thể: "expected response to have status 200 but got 404" - từ đó bạn biết endpoint bị sai hoặc data không tồn tại.

Export kết quả bằng Export Results để gửi cho team hoặc lưu vào bug report.

Gợi ý bộ test case tối thiểu cho bất kỳ tính năng nào:

Loại test Mô tả
Happy path Input hợp lệ, đúng flow
Missing required field Thiếu field bắt buộc
Invalid format Sai kiểu dữ liệu (text thay vì số)
Boundary value Giá trị biên (0, -1, max+1)
Unauthorized Gọi API không có token
Not found ID không tồn tại

Sáu loại này cover được phần lớn lỗi phổ biến. Khi đi làm, bạn sẽ thêm vào dần dựa trên spec thực tế của project.

Tải bộ collection mẫu đã build sẵn cho API tỉnh thành: API Testing Checklist (Interactive)


Bước tiếp theo để xin việc được nhờ API testing

Phần lớn vị trí tester tại các công ty product Việt Nam hiện nay đều đề cập API testing trong job description - con số này phản ánh một thực tế: biết API testing không chỉ là "điểm cộng", nó đang dần trở thành yêu cầu tối thiểu ở nhiều công ty product.

Bạn đã học được:

  • Gửi GET/POST request với Postman
  • Validate status code, cấu trúc data, edge case
  • Build collection có tổ chức theo tính năng
  • Chạy toàn bộ test và đọc kết quả

Làm gì tiếp theo để bổ sung vào CV?

1. Thực hành thêm với API công khai Việt Nam

Ngoài API tỉnh thành, bạn có thể test thêm:

  • API tỷ giá của Vietcombank (có endpoint JSON công khai)
  • API dự báo thời tiết của Tổng cục Khí tượng Thủy văn
  • API tra cứu mã số thuế của Tổng cục Thuế

Mỗi API là một mini project thực hành.

2. Ghi lại thành portfolio

Chụp màn hình collection đã build, test results, bug bạn tìm được (kể cả API public có lỗi). Đưa vào CV phần "Dự án tự học" kèm mô tả: "Build collection 20 test case cho API X, tìm được Y bug edge case".

3. Học thêm Environment Variable

Postman cho phép tạo biến môi trường (ví dụ: {{base_url}}, {{auth_token}}). Khi chuyển từ test sang staging sang production, chỉ cần đổi 1 chỗ thay vì sửa 20 URL. Đây là kỹ năng tester đi làm cần ngay.

342839 Lộ trình API testing từ fresher đến có thể xin việc

Mình biết phần script test trong tab Tests có thể khó với bạn chưa biết code. Không cần lo - copy-paste là đủ để bắt đầu. Hiểu code sâu hơn là việc sau. Quan trọng nhất là bạn hiểu tại sao cần test từng trường hợp đó.

Nếu muốn đi sâu vào kiểm thử phần mềm một cách bài bản, khóa Kiểm thử phần mềm tại F8 có module API testing chi tiết hơn, kèm bài tập thực hành có hướng dẫn.

Comment bên dưới nếu bạn gặp khó ở bước nào - mình trả lời từng bạn. Chúc thực hành suôn sẻ!