API Testing là gì? Hướng dẫn kiểm thử API từ cơ bản đến nâng cao

• Bùi Tấn Lực
• 105
• 05/09/2026

Trong một ứng dụng hiện đại, giao diện mà người dùng nhìn thấy chỉ là phần nổi. Phía sau website, ứng dụng di động, phần mềm quản lý hay hệ thống thương mại điện tử là hàng loạt thành phần trao đổi dữ liệu với nhau thông qua API. Nếu API xảy ra lỗi, giao diện có thể vẫn hiển thị bình thường nhưng dữ liệu không được lưu, đơn hàng không được tạo, thanh toán thất bại hoặc thông tin trả về sai mà người dùng không hề biết nguyên nhân.

Đó là lý do API Testing trở thành một phần quan trọng trong quy trình kiểm thử phần mềm. Kiểm thử API không đơn giản là gửi một request và xem có nhận được response hay không. Một API có thể trả về mã thành công nhưng vẫn chứa dữ liệu sai, xử lý sai quyền truy cập, làm lộ thông tin nhạy cảm hoặc hoạt động chậm đến mức không thể đáp ứng khi hệ thống có nhiều người dùng.

Bài viết này sẽ giúp bạn hiểu API Testing từ nền tảng đến chuyên sâu, bao gồm cách kiểm thử request và response, xây dựng test case, kiểm tra authentication, validation, hiệu năng, bảo mật và từng bước nâng cấp quy trình kiểm thử API trong dự án thực tế.

API Testing là gì và vì sao kiểm thử API ngày càng quan trọng?

API Testing là quá trình kiểm tra cách một API tiếp nhận yêu cầu, xử lý dữ liệu và trả kết quả cho hệ thống hoặc ứng dụng khác. Thay vì kiểm tra thông qua giao diện người dùng, người kiểm thử tương tác trực tiếp với các endpoint để đánh giá logic nghiệp vụ, dữ liệu đầu vào, dữ liệu đầu ra, trạng thái xử lý và khả năng chịu lỗi của hệ thống.

API có thể được xem là cầu nối giữa các thành phần khác nhau. Ví dụ, khi người dùng đăng nhập vào website, giao diện sẽ gửi thông tin tài khoản đến API. API tiếp nhận dữ liệu, kiểm tra thông tin trong cơ sở dữ liệu, xác thực người dùng và trả kết quả về cho giao diện.

Một quy trình tưởng chừng đơn giản thực tế có thể phát sinh rất nhiều vấn đề:

• API nhận được dữ liệu không hợp lệ nhưng vẫn xử lý.
• Mật khẩu sai nhưng hệ thống trả về thông tin quá chi tiết.
• Người dùng không có quyền nhưng vẫn truy cập được dữ liệu.
• API trả về mã thành công nhưng dữ liệu thực tế bị thiếu hoặc sai.
• Dữ liệu được lưu nhiều lần khi request bị gửi lại.
• Endpoint hoạt động tốt với một người dùng nhưng chậm hoặc lỗi khi có nhiều request đồng thời.
• Thay đổi một chức năng làm ảnh hưởng đến API đang được ứng dụng khác sử dụng.

API Testing được thực hiện để phát hiện những vấn đề này càng sớm càng tốt. Đây không chỉ là công việc kiểm tra kỹ thuật đơn thuần mà còn là cách bảo vệ logic cốt lõi của hệ thống.

API Testing không chỉ kiểm tra API có chạy hay không

Một sai lầm phổ biến là cho rằng API trả về HTTP 200 nghĩa là API hoạt động chính xác. Trên thực tế, HTTP status code chỉ phản ánh một phần trạng thái xử lý.

Ví dụ, một API lấy thông tin sản phẩm có thể trả về HTTP 200 nhưng dữ liệu sản phẩm lại thiếu giá bán. Về mặt kết nối, request đã thành công. Tuy nhiên, về mặt nghiệp vụ, API vẫn bị lỗi vì ứng dụng phía client không thể hiển thị thông tin đầy đủ.

Do đó, một bài kiểm thử API tốt cần xem xét đồng thời nhiều yếu tố:

• Request có được tiếp nhận đúng hay không.
• Dữ liệu đầu vào có được kiểm tra hợp lệ hay không.
• Logic nghiệp vụ có xử lý đúng yêu cầu hay không.
• Status code có phản ánh đúng kết quả xử lý hay không.
• Dữ liệu response có đúng cấu trúc và giá trị mong đợi hay không.
• Thông báo lỗi có phù hợp và an toàn hay không.
• Quyền truy cập có được kiểm soát đúng hay không.
• API có duy trì hiệu năng ổn định hay không.

Hiểu cách API hoạt động trước khi bắt đầu kiểm thử

Muốn kiểm thử API hiệu quả, trước hết cần hiểu luồng giao tiếp cơ bản giữa client và server. Phần lớn API web hiện nay hoạt động theo mô hình request và response.

Client có thể là website, ứng dụng mobile, phần mềm nội bộ hoặc một hệ thống khác. Khi cần dữ liệu hoặc muốn thực hiện một thao tác, client gửi request đến địa chỉ endpoint của API. Server tiếp nhận request, xử lý logic cần thiết rồi trả response về.

Một request API thường bao gồm nhiều thành phần khác nhau.

Endpoint

Endpoint là địa chỉ cụ thể mà client sử dụng để tương tác với một chức năng của API. Mỗi endpoint thường đại diện cho một tài nguyên hoặc một nghiệp vụ.

Ví dụ, hệ thống có thể tách riêng các endpoint để lấy danh sách sản phẩm, xem chi tiết sản phẩm, tạo đơn hàng hoặc cập nhật thông tin người dùng.

Khi kiểm thử endpoint, không nên chỉ quan tâm địa chỉ có truy cập được hay không. Cần kiểm tra endpoint có được thiết kế đúng mục đích, có xử lý đúng dữ liệu tương ứng và có hạn chế truy cập trái phép hay không.

HTTP Method

HTTP Method cho server biết client muốn thực hiện hành động gì. Một số phương thức thường gặp gồm GET, POST, PUT, PATCH và DELETE.

Method	Mục đích phổ biến	Ví dụ sử dụng
GET	Lấy dữ liệu	Lấy danh sách bài viết hoặc thông tin sản phẩm
POST	Tạo dữ liệu mới	Tạo tài khoản hoặc đơn hàng
PUT	Cập nhật toàn bộ dữ liệu	Thay thế thông tin một bản ghi
PATCH	Cập nhật một phần dữ liệu	Thay đổi trạng thái đơn hàng
DELETE	Xóa dữ liệu	Xóa một bản ghi khỏi hệ thống

Khi kiểm thử, cần kiểm tra API có thực sự giới hạn hành vi theo HTTP Method hay không. Một endpoint chỉ cho phép lấy dữ liệu không nên vô tình cho phép cập nhật dữ liệu bằng một method khác.

Headers

Headers chứa thông tin bổ sung cho request hoặc response. Đây là nơi thường xuất hiện các dữ liệu quan trọng như kiểu nội dung, token xác thực, ngôn ngữ hoặc thông tin phiên làm việc.

Một số lỗi API chỉ xuất hiện khi headers bị thiếu hoặc không đúng định dạng. Vì vậy, API Testing cần kiểm tra cả trường hợp headers hợp lệ lẫn headers bất thường.

Ví dụ, cần xác định điều gì xảy ra nếu request thiếu token, token hết hạn hoặc token không đúng định dạng. Hệ thống có từ chối request một cách an toàn hay vẫn tiếp tục xử lý?

Parameters

Parameters là dữ liệu được truyền vào API để xác định nội dung cần xử lý. Parameters có thể nằm trên URL, trong query string hoặc trong body của request.

Ví dụ, API lấy danh sách sản phẩm có thể nhận các tham số phân trang, từ khóa tìm kiếm hoặc danh mục. API xem chi tiết có thể nhận ID của một bản ghi.

Đây là khu vực cần kiểm thử rất kỹ vì phần lớn lỗi validation xuất hiện từ dữ liệu đầu vào. Không nên chỉ kiểm tra dữ liệu đúng mà phải kiểm tra nhiều tình huống bất thường.

• Không truyền parameter bắt buộc.
• Truyền dữ liệu rỗng.
• Truyền sai kiểu dữ liệu.
• Truyền giá trị quá dài.
• Truyền giá trị nhỏ hơn hoặc lớn hơn giới hạn.
• Truyền ký tự đặc biệt.
• Truyền dữ liệu không tồn tại trong hệ thống.
• Truyền dữ liệu hợp lệ nhưng không thuộc quyền của người dùng hiện tại.

Request Body

Request Body thường được sử dụng khi client cần gửi một lượng dữ liệu lớn hơn đến server, đặc biệt trong các thao tác tạo mới hoặc cập nhật.

Đối với API sử dụng JSON, người kiểm thử cần quan tâm đến cả cấu trúc lẫn giá trị dữ liệu. Một body có cú pháp JSON hợp lệ chưa chắc đã hợp lệ về mặt nghiệp vụ.

