Dữ liệu kiểm thử thực tế mà không dùng dữ liệu cá nhân thật

Một lập trình viên cần vài nghìn khách hàng để thử một báo cáo mới. Nguồn nhanh nhất là cơ sở dữ liệu thật, và đó chính là vấn đề: tên, e-mail và lịch sử mua hàng thật nằm rải rác trên laptop, trong log CI và trong ảnh chụp màn hình đính kèm ticket. Dữ liệu sinh ngẫu nhiên tránh được tất cả những điều đó, nhưng chỉ khi nó đủ thực tế để thực sự thử thách mã nguồn. Bài này cho thấy cách dựng một bộ dữ liệu như vậy, với ví dụ thật từ công cụ tạo dữ liệu ngẫu nhiên, cùng những cái bẫy khiến dữ liệu giả kém hữu ích hơn mức nên có.

Vì sao không "ẩn danh hoá" dữ liệu thật cho xong

Xoá cột tên không làm bộ dữ liệu thành ẩn danh. Tổ hợp các trường bình thường vẫn nhận diện được con người: nghiên cứu nổi tiếng năm 2000 của Latanya Sweeney ước tính khoảng 87% dân số Mỹ có thể được nhận diện duy nhất chỉ bằng mã bưu chính, giới tính và ngày sinh. Một bảng đơn hàng "đã ẩn danh" còn mã bưu chính, ngày sinh và giờ giao hàng thường có thể được đối chiếu ngược ra từng người bởi bất kỳ ai có trong tay một bộ dữ liệu thứ hai.

Dữ liệu cá nhân chép sang hệ thống kiểm thử thường vẫn chịu các nghĩa vụ pháp lý như bản gốc, trong khi được bảo vệ kém hơn nhiều. Dữ liệu chưa từng thuộc về người thật nào thì không có những vấn đề đó.

Một ví dụ cụ thể

Đây là lược đồ bảy cột: số thứ tự, họ tên, e-mail, gói dịch vụ lấy từ danh sách có trọng số (free|70, pro|25, team|5), số dư từ 0 tới 500 với hai chữ số thập phân và 20% ô để trống, ngày đăng ký trong năm 2025, và một địa chỉ IPv4 nội bộ. Với hạt giống (seed) demo-2026, năm dòng đầu dạng CSV là:

id,name,email,plan,balance,signup,ip
1,Nadia Pham,[email protected],free,165.05,2025-08-27,10.112.167.30
2,Leila Ivanov,[email protected],free,67.37,2025-03-29,192.168.228.38
3,Åsa Petrov,[email protected],free,12.61,2025-05-05,172.30.59.194
4,Chen Ivanov,[email protected],free,473.97,2025-12-24,192.168.207.39
5,Quang Wang,[email protected],free,285.30,2025-11-24,172.28.28.54

Có vài điều được làm có chủ ý:

• Tên miền e-mail là `example.com`, `example.net` và `example.org`. Đây là các tên miền được RFC 2606 dành riêng cho tài liệu và không bao giờ là hộp thư thật, nên một bài kiểm thử lỡ gửi mail cũng không tới tay ai.
• Địa chỉ IP lấy từ các dải nội bộ của RFC 1918 (10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16) khi bạn yêu cầu, nên không thể trỏ tới một máy chủ thật trên Internet.
• Họ và tên được ghép ngẫu nhiên từ danh sách ngắn các tên phổ biến ở nhiều nước. Trùng với người thật là ngẫu nhiên, không phải rò rỉ.
• Cùng hạt giống cho cùng dữ liệu. Tạo lại với demo-2026 cho ra tệp giống hệt, nhờ vậy bài kiểm thử thất bại có thể tái hiện: hãy ghi hạt giống vào báo cáo lỗi.

Cần nói thật một hạn chế: mỗi cột được tạo độc lập, nên e-mail của Nadia Pham là jose.gonzalez84. Nếu mã của bạn kiểm tra e-mail có khớp với tên hay không, hãy tự tạo e-mail từ tên trong mã fixture của mình.

Phân bố có hợp lý không?

