Các bước viết testcase

1. Lý thuyết chung – Tại sao phải viết test case theo chuẩn này?

Mục tiêu cuối cùng: Đảm bảo 100% coverage các khía cạnh: Giao diện + Chức năng + Tích hợp + API + SQL + Ghi log + Điều hướng & UX.
Nguyên tắc cốt lõi:
- Mọi test case phải cụ thể, kiểm chứng được (có thể verify bằng mắt, bằng DB, bằng response API).
- Phải có test data + SQL query để kiểm tra dữ liệu thực tế.
- Luôn bao gồm cả positive case (thành công) và negative case (lỗi, biên giới).
- Mọi hành động quan trọng phải có Ghi log và DB verification.
- Tuân thủ UI/UX Design Guideline (font, màu, spacing, responsive…).

Quy ước chung (bắt buộc):

ID test case: Dự án_module_xxx (xxx tăng dần liên tục). Ví dụ: TCSG_DHVB_001
Mã chức năng: Mã chức năng của module/màn hình (BA cung cấp).
Loại test: Giao diện / Chức năng / Tích hợp / API / SQL / Ghi log / Điều hướng & UX.
UAT: Có / Không. (Để chọn các happy case thêm vào tài liệu UAT)
Test Data: Là dữ liệu mẫu cụ thể để thực hiện test (Có thể là câu truy vấn SQL hoặc dự liệu nhập liệu).

2. Template chung cho 1 test case (dùng cho mọi loại)

Cột	Nội dung cần điền
Mã chức năng	F1002
ID	TCSG_QLVB_001
Loại test	Giao diện / Chức năng…
UAT	Có / Không
Tên chức năng	Thêm mới văn bản đến
Tên tác nhân chính	Văn thư
Điều kiện trước	Màn hình Thêm mới văn bản đến đã mở
Test Data	Để trống
Mô tả trường hợp sử dụng	Kiểm tra trường Sổ văn bản*
Tên các trường hợp kiểm thử chức năng	Kiểm tra để trống trường Sổ văn bản*
Mô tả các bước thực hiện kiểm thử	1. Để trống trường… 2. Nhập thông tin còn lại hợp lệ 3. Nhấn Lưu
Kết quả mong đợi	Hiển thị thông báo bên dưới textbox “Vui lòng chọn Sổ văn bản.” + highlight trường
Kết quả thực tế
Ghi chú	(nếu có)

3. Test case mẫu chi tiết theo từng Loại test

3.1. Loại test: Giao diện (UI/UX)

Mục đích: Kiểm tra tuân thủ Design Guideline, tính trực quan, lỗi hiển thị.

Test case bắt buộc phải có ở đầu chức năng/màn khi viết/test testcase:

Kiểm tra giao diện tổng quan của màn hình dựa trên thiết kế đã có (Ví dụ: Figma,.. - tùy theo dự án)

Các quy tắc về giao diện sẽ được quy ước chung

Test case mẫu 1: Để trống trường bắt buộc

Mã chức năng: F1002
ID: TCSG_QLVB_002
Loại test: Giao diện
Tên chức năng: Thêm mới văn bản đến
Tên tác nhân chính: Văn thư
Tên các trường hợp kiểm thử: Kiểm tra để trống trường Sổ văn bản*
Các bước:
- 1. Để trống trường Sổ văn bản.
- 2. Nhập thông tin còn lại hợp lệ.
- 3. Nhấn Lưu.
Kết quả mong đợi: Hiển thị thông báo “Vui lòng chọn Sổ văn bản.” + highlight & focus trường.

Test case mẫu 2: Kiểm tra hiển thị mặc định

ID: TCSG_QLVB_003
Tên các trường hợp kiểm thử: Kiểm tra giá trị mặc định trường Sổ văn bản
Kết quả mong đợi: Hiển thị default text “<mặc định để trống>”.

Test case mẫu 3 (Date field): Kiểm tra hộp Calendar

Tên các trường hợp kiểm thử: Kiểm tra hoạt động hộp Calendar trường Ngày đến*
Các bước:
- 1. Click icon Calendar.
- 2. Chọn ngày.
- 3. Nhấn Đồng ý.
Kết quả mong đợi: Hộp đóng lại + ngày hiển thị đúng định dạng dd/mm/yyyy.

Test case mẫu 4 (File upload): Kiểm tra tải lên file

Tên các trường hợp kiểm thử: Kiểm tra tải file không đúng định dạng
Kết quả mong đợi: Hiển thị thông báo upload không hợp lệ.

Test case mẫu 5 (Dropdown): Kiểm tra tìm kiếm trong dropdownlist (nếu có)

Tên các trường hợp kiểm thử: Kiểm tra nhập tìm kiếm dữ liệu không tồn tại
Kết quả mong đợi: Hiển thị “Không có dữ liệu”.

3.2. Loại test: Chức năng (Functional) + SQL

Mục đích: Kiểm tra logic nghiệp vụ và dữ liệu lưu đúng DB.

