🍀 “API Automation” là việc sử dụng công cụ hoặc chương trình để tự động hoá các test case kiểm thử API. Các test case tự động này sẽ gửi yêu cầu và kiểm tra kết quả trả về so với kết quả mong đợi đã được lập trình sẵn.

Thay vì tester phải gửi từng yêu cầu và kiểm tra kết quả trả về một cách thủ công cho từng test case, việc tự động hoá những test case này cho phép máy tính thực hiện các bước này tự động.

Trình tự các bước thường gặp:

1. Dựa vào các test case thủ công đã viết cho một API, bạn viết nó thành test case tự động (automated test case)
2. Chương trình (cypress, playwright, postman, v.v…) sẽ gửi API request
3. Chương trình nhận kết quả trả về (kết quả thực tế)
4. Chương trình kiểm tra kết quả thực tế này với kết quả mong đợi
5. Cho kết quả cuối (Pass / Fail)

API Automation thường được sử dụng để thực hiện các test case lặp lại, regression testing và có thể tích hợp vào CI/CD.

Xem thêm Test Case API và HTTP Status Code ở đây 

API Testing và API Automation khác nhau như thế nào?

API Testing là hoạt động kiểm tra API. API Automation là áp dụng việc tự động hoá để thực hiện một phần hoặc toàn bộ các bước kiểm tra đó.

Có thể hiểu đơn giản, API Testing là kiểm thử một API. API Automation là tự động việc kiểm thử đó.

Ví dụ, khi tester cần kiểm tra API: POST /users, với dữ liệu hợp lệ.

Test case API bình thường (manual) có thể là:

Request:

name = John
email = john@example.com

Kết quả mong đợi: Status Code = 201, và user mới đã được tạo thành công

Khi tự động hóa test case này, các bước trên được thực hiện bằng code (script). Mọi bước từ việc gửi POST request → nhận response → kiểm tra Status Code = 201 → kiểm tra response body → và cuối cùng là gán kết quả Pass / Fail cho từng test case.

Xem thêm API Testing và REST API

Vì sao nên tự động hóa test case API?

Lợi ích lớn nhất của việc áp dụng kiểm thử tự động các API là giảm việc lặp lại các test case này sau mỗi lần có thay đổi trong mã nguồn API/chương trình. Dưới đây là một số lợi ích khi áp dụng tự động hoá vào kiểm thử API.

1. Hỗ trợ Regression Testing

Khi mã nguồn một API được thay đổi, các chức năng đang hoạt động khác có liên quan đến API này, có thể bị ảnh hưởng. Cần kiểm tra các chức năng đã có trước đó.

Khi nói đến regression testing, bạn sẽ nghĩ ngay đến việc tự động hoá các test case liên quan đến UI, nhưng chúng ta cũng có thể làm điều tương tự cho các test case API. Chúng chạy nhanh hơn và ổn định hơn so với test case ở tầng UI. 

Ví dụ: Order Service đã thay đổi theo yêu cầu mới → Chạy bộ API regression tests → Kiểm tra các trường hợp sau

• Create Order (tạo đơn hàng)
• Update Order (cập nhật đơn hàng)
• Cancel Order (huỷ đơn hàng)
• Get Order (xem đơn hàng)
• Payment (thanh toán)

Nếu một test case nào đó trên đây thất bại, nhóm bạn có thể điều tra và sửa lỗi sớm hơn.

2. Thực hiện kiểm thử nhanh hơn

Một tester có thể mất nhiều thời gian để thực hiện hàng trăm test case API thủ công. Việc chạy tự động các test case này sẽ hoàn thành trong thời gian ngắn hơn.

Ví dụ: 100 API Test Cases

• Manual → Thực hiện từng test case
• Automation → Chạy toàn bộ test suite

Điều này đặc biệt hữu ích khi bộ test case cần được thực hiện thường xuyên.

3. Có thể chạy thường xuyên

API automated tests không nhất thiết chỉ chạy khi tester bắt đầu một vòng kiểm thử hồi quy (regression testing). Mà có thể chạy với tần suất:

• Mỗi ngày
• Sau mỗi lần build
• Khi deploy
• Trong CI/CD
• Trước khi release

Ví dụ: Khi DEV commit code → Build tự động → chạy API Automated Tests → kiểm tra kết quả Pass/Fail → Deploy (nếu bước trước không có test case nào failed)

