Phát triển phần mềm diễn ra nhanh chóng, đặc biệt trong môi trường Agile và phân phối liên tục. Các nhóm phát hành bản dựng thường xuyên, áp dụng các bản sửa lỗi nhanh và triển khai các cập nhật gia tăng. Trong bối cảnh này, kiểm thử Sanity đóng vai trò quan trọng trong việc đảm bảo rằng các thay đổi gần đây không làm hỏng chức năng cốt lõi của ứng dụng.
Bài viết này cung cấp một hướng dẫn chi tiết, thực tế về kiểm thử Sanity, giải thích nó là gì, khi nào nên sử dụng, cách nó phù hợp với vòng đời kiểm thử và cách các công cụ hiện đại như Apidog có thể hỗ trợ kiểm thử Sanity cho các hệ thống dựa trên API.
Nút

Kiểm thử Sanity là gì?
Kiểm thử Sanity là một loại kiểm thử phần mềm có trọng tâm, được thực hiện sau các thay đổi mã nhỏ, sửa lỗi hoặc cập nhật cấu hình. Mục đích của nó là nhanh chóng xác minh rằng các chức năng cụ thể vẫn hoạt động như mong đợi và bản dựng đủ ổn định để kiểm thử thêm.
Không giống như các phương pháp kiểm thử toàn diện, kiểm thử Sanity có tính hẹp, nông và có mục tiêu. Nó chỉ xác nhận các khu vực bị ảnh hưởng chứ không phải toàn bộ hệ thống.
Nói một cách đơn giản:
“Liệu thay đổi nhỏ này có hoạt động đúng cách không, hay nó đã làm hỏng một điều gì đó quan trọng?”
Kiểm thử Sanity và Kiểm thử Smoke
Kiểm thử Sanity thường bị nhầm lẫn với kiểm thử Smoke. Mặc dù chúng có liên quan, nhưng chúng phục vụ các mục đích khác nhau.
| Khía cạnh | Kiểm thử Sanity | Kiểm thử Smoke |
|---|---|---|
| Phạm vi | Hẹp và có trọng tâm | Rộng và nông |
| Kích hoạt | Sau các thay đổi nhỏ hoặc sửa lỗi | Sau một bản dựng mới |
| Mục đích | Xác minh tính đúng đắn của các tính năng cụ thể | Xác minh tính ổn định của bản dựng |
| Độ sâu | Sâu hơn kiểm thử Smoke | Rất cơ bản |
| Thực hiện | Thường là thủ công, đôi khi tự động | Thường là tự động |
Kiểm thử Smoke kiểm tra liệu bản dựng có thể kiểm thử được không. Kiểm thử Sanity kiểm tra liệu các thay đổi gần đây có hợp lý không.
Khi nào bạn nên thực hiện kiểm thử Sanity?
Kiểm thử Sanity thường được thực hiện trong các trường hợp sau:
- Sau khi một bản sửa lỗi được áp dụng
- Sau một cải tiến nhỏ hoặc tinh chỉnh tính năng
- Sau các thay đổi cấu hình hoặc môi trường
- Trước khi chạy kiểm thử hồi quy
- Trong các pipeline tích hợp liên tục (CI) để nhanh chóng xác nhận các bản vá
Nó đặc biệt có giá trị khi thời gian hạn chế và các nhóm cần phản hồi nhanh trước khi tiến hành xa hơn.
Quy trình kiểm thử Sanity
Kiểm thử Sanity không tuân theo một quy trình nặng nề, chính thức, nhưng nó vẫn được hưởng lợi từ cấu trúc.
Quy trình kiểm thử Sanity từng bước
- Xác định các module bị ảnh hưởng
Chỉ tập trung vào các khu vực bị ảnh hưởng bởi thay đổi gần đây. - Chọn (Đánh giá) các trường hợp kiểm thử quan trọng
Chọn các kiểm thử xác nhận logic cốt lõi và kết quả mong đợi. - Thực hiện kiểm thử Sanity
Thực hiện kiểm tra thủ công hoặc tự động.
Phân tích kết quả
- Nếu kiểm thử Sanity vượt qua → tiến hành kiểm thử sâu hơn
- Nếu kiểm thử Sanity thất bại → từ chối bản dựng và sửa lỗi ngay lập

