# Cách Viết Test Case Chuẩn (Kèm Ví Dụ + Template)

> Nắm được cách viết test case rõ ràng là kỹ năng "cơm áo" đầu tiên của mọi Manual Tester — vì đây là thứ bạn làm gần như mỗi ngày. 🙂 Một test case tốt giúp ai đọc cũng thực thi được y hệt, kết quả kiểm chứng được, và không bỏ sót tình huống quan trọng. Bài này tôi hướng dẫn từng bước theo đúng một template thực tế, kèm ví dụ màn hình đăng nhập và file template để bạn tải về dùng ngay.

- **URL canonical**: https://itlearn.edu.vn/blog/cach-viet-test-case
- **Published**: 2026-06-19T09:20:00+07:00
- **Modified**: 2026-08-02T21:19:18+07:00
- **Author**: Anh Tuấn
- **Category**: Manual Testing (https://itlearn.edu.vn/blog/cat/manual-testing)
- **Reading time**: 10 phút
- **Source site**: IT LEARN — Học viện Software Testing tiếng Việt

---

## Test case là gì?

**Test case là một tập hợp gồm điều kiện tiền đề, các bước thực hiện và kết quả mong đợi**, được thiết kế để kiểm tra xem một chức năng có hoạt động đúng yêu cầu hay không. Theo ISTQB, test case được phát triển từ các điều kiện test (test condition) trong [bước thiết kế test của quy trình kiểm thử](/blog/quy-trinh-kiem-thu-stlc), nhằm kiểm chứng một mục tiêu cụ thể, đo lường được.

Nói nôm na, test case giống một "kịch bản thử" rất chi tiết: làm gì, ở trạng thái nào, và mong đợi hệ thống phản hồi ra sao. Viết tốt thì người khác cầm lên chạy được ngay mà không cần hỏi lại bạn câu nào — đó mới là test case đạt chuẩn.

## Các trường bắt buộc trong một test case

Dưới đây là các cột theo đúng template IT LEARN dùng. Mỗi test case khai báo ở dòng đầu (ID, Description, Pre-condition), sau đó liệt kê từng bước:

Cột trong template

Ý nghĩa / cách điền

ID

Mã định danh duy nhất, gắn theo ticket (VD: TC_FCQ12-81_001)

Test Case Description

Mô tả mục tiêu test trong 1 câu, đọc là hiểu test cái gì

Pre-condition

Trạng thái cần có TRƯỚC khi chạy (VD: user chưa đăng nhập)

Step

Các bước thực hiện, đánh số — **mỗi bước một dòng**

Expected output

Kết quả mong đợi tương ứng cho từng bước

Expected result

Kết quả mong đợi (theo bước/tổng thể) — nhiều đội điền trùng output

Actual Output

Kết quả thực tế quan sát được khi chạy

Result

Passed / Failed / Blocked / Pending

Test date

Ngày thực thi test

Note

Link bug, ảnh chụp, lưu ý đặc biệt

Ngoài bảng test case, phần đầu sheet còn có khối thông tin chung cần điền: **Function Name** (chức năng đang test), **Created By** (người viết), **Environment** và **Screen resolution** (môi trường, độ phân giải). Các ô **Passed / Failed / Number of Test cases** tự đếm bằng công thức, bạn không cần điền tay.

## Cách viết test case từng bước

Đây là quy trình tôi vẫn dạy học viên, khớp với cách điền template ở trên:

- **Điền khối thông tin chung trước.** Function Name, Created By, Environment, Screen resolution — để người đọc biết test cho chức năng nào, trên môi trường nào.

- **Hiểu yêu cầu cần test.** Đọc kỹ user story/đặc tả, làm rõ chỗ mơ hồ với BA. Không hiểu "đúng" là gì thì không test đúng được.

- **Xác định các điều kiện test.** Liệt kê những gì cần kiểm tra: hợp lệ, không hợp lệ, biên, ngoại lệ — mỗi điều kiện sẽ thành một test case.

- **Đặt ID và Description.** Mỗi test case một ID theo quy luật (ticket + số thứ tự), Description tóm tắt mục tiêu trong một câu.

- **Ghi Pre-condition và liệt kê Step.** Mỗi bước một dòng, đánh số, mỗi dòng một hành động duy nhất để người chạy không nhầm.

- **Viết Expected output cho từng bước.** Đây là phần quan trọng nhất: nêu cụ thể hệ thống phải hiển thị/chuyển hướng/báo lỗi gì ở mỗi bước, tránh viết chung chung "chạy đúng".

- **Review chéo, rồi cập nhật khi thực thi.** Nhờ đồng nghiệp đọc lại để bắt lỗi thiết kế; lúc chạy thật thì điền Actual Output, Result và Test date — nếu phát hiện lỗi, ghi nhận theo [vòng đời bug & cách viết bug report](/blog/bug-life-cycle-bug-report).

Mẹo nhỏ: phủ đủ ba nhóm — **hợp lệ (positive)**, **không hợp lệ (negative)** và **biên (boundary)** — là tránh được phần lớn lỗi sót. Gặp thuật ngữ lạ thì tra nhanh ở [thuật ngữ kiểm thử](/blog/thuat-ngu-kiem-thu/).

## Ví dụ test case thực tế (form đăng nhập)

Lấy luôn màn hình đăng nhập của một "Hệ thống đặt phòng họp nội bộ" làm ví dụ. Để ý cách mỗi Step có một Expected output tương ứng:

ID

Description

Pre-condition

Step

Expected output

Result

TC_FCQ12-81_002

Đăng nhập với email & mật khẩu đúng

Đã có tài khoản hợp lệ; user chưa đăng nhập

1. Mở màn hình đăng nhập
2. Nhập email đúng
3. Nhập mật khẩu đúng
4. Click "Đăng nhập"

1. Form hiển thị, focus ở Email
2. Email hiển thị giá trị
3. Mật khẩu dạng masked (••••)
4. Xác thực thành công, chuyển sang Dashboard

Pending

TC_FCQ12-81_006

Đăng nhập với email đúng, mật khẩu sai

Đã có tài khoản hợp lệ; user chưa đăng nhập

1. Mở màn hình đăng nhập
2. Nhập email tồn tại
3. Nhập mật khẩu sai
4. Click "Đăng nhập"

1. Form hiển thị
2. Email hiển thị giá trị
3. Mật khẩu masked
4. Hiện alert đỏ "Email hoặc mật khẩu không đúng", vẫn ở LoginScreen

Pending

TC_FCQ12-81_011

Bỏ trống trường Email

User chưa đăng nhập, đang ở LoginScreen

1. Mở màn hình đăng nhập
2. Để trống Email
3. Nhập mật khẩu
4. Click "Đăng nhập"

1. Form hiển thị
2. Email rỗng
3. Mật khẩu masked
4. Trình duyệt báo lỗi inline required, form không submit

Pending

Hai dấu hiệu của bộ test case chuyên nghiệp: **ID đặt theo quy luật** và **Expected output luôn cụ thể, kiểm chứng được** ở từng bước.

## Template test case tải về

Để bạn khỏi mất công kẻ bảng từ đầu, dùng luôn template chuẩn của IT LEARN (đã có sẵn khối thông tin chung, công thức tự đếm Passed/Failed và bộ ví dụ màn hình đăng nhập):

👉 **[Tải template test case (.xlsx)](https://1drv.ms/x/c/be5dea834011f600/IQDzmYqHRFBFRo9yZPl6Xo8BAYOkRaAbdXPc44bAO2Zh9N4?e=gSHWJF)**

Cách dùng nhanh:

- Mỗi **chức năng/màn hình** nên là một sheet riêng (sheet mẫu tên "Đăng nhập").

- Điền khối thông tin chung ở đầu sheet (Function Name, Created By, Environment…).

- Với mỗi test case: ghi **ID + Description + Pre-condition** ở dòng đầu, rồi liệt kê **Step** mỗi bước một dòng, kèm **Expected output** tương ứng.

- Khi chạy test: điền **Actual Output**, chọn **Result** (Passed/Failed/Blocked/Pending) và **Test date** — ô tổng kết sẽ tự cập nhật.

## Lỗi thường gặp khi viết test case

Qua 18 năm review test case, đây là những lỗi tôi gặp nhiều nhất ở người mới:

- **Expected output mơ hồ.** Viết "hệ thống chạy đúng" thay vì mô tả cụ thể hiển thị/chuyển hướng/thông báo gì. Người khác không biết lấy gì để kết luận Pass/Fail.

- **Gộp nhiều hành động vào một Step.** Một dòng nhồi 3-4 thao tác khiến người chạy dễ nhầm. Mỗi Step nên là một hành động, và có Expected output riêng.

- **Chỉ test trường hợp hợp lệ.** Quên các tình huống sai/biên (mật khẩu sai, bỏ trống, sai định dạng) — vốn là nơi lỗi hay ẩn nấp nhất.

- **Thiếu Pre-condition.** Người chạy không biết phải chuẩn bị trạng thái gì trước, dẫn đến kết quả không nhất quán.

- **Test case quá lớn hoặc trùng lặp.** Một test case nên kiểm chứng một mục tiêu rõ ràng, không "ôm" cả luồng dài.

Sửa được năm lỗi này thôi là chất lượng test case của bạn đã hơn hẳn rồi. 💪

## Câu hỏi thường gặp

### Test case khác test scenario thế nào?

Test scenario là một tình huống/luồng cần kiểm thử ở mức tổng quát (ví dụ "kiểm thử chức năng đăng nhập"). Test case là phần chi tiết hóa scenario thành các bước cụ thể với điều kiện tiền đề và kết quả mong đợi. Một test scenario thường sinh ra nhiều test case khác nhau — xem chi tiết [test scenario vs test case](/blog/test-scenario-vs-test-case).

### Một test case gồm những gì?

Theo template chuẩn, một test case gồm: ID, Test Case Description, Pre-condition, Step, Expected output, Expected result, và khi thực thi thì thêm Actual Output, Result, Test date, Note. Trong đó Expected output là phần quan trọng nhất vì nó quyết định Pass hay Fail ở mỗi bước.

### Viết bao nhiêu test case là đủ?

Không có con số cố định; đủ là khi phủ hết các điều kiện test quan trọng theo rủi ro. Hãy đảm bảo cả ba nhóm: hợp lệ, không hợp lệ và biên. Ưu tiên chức năng rủi ro cao và dùng kỹ thuật thiết kế test để tránh viết tràn lan mà vẫn sót trường hợp.

### Có cần biết code để viết test case không?

Không. Viết test case là kỹ năng tư duy và diễn đạt, không phải lập trình — phù hợp cả với người mới và trái ngành. Bạn chỉ cần hiểu yêu cầu và mô tả mạch lạc. Xem thêm [lộ trình học tester](/blog/lo-trinh-hoc-tester-cho-nguoi-moi-bat-dau-2026) để biết nên học gì trước.

### Công cụ quản lý test case nào phổ biến?

Với đội nhỏ, nhiều người dùng Excel hoặc Google Sheets (như template ở trên). Khi quy mô lớn hơn, các công cụ phổ biến gồm TestRail, Zephyr, Xray (tích hợp Jira) hay qTest. Quan trọng vẫn là chất lượng test case; công cụ chỉ giúp tổ chức và theo dõi thuận tiện hơn. Muốn luyện viết test case bài bản trên dự án thật và được review trực tiếp, bạn có thể tham khảo [khóa Manual Testing](/newtester.html) của IT LEARN.