API Testing

1. Tổng quan

1.1 API là gì?

API là cơ chế cho phép 2 thành phần của một phần mềm hoặc 2 phần mềm giao tiếp với nhau bằng một tập hợp các định nghĩa và giao thức.
API viết tắt của Application Programming Interface là một tập hợp các câu lệnh (commands), functions, các giao thức (protocols), objects,... giúp hai phần mềm (ứng dụng) có thể tương tác và trao đổi dữ liệu qua lại được với nhau.

1.2 Kiểm thử API là gì?

Kiểm thử API là gì?
- Là quá trình kiểm tra trực tiếp các API nhằm đánh giá tính năng, độ tin cậy, hiệu suất và bảo mật của hệ thống.
Ai kiểm thử API?
- Các Tester.
Chiến lược kiểm thử API:
- Gửi nhiều yêu cầu đến API để kiểm thử hiệu năng (tăng lượng request).
- Viết kiểm thử đơn vị để kiểm tra logic kinh doanh và tính đúng đắn của chức năng.
- Kiểm thử bảo mật bằng cách mô phỏng các cuộc tấn công như SQL Injection.
- Sử dụng phần mềm trung gian để gọi API, ghi nhận phản hồi và đánh giá hệ thống.
Trọng tâm kiểm thử API:
- Không tập trung vào giao diện người dùng (GUI).
- Tập trung vào lớp business logic, kiểm tra chính xác logic và phản hồi của hệ thống.

1.3 Tại sao cần kiểm thử API?

Mục đích và lợi ích chính:
- Đảm bảo API hoạt động ổn định, chính xác, và đáng tin cậy để hỗ trợ sự tương tác giữa các ứng dụng và dịch vụ.
- Phát hiện lỗi sớm, tiết kiệm chi phí khắc phục lỗi sau này.
Đặc điểm nổi bật:
- Kiểm thử sớm: Thực hiện ngay cả khi chưa có giao diện người dùng (UI), giúp phát hiện và sửa lỗi trước khi xây dựng UI.
- Hệ thống chỉ dùng API: Kiểm thử API rất quan trọng với các hệ thống như xác thực OTP hoặc thanh toán, không phụ thuộc vào UI.
Kiểm thử toàn diện giữa BE và FE:
- Kiểm tra API đảm bảo dữ liệu từ backend (BE) lưu xuống database đúng và hiển thị trên frontend (FE) chính xác.
- Phát hiện lỗi do không đồng nhất giữa BE và FE (ví dụ: format dữ liệu khác nhau).
Tăng hiệu quả và giảm chi phí:
- Hỗ trợ xây dựng chiến lược tự động hóa kiểm thử tốt hơn.
- Giảm kiểm thử hồi quy thủ công, tăng tốc độ kiểm thử theo phương pháp Agile.
Tích hợp API Testing:
- Giảm áp lực kiểm thử hồi quy cho QA, tăng tốc độ phản hồi về chất lượng ứng dụng.
- Kiểm thử API yêu cầu ít code hơn, phạm vi kiểm tra rộng hơn, và cho kết quả nhanh hơn, giúp hệ thống được đánh giá toàn diện trước khi kiểm thử GUI.

1.4 Lợi ích kiểm thử API

Đảm bảo tính đúng đắn
- Kiểm thử API giúp đảm bảo rằng API hoạt động chính xác và đáp ứng các yêu cầu và ràng buộc. Đảm bảo rằng API trả về dữ liệu chính xác và thực hiện các chức năng như mong đợi.
Kiểm tra tính bảo mật.
- Kiểm thử API cho phép xác minh tính bảo mật của API. Đảm bảo rằng API không có lỗ hổng bảo mật và không mở ra các lỗ hổng tiềm năng trong hệ thống.
Đảm bảo tính ổn định.
Tăng khả năng tái sử dụng.
Tăng độ tin cậy và chất lượng.
Giảm rủi ro và chi phí.
Hỗ trợ kiểm thử hồi quy tự động.
Yêu cầu ít code, hiệu quả cao.

2. REST API

2.1 Rest API là gì?