Ví dụ, trường email có thể tồn tại và là chuỗi văn bản hợp lệ nhưng giá trị bên trong không đúng định dạng email. Tương tự, giá sản phẩm có thể là số nhưng lại là số âm. Những trường hợp này yêu cầu validation ở cấp độ nghiệp vụ thay vì chỉ kiểm tra cú pháp.

Response

Response là kết quả API trả về sau khi xử lý request. Đây là thành phần được kiểm tra nhiều nhất, nhưng kiểm tra response hiệu quả không có nghĩa là chỉ đọc dữ liệu bằng mắt.

Một response cần được đánh giá dựa trên:

• HTTP status code.
• Cấu trúc dữ liệu.
• Kiểu dữ liệu của từng trường.
• Giá trị thực tế.
• Thông báo lỗi.
• Dữ liệu bắt buộc và dữ liệu không nên xuất hiện.
• Thời gian phản hồi.
• Tính nhất quán với trạng thái dữ liệu thực tế.

API Testing khác gì so với kiểm thử giao diện?

Kiểm thử giao diện và kiểm thử API đều quan trọng nhưng giải quyết hai lớp vấn đề khác nhau.

Kiểm thử giao diện tập trung vào những gì người dùng tương tác trực tiếp, chẳng hạn nút bấm, biểu mẫu, bố cục, thông báo và luồng sử dụng. API Testing đi sâu hơn vào tầng giao tiếp và xử lý dữ liệu phía sau.

Tiêu chí	Kiểm thử giao diện	API Testing
Đối tượng kiểm tra	Giao diện người dùng	Logic giao tiếp và xử lý dữ liệu
Phụ thuộc giao diện	Cao	Thấp
Tốc độ kiểm thử	Thường chậm hơn	Thường nhanh hơn
Phát hiện lỗi backend	Có thể gián tiếp	Trực tiếp hơn
Khả năng tự động hóa	Phức tạp hơn khi UI thay đổi	Thuận lợi cho automation
Kiểm tra dữ liệu chi tiết	Bị giới hạn bởi giao diện	Kiểm tra trực tiếp response

Một ưu điểm lớn của API Testing là có thể bắt đầu kiểm thử ngay cả khi giao diện chưa hoàn thiện. Điều này giúp đội phát triển phát hiện lỗi sớm thay vì chờ đến khi toàn bộ website hoặc ứng dụng được xây dựng xong.

Trong các dự án phát triển website theo yêu cầu, đặc biệt với hệ thống có nhiều chức năng quản trị, dữ liệu và tích hợp bên thứ ba, kiểm thử API sớm giúp giảm đáng kể chi phí sửa lỗi về sau. Khi một lỗi logic đã lan sang nhiều màn hình hoặc nhiều hệ thống khác, việc xác định nguyên nhân thường phức tạp hơn rất nhiều.

Những loại API Testing quan trọng cần thực hiện

API Testing không phải là một bài kiểm tra duy nhất. Tùy vào mức độ phức tạp của hệ thống, API có thể cần được kiểm thử dưới nhiều góc độ khác nhau.

Functional Testing

Functional Testing kiểm tra API có thực hiện đúng chức năng theo yêu cầu hay không. Đây là lớp kiểm thử cơ bản nhất nhưng cũng là nền tảng của toàn bộ quá trình.

Ví dụ, API tạo đơn hàng cần được kiểm tra xem khi nhận đầy đủ dữ liệu hợp lệ thì có tạo đúng đơn hàng hay không. Sau khi thành công, dữ liệu được lưu như thế nào, tổng tiền có chính xác không và response trả về có phản ánh đúng trạng thái mới hay không.

Điểm quan trọng là Functional Testing không nên dừng lại ở việc kiểm tra một tình huống thành công. Một chức năng tốt cần xử lý đúng cả trường hợp thành công và thất bại.

Validation Testing

Validation Testing tập trung kiểm tra khả năng xác thực dữ liệu đầu vào. Đây là lớp bảo vệ đầu tiên giúp hệ thống tránh nhận dữ liệu sai.

Một API chất lượng không nên tin tưởng hoàn toàn dữ liệu từ client. Ngay cả khi giao diện đã có validation, backend vẫn cần kiểm tra lại vì request có thể được gửi trực tiếp mà không đi qua giao diện.

Các trường hợp nên được kiểm tra bao gồm:

• Trường bắt buộc bị thiếu.
• Chuỗi vượt quá độ dài cho phép.
• Số nằm ngoài phạm vi hợp lệ.
• Định dạng ngày tháng không đúng.
• Email hoặc số điện thoại không hợp lệ.
• Dữ liệu trùng với bản ghi đã tồn tại.
• Quan hệ dữ liệu không tồn tại.

Validation tốt cần vừa đủ chặt chẽ để bảo vệ hệ thống nhưng không được gây khó khăn không cần thiết cho dữ liệu hợp lệ.

Authentication Testing

Authentication Testing kiểm tra cơ chế xác thực danh tính. Mục tiêu là đảm bảo API biết chính xác request đang được gửi bởi ai.

Các tình huống cần kiểm tra thường gồm request không có thông tin xác thực, token không hợp lệ, token hết hạn hoặc thông tin xác thực đã bị thu hồi.

Một lỗi authentication nguy hiểm có thể cho phép người không đăng nhập truy cập API vốn chỉ dành cho người dùng đã xác thực.

Authorization Testing

Authentication và Authorization thường bị nhầm lẫn với nhau. Authentication trả lời câu hỏi người gửi request là ai, còn Authorization trả lời câu hỏi người đó có được phép thực hiện hành động này hay không.

Một người dùng đã đăng nhập không có nghĩa họ có quyền truy cập mọi dữ liệu trong hệ thống.

Ví dụ, người dùng A không nên chỉ cần thay đổi ID trên URL là có thể xem thông tin đơn hàng của người dùng B. Đây là một dạng lỗi phân quyền phổ biến và có thể gây rò rỉ dữ liệu nghiêm trọng.

Security Testing

Security Testing đánh giá khả năng API chống lại các request bất thường và hành vi khai thác. Mục tiêu không phải chỉ tìm lỗi bảo mật phức tạp mà còn kiểm tra những nguyên tắc cơ bản thường bị bỏ qua.

Một số nội dung cần chú ý gồm kiểm soát quyền truy cập, xử lý dữ liệu đầu vào, giới hạn request, bảo vệ thông tin nhạy cảm và tránh trả về quá nhiều thông tin trong thông báo lỗi.

Ví dụ, khi đăng nhập thất bại, API không nên trả về thông tin nội bộ liên quan đến cơ sở dữ liệu hoặc cấu trúc server. Thông báo lỗi cần đủ để client xử lý nhưng không được vô tình cung cấp thông tin hữu ích cho người có ý đồ xấu.

Performance Testing

Một API xử lý đúng nhưng mất quá nhiều thời gian vẫn có thể trở thành vấn đề nghiêm trọng trong môi trường thực tế.

Performance Testing giúp đánh giá tốc độ phản hồi, khả năng xử lý nhiều request và mức độ ổn định khi tải tăng lên. Đây là nội dung đặc biệt quan trọng với hệ thống thương mại điện tử, nền tảng có lượng truy cập lớn hoặc API phục vụ nhiều ứng dụng cùng lúc.

Regression Testing

Khi hệ thống được cập nhật, một thay đổi nhỏ có thể vô tình làm hỏng chức năng cũ. Regression Testing được sử dụng để kiểm tra lại những API đã hoạt động trước đó.

Ví dụ, đội phát triển thay đổi logic đăng nhập để bổ sung một hình thức xác thực mới. Nếu không kiểm tra hồi quy, thay đổi này có thể ảnh hưởng đến ứng dụng mobile hoặc các dịch vụ đang sử dụng cơ chế đăng nhập cũ.

Đây là lý do các dự án lớn thường xây dựng bộ API test tự động thay vì thực hiện lại toàn bộ kiểm tra thủ công sau mỗi lần cập nhật.

Quy trình kiểm thử API đúng cách bắt đầu từ đâu?

Một trong những lý do khiến API Testing trở nên rối là người kiểm thử bắt đầu gửi request ngay mà chưa hiểu API đang giải quyết vấn đề gì. Điều này dẫn đến tình trạng kiểm tra rất nhiều nhưng vẫn bỏ sót lỗi quan trọng.

Quy trình hiệu quả nên bắt đầu từ việc hiểu nghiệp vụ trước, sau đó mới đi vào endpoint và dữ liệu kỹ thuật.

Bước đầu tiên: hiểu mục đích nghiệp vụ của API

Trước khi tạo test case, hãy trả lời API này tồn tại để làm gì.

Ví dụ, API tạo đơn hàng không chỉ đơn giản nhận dữ liệu và thêm một dòng vào cơ sở dữ liệu. Nó có thể liên quan đến kiểm tra tồn kho, tính giá, áp dụng mã giảm giá, xác định phương thức thanh toán và cập nhật trạng thái đơn hàng.

Nếu chỉ kiểm tra API có trả về thành công hay không, rất nhiều lỗi nghiệp vụ sẽ bị bỏ qua.

