Trang chủ Kho kiến thức Lý thuyết kiểm thử phần mềm: Test Case & Test Data

Lý thuyết kiểm thử phần mềm: Test Case & Test Data

Khám phá kiến thức về Test Case, quy trình thực thi kiểm thử và cách quản lý dữ liệu Test Data chuẩn xác giúp nâng cao chất lượng phần mềm hiệu quả nhất hiện nay.

Test Case là gìThực thi kiểm thửTest DataQuy trình kiểm thửKỹ thuật thiết kế test caseDefect Life CycleQuản lý dữ liệu kiểm thử

 
Infographic: Test Case, Thực Thi & Dữ Liệu Kiểm Thử

1. Kịch Bản Kiểm Thử (Test Case)

1.1. Khái Niệm Cốt Lõi

fact_check

Test Case (Kịch bản kiểm thử) là một tập hợp các điều kiện, biến số, và hành động được sử dụng để xác định liệu một hệ thống phần mềm có hoạt động đúng theo yêu cầu đã định trước hay không.

  • Đóng vai trò là bản đồ chỉ đường cho tester.
  • Đảm bảo mọi tính năng được kiểm tra kỹ lưỡng.
  • Là tài liệu chuẩn mực để đánh giá chất lượng phần mềm trước khi phát hành.

1.2. Tại Sao Cần Viết Test Case?

verified_user
Đảm bảo độ bao phủ (Coverage) Giúp xác nhận không có yêu cầu chức năng nào bị bỏ sót trong quá trình kiểm thử.
history
Tái sử dụng & Lịch sử Có thể dùng lại cho các bản phát hành sau (Regression Testing). Lưu lại lịch sử kiểm thử rõ ràng.
bug_report
Phát hiện lỗi sớm Việc phân tích yêu cầu để viết test case giúp phát hiện các điểm mâu thuẫn ngay từ khâu thiết kế.
group
Đồng bộ nhóm Bất kỳ tester nào cũng có thể đọc và thực hiện theo kịch bản mà không cần phụ thuộc vào người tạo ban đầu.

1.3. Cấu Trúc Chuẩn Của Một Test Case

Một Test Case chuyên nghiệp không chỉ có "Bước thực hiện" và "Kết quả mong đợi". Nó bao gồm nhiều thành phần quan trọng để đảm bảo tính rõ ràng và khả năng truy vết.

tag Test Case ID

Mã định danh duy nhất. Thường đặt theo quy tắc: [Dự_án]_[Module]_[Số_thứ_tự]. Ví dụ: LOGIN_TC_001.

description Tiêu Đề (Title)

Mô tả ngắn gọn mục đích của test case. Phải rõ ràng, có động từ và kết quả. Ví dụ: "Kiểm tra đăng nhập thành công với tài khoản hợp lệ".

vpn_key Điều Kiện Tiên Quyết

Các điều kiện phải có sẵn trước khi bắt đầu test. (Pre-conditions). Ví dụ: "Người dùng đã có tài khoản active trên hệ thống".

format_list_numbered Các Bước Thực Hiện (Test Steps)

Liệt kê tuần tự, chi tiết từng thao tác người dùng sẽ thực hiện.

  1. Truy cập trang đăng nhập.
  2. Nhập username hợp lệ.
  3. Nhập password hợp lệ.
  4. Click nút "Đăng nhập".
database Dữ Liệu Test (Data)

Dữ liệu cụ thể được dùng cho các bước. Ví dụ:
User: admin_test
Pass: 123456@Aa.

done_all Kết Quả Mong Đợi (Expected Result)

Trạng thái hệ thống phải đạt được sau khi thực hiện các bước. Dựa vào tài liệu yêu cầu (SRS).
Ví dụ: "Hệ thống chuyển hướng sang trang Dashboard và hiển thị lời chào 'Xin chào admin_test'".

rule Trạng Thái (Status)

Được điền trong quá trình thực thi. Thường bao gồm: Pass (Đạt), Fail (Trượt), Blocked (Bị chặn), Skipped (Bỏ qua).