REST API (Representational State Transfer Application Programming Interface) là một giao diện lập trình ứng dụng dựa trên kiến trúc REST.
REST là một phong cách kiến trúc được sử dụng rộng rãi trong việc thiết kế các hệ thống web để giao tiếp giữa các client (frontend, ứng dụng di động) và server.

2.2 Rest API hoạt động như thế nào?

REST API hoạt động dựa trên giao tiếp giữa client (máy khách) và server (máy chủ) thông qua giao thức HTTP. Khi một client gửi yêu cầu (request), server sẽ xử lý và trả về phản hồi (response).

2.3 Rest API request

REST API request (yêu cầu) là một thông điệp được client (máy khách) gửi đến server (máy chủ) để yêu cầu dữ liệu hoặc thực hiện một hành động nào đó.

Một request REST API gồm các thành phần chính sau:

2.3.1. HTTP Method (Phương thức HTTP)

Phương thức HTTP xác định hành động cần thực hiện trên server. Các phương thức phổ biến:

Phương thức	Mô tả	Ví dụ URL
GET	Lấy dữ liệu	/users (Lấy danh sách người dùng)
POST	Gửi dữ liệu để tạo mới	/users (Thêm một user mới)
PUT	Cập nhật toàn bộ dữ liệu	/users/1 (Cập nhật user có ID = 1)
PATCH	Cập nhật một phần dữ liệu	/users/1 (Cập nhật email của user)
DELETE	Xóa dữ liệu	/users/1 (Xóa user có ID = 1)

2.3.2 Endpoint (URL API)

Mỗi API có một địa chỉ URL cụ thể, gọi là endpoint.

Ví dụ: API lấy danh sách người dùng:https://api.example.com/users

2.3.3 Headers (Tiêu đề HTTP)

Headers chứa metadata của request, bao gồm:

Authorization: Xác thực người dùng (API Key, JWT Token).
Content-Type: Loại dữ liệu gửi đi (application/json, application/xml).
Accept: Loại dữ liệu mong muốn nhận (application/json).

Ví dụ headers:

Authorization: Bearer <your_token>

Content-Type: application/json

Accept: application/json

2.3.4. Query Parameters (Tham số trên URL)

Query parameters giúp lọc hoặc sắp xếp dữ liệu.

Ví dụ: Lọc danh sách người dùng theo tuổi và giới tính:

GET /users?age=25&gender=male

2.3.5. Request Body (Dữ liệu gửi đi)

Dùng với POST, PUT, PATCH để gửi dữ liệu lên server.
Dữ liệu thường ở định dạng JSON hoặc XML.

Ví dụ POST request gửi body JSON để tạo user mới:

{
  "name": "Nguyễn Văn A",
  "email": "nguyenvana@example.com",
  "age": 25
}

2.4 Rest API response

REST API Response (phản hồi của API) là dữ liệu mà server trả về sau khi nhận và xử lý một request từ client. Phản hồi này có thể chứa dữ liệu được yêu cầu, thông báo lỗi, hoặc trạng thái của request.

Một response REST API thường bao gồm các thành phần sau:

2.4.1 Status Code (Mã trạng thái HTTP)

Mã trạng thái HTTP cho biết kết quả của request.

Nhóm	Mã	Ý nghĩa	Ví dụ
Thành công	200 OK	Yêu cầu xử lý thành công	Lấy danh sách user thành công
Tạo mới	201 Created	Tạo mới thành công	User mới đã được tạo
Lỗi Client	400 Bad Request	Request không hợp lệ	Dữ liệu gửi lên không đúng định dạng
Không quyền truy cập	401 Unauthorized	Không có quyền truy cập	API cần token xác thực
Không tìm thấy	404 Not Found	Không có dữ liệu yêu cầu	ID user không tồn tại
Lỗi Server	500 Internal Server Error	Lỗi từ server	Server bị lỗi khi xử lý yêu cầu

2.4.2 Response Headers (Tiêu đề phản hồi HTTP)

Response headers chứa metadata về phản hồi, ví dụ:

Content-Type: application/json