Xác định dữ liệu đầu vào và điều kiện hợp lệ

Mỗi API cần được phân tích rõ dữ liệu nào là bắt buộc, dữ liệu nào là tùy chọn và điều kiện nào khiến request bị từ chối.

Đây là bước giúp xây dựng các nhóm test case thay vì kiểm tra ngẫu nhiên.

Với mỗi trường dữ liệu, nên đặt những câu hỏi như:

• Trường này có bắt buộc không?
• Kiểu dữ liệu mong đợi là gì?
• Giá trị nhỏ nhất và lớn nhất là bao nhiêu?
• Có được phép để trống không?
• Có thể nhận giá trị trùng lặp không?
• Giá trị này có phụ thuộc vào trường khác không?
• Người dùng hiện tại có quyền gửi giá trị này không?

Cách đặt câu hỏi theo từng trường dữ liệu giúp quá trình kiểm thử có hệ thống hơn và giảm nguy cơ bỏ sót các trường hợp biên.

Xác định kết quả mong đợi trước khi gửi request

Một lỗi phổ biến trong kiểm thử thủ công là gửi request trước rồi nhìn response để quyết định kết quả có vẻ đúng hay không.

Cách làm tốt hơn là xác định expected result trước khi kiểm tra. Khi đã biết rõ API phải làm gì, người kiểm thử sẽ dễ phát hiện những sai lệch nhỏ.

Kết quả mong đợi không chỉ là status code. Nó có thể bao gồm:

• Trạng thái HTTP.
• Cấu trúc response.
• Thông tin phải được trả về.
• Thông tin không được phép trả về.
• Dữ liệu có được lưu hoặc thay đổi hay không.
• Trạng thái dữ liệu sau khi API thực hiện.
• Thông báo lỗi trong trường hợp thất bại.

Những kiến thức cần chuẩn bị trước khi thực hành API Testing

Không cần phải là lập trình viên mới có thể kiểm thử API, nhưng hiểu một số kiến thức nền tảng sẽ giúp quá trình kiểm tra chính xác và hiệu quả hơn.

Hiểu HTTP status code phổ biến

Status code cho biết kết quả tổng quát của request. Tuy nhiên, cần hiểu ý nghĩa thay vì chỉ nhớ con số.

Status	Ý nghĩa cơ bản	Tình huống thường gặp
200	Request được xử lý thành công	Lấy hoặc xử lý dữ liệu thành công
201	Tài nguyên mới được tạo	Tạo tài khoản hoặc bản ghi mới
400	Request không hợp lệ	Dữ liệu gửi lên sai hoặc thiếu
401	Chưa được xác thực hợp lệ	Thiếu hoặc sai thông tin xác thực
403	Không có quyền thực hiện	Người dùng đã xác thực nhưng bị từ chối quyền
404	Không tìm thấy tài nguyên	ID hoặc endpoint không tồn tại
422	Dữ liệu không đạt yêu cầu xử lý	Validation nghiệp vụ thất bại
500	Lỗi phía server	Hệ thống xảy ra lỗi khi xử lý

Việc API trả status code đúng rất quan trọng vì client thường dựa vào mã trạng thái để quyết định cách xử lý tiếp theo.

Hiểu cấu trúc dữ liệu JSON

JSON là định dạng dữ liệu phổ biến trong API hiện đại. Người kiểm thử cần có khả năng đọc cấu trúc object, array, string, number, boolean và giá trị rỗng.

Quan trọng hơn, cần kiểm tra tính nhất quán của cấu trúc. Một API không nên lúc trả về một object, lúc khác lại thay đổi thành array mà không có quy ước rõ ràng.

Sự không nhất quán của response có thể khiến phía client phát sinh lỗi dù dữ liệu bên trong vẫn tồn tại.

Hiểu cơ chế xác thực API

Nhiều API yêu cầu thông tin xác thực trước khi cho phép truy cập. Người kiểm thử cần biết hệ thống đang sử dụng cơ chế nào và dữ liệu xác thực được truyền ở đâu.

Điều quan trọng không chỉ là biết cách gửi token hợp lệ mà còn phải chủ động kiểm tra các trường hợp token không hợp lệ, hết hạn hoặc không có quyền.

Hiểu dữ liệu và trạng thái hệ thống

API Testing hiệu quả thường cần kiểm tra dữ liệu trước và sau khi thực hiện request.

Ví dụ, khi gọi API hủy đơn hàng, không nên chỉ kiểm tra response trả về thành công. Cần xác định trạng thái đơn hàng trong hệ thống có thực sự thay đổi hay không, số lượng tồn kho có được xử lý đúng không và người dùng có được phép hủy đơn hàng ở trạng thái hiện tại hay không.

Đây chính là sự khác biệt giữa việc kiểm tra response đơn giản và kiểm thử logic nghiệp vụ thực sự.

Cách xây dựng test case API để không bỏ sót lỗi quan trọng

Một API có thể có hàng chục trường dữ liệu, nhiều điều kiện nghiệp vụ và các trạng thái xử lý khác nhau. Nếu kiểm thử theo kiểu mở công cụ rồi thử ngẫu nhiên từng request, quá trình test dễ trở nên thiếu hệ thống. Có thể phát hiện được một vài lỗi đơn giản nhưng lại bỏ sót những trường hợp quan trọng.

Test case API nên được xây dựng dựa trên hành vi mong đợi của hệ thống thay vì chỉ dựa vào danh sách endpoint. Mỗi endpoint cần được phân tích theo câu hỏi: API nhận gì, xử lý như thế nào, ai được phép sử dụng và trạng thái hệ thống thay đổi ra sao sau khi request hoàn thành.

Một test case API cơ bản thường cần làm rõ các thành phần sau:

Thành phần	Nội dung cần xác định
Mục tiêu kiểm thử	Chức năng hoặc tình huống cần kiểm tra
Endpoint	Địa chỉ API cần thực hiện request
HTTP Method	GET, POST, PUT, PATCH hoặc DELETE
Điều kiện trước khi test	Trạng thái dữ liệu hoặc quyền người dùng cần có
Dữ liệu đầu vào	Parameters, headers và request body
Các bước thực hiện	Trình tự gửi request và kiểm tra
Kết quả mong đợi	Status code, response và thay đổi dữ liệu

Tuy nhiên, trong dự án thực tế không nhất thiết phải biến mọi test case thành một tài liệu quá dài. Điều quan trọng là người kiểm thử xác định được đầy đủ các điều kiện và có thể lặp lại quá trình kiểm tra một cách nhất quán.

Phân tích API theo đầu vào, xử lý và đầu ra

Một cách đơn giản nhưng hiệu quả để xây dựng test case là chia API thành ba phần: dữ liệu đầu vào, quá trình xử lý và kết quả đầu ra.

Giả sử có API tạo tài khoản người dùng. Thay vì chỉ tạo một test case với email và mật khẩu hợp lệ, cần phân tích toàn bộ luồng:

• API nhận những trường dữ liệu nào?
• Trường nào bắt buộc?
• Kiểu dữ liệu của từng trường là gì?
• Dữ liệu nào cần kiểm tra định dạng?
• Dữ liệu nào phải là duy nhất?
• API xử lý thế nào nếu email đã tồn tại?
• Mật khẩu có yêu cầu độ dài tối thiểu không?
• Sau khi tạo thành công, hệ thống tạo dữ liệu nào?
• Response có trả về thông tin nhạy cảm không?

Chỉ với một endpoint, cách phân tích này đã tạo ra nhiều tình huống kiểm thử hơn rất nhiều so với việc chỉ kiểm tra một request thành công.

Không chỉ test dữ liệu, cần test cả trạng thái hệ thống

Một API có thể trả về response hoàn toàn đúng nhưng dữ liệu bên trong hệ thống lại sai. Vì vậy, với các API làm thay đổi dữ liệu, việc kiểm tra response là chưa đủ.

Ví dụ, API tạo đơn hàng trả về thành công. Người kiểm thử cần tiếp tục kiểm tra:

• Đơn hàng có thực sự được tạo hay không.
• Số tiền được lưu có chính xác không.
• Sản phẩm trong đơn hàng có đúng số lượng không.
• Trạng thái đơn hàng ban đầu có đúng không.
• Tồn kho có bị thay đổi đúng theo nghiệp vụ không.
• Request gửi lại có tạo thêm đơn hàng trùng hay không.

Đây là tư duy quan trọng khi kiểm thử API. Response chỉ là thông tin API thông báo ra bên ngoài, còn trạng thái dữ liệu mới phản ánh đầy đủ kết quả xử lý của hệ thống.

Positive Testing và Negative Testing trong API Testing

Một API không thể được đánh giá đầy đủ nếu chỉ kiểm tra trường hợp người dùng gửi dữ liệu hoàn toàn chính xác. Trong môi trường thực tế, hệ thống luôn phải đối mặt với dữ liệu thiếu, sai định dạng, request bất thường hoặc hành vi không đúng quy trình.