Trọng số là tỉ lệ tương đối, không phải số lượng chính xác. Với 10.000 dòng, cột gói dịch vụ ra 7.043 free, 2.488 pro và 469 team, so với kỳ vọng 7.000, 2.500 và 500. Cột số dư có 2.002 ô trống, so với 2.000 kỳ vọng cho mức 20%. Đó là dao động lấy mẫu bình thường, và nó có ích: một báo cáo chỉ chạy đúng khi một nhóm chiếm chính xác 5% số dòng là một báo cáo mong manh.

Tỉ lệ thực tế cũng quan trọng khi kiểm thử hiệu năng. Một kế hoạch truy vấn chạy tốt với 50 khách "team" có thể thay đổi hoàn toàn khi chỉ mục gặp 7.000 khách "free".

Những trường hợp tìm ra lỗi

Dữ liệu "đẹp" ít khi tìm ra lỗi. Hãy chắc chắn bộ dữ liệu của bạn có cả:

1. Giá trị rỗng. 20% số dư để trống trở thành null trong JSON, NULL trong SQL và một ô trống trong CSV, đúng chỗ mà mã giả định luôn có số sẽ hỏng.
2. Tên ngoài bảng ASCII. Åsa, Hương và Nguyễn kiểm tra collation của cơ sở dữ liệu, bảng mã khi xuất CSV và phông chữ trong PDF. Cột e-mail của công cụ chuyển chúng về ASCII (José thành jose, như ở dòng 1) vì phần trước @ của địa chỉ thường như vậy; cột tên của bạn thì không nên.
3. Dấu nháy và gạch chéo ngược. Họ như O'Brien phải chèn được vào SQL. Kết quả SQL của công cụ nhân đôi dấu nháy ('O''Brien'), với MySQL thì nhân đôi cả dấu gạch chéo ngược ('C:\\temp'), và viết N'Nguyễn' cho SQL Server để chữ Unicode được lưu đúng.
4. Giá trị biên. Ngày đầu và ngày cuối của khoảng, số dư bằng 0, giá trị lớn nhất. Hãy đặt khoảng giá trị bao gồm chúng.
5. Khối lượng. Mười dòng che giấu lỗi phân trang và truy vấn chậm. Hãy tạo hàng nghìn dòng.

Bẫy về ngôn ngữ và vùng miền

• Dấu thập phân. Công cụ viết 165.05 với dấu chấm, đúng như CSV và JSON yêu cầu. Bảng tính đặt theo vùng Việt Nam hay Đức có thể đọc nó thành văn bản, thậm chí thành ngày tháng. Hãy nhập tệp với đúng thiết lập vùng thay vì sửa dữ liệu; bài chuyển CSV sang JSON mà không làm hỏng dữ liệu nói về các bẫy này.
• Ngày tháng. 2025-03-29 theo ISO 8601 và không thể hiểu nhầm. Nếu giao diện hiển thị 29/03/2025, hãy kiểm thử riêng phép chuyển đổi đó, kể cả các ngày lớn hơn 12, nơi việc tráo ngày với tháng lộ ra.
• Thứ tự họ tên. Trong tiếng Việt họ đứng trước: với "Nguyễn Văn An", họ là Nguyễn và tên là An. Một trường tên first_name mang nghĩa khác nhau ở mỗi nước, và đó là vấn đề thiết kế mà không công cụ tạo dữ liệu nào giải quyết hộ bạn.

Những lỗi thường gặp

1. Chép "chỉ một bảng thôi" từ dữ liệu thật sang cơ sở dữ liệu kiểm thử.
2. Dùng tên miền trông như thật, như gmail.com, cho e-mail giả. Hãy dùng các tên miền example đã được dành riêng.
3. Số điện thoại giả hoá ra là số thật. Nhiều nước dành riêng dải số cho phim ảnh và kiểm thử; hãy dùng dải đó, hoặc bỏ cột điện thoại.
4. Dữ liệu ngẫu nhiên không có hạt giống, nên lỗi không tái hiện được.
5. Chỉ có dữ liệu "đẹp": không rỗng, không dấu, không dấu nháy.

Hãy dựng lược đồ trong công cụ tạo dữ liệu ngẫu nhiên, xuất CSV, JSON hoặc SQL, và dùng công cụ chuyển CSV và JSON nếu cần đổi dạng kết quả. Mọi thứ được tạo ngay trong trình duyệt của bạn.