1.4. Đặc Điểm Của Một Test Case Tốt

  • check
    Độc lập và tự chứa (Independent): Không nên phụ thuộc vào test case khác. Nếu có, phải ghi rõ trong Điều kiện tiên quyết.
  • check
    Rõ ràng và súc tích (Clear & Concise): Viết để ai đọc cũng hiểu và làm theo được. Tránh dùng từ ngữ mơ hồ như "kiểm tra xem nó có ok không".
  • check
    Đại diện cho người dùng cuối (End-user perspective): Hãy suy nghĩ như một khách hàng đang sử dụng sản phẩm.
  • check
    Có khả năng truy vết (Traceable): Phải map (liên kết) được với một Requirement (Yêu cầu) cụ thể trong tài liệu.

1.5. Các Kỹ Thuật Thiết Kế Test Case Cơ Bản

Để viết test case hiệu quả mà không bị bùng nổ số lượng, tester sử dụng các kỹ thuật thiết kế hộp đen (Black-box testing techniques):

border_all Phân vùng tương đương (Equivalence Partitioning)

Chia dữ liệu đầu vào thành các nhóm (vùng) hợp lệ và không hợp lệ. Chọn 1 giá trị đại diện từ mỗi vùng để test thay vì test tất cả.

Ví dụ: Yêu cầu tuổi từ 18-60. Chia vùng: <18, 18-60, >60.

linear_scale Phân tích giá trị biên (Boundary Value Analysis)

Lỗi thường xảy ra ở các ranh giới. Kỹ thuật này tập trung kiểm thử các giá trị ngay tại biên và sát biên.

Ví dụ biên 18 và 60: Cần test các giá trị: 17, 18, 19 và 59, 60, 61.

alt_route Bảng quyết định (Decision Table)

Sử dụng cho các logic kinh doanh phức tạp có nhiều điều kiện kết hợp. Liệt kê tất cả các tổ hợp điều kiện (Input) và hành động tương ứng (Output) dưới dạng bảng.

2. Thực Thi Kiểm Thử (Test Execution)

2.1. Định Nghĩa Thực Thi Kiểm Thử

Test Execution là quá trình chạy các đoạn mã phần mềm trong môi trường kiểm thử để so sánh Kết quả thực tế (Actual Result) với Kết quả mong đợi (Expected Result) đã được định nghĩa trong Test Case.

2.2. Điều Kiện Tiên Quyết Để Thực Thi

Bạn không thể cứ thế mà test. Mọi thứ phải sẵn sàng:

task Test Case đã được thiết kế và review xong.
code Team Dev đã hoàn thành code và build bản Release.
dns Môi trường Test (QA/Staging Environment) đã sẵn sàng.
dataset Dữ liệu kiểm thử (Test Data) đã được chuẩn bị đầy đủ.

2.3. Trạng Thái Của Quá Trình Thực Thi

Sau khi chạy một Test Case, Tester phải gán trạng thái (Status) cho nó. Đây là các trạng thái phổ biến nhất:

check_circle

PASS

Kết quả thực tế khớp hoàn toàn với kết quả mong đợi. Tính năng hoạt động đúng.

cancel

FAIL

Kết quả thực tế sai lệch với kết quả mong đợi. Phát hiện Bug và cần log lỗi cho Dev.

block

BLOCKED

Không thể thực hiện Test Case này do bị chặn bởi một lỗi khác hoặc môi trường lỗi.

next_plan

SKIPPED

Bỏ qua không thực hiện do yêu cầu bị thay đổi hoặc không còn cần thiết trong chu kỳ test này.

2.4. Quy Trình Vòng Đời Của Lỗi (Defect Life Cycle) Trong Thực Thi

Khi quá trình thực thi trả về trạng thái FAIL, một vòng đời của Bug sẽ bắt đầu:

1. New / Mới

Tester báo cáo lỗi.

arrow_downward
2. Assigned

Giao cho Developer sửa.

arrow_downward
3. Fixed

Dev đã sửa và đẩy code.

arrow_downward
4. Re-test

Tester kiểm tra lại.

arrow_downward
5. Closed

Lỗi đã hoàn toàn khắc phục.