Vì vậy, hai nhóm kiểm thử cơ bản cần được thực hiện song song là Positive Testing và Negative Testing.

Positive Testing kiểm tra điều gì?

Positive Testing kiểm tra API trong điều kiện dữ liệu và thao tác hợp lệ. Mục tiêu là xác nhận hệ thống thực hiện đúng chức năng khi nhận được yêu cầu đúng.

Ví dụ với API đăng nhập:

• Email tồn tại và đúng định dạng.
• Mật khẩu chính xác.
• Tài khoản đang hoạt động.
• Request chứa đầy đủ thông tin cần thiết.

Kết quả mong đợi có thể là API xác thực thành công và trả về dữ liệu cần thiết để người dùng tiếp tục sử dụng hệ thống.

Positive Testing là nền tảng nhưng không nên dừng ở một trường hợp duy nhất. Một API có thể có nhiều dữ liệu hợp lệ khác nhau. Cần kiểm tra các tổ hợp dữ liệu có khả năng ảnh hưởng đến logic xử lý.

Negative Testing giúp phát hiện lỗi ở đâu?

Negative Testing kiểm tra phản ứng của API khi nhận request không hợp lệ hoặc không đáp ứng điều kiện nghiệp vụ.

Ví dụ:

• Không gửi email.
• Email sai định dạng.
• Mật khẩu sai.
• Token không hợp lệ.
• ID tài nguyên không tồn tại.
• Gửi giá trị âm vào trường chỉ chấp nhận số dương.
• Gửi chuỗi văn bản vào trường yêu cầu kiểu số.
• Gửi request không đúng thứ tự nghiệp vụ.

Mục tiêu của Negative Testing không phải khiến API trả về lỗi càng nhiều càng tốt. Mục tiêu là xác nhận API từ chối request không hợp lệ một cách chính xác, an toàn và không làm thay đổi dữ liệu ngoài ý muốn.

Một API tốt phải biết xử lý cả tình huống thành công lẫn thất bại.

Negative Testing đặc biệt quan trọng với API công khai

Giao diện người dùng thường giới hạn cách người dùng nhập dữ liệu. Ví dụ, một ô nhập tuổi có thể chỉ cho phép nhập số. Nhưng API không thể giả định rằng mọi request đều đi qua giao diện đó.

Một người có thể gửi request trực tiếp đến API với bất kỳ dữ liệu nào. Vì vậy, validation phía backend phải được kiểm thử độc lập.

Nếu hệ thống chỉ dựa vào validation của giao diện, API có thể nhận dữ liệu bất thường ngay khi bị gọi trực tiếp.

Kiểm thử Boundary Value để tìm lỗi tại các giá trị biên

Nhiều lỗi không xuất hiện ở dữ liệu thông thường mà chỉ xuất hiện khi giá trị nằm sát giới hạn. Đây là lý do Boundary Value Testing trở thành một kỹ thuật quan trọng.

Giả sử API yêu cầu tên người dùng có độ dài từ 3 đến 50 ký tự. Nếu chỉ kiểm tra một giá trị 10 ký tự, bạn chưa thực sự xác nhận được validation hoạt động đúng.

Các giá trị cần được quan tâm gồm:

• Nhỏ hơn giới hạn dưới một đơn vị.
• Đúng giới hạn dưới.
• Lớn hơn giới hạn dưới một đơn vị.
• Nhỏ hơn giới hạn trên một đơn vị.
• Đúng giới hạn trên.
• Lớn hơn giới hạn trên một đơn vị.

Với ví dụ độ dài từ 3 đến 50 ký tự, những trường hợp đáng kiểm tra gồm 2, 3, 4, 49, 50 và 51 ký tự.

Phương pháp này áp dụng cho nhiều loại dữ liệu:

• Độ dài chuỗi.
• Giá trị số.
• Số lượng sản phẩm.
• Giới hạn dung lượng upload.
• Số phần tử trong danh sách.
• Thời gian hiệu lực.
• Phân trang.

Đừng bỏ qua giá trị rỗng và giá trị đặc biệt

Ngoài giá trị biên thông thường, cần kiểm tra các trường hợp đặc biệt như giá trị rỗng, null, chuỗi chỉ chứa khoảng trắng hoặc dữ liệu có cấu trúc bất thường.

Ví dụ, một trường tên người dùng có thể không chấp nhận chuỗi rỗng. Nhưng nếu gửi một chuỗi chỉ chứa khoảng trắng thì hệ thống xử lý như thế nào?

Đây là những trường hợp tưởng nhỏ nhưng thường gây ra lỗi dữ liệu trong hệ thống.

Hướng dẫn kiểm thử API CRUD trong thực tế

CRUD là nhóm thao tác phổ biến trong phần lớn hệ thống quản lý dữ liệu, bao gồm Create, Read, Update và Delete. Tuy nhiên, kiểm thử CRUD không nên thực hiện từng API một cách độc lập hoàn toàn.

Các thao tác này thường liên quan đến cùng một tài nguyên, vì vậy kết quả của API trước có thể trở thành điều kiện kiểm tra cho API tiếp theo.

Kiểm thử API Create

Với API tạo dữ liệu mới, trường hợp đầu tiên cần kiểm tra là request hoàn toàn hợp lệ. Sau đó cần xác nhận dữ liệu được tạo đúng.

Các điểm quan trọng bao gồm:

• Dữ liệu bắt buộc có được kiểm tra không.
• Dữ liệu tùy chọn có được xử lý đúng không.
• Giá trị mặc định có đúng không.
• Dữ liệu trùng lặp được xử lý thế nào.
• Dữ liệu không hợp lệ có bị từ chối không.
• Tài nguyên sau khi tạo có đúng thông tin không.
• Response có chứa dữ liệu nhạy cảm không cần thiết không.

Một vấn đề quan trọng cần chú ý là request lặp lại. Trong một số tình huống, kết nối mạng không ổn định khiến client gửi lại request. Nếu API không có cơ chế xử lý phù hợp, một thao tác có thể tạo ra nhiều bản ghi trùng nhau.

Kiểm thử API Read

API đọc dữ liệu cần được kiểm tra không chỉ về việc có trả dữ liệu hay không mà còn về phạm vi dữ liệu được phép hiển thị.

Các tình huống quan trọng gồm:

• Lấy dữ liệu khi tài nguyên tồn tại.
• Lấy dữ liệu khi tài nguyên không tồn tại.
• Người dùng không đăng nhập.
• Người dùng không có quyền.
• Dữ liệu trả về có đầy đủ không.
• Dữ liệu nhạy cảm có bị lộ không.
• Phân trang có chính xác không.
• Bộ lọc có trả về đúng kết quả không.
• Sắp xếp có đúng theo điều kiện yêu cầu không.

Đặc biệt với API danh sách, cần kiểm tra trường hợp không có dữ liệu. Response khi danh sách rỗng cần được thiết kế nhất quán để phía client có thể xử lý ổn định.

Kiểm thử API Update

API cập nhật thường phức tạp hơn tạo mới vì nó liên quan đến trạng thái dữ liệu hiện tại.

Khi kiểm thử, cần xác định rõ API được phép thay đổi những trường nào và trường nào không được phép chỉnh sửa.

Một số tình huống nên kiểm tra:

• Cập nhật với dữ liệu hợp lệ.
• Cập nhật một phần dữ liệu.
• Không truyền trường bắt buộc.
• Cập nhật ID không tồn tại.
• Cập nhật tài nguyên không thuộc quyền sở hữu.
• Cố gắng thay đổi trường không được phép.
• Gửi cùng một dữ liệu nhiều lần.
• Cập nhật làm phát sinh xung đột dữ liệu.

Điểm cần chú ý là kiểm tra dữ liệu không được cập nhật ngoài ý muốn. Một request chỉ thay đổi tên không nên vô tình làm mất các trường khác.

Kiểm thử API Delete

Delete là thao tác có nguy cơ ảnh hưởng trực tiếp đến dữ liệu. Một bài kiểm thử tốt cần xác nhận không chỉ việc API có xóa thành công hay không mà còn kiểm tra các quan hệ liên quan.

Ví dụ, khi xóa một danh mục sản phẩm, hệ thống xử lý các sản phẩm thuộc danh mục đó như thế nào? Có cho phép xóa hay phải từ chối? Nếu xóa, dữ liệu liên quan được xử lý theo quy tắc nào?

Các trường hợp cần kiểm tra:

• Xóa tài nguyên tồn tại.
• Xóa tài nguyên không tồn tại.
• Xóa khi không có quyền.
• Xóa dữ liệu đang được sử dụng bởi dữ liệu khác.
• Gửi lại request xóa nhiều lần.
• Kiểm tra dữ liệu sau khi xóa.

Kiểm thử Authentication và Authorization một cách có hệ thống

Authentication và Authorization là hai lớp kiểm tra bắt buộc với những API có dữ liệu riêng tư hoặc chức năng phân quyền. Không ít hệ thống chỉ kiểm tra token có tồn tại hay không mà chưa thực sự kiểm tra quyền truy cập ở từng tài nguyên.

Các tình huống Authentication cần kiểm tra

