Dữ liệu dùng trong kiểm thử phải đủ giống thật để bắt được lỗi thật, nhưng không được là dữ liệu thật của khách. Hai yêu cầu đó kéo nhau theo hai hướng, và nhiều nhóm chọn đường tắt: sao một phần cơ sở dữ liệu sản phẩm về máy, hoặc dán vài dòng dữ liệu khách vào chatbot nhờ "làm giả giống thế này". Cả hai đều đưa thông tin cá nhân ra khỏi nơi nó được phép ở.
Trợ lý AI giúp được rất nhiều ở việc này mà không cần nhìn thấy dữ liệu thật: soạn bộ dữ liệu mẫu tiếng Việt theo mô tả, viết hàm sinh dữ liệu có thể tái lập, viết kịch bản che dữ liệu để bạn chạy ngay trên máy mình. Bài này trình bày cả ba, kèm ví dụ giả định bằng Python.
Vì sao không dùng bản sao dữ liệu thật
Lý do đầu tiên là pháp lý và đạo đức. Thông tin khách hàng được thu thập cho mục đích phục vụ khách, không phải để lập trình viên thử tính năng. Quy định về bảo vệ dữ liệu cá nhân ở Việt Nam ngày càng chặt; chi tiết nghĩa vụ của doanh nghiệp bạn nên hỏi bộ phận pháp chế hoặc luật sư, nhưng nguyên tắc chung là dữ liệu càng ít người, ít máy chạm vào thì càng an toàn.
Lý do thứ hai rất thực tế: dữ liệu trong môi trường kiểm thử thường được bảo vệ lỏng hơn. Máy của lập trình viên, máy chủ thử nghiệm, kho mã, nhật ký của hệ thống tích hợp liên tục, ảnh chụp màn hình gửi trong nhóm chat, và cả lịch sử trò chuyện với chatbot. Mỗi nơi là một chỗ có thể rò.
Lý do thứ ba ít người nghĩ tới: dữ liệu thật không phải dữ liệu kiểm thử tốt. Nó lộn xộn theo kiểu ngẫu nhiên, thiếu đúng những ca bạn cần kiểm, và thay đổi mỗi lần sao về nên kiểm thử chạy hôm nay xanh mai đỏ. Dữ liệu giả được thiết kế có chủ đích thì lặp lại được, có đủ ca mép, và ai đọc cũng hiểu vì sao nó ở đó.
Ba loại dữ liệu giả và khi nào dùng
Không có một loại dữ liệu giả dùng cho mọi việc. Bảng dưới so ba cách phổ biến:
| Loại | Hợp với | AI giúp được gì | Điểm yếu |
|---|---|---|---|
| Dữ liệu viết tay cố định (fixture) | Kiểm thử đơn vị, ca mép cụ thể, ví dụ minh hoạ quy tắc | Soạn nhanh vài chục bản ghi theo mô tả, đặt tên gợi nghĩa | Khó mở rộng khi cần nhiều bản ghi |
| Dữ liệu sinh bằng thư viện, có seed cố định | Kiểm thử tích hợp, giao diện danh sách, cần số lượng vừa | Viết hàm sinh, chọn thư viện và cấu hình ngôn ngữ | Giá trị ngẫu nhiên có thể thiếu ca mép nếu không thêm tay |
| Dữ liệu lấy mẫu từ hệ thống thật rồi che | Tái hiện lỗi chỉ xảy ra với dữ liệu thật, kiểm thử chuyển đổi dữ liệu | Viết kịch bản che để bạn chạy tại máy, không cần thấy dữ liệu | Rủi ro rò nếu quy trình che có kẽ hở, cần người duyệt |
Phần lớn dự án dùng hai loại đầu. Loại thứ ba chỉ dùng khi thật cần, có người chịu trách nhiệm, và dữ liệu sau khi che vẫn được đối xử như dữ liệu nhạy cảm.
Nhờ AI soạn bộ dữ liệu mẫu tiếng Việt
Đây là việc AI làm nhanh nhất mà rủi ro thấp nhất, vì bạn chỉ đưa mô tả cấu trúc chứ không đưa dữ liệu. Câu lệnh mẫu:
"Soạn 20 bản ghi khách hàng giả ở dạng JSON cho kiểm thử, cột: ho_ten, email, tinh_thanh, ngay_sinh, so_du (số nguyên, đơn vị đồng). Họ tên đa dạng vùng miền, có người tên một chữ, có tên rất dài, có tên viết hoa lộn xộn. Tỉnh thành dùng tên trong danh sách 34 tỉnh, thành phố hiện hành. Email dùng tên miền dành riêng cho thử nghiệm, không dùng tên miền thật. Có ít nhất hai bản ghi số dư bằng 0, một bản ghi ngày sinh 29 tháng 2. Không dùng tên người nổi tiếng."
Mấy điều kiện ở cuối câu lệnh là chỗ biến một danh sách nhàm thành dữ liệu kiểm thử có ích: chúng cài sẵn ca mép vào bộ mẫu. Khi nhận kết quả, bạn soát lại tên tỉnh thành có đúng danh sách hiện hành không, vì AI có thể trộn tên đơn vị trước và sau khi sắp xếp lại năm 2025. Bạn cũng xem email có thật sự dùng tên miền thử nghiệm không và ngày 29 tháng 2 có rơi vào năm nhuận không.
Với cột số điện thoại, cách an toàn là không cần cột đó trong kiểm thử nếu tính năng không xử lý nó; nếu cần, quy định một mẫu dễ nhận ra là giả và đảm bảo môi trường kiểm thử không bao giờ thật sự gửi tin nhắn đi.
Hàm sinh dữ liệu có thể tái lập
Khi cần hàng trăm bản ghi, viết hàm sinh tốt hơn soạn tệp tĩnh. Thư viện Faker của Python có cấu hình ngôn ngữ tiếng Việt; bạn có thể nhờ AI viết hàm sinh theo mẫu nhà máy (factory), mỗi lần gọi trả về một bản ghi hợp lệ, cho phép ghi đè từng trường. Ví dụ giả định:
from faker import Faker
fake = Faker("vi_VN")
Faker.seed(2026)
def tao_khach(**ghi_de):
khach = {
"ho_ten": fake.name(),
"email": fake.unique.email(),
"ngay_sinh": fake.date_of_birth(minimum_age=18, maximum_age=80),
"so_du": 0,
}
khach.update(ghi_de)
return khach
Hai chi tiết quan trọng. Dòng đặt seed cố định khiến mỗi lần chạy sinh ra cùng một bộ dữ liệu, nên khi kiểm thử đỏ, bạn tái hiện được. Tham số ghi đè cho phép mỗi kiểm thử chỉ khai báo trường nó quan tâm, ví dụ tao_khach(so_du=-1) cho ca số dư âm, phần còn lại để hàm lo. Kiểm thử đọc lên ngắn và rõ ý.
Dữ liệu địa chỉ do thư viện sinh có thể theo đơn vị hành chính cũ hoặc định dạng không giống thực tế; nếu tính năng xử lý địa chỉ, tự soạn danh sách tỉnh thành hiện hành và chọn ngẫu nhiên từ đó thay vì tin bộ sinh sẵn.
Khi buộc phải lấy mẫu từ dữ liệu thật: che tại máy
Có lỗi chỉ tái hiện được với một bản ghi thật cụ thể. Khi đó, nguyên tắc là AI viết công cụ che, còn dữ liệu chỉ chạy qua công cụ đó trên máy được phép, không bao giờ dán vào chatbot:
- Mô tả cho AI cấu trúc bảng, tên cột và kiểu dữ liệu, không kèm dòng dữ liệu nào. Yêu cầu viết kịch bản che: thay họ tên, email, điện thoại, địa chỉ, số giấy tờ bằng giá trị giả; giữ nguyên định dạng và độ dài gần đúng.
- Yêu cầu giữ nhất quán: cùng một email thật luôn được thay bằng cùng một email giả, để quan hệ giữa các bảng không vỡ.
- Đọc kịch bản AI viết, đặc biệt danh sách cột được che. Cột ghi chú tự do thường chứa thông tin cá nhân mà không ai để ý; mặc định xoá trắng.
- Chạy kịch bản trên máy hoặc máy chủ được phép truy cập dữ liệu thật, xuất ra bản đã che.
- Người thứ hai soát ngẫu nhiên vài chục dòng của bản đã che trước khi đưa sang môi trường kiểm thử.
- Xoá bản trung gian chưa che, ghi lại ai đã lấy mẫu, lúc nào, cho mục đích gì.
Đừng bao giờ dán dữ liệu thật vào chatbot với lý do nhờ nó che hộ. Lúc bạn dán là lúc dữ liệu đã rời khỏi hệ thống, việc che sau đó không còn ý nghĩa bảo vệ.
Dữ liệu giả cho quan hệ và khối lượng lớn
Kiểm thử tích hợp và kiểm thử hiệu năng cần thứ dữ liệu khác hẳn kiểm thử đơn vị. Vài điều cần dặn AI khi nhờ viết hàm sinh cho loại này:
- Giữ đúng quan hệ. Đơn hàng phải trỏ tới khách có thật trong bộ dữ liệu, chi tiết đơn phải trỏ tới sản phẩm có thật. Hàm sinh nên tạo theo thứ tự cha trước con sau.
- Phân bố gần thực tế. Đa số khách có ít đơn, một số ít khách có rất nhiều đơn. Dữ liệu chia đều quá sẽ che mất lỗi hiệu năng chỉ xuất hiện với khách nhiều đơn.
- Khối lượng theo bậc. Sinh được 100, 10.000 và 1.000.000 bản ghi bằng cùng một hàm để thấy truy vấn nào chậm dần theo số lượng.
- Chèn theo lô. Dặn AI dùng lệnh chèn nhiều dòng một lần hoặc công cụ nạp hàng loạt của cơ sở dữ liệu, không chèn từng dòng.
- Dọn sạch sau khi chạy. Mỗi kiểm thử tích hợp tự tạo và tự xoá dữ liệu của mình, hoặc chạy trong giao dịch rồi huỷ, để kiểm thử sau không phụ thuộc kiểm thử trước.
Câu lệnh gợi ý: "Viết hàm sinh dữ liệu cho ba bảng khách hàng, sản phẩm, đơn hàng theo cấu trúc dưới đây, tham số số lượng khách. 80% khách có từ 0 đến 3 đơn, 20% còn lại có từ 10 đến 200 đơn. Chèn theo lô. Seed cố định. Kèm hàm dọn dữ liệu." Tỉ lệ trong câu là ví dụ giả định; bạn chỉnh theo hình dạng dữ liệu thật của hệ thống mình mà không cần đưa dữ liệu ra.
Tổ chức dữ liệu giả để người sau đọc được
Dữ liệu giả cũng là mã, và nó mục nhanh không kém. Sau vài tháng, thư mục kiểm thử có thể chứa hàng chục tệp JSON tên na ná nhau, không ai dám xoá vì không biết kiểm thử nào đang dùng. AI sinh dữ liệu càng nhanh thì đống này càng phình nhanh, nên cần vài quy ước ngay từ đầu.
Thứ nhất, đặt tên bản ghi theo vai trò trong kiểm thử chứ không theo thứ tự. Một khách tên "khách số dư âm" hay "khách chưa xác thực email" nói rõ vì sao nó tồn tại hơn "khách 17". Khi nhờ AI soạn fixture, dặn nó đặt khoá hoặc ghi chú theo vai trò như vậy. Thứ hai, mỗi kiểm thử chỉ khai báo trường nó quan tâm, phần còn lại lấy giá trị mặc định từ hàm sinh; người đọc kiểm thử thấy ngay dữ liệu nào là điểm mấu chốt.
Thứ ba, giữ một chỗ duy nhất cho hàm sinh dữ liệu dùng chung, thay vì mỗi tệp kiểm thử tự chế một bản. Khi cấu trúc bảng đổi, bạn sửa một chỗ. Cuối cùng, định kỳ nhờ AI rà thư mục dữ liệu kiểm thử: liệt kê tệp nào không còn kiểm thử nào tham chiếu tới. Danh sách đó bạn tự xác nhận bằng tìm kiếm trong kho mã rồi mới xoá, vì AI có thể bỏ sót tham chiếu nằm trong cấu hình hoặc kịch bản ngoài thư mục kiểm thử.
Câu hỏi thường gặp
Dán vài dòng dữ liệu khách đã xoá tên vào chatbot có sao không?
Vẫn có rủi ro. Xoá tên chưa đủ nếu còn địa chỉ, ngày sinh, số tiền hay ghi chú đủ để đoán ra người. Cách an toàn là chỉ đưa cấu trúc cột và mô tả, để AI tạo dữ liệu giả hoặc viết công cụ che chạy trên máy bạn.
Seed cố định có làm dữ liệu kém ngẫu nhiên không?
Dữ liệu vẫn đa dạng, chỉ là lần chạy nào cũng giống lần trước. Đó là điều bạn cần trong kiểm thử: khi có ca đỏ, chạy lại phải ra đúng ca đó. Muốn thử nhiều tổ hợp hơn thì đổi seed có chủ đích và ghi lại giá trị seed đã dùng.
Có nên đưa tệp dữ liệu giả vào kho mã không?
Tệp nhỏ viết tay cho kiểm thử đơn vị thì nên, để ai cũng chạy được. Dữ liệu lớn nên sinh bằng hàm lúc chạy thay vì lưu tệp, kho mã gọn hơn. Tuyệt đối không đưa vào kho bất cứ bản dữ liệu nào lấy từ hệ thống thật, kể cả đã che.
AI soạn tên người giả có thể trùng tên người thật không?
Có thể, vì họ tên Việt Nam trùng nhau rất nhiều. Trùng tên đơn thuần không phải vấn đề; vấn đề là ghép tên với thông tin khác đủ để chỉ ra một người. Tránh dùng tên người nổi tiếng và không ghép tên với địa chỉ, nơi làm việc cụ thể.
Dữ liệu giả có thể lọt lên hệ thống thật không?
Có, nếu kịch bản sinh dữ liệu chạy nhầm môi trường. Hãy chặn từ đầu: kịch bản kiểm tra biến môi trường và từ chối chạy khi trỏ vào cơ sở dữ liệu sản phẩm, email giả luôn dùng tên miền dành riêng cho thử nghiệm để dễ lọc.
Thư viện sinh dữ liệu tiếng Việt có đáng tin không?
Đủ dùng cho họ tên và văn bản chung, nhưng địa chỉ, số điện thoại hay đơn vị hành chính có thể không theo thực tế hiện hành. Với các trường mà tính năng thật sự xử lý, tự soạn danh sách giá trị hợp lệ và để hàm sinh chọn từ đó.