The API Testing Checklist I Use for Every Endpoint

Ba năm trước, tôi đã chứng kiến một API sản xuất thất bại thảm hại vào lúc 2 giờ sáng vì không ai kiểm tra những gì xảy ra khi bạn gửi một trường ngày tháng được định dạng là "32/13/2021." Sự lặp lại này thật đẹp theo cách tồi tệ nhất có thể: 47,000 giao dịch thất bại, khách hàng tức giận tràn ngập kênh hỗ trợ, và một CEO muốn có câu trả lời mà tôi không có. Đêm hôm đó đã thay đổi cách tiếp cận của tôi đối với việc kiểm tra API mãi mãi.

Tôi là Sarah Chen, và tôi đã là kỹ sư tự động hóa QA trong tám năm, năm năm qua chỉ tập trung vào kiểm tra API cho các nền tảng fintech và chăm sóc sức khỏe. Tôi đã kiểm tra mọi thứ từ các điểm cuối CRUD đơn giản đến các API xử lý thanh toán phức tạp xử lý hàng triệu đô la mỗi ngày. Điều tôi đã học được là: hầu hết các lỗi API không phải là các trường hợp đặc biệt kỳ lạ—chúng là những vấn đề có thể dự đoán được mà một danh sách kiểm tra hệ thống sẽ phát hiện ra.

Danh sách kiểm tra mà tôi chia sẻ hôm nay là chính xác những gì tôi sử dụng cho từng điểm cuối mà tôi kiểm tra. Nó đã cứu đội ngũ của tôi khỏi ít nhất một tá sự cố sản xuất chỉ trong năm qua, và nó đủ đầy đủ để các kỹ sư trẻ có thể tuân theo trong khi chi tiết đủ để phát hiện các vấn đề mà các lập trình viên kỳ cựu bỏ lỡ. Đây không phải là lý thuyết—đây là quy trình đã được thử nghiệm trong chiến đấu qua hàng trăm triển khai API.

Xác thực và Ủy quyền: Lớp Nền Tảng

Trước khi tôi kiểm tra bất kỳ điều gì khác, tôi xác minh ranh giới bảo mật. Điều này không chỉ là kiểm tra xem xác thực có hoạt động hay không—đó là về việc hệ thống kiểm tra mọi kịch bản xác thực và ranh giới ủy quyền. Tôi đã thấy quá nhiều API hoạt động hoàn hảo với thông tin xác thực hợp lệ nhưng thất bại thảm hại hoặc để lộ dữ liệu khi thông tin xác thực bị thiếu, sai định dạng, hoặc thuộc về người dùng sai.

Đầu tiên, tôi kiểm tra mà không có mã xác thực nào cả. Điểm cuối nên trả về mã trạng thái 401 Không Được Phép, không phải 500 Lỗi Máy Chủ Nội Bộ, và chắc chắn không phải dữ liệu thực. Tôi đã gặp các API sản xuất trả về đầy đủ thông tin người dùng khi không có mã xác thực nào được cung cấp vì nhà phát triển giả định rằng lớp giữa xác thực sẽ luôn chạy. Nó đã không chạy.

Tiếp theo, tôi kiểm tra với một mã đã hết hạn. Điều này phát hiện ra một số lượng vấn đề đáng ngạc nhiên bởi vì logic hết hạn mã thường nằm ở một phần khác của mã nguồn so với xác thực ban đầu. Phản hồi nên là 401 rõ ràng với một thông điệp chỉ ra rằng mã đã hết hạn, không phải một thông điệp chung chung "không được phép" khiến khách hàng đoán được có nên làm mới hay tái xác thực.

Sau đó, tôi kiểm tra với một mã sai định dạng—chuỗi ngẫu nhiên, mã mà các ký tự đã bị xóa, mã từ các hệ thống khác. API nên xử lý những điều này một cách thanh lịch mà không tiết lộ các thông tin chi tiết lỗi hoặc ngăn xếp. Tôi từng thấy một API sẽ làm sập toàn bộ dịch vụ khi nhận được một mã chứa các ký tự Unicode nhất định vì thư viện phân tích JWT không xử lý đúng việc mã hóa.

Kiểm tra ủy quyền là nơi mọi thứ trở nên thú vị. Tôi kiểm tra với các mã hợp lệ thuộc về người dùng không nên có quyền truy cập vào tài nguyên. Đối với điểm cuối GET /users/123, tôi sẽ xác thực dưới tên người dùng 456 và thử truy cập dữ liệu của 123. Phản hồi nên là 403 Bị Cấm, không phải 404 Không Tìm Thấy (điều này rò rỉ thông tin về sự tồn tại của tài nguyên) và chắc chắn không phải 200 với dữ liệu.