Không nên chỉ đăng nhập thành công rồi sử dụng token để kiểm tra các API khác. Cần chủ động tạo các tình huống lỗi.

• Không gửi thông tin xác thực.
• Gửi token sai.
• Gửi token đã hết hạn.
• Gửi token đã bị thu hồi.
• Gửi token sai định dạng.
• Gửi thông tin xác thực không đúng vị trí.
• Gửi request với thông tin xác thực của tài khoản đã bị khóa.

Mỗi tình huống cần có phản hồi rõ ràng và nhất quán. Quan trọng hơn, request không hợp lệ không được phép tiếp tục thực hiện logic phía sau.

Kiểm thử quyền theo vai trò

Nếu hệ thống có nhiều nhóm người dùng như quản trị viên, nhân viên và khách hàng, mỗi vai trò cần được kiểm tra riêng.

Không nên chỉ test bằng tài khoản quản trị vì tài khoản này thường có nhiều quyền nhất. Những lỗi phân quyền thường chỉ xuất hiện khi kiểm tra bằng tài khoản có quyền hạn chế.

Có thể xây dựng một ma trận quyền đơn giản:

Chức năng	Khách	Người dùng	Quản trị viên
Xem dữ liệu công khai	Cho phép	Cho phép	Cho phép
Xem dữ liệu cá nhân	Từ chối	Cho phép dữ liệu của mình	Theo chính sách hệ thống
Tạo dữ liệu quản trị	Từ chối	Từ chối	Cho phép
Xóa dữ liệu hệ thống	Từ chối	Từ chối hoặc giới hạn	Cho phép theo quyền

Cách kiểm tra này giúp phát hiện những endpoint có thể đã được bảo vệ bằng authentication nhưng chưa được kiểm soát authorization đầy đủ.

Kiểm tra quyền sở hữu dữ liệu

Phân quyền không chỉ dựa trên vai trò. Nhiều hệ thống còn yêu cầu kiểm tra quyền sở hữu tài nguyên.

Ví dụ, hai người dùng đều có quyền xem đơn hàng của mình. Tuy nhiên, người dùng A không được phép xem đơn hàng của người dùng B.

Một cách kiểm tra quan trọng là sử dụng tài khoản A, sau đó thử truy cập ID tài nguyên thuộc tài khoản B. Nếu API chỉ kiểm tra người dùng đã đăng nhập mà không kiểm tra quyền sở hữu, dữ liệu có thể bị lộ.

Kiểm thử Request và Response không chỉ nhìn bằng mắt

Khi mới bắt đầu API Testing, nhiều người thường gửi request rồi đọc response để xác nhận kết quả. Phương pháp này có thể phù hợp với vài request đơn giản nhưng nhanh chóng trở nên khó kiểm soát khi số lượng endpoint tăng lên.

Cách tiếp cận tốt hơn là xác định rõ từng thành phần cần kiểm tra.

Những yếu tố cần kiểm tra trong Request

Request cần được xem xét từ nhiều góc độ:

• Endpoint có đúng không.
• HTTP Method có đúng không.
• Headers có đầy đủ không.
• Token có hợp lệ không.
• Parameters có đúng tên không.
• Kiểu dữ liệu có đúng không.
• Request body có đúng cấu trúc không.
• Dữ liệu có vượt giới hạn không.

Việc thay đổi từng thành phần của request một cách có chủ đích sẽ giúp phát hiện API xử lý lỗi ở đâu.

Những yếu tố cần kiểm tra trong Response

Response cần được kiểm tra theo nhiều lớp thay vì chỉ kiểm tra một status code.

• Status code có đúng tình huống không.
• Content-Type có phù hợp không.
• Cấu trúc response có nhất quán không.
• Các trường bắt buộc có tồn tại không.
• Kiểu dữ liệu có đúng không.
• Giá trị trả về có chính xác không.
• Thông tin nhạy cảm có bị lộ không.
• Thông báo lỗi có hỗ trợ client xử lý không.
• Thời gian phản hồi có đáp ứng yêu cầu không.

Một API tốt không chỉ trả dữ liệu đúng mà còn phải duy trì cấu trúc ổn định. Nếu mỗi tình huống lại trả về một cấu trúc khác nhau mà không có quy ước rõ ràng, việc tích hợp API sẽ trở nên khó khăn.

Kiểm thử Error Handling để API không thất bại một cách khó kiểm soát

Lỗi là điều không thể tránh khỏi trong một hệ thống thực tế. Điều quan trọng không phải là cố gắng tạo ra API không bao giờ xảy ra lỗi mà là thiết kế cách hệ thống phản ứng khi lỗi xuất hiện.

Error Handling cần được kiểm thử vì một request bất thường không nên khiến toàn bộ hệ thống phản hồi một cách không kiểm soát.

API cần phân biệt các loại lỗi

Lỗi do người dùng gửi dữ liệu sai khác với lỗi do server gặp sự cố. Nếu tất cả tình huống đều trả về cùng một kiểu lỗi, phía client sẽ khó xử lý chính xác.

Ví dụ, thiếu một trường bắt buộc là lỗi có thể được người dùng sửa ngay. Trong khi đó, lỗi hệ thống nội bộ lại cần được xử lý ở phía server.

Vì vậy, cần kiểm tra API có phân loại tình huống hợp lý hay không.

Thông báo lỗi không được làm lộ thông tin nội bộ

Khi API gặp lỗi, thông tin trả về cho client cần đủ để xác định vấn đề nhưng không nên chứa chi tiết nội bộ như đường dẫn server, truy vấn cơ sở dữ liệu hoặc thông tin cấu hình.

Đây là điểm thường bị bỏ qua trong quá trình kiểm thử chức năng. API có thể xử lý đúng nhưng response lỗi lại vô tình tiết lộ cấu trúc bên trong của hệ thống.

Kiểm tra tính nhất quán của response lỗi

Nếu API thành công luôn trả về một cấu trúc nhất định nhưng khi thất bại mỗi endpoint lại trả về một kiểu khác nhau, phía client sẽ phải xử lý phức tạp hơn.

Do đó, cần kiểm tra hệ thống có quy ước chung cho response lỗi hay không. Ví dụ, các lỗi validation, authentication và lỗi hệ thống có thể có cấu trúc riêng nhưng cần nhất quán trong cùng nhóm.

Kiểm thử luồng API thay vì kiểm tra từng endpoint riêng lẻ

Một endpoint có thể hoạt động hoàn hảo khi kiểm tra độc lập nhưng lại gặp lỗi khi đặt trong luồng nghiệp vụ thực tế.

Ví dụ, quy trình mua hàng có thể bao gồm nhiều bước:

1. Người dùng đăng nhập.
2. Lấy thông tin sản phẩm.
3. Thêm sản phẩm vào giỏ hàng.
4. Áp dụng mã giảm giá.
5. Tạo đơn hàng.
6. Thực hiện thanh toán.
7. Cập nhật trạng thái đơn hàng.

Nếu chỉ kiểm tra từng endpoint riêng lẻ, có thể bỏ qua lỗi xảy ra khi dữ liệu được truyền từ bước này sang bước khác.

Kiểm tra dữ liệu xuyên suốt toàn bộ luồng

Khi thực hiện API Flow Testing, dữ liệu trả về từ request trước thường được sử dụng cho request tiếp theo.

Ví dụ, ID đơn hàng được tạo ở bước tạo đơn sẽ được sử dụng trong API thanh toán. Nếu API trả về ID không đúng hoặc API tiếp theo xử lý sai trạng thái, lỗi chỉ xuất hiện khi chạy toàn bộ luồng.

Đây cũng là nền tảng quan trọng để xây dựng API Automation Test.

Kiểm tra các trạng thái không đúng thứ tự

Một hệ thống có quy trình nghiệp vụ thường yêu cầu các thao tác diễn ra theo thứ tự nhất định.

Ví dụ, một đơn hàng chưa thanh toán không thể được chuyển trực tiếp sang trạng thái hoàn thành nếu nghiệp vụ không cho phép.

Người kiểm thử nên chủ động gửi các request sai thứ tự để xác nhận backend thực sự kiểm soát trạng thái thay vì chỉ tin tưởng vào luồng được thiết kế trên giao diện.

Những lỗi phổ biến khi mới bắt đầu API Testing

API Testing không khó để bắt đầu, nhưng để kiểm thử sâu thì cần thay đổi cách tư duy. Nhiều lỗi quan trọng bị bỏ sót không phải vì thiếu công cụ mà vì cách tiếp cận chưa đúng.

Chỉ kiểm tra status code

Đây là lỗi phổ biến nhất. API trả về HTTP 200 không đồng nghĩa với việc toàn bộ dữ liệu và nghiệp vụ đều chính xác.

Luôn kiểm tra thêm response body, dữ liệu thực tế và trạng thái hệ thống sau khi request được xử lý.

Chỉ test trường hợp thành công

Một API thường hoạt động tốt nhất khi nhận dữ liệu hoàn hảo. Giá trị thực sự của kiểm thử nằm ở việc tìm ra điều gì xảy ra khi dữ liệu không hoàn hảo.