4. Không phụ thuộc vào UI

API Automation có thể kiểm tra backend trực tiếp mà không cần thực hiện các thao tác trên giao diện. Ví dụ, với test case trên UI, tester phải: mở trình duyệt → đăng nhập → tìm sản phẩm → thêm vào giỏ hàng → thanh toán

Với test case API, tester có thể gọi trực tiếp các API như:

• POST /login
• POST /cart
• POST /orders
• POST /payment

Điều này có thể giúp test nhanh hơn và giảm sự phụ thuộc vào UI. Đỡ bị flaky rất nhiều.

5. Phát hiện lỗi sớm hơn

API thường được lập trình xong trước phần UI. Nếu một API đã có các test case tự động, thì một số lỗi có thể được phát hiện trước khi thực hiện kiểm thử trên giao diện UI.

Đây cũng là một phần của cách tiếp cận shift-left testing, trong đó việc kiểm thử được thực hiện sớm hơn trong vòng đời phát triển phần mềm.

API Automation có thay thế “manual” không?

Nói đơn giản là KHÔNG.

Khi áp dụng tự động hoá vào kiểm thử API không có nghĩa là mọi test case và công việc đều được tự động hóa. Vì thế, tester vẫn cần thực hiện một số hoạt động sau:

• Phân tích requirement
• Xác định test condition
• Thiết kế test case
• Xác định test data
• Xác định expected result
• Phân tích kết quả test
• Điều tra lỗi khi test case failed

Automation chủ yếu giúp thực hiện các kiểm tra đã được xác định một cách tự động.

Có thể hình dung, tester sẽ thực hiện các bước sau để viết test case tự động cho API.

1. Phân tích tài liệu
2. Thiết kế test case API (manual)
3. Tự động hoá chúng, được kết quả test case tự động

Do đó, làm automation không có nghĩa là sẽ bỏ qua kỹ năng kiểm thử.

Những API Test Case nào nên được tự động hóa?

Không phải test case nào cũng có cùng giá trị khi automation. Các test case phù hợp để tự động hóa thường có một hoặc nhiều đặc điểm sau:

Test case lặp lại thường xuyên

Những test case này được thực thi trong mỗi lần chạy “regression testing”.

Ví dụ:

• Login
• Create User
• Get User
• Create Order
• Cancel Order

Test case có kết quả mong đợi rõ ràng

Ví dụ:

• Expected Status Code = 200
• Expected field = “active”
• Expected value = true

Regression Test case

Những test case cần chạy lại nhiều lần thường là ứng viên tốt cho automation.

Smoke Test case

Một số API quan trọng có thể được đưa vào automated smoke test để kiểm tra nhanh hệ thống sau khi deploy.

Data-driven Test case

Cùng một test case nhưng có thể được chạy với nhiều bộ dữ liệu đầu vào khác nhau.

Ví dụ:

• Email hợp lệ
• Email không hợp lệ
• Email rỗng
• Email đã tồn tại

Những API Test Case nào chưa chắc nên tự động hóa?

Khi một API mới đang được thiết kế và “contract” còn thay đổi thường xuyên, việc viết test case tự động cho chúng quá sớm có thể tốn nhiều công sức để cập nhật về sau.

Một số trường hợp vẫn có thể phù hợp với manual testing hơn so với test case tự động, đặc biệt khi:

• Yêu cầu cho API chưa ổn định, còn trao đổi nhiều
• Yêu cầu của API đang thay đổi liên tục
• Kết quả mong đợi chưa rõ ràng
• Test case chỉ thực hiện một lần (không cần sử dụng lại)
• Các trường hợp cần thực hiện exploratory testing (kiểm thử khám phá)
• Cần đánh giá trải nghiệm hoặc hành vi của API mà automation khó xác định

API Automation kiểm tra những gì?

Test case API tự động có thể kiểm tra nhiều thành phần của cả yêu cầu (request) và phản hồi (response).

Request

Có thể kiểm tra:

• HTTP method (phương thức như GET, POST, v.v…)
• Endpoint (điểm cuối, như: …/v1/payment)
• Path parameter (tham số trên đường dẫn, như …/users/{id})
• Query parameter (tham số trong yêu cầu, như key=value hoặc dạng khác)
• Header
• Request body (nội dung yêu cầu)

Response

Có thể kiểm tra:

