Data-driven testing cho người mới: chạy 1 kịch bản với nhiều bộ dữ liệu (có code chạy được)

1. Tóm tắt nhanh & màn hình bạn sẽ test

Chào bạn mới! Khi vừa học automation, phản xạ tự nhiên là viết 1 test cho 1 trường hợp: mở trang, nhập mã 'SUMMER10', bấm áp dụng, kiểm tra thông báo thành công. Nhưng thực tế 1 ô nhập mã giảm giá cần kiểm tra rất nhiều trường hợp: mã hợp lệ, mã hết hạn, mã không tồn tại, mã để trống, mã quá ngắn/quá dài... Nếu viết riêng từng test cho mỗi trường hợp, bạn sẽ có hàng chục file gần giống hệt nhau, chỉ khác đúng 2 dòng: giá trị nhập và kết quả mong đợi. Data-driven testing giải quyết vấn đề này: viết đúng 1 kịch bản, rồi 'nạp' nhiều bộ dữ liệu vào chạy lặp lại. Chúng ta sẽ học qua ô mã giảm giá thật của ShopEasy, có hình minh hoạ và code Playwright chạy được.

2. Vấn đề: khi bạn có 20 test gần giống hệt nhau

Hãy hình dung bạn được giao kiểm tra ô mã giảm giá của ShopEasy. Bạn viết test đầu tiên: nhập 'SUMMER10', kiểm tra thông báo 'Áp dụng thành công'. Rồi bạn copy file đó, đổi giá trị thành 'ABCXYZ', đổi kỳ vọng thành 'Mã không hợp lệ'. Rồi lại copy tiếp cho mã hết hạn, mã để trống, mã quá dài... Chỉ sau vài giờ, bạn có 8, 10, rồi 20 file test — mỗi file giống hệt nhau 95%, chỉ khác đúng giá trị nhập và câu kiểm tra kết quả.

Vấn đề thật sự xuất hiện khi bạn cần thay đổi logic kiểm tra — ví dụ sếp yêu cầu thêm bước kiểm tra số tiền cuối cùng sau khi áp dụng mã, không chỉ thông báo. Với 20 file gần giống nhau, bạn phải mở từng file, sửa từng chỗ, rất dễ bỏ sót 1-2 file. Đây chính là lúc bạn nhận ra: cái mình cần không phải 20 kịch bản khác nhau, mà là 1 kịch bản và 20 bộ dữ liệu.

3. Data-driven testing là gì & nguyên tắc cốt lõi

Nguyên tắc cốt lõi của data-driven testing là 'tách dữ liệu khỏi logic': logic kiểm tra (mở trang, nhập liệu, bấm nút, so sánh kết quả) được viết đúng 1 lần, còn dữ liệu (mã nào, mong đợi kết quả gì) được gom vào một bảng riêng — thường là mảng object trong JavaScript, hoặc file JSON/CSV. Một vòng lặp (phổ biến nhất là for...of) sẽ đọc từng dòng dữ liệu và sinh ra 1 ca test tương ứng, chạy đúng cùng 1 logic nhưng với giá trị khác nhau.

Nói cách khác: bảng dữ liệu 'biết' phải test cái gì và mong đợi kết quả ra sao, còn kịch bản test chỉ 'biết' cách thực hiện và cách so sánh. Khi cần thêm 1 trường hợp mới, bạn chỉ thêm 1 dòng dữ liệu — không đụng tới logic. Khi cần sửa cách kiểm tra (ví dụ thêm kiểm tra số tiền), bạn chỉ sửa đúng 1 chỗ trong thân vòng lặp — mọi bộ dữ liệu tự động dùng logic mới. Đây là lý do data-driven testing giúp bộ test bền vững và dễ mở rộng hơn hẳn khi số lượng trường hợp cần kiểm tra tăng lên.

4. Chọn bộ dữ liệu: hợp lệ, không hợp lệ và biên

Data-driven testing chỉ mạnh khi bộ dữ liệu được chọn tốt. Với ô mã giảm giá ShopEasy, ta chia dữ liệu thành 3 nhóm: dữ liệu HỢP LỆ (mã đúng, còn hạn — kỳ vọng áp dụng thành công), dữ liệu KHÔNG HỢP LỆ (mã sai, mã hết hạn, mã không tồn tại — kỳ vọng thông báo lỗi tương ứng), và dữ liệu BIÊN (độ dài tối thiểu/tối đa, ô để trống, khoảng trắng thừa — nơi lỗi hay ẩn náu nhất). Nếu bạn chưa quen kỹ thuật chọn giá trị biên, có thể xem thêm bài phân vùng tương đương và giá trị biên trong phần liên kết cuối bài.

Chú ý bảng dữ liệu ở chương 2: dòng 'khong-phan-biet-hoa/thuong' và 'co-khoang-trang' không phải trường hợp 'hiển nhiên' — chúng kiểm tra những giả định ngầm (hệ thống có tự động chuẩn hoá chữ hoa/thường và khoảng trắng hay không). Đây chính là giá trị của data-driven testing: một khi đã có sẵn cơ chế chạy nhiều bộ dữ liệu, việc bổ sung thêm các trường hợp 'ngầm định' như vậy chỉ tốn thêm 1 dòng, gần như miễn phí.