2.5. Các Hướng Tiếp Cận Thực Thi

pan_tool Kiểm Thử Thủ Công (Manual Execution)

Tester tự tay mở ứng dụng, tự nhập dữ liệu, click nút bấm và quan sát kết quả bằng mắt. Phù hợp cho kiểm thử khám phá, tính tiện dụng (Usability) và các tính năng thay đổi liên tục.

smart_toy Kiểm Thử Tự Động (Automated Execution)

Sử dụng các công cụ/script (Selenium, Appium, Cypress) để máy tính tự động chạy các bước test. Cực kỳ nhanh, độ chính xác cao. Hoàn hảo cho Regression Testing (kiểm thử hồi quy) khối lượng lớn.

3. Dữ Liệu Kiểm Thử (Test Data)

3.1. Dữ Liệu Kiểm Thử Là Gì?

dataset

Test Data là toàn bộ dữ liệu, thông tin đầu vào được cung cấp cho hệ thống phần mềm nhằm mục đích thực thi một Test Case. Nó là "nhiên liệu" để kích hoạt các logic nghiệp vụ bên trong code.

3.2. Vai Trò Tối Quan Trọng Của Test Data

  • Kiểm thử đường dẫn dương (Happy Path): Cung cấp dữ liệu chuẩn để xem ứng dụng có chạy mượt mà không.
  • Kiểm thử đường dẫn âm (Negative/Error Path): Cung cấp dữ liệu sai để xem hệ thống có bắt lỗi và văng ra thông báo đúng chuẩn (Validation message) hay bị sập (crash).
  • Kiểm thử hiệu năng (Performance): Tạo ra hàng triệu dòng dữ liệu để đo lường tải của Database.
  • Đảm bảo tính thực tế: Dữ liệu test càng giống thực tế (Production), chất lượng kiểm thử càng cao.

3.3. Phân Loại Dữ Liệu Kiểm Thử

Dữ liệu kiểm thử phải đa dạng, bao phủ nhiều trường hợp khác nhau. Dưới đây là các loại phổ biến:

check_circle Dữ liệu hợp lệ (Valid Data)

Dữ liệu hoàn toàn đúng chuẩn về định dạng, độ dài và logic nghiệp vụ. Hệ thống phải chấp nhận dữ liệu này.

VD Email: nguyenvan.a@gmail.com

cancel Dữ liệu không hợp lệ (Invalid Data)

Dữ liệu sai định dạng, chứa ký tự đặc biệt không cho phép. Hệ thống phải từ chối và báo lỗi.

VD Email: nguyenvan.a@gmail (thiếu đuôi .com)

straighten Dữ liệu ranh giới (Boundary Data)

Dữ liệu nằm ngay tại các ngưỡng tối thiểu hoặc tối đa cho phép. Thường dễ gây lỗi Off-by-one trong code.

VD Mật khẩu (8-16 ký tự): Test với chuỗi đúng 8 ký tự và chuỗi đúng 16 ký tự.

space_bar Dữ liệu trống / Null

Bỏ trống các trường dữ liệu. Kiểm tra xem các trường bắt buộc (Mandatory) có hoạt động đúng không.

VD: Bấm "Đăng ký" nhưng không điền gì vào ô Tên đăng nhập.

3.4. Nguồn Gốc Và Cách Tạo Test Data

edit_note
Tạo thủ công (Manual Generation) Tester tự bịa ra dữ liệu và nhập bằng tay. Phù hợp cho tính năng nhỏ, đơn giản. Mất nhiều thời gian.
auto_mode
Tạo tự động (Automated/Mock Data) Sử dụng tool, script hoặc thư viện (như Faker) để sinh ra hàng ngàn dòng dữ liệu ngẫu nhiên (Tên, Số điện thoại, Địa chỉ) nhanh chóng.
content_copy
Clone từ Production (Production Data Copy) Lấy trực tiếp dữ liệu thật của người dùng từ hệ thống thật đưa về môi trường Test. Đảm bảo tính thực tế cao nhất.
masks
Che dấu dữ liệu (Data Masking / Obfuscation) Cực kỳ quan trọng: Khi dùng data từ Production, phải mã hóa hoặc che đi các thông tin nhạy cảm PII (Tên thật, số thẻ tín dụng, mật khẩu) để bảo mật.