• HTTP Status Code (mã trạng thái của yêu cầu)
• Response body (nội dung phản hồi)
• Response schema (cấu trúc của phản hồi)
• Response header (thông tin trong header của phản hồi)
• Error message (thông báo lỗi)
• Response time (thời gian phản hồi)

Business Logic

Có thể kiểm tra:

• Business rules
• Data validation
• State transition
• Data consistency
• API dependency

Ví dụ, khi gọi API “POST /orders”, kết quả mong đợi gồm:

• Expected Status = 201
• Order được tạo
• Order status = “Pending”
• Inventory được cập nhật

Một API Automated Test đơn giản

Một test case tự động trên thực tế thường được viết bằng code hoặc sử dụng framework hỗ trợ cho việc kiểm thử API như Postman, REST Assured, hay Playwright.

Giả sử có API: GET /users/123

Expected: Status Code = 200

Response:

{
  "id": 123,
  "name": "John"
}

Automation có thể thực hiện:

1. Gửi GET /users/123

2. Nhận response

3. Kiểm tra Status Code = 200

4. Kiểm tra id = 123

5. Kiểm tra name = “John”

6. Nếu tất cả đúng → Pass

7. Nếu có kiểm tra thất bại → Fail

API Automation có thể sử dụng những công cụ nào?

Không có một công cụ API Automation duy nhất phù hợp với mọi dự án. Tùy ngữ cảnh, sở thích cá nhân hay công ty của bạn, sẽ có nhiều lựa chọn khác nhau. Việc lựa chọn công cụ nên dựa trên:

• Công nghệ của dự án
• Ngôn ngữ lập trình của team
• CI/CD
• Quy mô test suite
• Kỹ năng của team
• Khả năng maintain

Postman

Postman thường được sử dụng để thực hiện API testing thủ công và cũng hỗ trợ viết và chạy automated tests.

Phù hợp với Tester muốn bắt đầu làm quen với API testing và automation.

REST Assured

REST Assured là thư viện Java thường được sử dụng để kiểm thử REST API.

Phù hợp với các team sử dụng Java và muốn xây dựng API test framework bằng code.

Playwright

Playwright chủ yếu được biết đến với web automation nhưng cũng hỗ trợ gửi HTTP requests và kiểm tra API. Vì thế, chúng ta hoàn toàn có thể sử dụng Playwright vào việc tự động hóa các test case trong kiểm thử API.

Áp dụng Playwright, giúp nhóm của bạn có thể sử dụng cùng một công cụ cho các nhu cầu kiểm thử tự động khác nhau từ API đến UI.

Cypress

Tương tự Playwright, Cypress cũng có khả năng gửi request đến API và kiểm tra response, đồng thời có thể kết hợp API testing với web testing.

API Automation và CI/CD

API tests có thể được sử dụng ở nhiều giai đoạn khác nhau tùy chiến lược của team. Một trong những giá trị lớn của API Automation là khả năng tích hợp vào CI/CD pipeline. Khi một test case API tự động thất bại (bị failed), team bạn có thể phát hiện vấn đề ngay trong pipeline.

Ví dụ:

Developer

   ↓

Commit Code

   ↓

Build

   ↓

Deploy to Test Environment

   ↓

API Automated Tests

   ↓

Pass / Fail

API Automation và Test Data

Công cụ kiểm thử API tự động tốt không chỉ là tập hợp các API request mà còn cần giải quyết nhiều vấn đề như test data và môi trường kiểm thử. Ví dụ, cùng một tham số như BaseURL nhưng môi trường khác nhau thì giá trị của chúng sẽ khác nhau. Test data (dữ liệu kiểm thử) là một vấn đề quan trọng khi xây dựng và quyết định chọn công cụ để tự động hóa việc kiểm thử API.

Ví dụ test case: “POST /users” cần email chưa tồn tại.

Nếu test chạy nhiều lần với “john@example.com” lần đầu có thể thành công nhưng lần sau có thể fail vì user đã tồn tại. Do đó, automation có thể cần chiến lược quản lý test data như:

• Tạo data trước test
• Xóa data sau test
• Sử dụng data động
• Sử dụng dữ liệu được chuẩn bị sẵn
• Mock hoặc stub dependency khi phù hợp

API Automation và API Dependency

Đây là một trong những vấn đề cần được xem xét khi thiết kế API Automation Framework. Một test case có thể phụ thuộc vào nhiều API khác nhau.

