Một API không ổn định hiếm khi lỗi vì ai đó quên kiểm tra. Nó lỗi vì bài kiểm tra đã chạy kiểm tra sai thứ, hoặc không kiểm tra gì ngoài mã trạng thái 200. Một trường hợp kiểm thử API được viết tốt là sự khác biệt giữa việc phát hiện một hợp đồng bị phá vỡ trước khi phát hành và giải thích sự cố sau đó.
Hướng dẫn này sẽ chỉ rõ trường hợp kiểm thử API là gì, các trường cần thiết cho một trường hợp tốt, và cách viết một trường hợp từ đầu. Bạn sẽ thấy một ví dụ hoàn chỉnh về điểm cuối đăng nhập, sau đó xây dựng cùng một bài kiểm thử trong Apidog mà không cần viết script.
Trường hợp kiểm thử API thực sự là gì
Một trường hợp kiểm thử API là một tập hợp các đầu vào, hành động và kết quả mong đợi được xác định để xác nhận rằng một điểm cuối hoạt động chính xác trong một điều kiện cụ thể. Nó hẹp hơn một kịch bản kiểm thử. Một kịch bản nói “xác minh đăng nhập người dùng.” Một trường hợp kiểm thử nói “POST thông tin xác thực hợp lệ đến /auth/login và xác nhận phản hồi 200 với một JWT trong phần thân trong vòng 800 ms.”
Mỗi trường hợp nhắm mục tiêu vào một hành vi duy nhất. Sự tập trung đó rất quan trọng. Khi một bài kiểm thử rộng, đa mục đích thất bại, bạn vẫn phải điều tra xem phần nào bị hỏng. Khi một trường hợp tập trung thất bại, tên lỗi cho bạn biết câu trả lời. Nếu bạn vẫn đang lập bản đồ cách các trường hợp liên quan đến kịch bản và script, kịch bản kiểm thử so với trường hợp kiểm thử và trường hợp kiểm thử so với script kiểm thử vẽ ra các đường rõ ràng.
Kiểm thử API thường bao gồm năm khía cạnh, và các trường hợp của bạn nên trải rộng trên tất cả chúng:
- Chức năng: điểm cuối có trả về dữ liệu đúng cho đầu vào hợp lệ không?
- Tiêu cực: nó có từ chối đầu vào xấu với lỗi và mã trạng thái chính xác không?
- Hiệu suất: nó có phản hồi trong giới hạn thời gian chấp nhận được không?
- Bảo mật: nó có thực thi xác thực, ủy quyền và giới hạn đầu vào không?
- Hợp đồng: phản hồi có khớp với lược đồ được tài liệu hóa không?
Một bộ kiểm thử chỉ kiểm tra trường hợp thành công sẽ vượt qua cho đến khi một người dùng thực gửi một trường mật khẩu trống.
Tại sao bạn cần một mẫu trường hợp kiểm thử
Viết từng trường hợp từ một trang trống tạo ra sự bao phủ không nhất quán. Một kỹ sư ghi lại mã trạng thái mong đợi; một người khác ghi lại phần thân phản hồi; người thứ ba viết “nên hoạt động.” Một mẫu khắc phục điều đó bằng cách buộc phải có cùng một cấu trúc mỗi lần.
Một mẫu chung mang lại cho bạn bốn lợi ích cụ thể. Mức độ bao phủ trở nên có thể kiểm toán được, vì mỗi trường hợp có cùng các trường và các khoảng trống đều hiển thị. Thời gian làm quen được tăng tốc, vì một người kiểm thử mới đọc một định dạng thay vì năm định dạng. Các trường hợp trở nên có thể tái sử dụng qua các bản phát hành, vì một trường hợp có cấu trúc dễ dàng nhân bản và điều chỉnh. Và khả năng truy xuất nguồn gốc được duy trì, vì mỗi trường hợp liên kết trở lại một yêu cầu hoặc điểm cuối.
Các mẫu cũng làm cho việc tự động hóa trở nên khả thi. Một trường hợp có cấu trúc ánh xạ rõ ràng sang một bước kiểm thử tự động; một trường hợp mơ hồ phải được viết lại trước khi máy có thể chạy nó.
Giải phẫu của một trường hợp kiểm thử API mạnh mẽ
Một mẫu trường hợp kiểm thử API hoàn chỉnh bao gồm các trường sau. Bạn không cần tất cả chúng cho mọi trường hợp, nhưng tập hợp cốt lõi là không thể thiếu.
| Trường | Mục đích |
|---|---|
| ID trường hợp kiểm thử | Tham chiếu duy nhất, ví dụ: AUTH-LOGIN-001 |
| Tiêu đề | Một dòng mô tả hành vi đang được kiểm thử |
| Điểm cuối | Phương thức và đường dẫn, ví dụ: POST /auth/login |
| Điều kiện tiên quyết | Trạng thái yêu cầu trước khi chạy, ví dụ: “người dùng tồn tại” |
| Headers | Headers yêu cầu cần thiết |
| Body/Tham số yêu cầu | Payload đầu vào chính xác |
| Trạng thái mong đợi | Mã HTTP bạn mong đợi |
| Phản hồi mong đợi | Các trường body, schema, hoặc giá trị để xác nhận |
| Thời gian phản hồi mong đợi | Giới hạn độ trễ |
| Ưu tiên | Nghiêm trọng, cao, trung bình, thấp |
| Loại kiểm thử | Chức năng, tiêu cực, bảo mật, hiệu suất |
Các trường mà các nhóm thường bỏ qua nhất là thời gian phản hồi mong đợi và body phản hồi mong đợi. Bỏ qua chúng là cách một bài kiểm thử “vượt qua” trong khi trả về 200 với một payload trống, hoặc một payload chính xác nhưng chậm ba giây.
Cách viết trường hợp kiểm thử API từng bước
Đọc tài liệu API trước. Ghi chú các tham số bắt buộc, phương thức xác thực, mã trạng thái được tài liệu hóa và lược đồ phản hồi. Mỗi trường hợp kiểm thử là một tuyên bố về hành vi được tài liệu hóa, vì vậy tài liệu là nguồn sự thật của bạn. Các công cụ đọc một đặc tả OpenAPI để tạo các bộ kiểm thử có thể cung cấp cho bạn một bộ xương khởi đầu.
Liệt kê các điều kiện đáng kiểm thử. Đối với một điểm cuối duy nhất, điều đó thường có nghĩa là: đầu vào hợp lệ, mỗi trường bắt buộc bị thiếu, mỗi trường bị định dạng sai, một yêu cầu không được ủy quyền, một token đã hết hạn và một payload quá lớn. Mỗi điều kiện trở thành một trường hợp.
Chuẩn bị dữ liệu kiểm thử riêng biệt. Các trường hợp tiêu cực cần dữ liệu sai chính xác theo một cách duy nhất. Việc tái sử dụng cùng một payload trên các trường hợp che giấu lỗi, vì bạn chỉ thực thi một đường dẫn.
Viết kết quả mong đợi một cách chính xác. “Trả về thành công” không phải là một xác nhận. “Trả về 200, body chứa một chuỗi token không trống, expires_in bằng 3600” mới là. Sự chính xác ở đây là điều làm cho trường hợp đáng chạy.
Thêm trường hợp vào một bộ có thể chạy. Một trường hợp trong bảng tính tài liệu hóa ý định. Một trường hợp trong công cụ kiểm thử tạo ra kết quả đạt hoặc không đạt. Nhóm các trường hợp liên quan lại với nhau để toàn bộ điểm cuối chạy chỉ với một cú nhấp chuột; bộ kiểm thử tồn tại chính xác vì mục đích này.
Giữ các trường hợp luôn cập nhật. Khi API thay đổi, các trường hợp cũng thay đổi theo. Một trường hợp lỗi thời xác nhận một lược đồ cũ còn tệ hơn không có trường hợp nào, vì nó thất bại vì lý do sai và huấn luyện nhóm bỏ qua các bản dựng báo đỏ.
Một ví dụ đã thực hiện: kiểm thử một điểm cuối đăng nhập
Lấy một điểm cuối xác thực tiêu chuẩn: POST /auth/login, chấp nhận email và mật khẩu và trả về một JWT. Dưới đây là bốn trường hợp bao phủ nó đúng cách.
AUTH-LOGIN-001: thông tin đăng nhập hợp lệ (chức năng, nghiêm trọng)
- Điểm cuối:
POST /auth/login - Điều kiện tiên quyết: một người dùng tồn tại với email
dana@example.com - Body:
{"email": "dana@example.com", "password": "Correct-Horse-9"} - Trạng thái mong đợi:
200 - Phản hồi mong đợi: body chứa một
tokenkhông trống (chuỗi),token_typebằngBearer,expires_inbằng3600 - Thời gian phản hồi mong đợi: dưới 800 ms
AUTH-LOGIN-002: sai mật khẩu (tiêu cực, nghiêm trọng)
- Body:
{"email": "dana@example.com", "password": "wrong"} - Trạng thái mong đợi:
401 - Phản hồi mong đợi:
errorbằnginvalid_credentials; không có trườngtoken - Lưu ý: thông báo không được tiết lộ liệu email có tồn tại hay không
AUTH-LOGIN-003: thiếu trường mật khẩu (tiêu cực, cao)
- Body:
{"email": "dana@example.com"} - Trạng thái mong đợi:
400 - Phản hồi mong đợi:
errorbằngvalidation_error;detailsnêu tên trườngpassword
AUTH-LOGIN-004: email sai định dạng (tiêu cực, trung bình)
- Body:
{"email": "not-an-email", "password": "Correct-Horse-9"} - Trạng thái mong đợi:
400 - Phản hồi mong đợi:
errorbằngvalidation_error
Bốn trường hợp, một điểm cuối, và bạn đã kiểm tra hợp đồng, định dạng lỗi, mã trạng thái và giới hạn độ trễ. Thêm một trường hợp bảo mật cho chuỗi SQL injection vào trường email và bạn có một bộ kiểm thử đáng chạy trên mỗi commit.
Viết cùng một trường hợp kiểm thử trong Apidog
Bạn có thể chạy tất cả bốn trường hợp trên mà không cần viết một dòng script nào. Trong Apidog, một trường hợp kiểm thử API được xây dựng trực quan.
- Import hoặc định nghĩa điểm cuối. Đưa
POST /auth/logintừ một tệp OpenAPI, một bộ sưu tập Postman, hoặc định nghĩa trực tiếp. Lược đồ yêu cầu trở thành cơ sở cho mọi xác nhận. - Thêm dữ liệu yêu cầu. Nhập body cho trường hợp AUTH-LOGIN-001. Để bao phủ theo dữ liệu, đính kèm tệp CSV hoặc JSON để một trường hợp chạy với mọi hàng thông tin xác thực; đây là cách kiểm thử API theo dữ liệu thay thế bốn trường hợp gần như giống hệt bằng một trường hợp.
- Đặt các xác nhận trực quan. Nhấp để xác nhận rằng trạng thái bằng 200, rằng
tokentồn tại và là một chuỗi không trống, rằngexpires_inbằng 3600, và rằng thời gian phản hồi nằm dưới 800 ms. Không cần scripting. - Nhóm các trường hợp vào một kịch bản kiểm thử. Thêm tất cả bốn trường hợp đăng nhập vào một kịch bản để điểm cuối được kiểm tra đầy đủ trong một lần chạy duy nhất.
- Chạy và đọc báo cáo. Apidog thực thi kịch bản, tạo báo cáo đạt/không đạt cho mỗi trường hợp và hiển thị chính xác xác nhận đã bị lỗi. Bạn có thể chạy kịch bản cục bộ, theo lịch trình hoặc trong CI.
Vấn đề không phải là scripting sai; mà là một trường hợp trực quan có cấu trúc nhanh hơn để viết, dễ xem xét hơn và khó mắc lỗi tinh vi hơn. Khi bạn cần mã, Apidog vẫn cho phép bạn tạo các script tùy chỉnh. Đối với quy trình làm việc hoàn toàn không cần script, kiểm thử API không cần Postman bao gồm cách tiếp cận rộng hơn.
Những lỗi thường gặp cần tránh
Chỉ xác nhận mã trạng thái. Một mã 200 có nghĩa là yêu cầu đã được xử lý, chứ không phải phản hồi là chính xác. Luôn xác nhận các trường body.
Một trường hợp khổng lồ cho mỗi điểm cuối. Khi nó thất bại, bạn không học được gì. Chia nhỏ theo điều kiện.
Dữ liệu kiểm thử được tái sử dụng. Nếu mọi trường hợp tiêu cực gửi cùng một payload, bạn chỉ kiểm tra một chế độ lỗi.
Không có xác nhận độ trễ. Sự suy giảm hiệu suất âm thầm xảy ra khi không có gì đo lường thời gian phản hồi.
Các trường hợp không bao giờ được tự động hóa. Một trường hợp được tài liệu hóa mà không có trình chạy nào thực thi chỉ là một bình luận, không phải một bài kiểm thử. Di chuyển các trường hợp vào một bộ kiểm thử chạy trên mỗi bản dựng; tạo script kiểm thử từ đặc tả OpenAPI là một cách nhanh chóng để khởi tạo bộ kiểm thử đó.
Tải xuống Apidog nếu bạn muốn làm theo ví dụ và tự mình xây dựng bốn trường hợp đăng nhập.
Các câu hỏi thường gặp
Một điểm cuối cần bao nhiêu trường hợp kiểm thử? Đủ để bao gồm trường hợp thành công, mọi lỗi trường bắt buộc, một lỗi xác thực và một thăm dò bảo mật. Đối với một điểm cuối đơn giản là bốn đến sáu trường hợp; đối với một điểm phức tạp có thể nhiều hơn.
Tôi có nên viết các trường hợp trước khi API được xây dựng không? Có. Viết các trường hợp dựa trên thiết kế, theo cách tiếp cận thiết kế trước, sẽ phát hiện ra các lỗ hổng hợp đồng sớm. Kết hợp điều này với tạo trường hợp kiểm thử được hỗ trợ bởi AI để nhanh chóng tạo ra một bộ đầu tiên, sau đó tinh chỉnh bằng tay.
Bảng tính hay công cụ kiểm thử để lưu trữ các trường hợp? Một bảng tính tài liệu hóa ý định nhưng không thể chạy. Giữ các trường hợp trong một công cụ thực thi chúng và báo cáo kết quả, để một trường hợp luôn có màu xanh hoặc đỏ.
Sự khác biệt giữa trường hợp kiểm thử và kịch bản kiểm thử là gì? Một kịch bản là mục tiêu cấp cao (“xác minh đăng nhập”); một trường hợp là một kiểm tra cụ thể, có thể chạy được trong đó. Xem kịch bản kiểm thử so với trường hợp kiểm thử.