Negative Testing cần được xem là một phần bắt buộc thay vì công việc thực hiện thêm khi còn thời gian.

Không kiểm tra quyền sở hữu tài nguyên

Nhiều hệ thống đã kiểm tra người dùng đăng nhập nhưng lại quên kiểm tra tài nguyên đó thuộc về ai.

Đây là lỗi có thể dẫn đến việc một người dùng truy cập dữ liệu của người khác chỉ bằng cách thay đổi ID trong request.

Không kiểm tra dữ liệu sau khi API xử lý

Response có thể báo thành công nhưng thao tác trong cơ sở dữ liệu chưa chắc đã đúng.

Với các API quan trọng, cần kiểm tra hậu quả thực tế của request thay vì chỉ tin tưởng response.

Test thủ công lặp đi lặp lại quá lâu

Kiểm thử thủ công rất phù hợp khi khám phá API hoặc tìm lỗi mới. Nhưng khi số lượng test case tăng lên, việc lặp lại cùng một bộ kiểm tra bằng tay sẽ tốn thời gian và dễ xảy ra sai sót.

Những test case ổn định, được sử dụng thường xuyên và có kết quả rõ ràng nên được cân nhắc tự động hóa.

Các công cụ API Testing phổ biến và cách lựa chọn phù hợp

Công cụ API Testing giúp gửi request, quan sát response, lưu test case và tự động hóa một phần quá trình kiểm thử. Tuy nhiên, công cụ chỉ hỗ trợ thao tác kỹ thuật, không thể thay thế tư duy kiểm thử. Một bộ test được xây dựng thiếu logic dù sử dụng công cụ hiện đại vẫn có thể bỏ sót lỗi nghiêm trọng.

Khi lựa chọn công cụ, nên dựa vào mục tiêu sử dụng thay vì chọn công cụ có nhiều tính năng nhất. Một số dự án chỉ cần kiểm thử thủ công trong giai đoạn phát triển, trong khi hệ thống lớn có thể cần automation, performance testing và tích hợp kiểm thử vào quy trình triển khai.

Công cụ gửi và kiểm tra request

Nhóm công cụ này phù hợp để khám phá API, gửi request thủ công, kiểm tra response và xây dựng các bộ kiểm thử cơ bản. Chúng đặc biệt hữu ích trong giai đoạn phát triển vì lập trình viên và tester có thể nhanh chóng thay đổi dữ liệu đầu vào để quan sát phản ứng của hệ thống.

Khi sử dụng công cụ kiểm thử request, nên tận dụng khả năng lưu environment để tránh phải nhập lại các thông tin như địa chỉ server, token hoặc biến dùng chung. Điều này giúp giảm lỗi thao tác khi chuyển giữa môi trường local, testing và production.

Công cụ hỗ trợ API Automation

Khi số lượng API tăng lên, việc kiểm tra thủ công toàn bộ hệ thống sau mỗi lần cập nhật sẽ không còn hiệu quả. API Automation cho phép định nghĩa các điều kiện kiểm tra và chạy lại chúng nhiều lần.

Một bộ automation có thể thực hiện hàng trăm request trong thời gian ngắn, kiểm tra response theo điều kiện định trước và thông báo khi phát hiện sai lệch.

Tuy nhiên, không phải mọi test case đều cần tự động hóa. Những tình huống còn thay đổi liên tục hoặc yêu cầu đánh giá linh hoạt thường phù hợp hơn với kiểm thử thủ công.

Công cụ kiểm thử hiệu năng

Performance Testing yêu cầu khả năng tạo nhiều request đồng thời và đo lường phản ứng của hệ thống. Công cụ thuộc nhóm này giúp mô phỏng tải, theo dõi thời gian phản hồi, tỷ lệ lỗi và mức độ ổn định khi số lượng người dùng tăng lên.

Điều quan trọng là không chỉ chạy thật nhiều request. Một bài performance test cần mô phỏng hành vi gần với thực tế và xác định rõ mục tiêu trước khi thực hiện.

Thực hành API Testing với tư duy của một quy trình chuyên nghiệp

Một quy trình kiểm thử API hiệu quả không bắt đầu bằng việc mở công cụ và nhập URL endpoint. Trước đó cần có bước phân tích để hiểu API, dữ liệu và nghiệp vụ.

Có thể triển khai quy trình theo các bước sau.

Thu thập tài liệu API

Trước khi kiểm thử, cần xác định API đang cung cấp những endpoint nào, mỗi endpoint sử dụng method gì, nhận dữ liệu ra sao và yêu cầu xác thực như thế nào.

Tài liệu API tốt nên mô tả được:

• Mục đích của endpoint.
• HTTP Method.
• Parameters.
• Headers cần thiết.
• Cấu trúc request body.
• Kiểu response.
• Status code có thể xảy ra.
• Quyền truy cập yêu cầu.

Tuy nhiên, không nên coi tài liệu API là kết quả tuyệt đối. Tài liệu mô tả API cần hoạt động như thế nào, còn API Testing xác nhận hệ thống có thực sự hoạt động đúng như vậy hay không.

Phân loại endpoint theo mức độ quan trọng

Không phải API nào cũng có mức độ rủi ro giống nhau. API hiển thị một danh sách dữ liệu công khai có thể ít nguy hiểm hơn API thanh toán hoặc thay đổi quyền người dùng.

Khi thời gian kiểm thử có giới hạn, nên ưu tiên các endpoint liên quan đến:

• Xác thực người dùng.
• Phân quyền.
• Thanh toán.
• Thay đổi dữ liệu quan trọng.
• Thông tin cá nhân.
• Tích hợp hệ thống bên thứ ba.
• Nghiệp vụ có nhiều điều kiện xử lý.

Cách tiếp cận dựa trên mức độ rủi ro giúp tập trung nguồn lực vào những khu vực có khả năng gây hậu quả lớn nhất nếu xảy ra lỗi.

Xây dựng dữ liệu kiểm thử riêng

Dữ liệu test nên được kiểm soát thay vì sử dụng ngẫu nhiên dữ liệu có sẵn. Nếu môi trường test chứa dữ liệu thay đổi liên tục, cùng một test case có thể cho kết quả khác nhau ở mỗi lần chạy.

Nên chuẩn bị các nhóm dữ liệu phục vụ từng mục đích:

• Dữ liệu hợp lệ.
• Dữ liệu không hợp lệ.
• Dữ liệu ở giá trị biên.
• Dữ liệu trùng lặp.
• Dữ liệu thuộc các nhóm quyền khác nhau.
• Dữ liệu phục vụ kiểm thử trạng thái.

Việc quản lý dữ liệu test tốt đặc biệt quan trọng với automation. Một bài test chỉ đáng tin cậy khi có thể chạy lặp lại với kết quả ổn định.

API Automation Testing là gì và khi nào nên áp dụng?

API Automation Testing là việc sử dụng mã lệnh hoặc công cụ để tự động gửi request và kiểm tra kết quả theo các điều kiện được xác định trước.

Mục tiêu lớn nhất của automation không phải thay thế hoàn toàn con người mà là giảm thời gian dành cho những công việc lặp lại.

Những test case phù hợp để tự động hóa

Một test case nên được cân nhắc automation khi có các đặc điểm sau:

• Được thực hiện thường xuyên.
• Có kết quả mong đợi rõ ràng.
• Ít phụ thuộc vào đánh giá cảm tính.
• Cần chạy lại sau mỗi lần cập nhật.
• Thuộc chức năng quan trọng của hệ thống.

Ví dụ, kiểm tra đăng nhập, tạo dữ liệu, phân quyền hoặc các luồng nghiệp vụ quan trọng thường phù hợp để đưa vào regression test tự động.

Không nên tự động hóa mọi thứ

Một sai lầm phổ biến là cố gắng đưa toàn bộ quá trình kiểm thử vào automation. Điều này có thể khiến chi phí xây dựng và bảo trì bộ test lớn hơn giá trị mang lại.

Automation cần được ưu tiên theo giá trị. Những chức năng ổn định và cần chạy lặp lại thường mang lại hiệu quả cao hơn các test case thay đổi liên tục.

Một bài API Automation cần kiểm tra gì?

Automation không nên chỉ gửi request rồi xác nhận status code. Một bài test chất lượng cần có nhiều assertion phù hợp.

• Kiểm tra HTTP status.
• Kiểm tra cấu trúc response.
• Kiểm tra trường dữ liệu bắt buộc.
• Kiểm tra giá trị mong đợi.
• Kiểm tra kiểu dữ liệu.
• Kiểm tra thời gian phản hồi khi cần thiết.
• Kiểm tra trạng thái dữ liệu sau request.

Việc kiểm tra nhiều lớp giúp automation phát hiện lỗi chính xác hơn thay vì tạo cảm giác an toàn giả khi tất cả request đều nhận được mã thành công.

Tích hợp API Testing vào CI/CD để phát hiện lỗi sớm