Ví dụ:

Login

  ↓

Create Product

  ↓

Create Order

  ↓

Payment

  ↓

Get Order

Nếu API Login thất bại, những test phía sau có thể cũng thất bại.

Tester cần phân biệt: Test thực sự fail

Và: Test fail vì dependency trước đó fail.

API Automation có cần Framework không?

Khi số lượng test nhỏ, có thể bắt đầu với một số test đơn giản. Nhưng khi test suite phát triển, việc tổ chức thành một framework sẽ giúp dễ quản lý và bảo trì hơn.

Một API Automation Framework có thể bao gồm:

Test Cases

     ├── API Requests

     ├── Assertions

     ├── Test Data

     ├── Authentication

     ├── Utilities

     ├── Configuration

     ├── Reporting

     └── CI/CD

Mục tiêu không phải tạo framework càng phức tạp càng tốt. Mà là: Dễ đọc → Dễ chạy → Dễ debug → Dễ maintain

Một số vấn đề thường gặp khi làm API Automation

Test quá phụ thuộc vào dữ liệu

Test có thể fail chỉ vì test data của một tham số đã thay đổi.

Test phụ thuộc lẫn nhau quá nhiều

Một API fail, khiến hàng loạt các bước khác trong test case fail theo. Tương tự, 1 test case fail làm cho các test case khác trong bộ “e2e api test” bị fail

Hard-code dữ liệu

Ví dụ, khi gán cứng userId = 123, nếu môi trường khác không có user nào có ID = 123, test case sẽ fail.

Kiểm tra phần phản hồi không đủ

Chỉ kiểm tra: Status Code = 200, mà không kiểm tra response data.

Tự động hoá quá nhiều

Không phải test case nào cũng cần automation.

Framework quá phức tạp

Nếu một công cụ khó sử dụng hơn cả việc thực hiện test thủ công, việc tự động hoá các test case API có thể đang tạo ra nhiều vấn đề hơn giá trị.

Tester cần biết gì để bắt đầu API Automation?

Nếu đã có kiến thức API Testing, có thể học theo thứ tự:

01. API Testing

Cần phải hiểu:

• Request
• Response
• HTTP method
• Status Code
• JSON (Xem thêm JSON là gì?)
• API Test Case

02. Một ngôn ngữ lập trình

Không nhất thiết phải trở thành Developer, nhưng cần đủ kiến thức lập trình để đọc, viết và maintain automated tests. Tùy công cụ:

• Java
• JavaScript / TypeScript
• Python
• C#

03. Một API Automation Tool

Ví dụ:

• Postman
• REST Assured
• Playwright
• Cypress

04. Assertions

Biết cách kiểm tra: Kết quả mong đợi, và kết quả thực tế (expected vs actual)

05. Test Data

Biết cách tạo, quản lý và sử dụng test data.

06. CI/CD

Hiểu cách chạy automated tests trong pipeline.

API Automation có phải kỹ năng dành riêng cho Automation Tester?

KHÔNG.

Điều quan trọng là Tester vẫn phải hiểu testing trước khi automation. Biết lập trình nhưng không biết xác định test condition, test data, và expected result thì chưa đủ để xây dựng API automation hiệu quả.

Manual Tester cũng có thể bắt đầu học API Automation. Thực tế, một hướng phát triển khá tự nhiên là:

Manual Testing

      ↓

API Testing

      ↓

API Automation

      ↓

Test Automation

      ↓

CI/CD

Kết luận

API Automation là việc tự động thực hiện các API Test Case bằng công cụ hoặc framework.

API Automation giúp Tester:

• Giảm kiểm tra lặp lại
• Chạy regression nhanh hơn
• Phát hiện lỗi sớm
• Chạy test thường xuyên
• Tích hợp với CI/CD
• Mở rộng phạm vi kiểm thử

Tuy nhiên: API Automation không thay thế API Testing.

Tester vẫn cần bắt đầu từ:

Requirement → Test Condition → Test Case → Test Data → Automation

Nếu mới bắt đầu, có thể đi theo lộ trình:

API Testing → API Test Case → API Automation → CI/CD

Khi đã nắm được nền tảng này, Tester có thể tiếp tục tìm hiểu cách xây dựng API Automation Framework và tích hợp automated API tests vào quy trình phát triển phần mềm.