API trả thành công, nghiệp vụ đã đúng chưa?

Trong một tình huống giả định, ứng dụng gửi yêu cầu tạo vận đơn nhưng mạng bị ngắt trước khi nhận phản hồi. Người dùng thử lại và thấy thông báo thành công. Nếu hệ thống tạo hai vận đơn, từng yêu cầu riêng lẻ vẫn có thể trả dữ liệu hợp lệ. Một phép kiểm tra chỉ nhìn mã phản hồi sẽ bỏ qua vấn đề người dùng thực sự gặp.

Kiểm thử API cần nối ba điều: lời hứa của giao diện, trạng thái trước yêu cầu và hậu quả sau yêu cầu. Đặc tả giúp xác định đường vào; nghiệp vụ mới quyết định một phản hồi có ý nghĩa đúng hay không.

Đọc đặc tả cùng người sử dụng nó

Với thao tác tạo vận đơn, hãy xác định trường bắt buộc, kiểu dữ liệu, quyền của người gọi và trạng thái đơn hàng được phép chuyển tiếp. Những giá trị như rỗng, thiếu trường và không có dữ liệu không nên được xem là tương đương nếu hợp đồng phân biệt chúng.

Sau đó hỏi ứng dụng sẽ làm gì với từng kết quả. Một trường đúng kiểu chuỗi nhưng chứa mã không tồn tại có thể không dùng được. Một thông báo lỗi đúng cấu trúc nhưng thiếu cách nhận diện trường sai có thể khiến giao diện không chỉ ra điều người dùng cần sửa.

Đặc tả chưa trả lời câu nào thì ghi câu ấy thành điểm cần làm rõ. Đừng biến một ví dụ phản hồi duy nhất thành luật cho mọi trường hợp.

Mỗi phép thử cần một trạng thái có tên

Chuẩn bị các đơn hàng khác nhau: chưa có vận đơn, đã có vận đơn, đã hủy và thuộc tài khoản khác. Khi gọi cùng một thao tác, bạn đang kiểm tra những điều kiện nghiệp vụ khác nhau, không chỉ thay một mã định danh.

Dữ liệu nên thuộc riêng lượt chạy và được tạo theo cách có thể lặp lại. Nếu dùng lại một đơn đã bị ca trước sửa, kết quả sẽ phụ thuộc thứ tự chạy. Ghi trạng thái ban đầu trong báo cáo giúp người điều tra phân biệt lỗi sản phẩm với dữ liệu đã cũ.

Với quyền truy cập, dùng tài khoản thử được cấp phép và dữ liệu kiểm soát. Cần xem cả nội dung trả về, bởi từ chối thao tác nhưng vẫn tiết lộ dữ liệu của người khác chưa bảo vệ đúng ranh giới.

Nhìn thêm một bước sau phản hồi

Sau khi tạo vận đơn, đọc lại trạng thái và kiểm tra mối liên hệ với đơn gốc. Nếu hệ thống xử lý bất đồng bộ, xác định dấu hiệu hoàn thành cùng khoảng chờ đã thống nhất. Việc chưa thấy kết quả ngay không tự chứng minh thất bại; chờ vô hạn cũng không phải một phép kiểm tra hữu ích.

Với tình huống mất phản hồi, nhóm cần quy định cách nhận diện một yêu cầu lặp. Nếu API có cơ chế tránh tạo trùng, kiểm tra cùng định danh yêu cầu được gửi lại, rồi đối chiếu số vận đơn thực sự tạo ra. Không mặc định mọi thao tác đều có đặc tính ấy khi hợp đồng chưa hứa.

Thành công giả cũng là một nhánh cần thiết

Hãy thử dữ liệu sai, quyền thiếu, tài nguyên không còn tồn tại và phụ thuộc ngoài bị chậm. Ngoài mã trạng thái, kiểm tra cấu trúc lỗi, thông tin nào được phép công khai và trạng thái dữ liệu có bị thay đổi một phần không.

Đối với GraphQL hoặc một giao thức có quy ước riêng, kết quả truyền tải và lỗi ứng dụng cần được đọc theo hợp đồng của hệ thống. Đừng áp một quy tắc “nhận phản hồi là qua” lên mọi loại API.

Kiểm tra schema hữu ích để phát hiện kiểu hoặc trường bị thay đổi. Nhưng nó không thay thế các khẳng định về chủ sở hữu, tổng số bản ghi hay sự chuyển trạng thái hợp lệ.

Báo cáo đủ để lần theo chuỗi

Bằng chứng nên giữ phương thức, đường dẫn, dữ liệu yêu cầu đã che phần nhạy cảm, phản hồi, thời điểm và mã liên kết nếu hệ thống cung cấp. Với lỗi tạo trùng, hai mã vận đơn và một định danh yêu cầu có thể thuyết phục hơn ảnh chụp một phản hồi đơn lẻ.

Máy chủ giả giúp phát triển và kiểm tra nhánh lỗi có kiểm soát; kết quả với nó chưa xác nhận dịch vụ thật hành xử như vậy. Hãy ghi rõ môi trường, phụ thuộc nào được mô phỏng và phần nghiệp vụ đã đối chiếu. Muốn kiểm tra lời hứa giữa hai dịch vụ qua nhiều bản phát hành, xem thêm kiểm thử hợp đồng.

Về nguồn tham khảo

Chủ đề tham khảo từ bộ AI Tester Skills. Bài viết và tình huống minh họa được biên soạn lại cho người đọc.