Cache-Control: no-cache

Server: nginx

Các header quan trọng:

Content-Type: Loại dữ liệu trả về (application/json, text/html).
Cache-Control: Kiểm soát bộ nhớ đệm.
Authorization: Trả về token nếu cần xác thực lại.

2.4.3 Response Body (Nội dung phản hồi)

Phần body chứa dữ liệu thực tế được trả về.

Ví dụ: Response thành công (JSON)

{
  "status": "success",
  "data": {
    "id": 1,
    "name": "Nguyễn Văn A",
    "email": "nguyenvana@example.com"
  }

Ví dụ: Response lỗi (JSON)

json
CopyEdit
{
"status": "error",
"message": "User not found"
}

2.5 Status code

HTTP Status Code là mã trạng thái được server trả về để thông báo kết quả xử lý một request REST API. Mã này giúp client hiểu request có thành công hay gặp lỗi.

Nhóm	Mã	Ý nghĩa
✅ 1xx: Informational (Thông tin)	100-199	Đang xử lý request
🟢 2xx: Success (Thành công)	200-299	Request xử lý thành công
🟡 3xx: Redirection (Chuyển hướng)	300-399	Client cần thực hiện bước tiếp theo
🔴 4xx: Client Errors (Lỗi phía client)	400-499	Request sai hoặc không được phép
⚫ 5xx: Server Errors (Lỗi phía server)	500-599	Lỗi từ server

2.5.1 Các Status Code phổ biến

✅ 2xx – Thành công

Mã	Ý nghĩa	Mô tả
200 OK	Thành công	Request được xử lý đúng
201 Created	Đã tạo mới	Tạo resource thành công (VD: tạo user mới)
204 No Content	Không có dữ liệu trả về	Server xử lý xong nhưng không có nội

🔴 4xx – Lỗi từ phía Client

Mã	Ý nghĩa	Mô tả
400 Bad Request	Request không hợp lệ	Dữ liệu sai hoặc thiếu
401 Unauthorized	Chưa xác thực	Cần login hoặc token không hợp lệ
403 Forbidden	Không có quyền	Request bị từ chối dù đã xác thực
404 Not Found	Không tìm thấy resource	API hoặc dữ liệu không tồn tại
405 Method Not Allowed	Sai phương thức HTTP	VD: Dùng POST thay vì GET

⚫ 5xx – Lỗi từ phía Server

Mã	Ý nghĩa	Mô tả
500 Internal Server Error	Lỗi hệ thống	Lỗi không xác định từ server
502 Bad Gateway	Lỗi proxy	Server trung gian không nhận được phản hồi hợp lệ
503 Service Unavailable	Server quá tải	Server đang bảo trì hoặc bị quá tải
504 Gateway Timeout	Hết thời gian chờ	Server trung gian chờ quá lâu không có phản hồi

2.6 Phân biệt Authorization và Authentication

Authentication (Xác thực) và Authorization (Ủy quyền) là hai khái niệm quan trọng trong bảo mật hệ thống, nhưng chúng có vai trò khác nhau:

Tiêu chí	Authentication (Xác thực)	Authorization (Ủy quyền)
Định nghĩa	Xác minh danh tính người dùng	Kiểm soát quyền truy cập của người dùng
Mục đích	Kiểm tra xem "bạn là ai?"	Kiểm tra xem "bạn có quyền gì?"
Cách hoạt động	Người dùng cung cấp thông tin đăng nhập (username/password, OTP, token, v.v.)	Hệ thống kiểm tra quyền hạn để xác định user có thể truy cập tài nguyên nào
Thời điểm kiểm tra	Xảy ra trước khi cấp quyền truy cập	Xảy ra sau khi xác thực thành công
Công nghệ phổ biến	Password, OTP, Biometric, OAuth, SAML, JWT	Role-Based Access Control (RBAC), JSON Web Token (JWT), Access Control List (ACL)
Ví dụ thực tế	- Nhập username & password để đăng nhập vào ứng dụng	- Sau khi đăng nhập, chỉ admin mới có quyền truy cập trang quản trị

3. Variables và environments trong Postman

3.1 Variables là gì?

Variables (biến) là một giá trị có thể thay đổi được trong quá trình chạy chương trình hoặc thực thi một tác vụ nào đó. Biến giúp lưu trữ và quản lý dữ liệu một cách linh hoạt mà không cần phải sửa đổi trực tiếp mã nguồn nhiều lần.
Biến là biểu diễn tượng trưng của dữ liệu cho phép bạn truy cập giá trị mà không cần phải nhập thủ công bất cứ nơi nào bạn cần
Biến cho phép bạn lưu trữ và sử dụng lại giá trị trong các yêu cầu và tập lệnh của mình
Sử dụng biến giúp tăng khả năng làm việc hiệu quả và giảm thiểu khả năng xảy ra lỗi
Biến giúp yêu cầu của bạn linh hoạt và dễ đọc hơn

3.2 Phạm vi của Biến trong Postman

Postman hỗ trợ năm phạm vi biến, mỗi phạm vi phù hợp cho các tác vụ phát triển, kiểm thử và cộng tác khác nhau:

3.2.1 Global (Toàn cục)

🔹 Phạm vi: Có thể sử dụng ở bất kỳ đâu trong Postman.

🔹 Mục đích: Lưu trữ các giá trị dùng chung như URL API, token xác thực.

3.2.2 Collection (Bộ sưu tập)

🔹 Phạm vi: Áp dụng cho toàn bộ các request trong một collection.

🔹 Mục đích: Lưu các giá trị chung cho một tập hợp API cụ thể.

3.2.3 Environment (Môi trường)

🔹 Phạm vi: Chỉ áp dụng trong môi trường cụ thể (dev, staging, production).

🔹 Mục đích: Dùng để thay đổi giá trị API khi làm việc với nhiều môi trường khác nhau.

3.2.4 Data (Dữ liệu)

🔹 Phạm vi: Chỉ có hiệu lực khi chạy Collection Runner với file dữ liệu (CSV/JSON).

🔹 Mục đích: Dùng để kiểm thử dữ liệu động với nhiều giá trị khác nhau.

3.2.5 Local (Cục bộ)

🔹 Phạm vi: Chỉ tồn tại trong một request duy nhất.

🔹 Mục đích: Lưu trữ dữ liệu tạm thời cho một request mà không ảnh hưởng đến các biến khác.

Độ ưu tiên của phạm vi biến

Nếu một biến có cùng tên tồn tại trong nhiều phạm vi, Postman sẽ sử dụng biến có phạm vi hẹp nhất (tức là cụ thể nhất).

🔹 Ví dụ: Nếu cả biến toàn cục (global) và biến cục bộ (local) đều có tên "username", thì giá trị từ biến cục bộ sẽ được sử dụng khi gửi request.

Thứ tự ưu tiên của phạm vi biến (từ hẹp nhất đến rộng nhất):

Local (Cục bộ) – cụ thể nhất
Data (Dữ liệu)
Environment (Môi trường)
Collection (Bộ sưu tập)
Global (Toàn cục) – chung nhất

3.3. Environments trong Postman?

3.3.1 Enviroments trong Postman là gì?

Environments (Môi trường) trong Postman là tập hợp các cặp khóa-giá trị (key-value pairs) giúp bạn dễ dàng chuyển đổi giữa các cấu hình khác nhau khi kiểm thử API.
Thay vì thay đổi URL, API Key, Token hoặc các tham số khác bằng tay, bạn có thể sử dụng biến môi trường để tự động điều chỉnh giá trị theo từng môi trường cụ thể.

3.3.2. Lợi ích của Environments

Tự động hóa – Không cần chỉnh sửa thủ công mỗi lần đổi môi trường.
Tiện lợi – Dễ dàng chuyển đổi giữa Dev, Staging, và Production chỉ bằng một cú click.
Bảo mật – Có thể quản lý API Key, Token trong môi trường mà không hiển thị trực tiếp trong request.
Tái sử dụng – Sử dụng cùng một request cho nhiều môi trường khác nhau.