Test case mẫu 1: Lưu thành công với dữ liệu đầy đủ

Loại test: Chức năng
Tên các trường hợp kiểm thử: Kiểm tra thêm mới văn bản thành công (nhập đầy đủ tất cả trường)
Test Data: SELECT * FROM incomming_documents WHERE to_book = N'UBND-TL1/2'
Các bước:
- 1. Nhập đầy đủ thông tin hợp lệ.
- 2. Nhấn Lưu.
- 3. Thực hiện SELECT trên DB.
- 4. Đối chiếu dữ liệu.
Kết quả mong đợi: Thông báo “Lưu thành công” + DB trả về đúng 1 dòng, dữ liệu khớp 100%.

Test case mẫu 2: Lưu thành công với các trường bắt buốc

Tên các trường hợp kiểm thử: Kiểm tra thêm mới khi chỉ nhập các trường bắt buộc
Các bước:
- 1. Nhập các trường bắt buộc, không nhập các trường bắt buộc.
- 2. Nhấn Lưu.
- 3. Thực hiện SELECT trên DB.
- 4. Đối chiếu dữ liệu.
Kết quả mong đợi: Lưu thành công, các trường không bắt buộc để trống hoặc giá trị mặc định.

3.3. Loại test: API

Mục đích: Kiểm tra endpoint, validation, quyền, response code.

Test case mẫu 1

Loại test: API
Tên các trường hợp kiểm thử: Kiểm tra Tạo mới văn bản thành công (full fields)
Test Data: Body JSON (đầy đủ) + token hợp lệ
Các bước:
- 1. Gửi POST request với body hợp lệ.
- 2. Kiểm tra response.
- 3. Kiểm tra DB.
Kết quả mong đợi: Status 201 + message “Document created successfully” + DB có bản ghi mới.

Test case mẫu 2

Tên các trường hợp kiểm thử: Kiểm tra thiếu trường bắt buộc
Các bước:
- 1. Gửi POST request với body thiếu trường bắt buộc.
- 2. Kiểm tra response.
- 3. Kiểm tra DB.
Kết quả mong đợi: Status 400 + message “Missing required field: So_van_ban”.

Test case mẫu 3

Tên các trường hợp kiểm thử: Kiểm tra user không có quyền
Các bước:
- 1. Gửi POST request với token của user không có quyền
- 2. Kiểm tra response.
- 3. Kiểm tra DB.
Kết quả mong đợi: Status 403 Forbidden.

Test case mẫu 4

Tên các trường hợp kiểm thử: Kiểm tra thiếu token
Các bước:
- 1. Gửi POST request với token để trống.
- 2. Kiểm tra response.
- 3. Kiểm tra DB.
Kết quả mong đợi: Status 401 Unauthorized.

3.4. Loại test: Tích hợp (Integration)

Mục đích: Kiểm tra các module liên kết với nhau.

Test case mẫu

Loại test: Tích hợp
Tên các trường hợp kiểm thử: Kiểm tra lưu văn bản tiếp nhận thành công vào Sổ văn bản
Các bước:
- 1. Thêm mới văn bản tiếp nhận.
- 2. Truy cập Sổ văn bản đến.
Kết quả mong đợi: Văn bản mới xuất hiện đúng trong sổ + file đính kèm được lưu vào bảng file_relations.

3.5. Loại test: Ghi log

Mục đích: Đảm bảo mọi hành động quan trọng đều được ghi lại.

Test case mẫu

Loại test: Ghi log
Tên các trường hợp kiểm thử: Kiểm tra Ghi log khi lưu văn bản
Các bước:
- 1. Thêm mới văn bản thành công.
- 2. Truy cập log hệ thống.
Kết quả mong đợi:
- Ghi đầy đủ:
  - Tài khoản, Họ tên, Đơn vị, Mô tả thao tác (“Thêm mới/Truy cập/.....”), Trạng thái, IP, Thời gian.

3.6. Loại test: Điều hướng & UX

Mục đích: Kiểm tra trải nghiệm người dùng mượt mà, không gây bất ngờ.

Test case mẫu 1

Loại test: Điều hướng và UX
Tên các trường hợp kiểm thử: Kiểm tra Button Hủy thêm mới
Kết quả mong đợi: Không lưu dữ liệu + quay về danh sách.

Test case mẫu 2

Tên các trường hợp kiểm thử: Kiểm tra confirm xóa file
Kết quả mong đợi: Popup xác nhận xuất hiện → Chọn Hủy → file vẫn còn.

4. Checklist bắt buộc khi viết xong 1 test case

Có Test Data + SQL query rõ ràng
Có cả positive & negative case
Có DB verification (SELECT)
Có API test song song (nếu là chức năng CRUD)
Có Ghi log cho action quan trọng
File upload/download/view/delete đầy đủ
Date field kiểm tra format + logic (quá khứ/hiện tại/tương lai)
Dropdown/search/empty/invalid data
Export theo filter (có dữ liệu / không dữ liệu)
UX: confirm, cancel, navigation không lag