Ví dụ về quy trình
Thay đổi mã → Bản dựng được tạo → Kiểm thử Sanity
→ Vượt qua → Kiểm thử hồi quy / hệ thống
→ Thất bại → Sửa chữa & Xây dựng lại
Các thuộc tính chính của kiểm thử Sanity
Kiểm thử Sanity có một số đặc điểm nổi bật:
- Tập trung: Chỉ nhắm mục tiêu vào chức năng bị ảnh hưởng
- Nhanh chóng: Thực hiện trong vài phút hoặc vài giờ, không phải vài ngày
- Không toàn diện: Không nhằm mục tiêu bao phủ hoàn toàn
- Theo định hướng thay đổi: Kích hoạt bởi các sửa đổi cụ thể
- Thường thủ công: Mặc dù tự động hóa là có thể đối với API và CI/CD
Những thuộc tính này làm cho kiểm thử Sanity trở nên lý tưởng cho các chu kỳ phát triển nhanh.
Ví dụ về kiểm thử Sanity (Quan điểm chức năng)
Hãy tưởng tượng một lỗi đăng nhập đã được sửa, trong đó logic xác thực mật khẩu đã được điều chỉnh.
Các trường hợp kiểm thử Sanity có thể bao gồm:
✓ Tên người dùng hợp lệ + mật khẩu hợp lệ → đăng nhập thành công
✓ Tên người dùng hợp lệ + mật khẩu không hợp lệ → hiển thị thông báo lỗi
✓ Tài khoản bị khóa → truy cập bị từ chối
Bạn sẽ không kiểm thử các tính năng không liên quan như chỉnh sửa hồ sơ người dùng hoặc xử lý thanh toán trong quá trình kiểm thử Sanity.
Kiểm thử Sanity cho API
Trong các ứng dụng hiện đại, API thường là những điểm tích hợp quan trọng nhất. Kiểm thử Sanity API đảm bảo rằng các thay đổi backend gần đây không làm hỏng hành vi yêu cầu/phản hồi.
Ví dụ: Kiểm thử Sanity cho một điểm cuối API
POST /api/login
Content-Type: application/json
{
"username": "test_user",
"password": "valid_password"
}
Phản hồi mong đợi:
{
"status": "success",
"token": "eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9..."
}
Nếu phản hồi này thay đổi bất ngờ sau khi sửa lỗi, kiểm thử Sanity sẽ phát hiện ra nó sớm.
Ưu điểm của kiểm thử Sanity
Kiểm thử Sanity mang lại một số lợi ích thiết thực:
- Tiết kiệm thời gian bằng cách tránh các chu kỳ hồi quy đầy đủ không cần thiết
- Cung cấp phản hồi nhanh chóng cho nhà phát triển
- Giảm rủi ro triển khai các bản dựng không ổn định
- Cải thiện sự tin cậy trong các bản phát hành nhỏ
- Phù hợp tự nhiên với quy trình làm việc Agile và DevOps
Hạn chế của kiểm thử Sanity
Mặc dù có giá trị, kiểm thử Sanity vẫn có những hạn chế:
- Không cung cấp độ bao phủ đầy đủ
- Có thể bỏ sót các lỗi ẩn hoặc gián tiếp
- Phụ thuộc nhiều vào phán đoán của người kiểm thử
- Không thể thay thế kiểm thử hồi quy hoặc kiểm thử hệ thống
Vì lý do này, kiểm thử Sanity nên được xem như một người gác cổng, chứ không phải là sự đảm bảo chất lượng cuối cùng.
Vị trí của kiểm thử Sanity trong Tháp kiểm thử
Kiểm thử Sanity thường nằm trên kiểm thử Smoke và dưới kiểm thử hồi quy.
Kiểm thử hệ thống / E2E
-------------------------
Kiểm thử hồi quy
-------------------------
Kiểm thử Sanity
-------------------------
Kiểm thử Smoke
-------------------------
Kiểm thử đơn vị
Vị trí này cho phép các nhóm lọc các bản dựng không ổn định sớm mà không tốn nhiều công sức kiểm thử.

