Tạo dữ liệu kiểm thử hoàn tiền: quan hệ đúng quan trọng hơn số lượng

Một nghìn đơn đẹp chưa chắc tạo được một bài thử tốt

Giả sử đội đang kiểm tra chức năng hoàn tiền. Công cụ tạo nhiều khách hàng, sản phẩm và đơn hàng trông rất thật, nhưng tất cả đơn đều chưa thanh toán. Bộ dữ liệu lớn ấy không giúp thử được tình huống hoàn tiền thành công. Dữ liệu kiểm thử cần được thiết kế từ câu hỏi nghiệp vụ, thay vì bắt đầu bằng số bản ghi muốn tạo.

Vẽ quan hệ tối thiểu giữa khách, đơn, lần thanh toán và khoản hoàn. Xác nhận trạng thái nào được hoàn, tổng đã hoàn được phép tới đâu và cách xử lý yêu cầu lặp. Nếu quy tắc chưa rõ, đánh dấu phần cần quyết định trước khi tạo dữ liệu. Một bộ sinh tự động không thể tự xác định chính sách tài chính của sản phẩm.

Tạo một bộ nhỏ đủ giải thích kết quả

Bắt đầu bằng vài đơn có mục đích rõ: đã thanh toán chưa hoàn, đã hoàn một phần, đã hoàn toàn bộ và chưa thanh toán. Mỗi đơn nên có nhãn tình huống trong dữ liệu thử để dễ tìm. Người kiểm thử cần biết vì sao bản ghi tồn tại và kết quả mong đợi là gì; tên khách giả giống thật không cung cấp căn cứ ấy.

Chọn giá trị ở ranh giới của quy tắc. Nếu cho hoàn tối đa phần tiền còn lại, thử nhỏ hơn, bằng và lớn hơn phần đó với đơn vị nhỏ nhất hệ thống sử dụng. Ghi cách biểu diễn và làm tròn đã thống nhất. Đừng chỉ lấy số thập phân ngẫu nhiên rồi mong chúng tự chạm các trường hợp dễ sai trong phép tính.

Giữ các quan hệ nhất quán: khoản hoàn phải trỏ đến đúng thanh toán, thanh toán thuộc đúng đơn và tổng phải phản ánh trạng thái dự kiến. Đồng thời tạo riêng một nhóm dữ liệu sai có chủ đích để thử cơ chế từ chối. Trộn dữ liệu vô tình hỏng với nhóm hợp lệ khiến người kiểm thử không biết lỗi thuộc sản phẩm hay khâu chuẩn bị.

Làm cho dữ liệu có thể tạo lại và dùng độc lập

Lưu định nghĩa bộ dữ liệu, phiên bản và tham số dùng để sinh. Nếu công cụ hỗ trợ giá trị khởi tạo cố định, giữ nó cùng điều kiện chạy; nhưng vẫn cần kiểm tra đầu ra thực tế. Thời gian hiện tại hoặc dữ liệu tham chiếu thay đổi có thể làm kết quả khác. Một tệp đầu vào được lưu giúp điều tra cụ thể hơn lời mô tả “tạo ngẫu nhiên”.

Mỗi lần chạy song song nên có không gian dữ liệu riêng để tránh hai bài thử cùng hoàn một đơn. Gắn dấu nhận diện cho dữ liệu thử và thiết kế cách dọn theo dấu đó. Xác nhận dọn dữ liệu không xóa bản ghi của lần chạy khác. Khả năng tạo lại và thu hồi bộ dữ liệu là một phần của tính tin cậy, không chỉ là việc hậu cần.

Kiểm tra định dạng xuất theo cách dữ liệu sẽ được nạp. Giá trị đúng trong bộ nhớ có thể bị biến đổi khi qua CSV, JSON hoặc cơ sở dữ liệu. Với tên tiếng Việt, ngày và số tiền, đối chiếu sau khi nạp thay vì chỉ mở tệp nguồn. Nếu dùng nhiều ngôn ngữ, thêm trường hợp ký tự dài hoặc cách viết khác có liên quan đến người dùng thật.

Dữ liệu tổng hợp vẫn cần được rà soát

Ưu tiên dữ liệu tổng hợp cho bài thử nếu nó đáp ứng mục tiêu. Việc thay tên trong dữ liệu sao chép không tự bảo đảm các chi tiết còn lại đã hết khả năng nhận diện. Khi dùng quy trình che dữ liệu được cho phép, cần xác nhận cả mức bảo vệ và việc giữ quan hệ cần thiết. Không đưa thông tin thật vào AI chỉ để tạo ví dụ thuận tiện.

Trước khi giao bộ dữ liệu, chạy các kiểm tra về khóa, quan hệ, tổng tiền và số lượng từng tình huống. Kèm hướng dẫn nạp, dọn và giới hạn sử dụng. AI có thể gợi ý tổ hợp và tên giả, nhưng quy tắc cùng đầu ra phải được người kiểm thử xác nhận. Giá trị của bộ dữ liệu nằm ở khả năng trả lời câu hỏi và tái hiện lỗi.

Về nguồn tham khảo

Chủ đề tham khảo từ bộ AI Tester Skills. Bài viết và tình huống minh họa được biên soạn lại cho người đọc.