3.5. Một Tính Toán Nhỏ Về Số Lượng Test Data

Trong trường hợp kiểm thử tổ hợp (Combinatorial Testing), số lượng test data tăng theo cấp số nhân.

Nếu có 3 biến: X (có 3 giá trị), Y (có 4 giá trị), Z (có 2 giá trị). Tổng số test data cần thiết là:

Ttotal=NX×NY×NZ=3×4×2=24T_{total} = N_X \times N_Y \times N_Z = 3 \times 4 \times 2 = 24

(Sử dụng kỹ thuật Pairwise/Orthogonal Array có thể giúp giảm thiểu con số này mà vẫn giữ độ bao phủ cao).

Mối Quan Hệ Tương Hỗ Chặt Chẽ

1. Test Case
Quy định luật chơi
arrow_downward
2. Test Data
Cung cấp nguyên liệu
arrow_downward
3. Test Execution
Tạo ra kết quả

Thiếu bất kỳ yếu tố nào, quá trình Đảm bảo chất lượng phần mềm (QA) đều sẽ thất bại hoặc không mang lại giá trị thực tiễn.

Mục lục
1. Kịch Bản Kiểm Thử (Test Case)
1.1. Khái Niệm Cốt Lõi
1.2. Tại Sao Cần Viết Test Case?
1.3. Cấu Trúc Chuẩn Của Một Test Case
1.4. Đặc Điểm Của Một Test Case Tốt
1.5. Các Kỹ Thuật Thiết Kế Test Case Cơ Bản
2. Thực Thi Kiểm Thử (Test Execution)
2.1. Định Nghĩa Thực Thi Kiểm Thử
2.2. Điều Kiện Tiên Quyết Để Thực Thi
2.3. Trạng Thái Của Quá Trình Thực Thi
2.4. Quy Trình Vòng Đời Của Lỗi (Defect Life Cycle) Trong Thực Thi
2.5. Các Hướng Tiếp Cận Thực Thi
3. Dữ Liệu Kiểm Thử (Test Data)
3.1. Dữ Liệu Kiểm Thử Là Gì?
3.2. Vai Trò Tối Quan Trọng Của Test Data
3.3. Phân Loại Dữ Liệu Kiểm Thử
3.4. Nguồn Gốc Và Cách Tạo Test Data
3.5. Một Tính Toán Nhỏ Về Số Lượng Test Data
Mối Quan Hệ Tương Hỗ Chặt Chẽ
Khoá học liên quan
Khóa học Tester: Lý thuyết Kiểm thử phần mềm cơ bản từ A-Z

2.371 xem 12 kiến thức 5 đề thi

Kiến thức tương tự
img
Lý thuyết kiểm thử phần mềm: Lập kế hoạch và chiến lược test

20.991 lượt xem 11/04/2026

img
Lý thuyết Kiểm Thử: KT CD Trạng Thái (State Transition Test)

21.101 lượt xem 11/04/2026

img
Lý thuyết Kiểm thử phần mềm: Quy trình & Vòng đời SDLC STLC

20.974 lượt xem 11/04/2026

img
Lý thuyết kiểm thử phần mềm: KT Cặp (Pairwise Testing)

21.150 lượt xem 11/04/2026

img
Lý thuyết Kiểm thử phần mềm: Các thuật ngữ quan trọng

20.945 lượt xem 11/04/2026

img
Lý thuyết kiểm thử phần mềm: KT Phân tích Giá trị Biên BVA

21.038 lượt xem 11/04/2026

img
Lý thuyết kiểm thử phần mềm: PP phân vùng tương đương

21.069 lượt xem 11/04/2026

img
Lý thuyết Kiểm thử Phần mềm: Bảng quyết định Decision Table

21.093 lượt xem 11/04/2026

img
Lý thuyết Kiểm thử: KT theo ca sử dụng (Use Case Testing)

21.122 lượt xem 11/04/2026