Apidog giúp kiểm thử Sanity cho API như thế nào?
Đối với các nhóm xây dựng hệ thống dựa trên API, kiểm thử Sanity thường xoay quanh việc xác minh hành vi của điểm cuối sau các thay đổi. Apidog đặc biệt hiệu quả trong bối cảnh này.
Cách Apidog hỗ trợ kiểm thử Sanity
- Xác thực API nhanh chóng: Ngay lập tức chạy kiểm tra Sanity đối với các điểm cuối sau các thay đổi
- Các trường hợp kiểm thử có thể tái sử dụng: Lưu và tái sử dụng các kịch bản kiểm thử Sanity quan trọng
- Chuyển đổi môi trường: Xác thực các thay đổi trên các thiết lập phát triển, staging và giống như sản xuất
- Thực thi tự động: Tích hợp các kiểm thử Sanity API vào các pipeline CI/CD
- Các khẳng định rõ ràng: Xác thực mã trạng thái, lược đồ phản hồi và logic nghiệp vụ

Ví dụ: Kiểm tra Sanity API trong Apidog
{
"assertions": [
"statusCode == 200",
"response.body.token != null"
]
}
Điều này làm cho Apidog trở thành một công cụ lý tưởng để đảm bảo API vẫn ổn định sau các cập nhật gia tăng, mà không cần chạy toàn bộ bộ kiểm thử.
Nút
Các thực tiễn tốt nhất cho kiểm thử Sanity hiệu quả
Để tận dụng tối đa giá trị từ kiểm thử Sanity:
- Chỉ tập trung vào các thay đổi gần đây
- Giữ các trường hợp kiểm thử đơn giản và có thể lặp lại
- Duy trì một bộ kiểm thử Sanity nhỏ
- Tự động hóa các kiểm thử Sanity API khi có thể
- Kết hợp kiểm thử Sanity với kiểm thử Smoke và hồi quy
- Chạy kiểm thử Sanity sớm trong các pipeline CI/CD
Các câu hỏi thường gặp
Q1. Kiểm thử Sanity là thủ công hay tự động?
Kiểm thử Sanity theo truyền thống là thủ công, nhưng nó có thể được tự động hóa—đặc biệt đối với API và dịch vụ backend sử dụng các công cụ như Apidog.
Q2. Kiểm thử Sanity khác với kiểm thử hồi quy như thế nào?
Kiểm thử Sanity có phạm vi hẹp và nhanh chóng, tập trung vào các thay đổi gần đây. Kiểm thử hồi quy có phạm vi rộng hơn và đảm bảo chức năng hiện có không bị ảnh hưởng.
Q3. Ai thực hiện kiểm thử Sanity?
Thông thường là kỹ sư QA hoặc nhà phát triển, tùy thuộc vào cấu trúc nhóm và mức độ khẩn cấp của bản phát hành.
Q4. Kiểm thử Sanity có thể thay thế kiểm thử hồi quy không?
Không. Kiểm thử Sanity là một kiểm tra sơ bộ, không phải là sự thay thế cho kiểm thử hồi quy toàn diện.
Q5. Kiểm thử Sanity có bắt buộc cho mọi bản phát hành không?
Nó rất được khuyến nghị cho các bản cập nhật nhỏ và hotfix, đặc biệt trong môi trường Agile và DevOps.
Kết luận
Kiểm thử Sanity là một kỹ thuật kiểm thử nhẹ nhưng mạnh mẽ, đảm bảo các thay đổi gần đây hoạt động đúng cách mà không lãng phí thời gian vào các chu kỳ kiểm thử đầy đủ. Bằng cách tập trung vào các khu vực bị ảnh hưởng, nó cung cấp phản hồi nhanh chóng, giảm rủi ro và cải thiện độ tin cậy của bản phát hành.
Trong kiến trúc lấy API làm trung tâm, kiểm thử Sanity càng trở nên có giá trị. Các công cụ như Apidog giúp các nhóm thực hiện các kiểm thử Sanity đáng tin cậy, có thể lặp lại cho các điểm cuối API—giúp dễ dàng phát hiện vấn đề sớm và giữ cho quá trình phát triển diễn ra nhanh chóng mà không làm giảm chất lượng.
Nút