Một bộ API test sẽ có giá trị lớn hơn khi được tích hợp vào quy trình phát triển và triển khai. Thay vì chờ đến cuối dự án mới kiểm tra, hệ thống có thể tự động chạy các bài test quan trọng khi có thay đổi.

CI/CD giúp biến kiểm thử thành một phần của quy trình phát triển thay vì một bước được thực hiện riêng biệt.

Quy trình cơ bản có thể áp dụng

Một luồng đơn giản có thể được tổ chức như sau:

1. Lập trình viên cập nhật mã nguồn.
2. Thay đổi được đưa vào hệ thống quản lý mã nguồn.
3. Quy trình tự động được kích hoạt.
4. Ứng dụng được build hoặc triển khai trên môi trường phù hợp.
5. Bộ API test được chạy tự động.
6. Kết quả được ghi nhận.
7. Nếu test quan trọng thất bại, quá trình triển khai có thể bị chặn.

Cách làm này giúp phát hiện regression ngay sau khi thay đổi xuất hiện thay vì chờ đến khi người dùng báo lỗi.

Không nên để bộ test automation quá chậm

Một bộ test mất quá nhiều thời gian có thể làm giảm hiệu quả của quy trình CI/CD. Vì vậy, nên phân chia test theo mục đích.

• Smoke Test chạy nhanh để kiểm tra chức năng cốt lõi.
• Regression Test kiểm tra phạm vi rộng hơn.
• Performance Test thực hiện theo lịch hoặc môi trường riêng.
• Security Test chuyên sâu được triển khai theo quy trình phù hợp.

Việc phân tầng giúp các bài test quan trọng được chạy thường xuyên mà không khiến toàn bộ quy trình phát triển trở nên chậm chạp.

Kiểm thử hiệu năng API cần quan tâm những gì?

Một API phản hồi tốt với một request chưa thể chứng minh hệ thống hoạt động ổn định khi có hàng trăm hoặc hàng nghìn request đồng thời.

Performance Testing giúp đánh giá giới hạn thực tế của API trong các điều kiện tải khác nhau.

Response Time

Response Time là thời gian API cần để xử lý và trả kết quả. Đây là chỉ số dễ quan sát nhưng không nên được đánh giá độc lập.

Một API có thể phản hồi nhanh khi tải thấp nhưng chậm đáng kể khi số lượng request tăng. Vì vậy, thời gian phản hồi cần được đo trong các điều kiện khác nhau.

Throughput

Throughput phản ánh khả năng xử lý request trong một khoảng thời gian nhất định. Chỉ số này giúp đánh giá năng lực xử lý tổng thể của hệ thống.

Tuy nhiên, throughput cao không có ý nghĩa nếu tỷ lệ request lỗi cũng tăng mạnh. Các chỉ số hiệu năng cần được phân tích cùng nhau.

Error Rate

Khi tải tăng, cần theo dõi tỷ lệ request thất bại. Một hệ thống có thể phản hồi nhanh nhưng chỉ vì nhiều request bị từ chối hoặc lỗi.

Performance Testing cần xác định rõ nguyên nhân lỗi xuất phát từ đâu, chẳng hạn giới hạn server, kết nối cơ sở dữ liệu, tài nguyên xử lý hoặc logic API.

Khả năng phục hồi sau tải cao

Một yếu tố quan trọng khác là hành vi của hệ thống sau khi tải giảm xuống.

Có những hệ thống hoạt động bình thường ở tải thấp, gặp quá tải trong thời gian ngắn và tiếp tục không ổn định ngay cả khi lượng request đã trở lại bình thường.

Vì vậy, không nên chỉ quan sát hệ thống trong lúc tạo tải mà cần theo dõi cả giai đoạn phục hồi.

Kiểm thử bảo mật API từ những rủi ro cơ bản

API thường là điểm tiếp xúc trực tiếp với dữ liệu và logic nghiệp vụ. Nếu bảo mật API không tốt, giao diện được thiết kế cẩn thận cũng không thể bảo vệ hệ thống.

Kiểm thử bảo mật API nên bắt đầu từ các vấn đề cơ bản có khả năng xảy ra cao trước khi đi sâu vào các kỹ thuật phức tạp.

Kiểm tra xác thực ở mọi endpoint cần bảo vệ

Không nên giả định rằng chỉ vì phần lớn endpoint yêu cầu đăng nhập thì tất cả endpoint đều được bảo vệ.

Cần kiểm tra từng nhóm API quan trọng trong trạng thái không có thông tin xác thực. Đôi khi một endpoint phụ hoặc endpoint mới được phát triển có thể bị bỏ quên cơ chế bảo vệ.

Kiểm tra phân quyền theo từng tài nguyên

Người dùng hợp lệ vẫn có thể thực hiện request vượt quá quyền của mình nếu backend không kiểm tra đầy đủ.

Kiểm thử cần tập trung vào câu hỏi: người dùng này có quyền thực hiện hành động này trên chính tài nguyên này hay không?

Đây là cách tiếp cận quan trọng hơn việc chỉ kiểm tra tài khoản có đăng nhập thành công hay không.

Kiểm tra dữ liệu nhạy cảm trong response

API không nên trả về toàn bộ dữ liệu chỉ vì thông tin đó tồn tại trong cơ sở dữ liệu.

Khi kiểm thử response, cần kiểm tra các trường nhạy cảm có vô tình xuất hiện hay không. Nguyên tắc tốt là chỉ trả về những dữ liệu thực sự cần thiết cho client.

Kiểm tra khả năng chống request bất thường

API cần được kiểm tra với dữ liệu bất thường để xác định validation có hoạt động đúng không. Tuy nhiên, mục tiêu không phải gửi dữ liệu ngẫu nhiên mà cần xây dựng các trường hợp dựa trên kiểu dữ liệu và nghiệp vụ.

Ví dụ, một trường số có thể được kiểm tra với số âm, giá trị quá lớn, kiểu chuỗi hoặc giá trị rỗng. Một trường văn bản có thể được kiểm tra với độ dài vượt giới hạn và ký tự không mong đợi.

Kiểm tra giới hạn request khi cần thiết

Một số API nhạy cảm như đăng nhập, gửi mã xác thực hoặc thực hiện thao tác quan trọng cần có cơ chế kiểm soát tần suất request phù hợp.

Khi kiểm thử, cần xác định hệ thống phản ứng như thế nào nếu một client gửi nhiều request liên tiếp. Mục tiêu là đảm bảo cơ chế bảo vệ không ảnh hưởng quá mức đến người dùng hợp lệ nhưng vẫn hạn chế các hành vi bất thường.

Kiểm thử API tích hợp với hệ thống bên thứ ba

Một API có thể hoạt động hoàn hảo trong môi trường nội bộ nhưng vẫn gặp vấn đề khi kết nối với dịch vụ bên ngoài. Các hệ thống như thanh toán, vận chuyển, gửi email hoặc đồng bộ dữ liệu thường phụ thuộc vào API của bên thứ ba.

Vì vậy, Integration Testing cần kiểm tra không chỉ request gửi đi mà còn cách hệ thống phản ứng khi dịch vụ bên ngoài hoạt động không như mong đợi.

Không giả định API bên thứ ba luôn phản hồi thành công

Hệ thống cần được kiểm tra trong các tình huống như phản hồi chậm, trả lỗi, trả dữ liệu thiếu hoặc tạm thời không thể kết nối.

Một lỗi phổ biến là toàn bộ luồng nghiệp vụ bị treo vì hệ thống đang chờ dịch vụ bên ngoài phản hồi quá lâu.

Kiểm tra dữ liệu giữa hai hệ thống

Khi dữ liệu được gửi từ hệ thống này sang hệ thống khác, cần kiểm tra sự nhất quán.

Ví dụ, một giao dịch được tạo thành công ở hệ thống bên ngoài nhưng hệ thống nội bộ lại chưa cập nhật trạng thái. Hoặc ngược lại, hệ thống nội bộ báo thành công trước khi xác nhận kết quả thực tế.

Đây là những lỗi thường không xuất hiện khi kiểm tra endpoint độc lập mà chỉ được phát hiện khi kiểm thử toàn bộ luồng tích hợp.

Checklist API Testing trước khi đưa chức năng vào sử dụng

Checklist không thay thế cho tư duy kiểm thử nhưng giúp hạn chế việc bỏ sót những vấn đề cơ bản. Tùy từng dự án, danh sách có thể được điều chỉnh theo nghiệp vụ.

Checklist về chức năng

• Endpoint có hoạt động đúng mục đích không.
• HTTP Method có được xử lý đúng không.
• Dữ liệu hợp lệ có cho kết quả đúng không.
• Dữ liệu không hợp lệ có bị từ chối không.
• Các trường bắt buộc có được kiểm tra không.
• Logic nghiệp vụ có xử lý đúng không.
• Dữ liệu sau khi xử lý có đúng không.

Checklist về response

• Status code có phù hợp không.
• Cấu trúc response có nhất quán không.
• Các trường cần thiết có đầy đủ không.
• Kiểu dữ liệu có chính xác không.
• Thông báo lỗi có rõ ràng không.
• Response có chứa thông tin không cần thiết không.

