🗃️Giới thiệu
Tuy nhiên, một API trả về dữ liệu chính xác chưa chắc đã hoạt động tốt trong mọi tình huống. API có thể phản hồi chậm khi có nhiều người dùng truy cập, trả về dữ liệu không nhất quán hoặc gặp lỗi khi các dịch vụ phụ thuộc không hoạt động.
Đó là lý do API Testing trở thành một phần quan trọng trong quy trình đảm bảo chất lượng phần mềm.
Bài viết này sẽ giúp bạn hiểu vai trò của API Testing, các khía cạnh cần kiểm thử, những khó khăn thường gặp và cách áp dụng hiệu quả vào công việc QA/QC.
Vai trò của API trong hệ thống phần mềm
API là cơ chế cho phép các ứng dụng hoặc thành phần phần mềm trao đổi dữ liệu và yêu cầu thực hiện chức năng theo những quy tắc đã được định nghĩa.
API giống như người phục vụ trong nhà hàng. Khách (ứng dụng) không vào bếp, chỉ gọi món với người phục vụ (API), người này chuyển yêu cầu cho bếp (hệ thống phía sau) rồi mang kết quả ra. Nhờ vậy các phần mềm khác nhau có thể “nói chuyện” với nhau mà không cần biết bên trong nhau hoạt động ra sao.
Trong hệ thống của chúng ta, API đóng ba vai trò chính:
🔌Kết nối các hệ thống với nhau
Những tính năng quen thuộc như đăng nhập bằng Google, thanh toán online hay xem dự báo thời tiết đều chạy nhờ API. Ở một phần mềm, API giúp [ví dụ: app di động lấy dữ liệu đơn hàng từ server, kết nối cổng thanh toán…].🌦️Là nền tảng cho kiến trúc microservice và đám mây
Khi hệ thống được chia thành nhiều dịch vụ nhỏ, các dịch vụ này không gọi trực tiếp vào code của nhau mà trao đổi qua API. Cách làm này giúp mỗi nhóm phát triển, sửa lỗi và triển khai dịch vụ của mình độc lập. Các hệ thống trên đám mây cũng dùng API để tạo, mở rộng hay thu hẹp tài nguyên khi cần.✈️Được dùng ở mọi lĩnh vực
Từ thương mại điện tử, y tế đến thiết bị IoT, API là cách phổ biến để doanh nghiệp trao đổi dữ liệu với đối tác và với khách hàng.
🧪Vì sao điều này liên quan đến việc test?
Vì API nằm giữa nhiều thành phần, một API lỗi sẽ kéo theo lỗi ở nhiều nơi: người dùng gặp trải nghiệm kém, quy trình kinh doanh bị gián đoạn, và trong trường hợp xấu là thiệt hại tài chính. Đó là lý do chúng ta cần test API cẩn thận trước khi đưa lên môi trường thật.
Vì sao API Testing quan trọng?
🧩Test được sớm hơn, phát hiện lỗi sớm hơn
Một lỗi API có thể ảnh hưởng đến nhiều chức năng cùng sử dụng API đó. Nếu lỗi chỉ được phát hiện sau khi tích hợp, nhóm phát triển có thể phải điều tra đồng thời backend, frontend và các dịch vụ liên quan.
API xong là test được ngay, không cần chờ giao diện hoàn thiện. Lỗi logic được phát hiện khi code còn “nóng” trong đầu dev, thu hẹp phạm vi nguyên nhân, giảm công sức sửa lỗi và hạn chế việc kiểm thử lại nhiều lần.
Điều này giúp QA phát hiện các vấn đề về logic nghiệp vụ, dữ liệu đầu vào và dữ liệu trả về sớm hơn, giảm nguy cơ lỗi lan sang các thành phần khác.
Ví dụ:
Một API tạo sự kiện yêu cầu các trường eventName, startTime và endTime.
QA cần kiểm tra: Tạo sự kiện với dữ liệu hợp lệ. / Bỏ trống trường bắt buộc. / Gửi thời gian kết thúc sớm hơn thời gian bắt đầu. / Gửi dữ liệu sai định dạng. / Gửi yêu cầu thiếu token xác thực.
Nếu phát hiện lỗi ngay ở API, nhóm phát triển có thể xử lý trước khi chức năng được tích hợp lên giao diện.
⚡Đánh giá và cải thiện hiệu năng
API thường nằm trên đường đi của các yêu cầu từ ứng dụng đến backend. Khi số lượng yêu cầu tăng lên, API có thể trở thành điểm nghẽn do truy vấn cơ sở dữ liệu chậm, xử lý nghiệp vụ phức tạp hoặc tài nguyên máy chủ không đủ.
API Performance Testing giúp đánh giá hệ thống phản hồi như thế nào trong các điều kiện tải khác nhau.
Ví dụ:
Một API lấy danh sách sự kiện phản hồi trong 300 ms khi chỉ có một người dùng. Nhưng khi có 200 người dùng đồng thời gửi yêu cầu, thời gian phản hồi tăng lên 4 giây và nhiều request bị timeout.
Điều này cho thấy API có thể hoạt động tốt khi tải thấp nhưng chưa đáp ứng được nhu cầu thực tế.
QA có thể đo lường:
Thời gian phản hồi (Response Time).
Tỷ lệ request thành công và thất bại.
Throughput – số request được xử lý trong một đơn vị thời gian.
Tỷ lệ lỗi và timeout.
Tài nguyên hệ thống như CPU và bộ nhớ, nếu có quyền truy cập số liệu giám sát.
Lưu ý: Mức tải và thời gian phản hồi đạt yêu cầu cần được xác định dựa trên tiêu chí của dự án, không nên áp dụng một ngưỡng chung cho mọi API.
View performance metrics
🏗️Chạm được vào những chỗ giao diện không thể
Gửi dữ liệu sai định dạng, thiếu trường bắt buộc, token hết hạn hay gọi lặp liên tục: những tình huống này khó tạo ra qua UI nhưng làm qua API rất dễ.
🔥Tăng cường bảo mật
API có thể cung cấp quyền truy cập vào dữ liệu cá nhân, thông tin tài khoản hoặc các chức năng quan trọng của hệ thống. Nếu không được bảo vệ đúng cách, API có thể bị khai thác để truy cập trái phép hoặc làm lộ dữ liệu.
Một số kiểm thử bảo mật thường gặp:
Xác thực người dùng bằng token.
Kiểm tra quyền truy cập theo vai trò.
Kiểm tra dữ liệu đầu vào không hợp lệ hoặc có dấu hiệu độc hại.
Xác nhận dữ liệu nhạy cảm không bị trả về cho người không có quyền.
Kiểm tra việc truyền dữ liệu qua HTTPS.
Ví dụ:
Người dùng A chỉ được xem thông tin của mình. Khi người dùng A thay đổi ID trong request để lấy thông tin của người dùng B, hệ thống phải từ chối nếu người dùng A không có quyền truy cập.
Việc chỉ kiểm tra mã trạng thái HTTP là chưa đủ; QA cần xác nhận dữ liệu và hành vi thực tế của hệ thống.
🕵️Cải thiện trải nghiệm người dùng
Người dùng không nhìn thấy các request hay response phía sau giao diện. Họ chỉ cảm nhận được hệ thống có nhanh, ổn định và dễ sử dụng hay không.
Một API hoạt động tốt góp phần giúp:
Trang hiển thị dữ liệu nhanh hơn.
Thao tác lưu hoặc cập nhật ít gặp lỗi hơn.
Thanh toán và đặt hàng đáng tin cậy hơn.
Dữ liệu hiển thị nhất quán giữa các màn hình.
Những khía cạnh quan trọng trong API Testing
--Functional Testing – Kiểm thử chức năng--
Mục tiêu là xác nhận API thực hiện đúng yêu cầu.
Các nội dung cần kiểm tra:
Endpoint và HTTP method có đúng không.
Request có đúng cấu trúc và dữ liệu yêu cầu không.
Response có đúng status code, schema và nội dung không.
Query parameters, path parameters và headers có được xử lý chính xác không.
Các trường hợp lỗi (404 Not Found, 401 Unauthorized) có được xử lý phù hợp không.
Ví dụ test case:
|
|---|
--Performance Testing – Kiểm thử hiệu năng--
Performance Testing giúp xác định API có đáp ứng được yêu cầu về tốc độ, khả năng xử lý và độ ổn định hay không.
Ba loại kiểm thử phổ biến:
Load Testing: Đánh giá API dưới mức tải dự kiến và tải cao điểm.
Stress Testing: Tăng tải vượt mức thông thường để tìm giới hạn và quan sát cách hệ thống phục hồi.
Latency Testing: Đo độ trễ trong các điều kiện khác nhau.
Ví dụ: API tìm kiếm cần đáp ứng mục tiêu phản hồi trong vòng 2 giây ở mức tải đã thống nhất. QA chạy thử với số lượng request đồng thời tăng dần và kiểm tra xem thời gian phản hồi, throughput và tỷ lệ lỗi có nằm trong giới hạn cho phép hay không.
--Security Testing – Kiểm thử bảo mật--
Kiểm thử bảo mật tập trung vào việc xác nhận API chỉ cho phép những hành động hợp lệ và bảo vệ dữ liệu đúng cách.
Ví dụ:
Token hết hạn phải được xử lý đúng.
Người dùng không đủ quyền không được thực hiện thao tác quản trị.
Dữ liệu đầu vào nguy hiểm phải được xử lý an toàn.
Thông tin nhạy cảm không được trả về ngoài phạm vi cho phép.
--Reliability Testing – Kiểm thử độ tin cậy--
Reliability Testing đánh giá khả năng API duy trì hành vi chính xác và ổn định trong nhiều tình huống khác nhau.
Các tình huống cần xem xét:
Kết nối mạng bị gián đoạn.
Dịch vụ phụ thuộc phản hồi chậm hoặc không khả dụng.
Request được gửi lại sau timeout.
Dữ liệu phải nhất quán giữa nhiều lần truy vấn.
Ví dụ thực tế:
Một API thanh toán đã gửi yêu cầu đến cổng thanh toán nhưng client không nhận được response do timeout. Nếu client gửi lại request, hệ thống cần có cơ chế phù hợp để tránh thu tiền hai lần.
QA nên kiểm tra cơ chế idempotency hoặc cách xử lý giao dịch lặp theo thiết kế của hệ thống.
Những khó khăn thực tế và cách xử lý
| 🚧Khó khăn | 🔐Cách xử lý gợi ý |
|---|---|
| API thay đổi liên tục, test cũ hỏng | Gắn test vào CI để biết ngay khi có thay đổi phá vỡ; thống nhất quy tắc versioning. |
| Phụ thuộc vào nhiều dịch vụ | Dùng mock server để giả lập response. |
| Thiếu giao diện người dùng cho ngữ cảnh | Đọc requirement, API documentation, technical design và trao đổi với BA, developer hoặc PO để hiểu rõ luồng nghiệp vụ trước khi thiết kế test case. |
| Khó giả lập tải lớn | Chạy test tải định kỳ trên môi trường staging thay vì làm thủ công; tăng tải theo từng giai đoạn và theo dõi cả số liệu API lẫn tài nguyên hệ thống khi có thể. |
| Xử lý xác thực và bảo mật | Dùng tài khoản test theo từng vai trò, lưu token trong biến môi trường; test cả các trường hợp bị chặn (token hết hạn, sai quyền) và kiểm tra response không lộ dữ liệu nhạy cảm. |
Best Practices để nâng cao hiệu quả API Testing
📃Hiểu rõ tài liệu API
Trước khi viết test case, hãy tìm hiểu:
Endpoint và HTTP method.
Cấu trúc request và response.
Các trường bắt buộc, kiểu dữ liệu và quy tắc nghiệp vụ.
Status code và cách xử lý lỗi.
Cơ chế xác thực và phân quyền.
Swagger/OpenAPI và Postman Collection là những nguồn tham khảo hữu ích.
📃Thiết kế test scenario trước khi automation
Nên bao phủ các nhóm:
Positive testing – dữ liệu hợp lệ.
Negative testing – dữ liệu không hợp lệ.
Boundary testing – giá trị biên.
Data validation – kiểm tra cấu trúc và tính chính xác của dữ liệu.
Performance testing – đánh giá hiệu năng.
Security testing – kiểm tra bảo mật theo phạm vi được phép.
Không nên chỉ kiểm tra status code 200. Một response có thể trả về thành công nhưng dữ liệu nghiệp vụ vẫn sai.
📈Tự động hóa những kiểm thử phù hợp
API Automation giúp chạy lại các kịch bản lặp lại nhanh chóng và nhất quán, đặc biệt là regression testing và data validation.
Một số công cụ có thể sử dụng:
Postman và Newman.
Playwright API Testing.
Robot Framework.
REST Assured.
Karate.
Nên chọn công cụ dựa trên công nghệ của dự án, khả năng bảo trì, kỹ năng của team và nhu cầu tích hợp CI/CD.
📈Sử dụng mock server khi cần thiết
Mock server giúp mô phỏng các dịch vụ phụ thuộc khi môi trường thật không sẵn sàng hoặc khó kiểm soát.
Có thể sử dụng WireMock hoặc Mockoon để mô phỏng các response như:
Thành công.
Dữ liệu không tồn tại.
Server lỗi.
Timeout.
Response chậm.
⛓️💥Kiểm tra response một cách toàn diện
Không chỉ kiểm tra status code. QA cần xác nhận:
Response schema.
Kiểu dữ liệu của từng field.
Các trường bắt buộc.
Giá trị và quy tắc nghiệp vụ.
Tính nhất quán giữa request, response và database khi có thể kiểm tra.
Thời gian phản hồi theo tiêu chí đã thống nhất.
⛓️💥Theo dõi hiệu năng định kỳ
Hiệu năng không phải yếu tố chỉ cần kiểm tra một lần trước khi release.
Khi dữ liệu tăng, code thay đổi hoặc số lượng người dùng tăng, API có thể hoạt động khác trước.
Các công cụ như JMeter và Gatling có thể hỗ trợ load testing. Kết quả nên được lưu lại để so sánh giữa các phiên bản.
📑Báo cáo kết quả rõ ràng
Một báo cáo API Testing hữu ích nên thể hiện:
Tổng số test case, số pass và fail.
Các lỗi quan trọng và điều kiện tái hiện.
Response time và tỷ lệ lỗi nếu có đo hiệu năng.
Môi trường, dữ liệu và mức tải đã sử dụng.
So sánh với lần chạy trước khi cần thiết.
Allure hoặc các công cụ báo cáo tương tự có thể giúp trình bày kết quả rõ ràng hơn.
Ví dụ thực tế 🧪: Kiểm thử API Performance
API kiểm thử: POST /auth/login và GET /auth/me (dùng API demo dummyjson.com)
| ID | Category | Objective | Data / Precondition | Expected Result |
|---|---|---|---|---|
| TC01 | Functional | Login successfully | Valid username and password | Status 200, accessToken is returned |
| TC02 | Functional | Login with wrong password | Correct username, incorrect password | Request rejected (400/401), no token returned |
| TC03 | Functional | Login with non-existent username | Username does not exist | Request rejected (400/401), no token returned |
| TC04 | Input validation | Missing required field | Request body has no password | Status 400, clear error message |
| TC05 | Input validation | Malformed request body | Invalid JSON or empty body | Status 400, server does not return a 500 error |
| TC06 | Authentication | Use a valid token | Call /auth/me with the token from TC01 | Status 200, user information is returned |
| TC07 | Authentication | Use an invalid or expired token | Call /auth/me with an invalid token | Status 401 |
| TC08 | Performance | Stable response time | Run login 20 times in a row | 100% of requests return 200, each under 1000 ms |
| TC09 | Security | No sensitive data exposure | Inspect responses from TC01 and TC02 | No password in the response; error messages are generic and do not reveal whether the username exists |
* Mã lỗi thực tế (400 hay 401) tùy cách API của bạn thiết kế, hãy đối chiếu với tài liệu API trước khi chốt.
Với các kịch bản này, QA vừa xác minh chức năng, vừa có thể mở rộng sang kiểm thử hiệu năng và độ tin cậy.
Nếu sử dụng Playwright, các bước gọi API, xác thực response và kiểm tra dữ liệu có thể được tái sử dụng để giảm công sức bảo trì.
🥎Kết luận
API Testing không chỉ là việc gửi request và kiểm tra response. Đây là một phần quan trọng của quy trình đảm bảo chất lượng, giúp phát hiện lỗi chức năng, đánh giá hiệu năng, xác minh bảo mật và tăng độ tin cậy của hệ thống.
Một API hoạt động tốt giúp các thành phần phần mềm phối hợp hiệu quả hơn, đồng thời góp phần tạo nên trải nghiệm ổn định và đáng tin cậy cho người dùng.
