Kiểm thử API thủ công nâng cao bằng Postman: contract, biên, âm, phân quyền — dự án bệnh án điện tử (có trắc nghiệm)

1. Tóm tắt nhanh & hệ thống bạn sẽ kiểm thử

Kiểm thử API thủ công nâng cao là kỹ năng bắt buộc với tester ở dự án doanh nghiệp, đặc biệt trong lĩnh vực y tế — nơi một API sai không chỉ gây bug hiển thị mà có thể ảnh hưởng trực tiếp tới an toàn bệnh nhân (đơn thuốc sai liều) hoặc vi phạm bảo mật dữ liệu (lộ chẩn đoán bệnh). Trong bài này, bạn sẽ làm tester cho hệ thống MediCare EHR: bệnh viện dùng REST API để bác sĩ và điều dưỡng truy cập hồ sơ bệnh án, đơn thuốc, và dữ liệu sinh hiệu của bệnh nhân qua nhiều ứng dụng (web nội bộ, app di động cho điều dưỡng, cổng liên viện).

Bảy khía cạnh nâng cao bạn sẽ luyện trong bài: (1) kiểm thử hợp đồng/schema response, (2) thiết kế ca theo mã trạng thái HTTP đúng ngữ nghĩa nghiệp vụ, (3) kiểm thử biên tham số phân trang/ID/ngày tháng, (4) kiểm thử dữ liệu âm cho payload, (5) kiểm thử phân quyền theo vai trò bác sĩ/điều dưỡng, (6) idempotency cho các API có tác dụng phụ, (7) kiểm thử phân trang nâng cao (offset vs cursor). Mỗi phần đều có ví dụ Postman thật, không phải lý thuyết suông.

2. Kiểm thử hợp đồng (contract) & schema response

Kiểm thử hợp đồng trả lời câu hỏi: 'Response API có ĐÚNG hình dạng mà mọi client (web, app di động, hệ thống liên viện) đang mong đợi không?'. Khác với kiểm thử chức năng chỉ hỏi 'API có trả về dữ liệu đúng nghiệp vụ không', contract testing kiểm tra ở mức thấp hơn: kiểu dữ liệu của từng trường, trường nào bắt buộc phải có, định dạng ngày giờ, và các ràng buộc giá trị. Đây là lớp kiểm thử cực kỳ quan trọng với hệ thống nhiều client tiêu thụ cùng một API như MediCare EHR.

Trong thực tế, đội phát triển hiếm khi cung cấp bộ JSON Schema hoàn chỉnh — tester nâng cao cần TỰ dựng bảng hợp đồng từ tài liệu API (Swagger/OpenAPI) hoặc từ response mẫu, rồi viết test script trong Postman (tab Tests) dùng pm.response.to.have.jsonSchema() hoặc kiểm tra thủ công typeof từng trường. Các lỗi hợp đồng phổ biến nhất ở hệ thống y tế: trường chẩn đoán (diagnosis) trả về null dù được đánh dấu bắt buộc, id bác sĩ trả kiểu số thay vì chuỗi mã hoá (BS-102 vs 102), và ngày tháng không theo chuẩn ISO 8601 khiến client parse sai lệch múi giờ.

3. Mã trạng thái HTTP: thiết kế ca theo status code

Người mới thường chỉ kiểm tra 'API có trả 200 không'. Tester nâng cao phải thiết kế ca kiểm thử sao cho MỖI tình huống nghiệp vụ ánh xạ đúng một mã trạng thái ngữ nghĩa: 200 (thành công, có body), 201 (tạo mới thành công), 204 (thành công, không body — ví dụ DELETE), 400 (payload sai định dạng), 401 (chưa xác thực/token hết hạn), 403 (đã xác thực nhưng không đủ quyền), 404 (tài nguyên không tồn tại), 409 (xung đột, ví dụ đơn thuốc đã bị huỷ), 422 (dữ liệu hợp lệ cú pháp nhưng sai logic nghiệp vụ), 500 (lỗi hệ thống). Nhầm giữa các mã này là lỗi nghiêm trọng vì client dựa vào status code để quyết định hành vi tiếp theo.

▶ Bước 1: Liệt kê toàn bộ endpoint cần test (vd PUT /v1/prescriptions/{id}), với từng endpoint liệt kê các tình huống nghiệp vụ có thể xảy ra.

▶ Bước 2: Với mỗi tình huống, tra bảng ánh xạ HTTP status để xác định mã ĐÚNG (không đoán, không copy từ endpoint khác).

▶ Bước 3: Viết ca kiểm thử Postman với assertion `pm.response.to.have.status(x)` CHÍNH XÁC theo bảng, không chấp nhận '2xx là được'.

ANH XA MA TRANG THAI - PUT /v1/prescriptions/{id}
Tinh huong: sua thanh cong, du quyen bac si       -> 200
Tinh huong: id don thuoc khong ton tai            -> 404 (KHONG phai 200)
Tinh huong: khong gui token / token het han        -> 401
Tinh huong: token hop le nhung sai vai tro (dieu duong) -> 403 (KHONG phai 200)
Tinh huong: don thuoc da bi huy truoc do            -> 409
Tinh huong: lieu luong am hoac rong                  -> 400
Tinh huong: loi he thong (DB timeout)                -> 500 (khong lo stack trace)

4. Kiểm thử biên tham số (boundary) cho API

Mọi tham số API đều có biên: `limit` trong phân trang có min/max, `page` phải ≥1, `id` phải đúng định dạng, khoảng ngày (`from`/`to`) phải hợp lý. Kiểm thử biên nâng cao nghĩa là bạn không chỉ thử giá trị hợp lệ điển hình mà thử CHÍNH XÁC tại và ngay ngoài ranh giới cho phép — đây là nơi lỗi off-by-one (lệch 1 đơn vị) và lỗi tràn số thường ẩn náu, đặc biệt nguy hiểm khi tham số điều khiển lượng dữ liệu y tế trả về.

▶ Bước 1: Với tham số `limit` (giới hạn tối đa 100), thử: limit=1 (biên dưới hợp lệ), limit=100 (biên trên hợp lệ), limit=0 và limit=101 (ngay ngoài biên), limit=-5 (số âm).