Checklist về Authentication và Authorization

• API cần bảo vệ có yêu cầu xác thực không.
• Token không hợp lệ có bị từ chối không.
• Token hết hạn có bị xử lý đúng không.
• Người dùng không có quyền có bị từ chối không.
• Người dùng có thể truy cập dữ liệu của người khác không.
• Các vai trò khác nhau có được kiểm tra riêng không.

Checklist về dữ liệu biên

• Giá trị nhỏ nhất.
• Giá trị lớn nhất.
• Giá trị nhỏ hơn giới hạn.
• Giá trị lớn hơn giới hạn.
• Dữ liệu rỗng.
• Dữ liệu null.
• Kiểu dữ liệu không đúng.
• Dữ liệu trùng lặp.

Checklist về hiệu năng và độ ổn định

• Thời gian phản hồi có phù hợp không.
• API có ổn định khi nhiều request không.
• Tỷ lệ lỗi thay đổi thế nào khi tải tăng.
• Hệ thống có phục hồi sau tải cao không.
• Các endpoint quan trọng có được ưu tiên kiểm tra không.

Làm thế nào để nâng cao chất lượng API Testing trong dự án thực tế?

Chất lượng API Testing không phụ thuộc hoàn toàn vào số lượng test case. Một bộ test có hàng nghìn trường hợp nhưng tập trung vào những tình huống ít quan trọng vẫn có thể bỏ sót lỗi nghiêm trọng.

Điều quan trọng là xây dựng tư duy kiểm thử dựa trên rủi ro và nghiệp vụ.

Kiểm thử từ yêu cầu thay vì chỉ từ endpoint

Endpoint chỉ cho biết hệ thống cung cấp một chức năng kỹ thuật. Yêu cầu nghiệp vụ mới cho biết chức năng đó phải hoạt động như thế nào.

Ví dụ, tài liệu có thể nói API dùng để hủy đơn hàng. Nhưng kiểm thử chuyên sâu cần trả lời thêm: đơn hàng nào được phép hủy, ai có quyền hủy, hủy ở trạng thái nào, dữ liệu liên quan thay đổi ra sao và điều gì xảy ra nếu request được gửi nhiều lần.

Kiểm thử từ yêu cầu giúp phát hiện những lỗi mà việc chỉ đọc tài liệu kỹ thuật có thể bỏ qua.

Ưu tiên kiểm tra các điểm có rủi ro cao

Những chức năng liên quan đến tiền, dữ liệu cá nhân, phân quyền hoặc thay đổi trạng thái quan trọng cần được kiểm tra sâu hơn.

Không nên phân bổ thời gian giống nhau cho mọi endpoint. API có mức độ ảnh hưởng lớn khi xảy ra lỗi cần được ưu tiên cả về số lượng test case lẫn mức độ kiểm tra.

Xây dựng bộ regression test theo thời gian

Không cần cố gắng tạo một bộ regression hoàn chỉnh ngay từ đầu. Có thể bắt đầu từ các luồng quan trọng nhất, sau đó bổ sung dần khi hệ thống phát triển.

Mỗi lỗi từng xảy ra cũng có thể trở thành một test case regression. Điều này giúp tránh tình trạng lỗi cũ xuất hiện lại trong tương lai.

Giữ test case dễ bảo trì

Một bộ test quá phức tạp có thể trở thành gánh nặng. Khi hệ thống thay đổi, việc cập nhật hàng loạt test case khó hiểu sẽ khiến đội ngũ mất nhiều thời gian.

Test case nên được tổ chức rõ ràng, đặt tên theo mục tiêu và hạn chế phụ thuộc không cần thiết giữa các bài test.

Xu hướng kiểm thử API trong quá trình phát triển phần mềm hiện đại

API ngày càng trở thành lớp trung tâm kết nối website, ứng dụng di động, hệ thống quản trị và các dịch vụ bên ngoài. Vì vậy, API Testing cũng không còn là công việc chỉ thực hiện ở giai đoạn cuối.

Một xu hướng quan trọng là đưa kiểm thử sớm hơn vào quy trình phát triển. Thay vì chờ giao diện hoàn thành, API có thể được kiểm tra ngay khi chức năng backend sẵn sàng.

Cách tiếp cận này mang lại nhiều lợi ích:

• Phát hiện lỗi logic sớm hơn.
• Giảm chi phí sửa lỗi.
• Không phụ thuộc vào tiến độ giao diện.
• Dễ xây dựng automation.
• Hỗ trợ regression testing tốt hơn.
• Tăng độ tin cậy khi triển khai các thay đổi.

Đối với các dự án website và hệ thống được lập trình theo yêu cầu, API rõ ràng và được kiểm thử kỹ giúp việc mở rộng trong tương lai dễ kiểm soát hơn. Khi website cần kết nối ứng dụng mobile, hệ thống quản lý nội bộ hoặc dịch vụ bên thứ ba, chất lượng API sẽ ảnh hưởng trực tiếp đến khả năng vận hành lâu dài.

API Testing có thể thay thế hoàn toàn kiểm thử giao diện không?

Câu trả lời là không. API Testing và UI Testing giải quyết những nhóm vấn đề khác nhau.

API Testing có thể xác nhận backend xử lý dữ liệu đúng, nhưng không thể đảm bảo nút trên giao diện hiển thị đúng, biểu mẫu có dễ sử dụng hay dữ liệu có được trình bày chính xác cho người dùng hay không.

Ngược lại, UI Testing có thể phát hiện vấn đề ở trải nghiệm sử dụng nhưng thường khó xác định nguyên nhân nằm ở giao diện hay backend nếu không có kiểm thử API.

Một chiến lược tốt thường kết hợp nhiều lớp kiểm thử:

• Kiểm thử logic ở mức phù hợp.
• Kiểm thử API cho lớp giao tiếp và nghiệp vụ.
• Kiểm thử giao diện cho trải nghiệm người dùng.
• Kiểm thử toàn bộ luồng cho các chức năng quan trọng.

Mục tiêu không phải tạo ra càng nhiều bài test càng tốt mà là xây dựng các lớp kiểm tra bổ sung cho nhau.

Những nguyên tắc quan trọng để kiểm thử API hiệu quả

Sau cùng, API Testing hiệu quả không nằm ở việc thuộc bao nhiêu status code hay sử dụng bao nhiêu công cụ. Điều quan trọng hơn là tư duy đặt câu hỏi với mỗi API.

Trước một endpoint, hãy luôn xem xét:

• API này thực sự giải quyết vấn đề gì?
• Ai được phép sử dụng?
• Dữ liệu nào hợp lệ?
• Dữ liệu nào cần bị từ chối?
• Điều gì xảy ra ở giá trị biên?
• Điều gì xảy ra nếu request được gửi sai thứ tự?
• Điều gì xảy ra nếu request được gửi lặp lại?
• Dữ liệu trong response có thực sự chính xác?
• Trạng thái hệ thống có thay đổi đúng không?
• API phản ứng thế nào khi xảy ra lỗi?

Càng trả lời rõ những câu hỏi này, khả năng phát hiện lỗi càng cao.

Kết luận

API Testing là quá trình kiểm tra lớp giao tiếp và xử lý dữ liệu phía sau ứng dụng, nhưng giá trị của nó vượt xa việc gửi request và xem response. Một API chỉ thực sự đáng tin cậy khi có thể xử lý đúng dữ liệu hợp lệ, từ chối dữ liệu không hợp lệ, bảo vệ quyền truy cập, duy trì tính nhất quán và hoạt động ổn định trong các điều kiện khác nhau.

Đối với người mới bắt đầu, có thể đi từ việc hiểu cấu trúc request và response, sau đó thực hành Positive Testing, Negative Testing, Boundary Testing và kiểm tra CRUD. Khi đã có nền tảng, nên tiếp tục mở rộng sang kiểm thử authentication, authorization, luồng nghiệp vụ, hiệu năng và automation.

Trong các dự án phát triển website theo yêu cầu, đặc biệt với hệ thống có nghiệp vụ phức tạp, API Testing nên được xem là một phần của quy trình phát triển thay vì bước kiểm tra sau cùng. Phát hiện lỗi ở API trước khi lỗi lan sang giao diện và các hệ thống tích hợp sẽ giúp giảm chi phí sửa chữa, tăng độ ổn định và tạo nền tảng tốt hơn cho việc mở rộng về sau.

Một API tốt không phải là API chỉ hoạt động trong tình huống lý tưởng. Đó là API vẫn kiểm soát được dữ liệu, quyền truy cập và trạng thái hệ thống ngay cả khi nhận những request không như mong đợi. Và đó chính là mục tiêu quan trọng nhất mà một quy trình API Testing chuyên nghiệp cần hướng đến.

Bùi Tấn Lực

Đánh giá

Chia sẻ nội dung đánh giá của bạn về API Testing là gì? Hướng dẫn kiểm thử API từ cơ bản đến nâng cao
Email, Điện thoại của bạn sẽ không được hiển thị công khai. Các trường bắt buộc được đánh dấu *

Bình luận, Hỏi đáp