Test case là gì? Cách viết test case chuẩn kèm mẫu và ví dụ

Test case là gì?

Test case là một tập hợp gồm điều kiện tiên quyết, dữ liệu đầu vào, các bước thực hiện và kết quả mong đợi, được xây dựng để kiểm tra xem phần mềm có hoạt động đúng như yêu cầu trong một tình huống cụ thể hay không.

Điểm cốt lõi nằm ở hai chữ "kết quả mong đợi". Nếu bạn không xác định trước hệ thống phải phản ứng thế nào, thì thao tác của bạn chỉ là dùng thử, không phải kiểm thử — vì bạn không có cơ sở nào để nói kết quả là đúng hay sai.

Phân biệt Test scenario và Test case

Một test case gồm những thành phần nào?

Ba nhóm test case cần có: Normal – Abnormal – Boundary

Đây là khung tư duy đơn giản nhất để không bỏ sót. Với bất kỳ chức năng nào, hãy tự hỏi ba câu theo thứ tự này.

1. Normal case — luồng đúng

Người dùng làm đúng mọi thứ thì hệ thống có chạy đúng không. Đây là nhóm ít lỗi nhất nhưng bắt buộc phải có, vì nếu luồng chính hỏng thì không cần test tiếp.

2. Abnormal case — luồng sai

Người dùng nhập sai, bỏ trống, nhập sai định dạng, thao tác sai thứ tự, mất mạng giữa chừng. Đây là nơi phần lớn khiếm khuyết ẩn náu, vì lập trình viên thường code cho luồng đúng trước.

3. Boundary case — giá trị biên

Các giá trị nằm ngay tại và sát ranh giới cho phép. Lỗi lệch một đơn vị là loại lỗi kinh điển của lập trình, nên đây là nhóm cho tỉ lệ tìm ra lỗi trên mỗi test case cao nhất.

Ví dụ: bộ test case cho chức năng đăng nhập

Giả sử yêu cầu: người dùng đăng nhập bằng email và mật khẩu; mật khẩu từ 8 đến 32 ký tự; sai quá 5 lần liên tiếp thì khoá tài khoản trong 15 phút.

7 nguyên tắc viết test case tốt

1. Mỗi test case kiểm tra đúng một điều. Gộp nhiều mục đích vào một test case khiến bạn không biết chính xác cái gì hỏng khi nó fail.
2. Viết cho người khác đọc. Giả định người thực thi chưa từng thấy sản phẩm — nếu họ phải hỏi bạn, test case chưa đạt.
3. Kết quả mong đợi phải cụ thể và kiểm chứng được. Tránh các từ như "đúng", "bình thường", "hợp lý".
4. Độc lập với nhau. Test case sau không nên phụ thuộc vào trạng thái do test case trước để lại, trừ khi bạn cố tình thiết kế một chuỗi.
5. Dữ liệu cụ thể, không nói chung chung. Ghi "nhập 100000000" thay vì "nhập số tiền lớn".
6. Truy vết được về yêu cầu. Mỗi test case nên chỉ ra nó phủ yêu cầu nào — để khi yêu cầu thay đổi bạn biết cần sửa test case nào.
7. Đặt tên có ý nghĩa. Đọc tiêu đề là hiểu tình huống, không cần mở chi tiết.

Mẫu test case dùng ngay

Nếu đội bạn quản lý test case bằng bảng tính, đây là bộ cột tối thiểu nên có. Thêm cột thì được, bớt cột thì nên cân nhắc kỹ.

Test Case ID   | Module    | Tiêu đề
Precondition   | Test Data | Steps
Expected Result| Actual Result | Status
Priority       | Requirement ID | Ghi chú

Ví dụ một dòng:
TC_LOGIN_007 | Đăng nhập | Khoá tài khoản sau 6 lần sai mật khẩu
Precondition: Tài khoản test@pinelab.vn active, bộ đếm sai = 0
Test Data: email hợp lệ + mật khẩu sai, lặp 6 lần
Steps: 1) Mở /login  2) Nhập email  3) Nhập mật khẩu sai  4) Bấm Đăng nhập  5) Lặp lại bước 3-4 sáu lần
Expected: Từ lần thứ 6, hệ thống khoá tài khoản 15 phút và hiển thị thời gian còn lại
Priority: High | Requirement: REQ-AUTH-012