Tôi cũng kiểm tra quyền truy cập dựa trên vai trò một cách có hệ thống. Nếu API của bạn có các vai trò quản trị viên, quản lý và người dùng, tôi kiểm tra từng điểm cuối với từng vai trò. Tôi duy trì một bảng ma trận: các hàng là các điểm cuối, các cột là các vai trò, các ô chứa các mã trạng thái dự kiến. Điều này phát hiện ra lỗi phân quyền trước khi chúng đến sản xuất, nơi chúng trở thành các lỗ hổng bảo mật.

Kiểm Tra Yêu Cầu: Kiểm Tra Giới Hạn Dữ Liệu Đầu Vào

Kiểm tra dữ liệu đầu vào là nơi mà hầu hết các API thể hiện chất lượng thực sự của chúng. Một API được thiết kế tốt xác thực mọi trường đầu vào một cách cẩn thận và trả về các thông điệp lỗi rõ ràng, có thể hành động. Một API được thiết kế kém thì hoặc là chấp nhận nguồn dữ liệu không hợp lệ hoặc là bị sập một cách bí ẩn.

"Hầu hết các lỗi API không phải là các trường hợp đặc biệt kỳ lạ—chúng là những vấn đề có thể dự đoán được mà một danh sách kiểm tra hệ thống sẽ phát hiện ra."

Tôi bắt đầu với kiểm tra các trường bắt buộc. Đối với mỗi trường bắt buộc, tôi gửi một yêu cầu mà không có nó. API nên trả về 400 Yêu Cầu Không Hợp Lệ với một thông điệp xác định rõ ràng trường nào bị thiếu. Tôi đã thấy các API trả về "lỗi xác thực" mà không chỉ ra điều gì đã thất bại, buộc các nhà phát triển phải đoán xem trường nào trong 15 trường gây ra vấn đề.

Tiếp theo, tôi kiểm tra xác thực kiểu dữ liệu. Nếu một trường mong đợi một số nguyên, tôi gửi chuỗi, số thực, boolean, null, mảng và đối tượng. Mỗi trường nên trả về 400 với một thông điệp rõ ràng như "tuổi phải là một số nguyên" chứ không phải "định dạng yêu cầu không hợp lệ." Tôi từng kiểm tra một API thương mại điện tử mà việc gửi chuỗi cho số lượng đã khiến hệ thống tạo ra đơn hàng cho số lượng bằng không, điều này đã làm hỏng toàn bộ quy trình thực hiện.

Kiểm tra độ dài chuỗi là rất quan trọng và thường bị bỏ qua. Tôi kiểm tra với các chuỗi rỗng, các ký tự đơn, các chuỗi ở độ dài tối đa, các chuỗi dài hơn độ dài tối đa một ký tự, và các chuỗi dài một cách vô lý (10,000+ ký tự). Tôi đã làm sập các cơ sở dữ liệu sản xuất bằng cách gửi các chuỗi kích thước megabyte vào các trường không được xác thực đúng cách, dẫn đến tình trạng hết bộ nhớ.

Đối với các trường số, tôi kiểm tra các giá trị biên một cách có hệ thống: không, số âm, thập phân khi số nguyên được mong đợi, các số lớn hơn giá trị số nguyên tối đa, và các giá trị đặc biệt như Vô Cùng hoặc NaN. Một API thanh toán mà tôi đã kiểm tra một lần đã chấp nhận các khoản thanh toán âm, điều này sẽ cho phép người dùng ghi có vào tài khoản của họ một cách tùy ý.

Kiểm tra ngày tháng và giờ cần được chú ý đặc biệt vì nó thường gặp vấn đề. Tôi kiểm tra với các ngày không hợp lệ (Ngày 30 tháng 2, tháng 13), các định dạng khác nhau (ISO 8601, dấu thời gian Unix, chuỗi dễ đọc), các ngày xa trong quá khứ hoặc tương lai, và các trường hợp ranh giới về múi giờ. Sự cố lúc 2 giờ sáng mà tôi đã đề cập ở đầu? Đó là một thất bại trong xác thực ngày tháng.

Đối với các trường enum, tôi kiểm tra với các giá trị hợp lệ, giá trị không hợp lệ, biến thể chữ hoa, và null. Nếu API chấp nhận "đang hoạt động" và "không hoạt động" như các giá trị trạng thái, tôi sẽ thử "ACTIVE", "Active", "pending", chuỗi rỗng và null. Mỗi giá trị nên được chấp nhận (nếu không phân biệt chữ hoa chữ thường) hoặc bị từ chối với một thông điệp rõ ràng liệt kê các lựa chọn hợp lệ.

Kiểm Tra Phản Hồi: Đảm Bảo Tính Toàn Vẹn Dữ Liệu

Kiểm tra những gì được trả về cũng quan trọng không kém như việc kiểm tra những gì được gửi vào. Tôi đã thấy các API chấp nhận yêu cầu một cách hoàn hảo nhưng trả về dữ liệu không đồng nhất, không đầy đủ hoặc được định dạng sai khiến ứng dụng khách bị hỏng.