Migration chạy xong chưa có nghĩa dữ liệu đã an toàn

Một thay đổi thêm trường tên hiển thị chạy thành công trên cơ sở dữ liệu trống. Khi áp dụng vào bản sao dữ liệu cũ, nhiều khách hàng lại có tên trống vì bước chuyển dữ liệu chỉ xử lý tài khoản mới. Thông báo migration thành công không sai: cấu trúc đã được đổi. Điều chưa được chứng minh là dữ liệu còn phục vụ đúng công việc.

Đây là tình huống giả định, nhưng nó cho thấy vì sao kiểm thử cơ sở dữ liệu cần hơn một lần chạy lệnh. Cần biết trạng thái nào phải được giữ, trạng thái nào được phép đổi và ứng dụng ở từng phiên bản sẽ đọc chúng ra sao.

Viết điều không được mất bằng ngôn ngữ nghiệp vụ

Với thay đổi tên hiển thị, kỳ vọng có thể là mọi tài khoản cũ vẫn nhận diện được trong danh sách, không làm đổi quan hệ với đơn hàng và không ghi đè tên người dùng đã tự chọn. Mỗi kỳ vọng cần được nối với cách đối chiếu dữ liệu.

So số dòng trước và sau chỉ bảo vệ một phần. Số lượng có thể giữ nguyên trong khi giá trị bị gán nhầm sang người khác. Chọn thêm các quan hệ, điều kiện không trùng và những trường hợp đặc biệt như tên có dấu, tên dài hoặc dữ liệu cũ chưa đầy đủ.

Đừng dùng dữ liệu thật có thể nhận diện khách hàng chỉ vì nó tiện. Dữ liệu giả hoặc bản sao đã xử lý cần giữ được những đặc tính gây lỗi mà phép thử đang quan tâm.

Cơ sở dữ liệu trống và dữ liệu đang sống là hai bài khác nhau

Khởi tạo mới kiểm tra một đường đi sạch. Nâng cấp từ phiên bản trước kiểm tra lịch sử. Hai bài đều cần nếu sản phẩm có cả khách hàng mới và hệ thống đang vận hành.

Chuẩn bị một tập dữ liệu cũ có chủ đích: bản ghi bình thường, giá trị thiếu được hệ thống cũ cho phép, quan hệ nhiều con và trường hợp ở đúng giới hạn độ dài. Ghi rõ chúng đại diện rủi ro nào. Không cần một lượng dữ liệu khổng lồ để phát hiện lỗi chuyển giá trị, nhưng lượng nhỏ cũng chưa đại diện thời gian khóa hoặc tốc độ nâng cấp.

Nếu dự định chạy lại migration sau thất bại, hãy kiểm tra điều xảy ra khi một phần công việc đã hoàn thành. Đường chạy lại phải được thiết kế, không được suy ra từ lần đầu may mắn thành công.

Ràng buộc cần được thử từ cả hai phía

Đọc khai báo khóa hoặc điều kiện bắt buộc là một bước. Bước tiếp theo là thử tạo dữ liệu vi phạm trên môi trường kiểm thử và xác nhận việc từ chối không để lại trạng thái dở dang.

Ví dụ, một quan hệ đơn hàng phải gắn với tài khoản tồn tại. Sau khi thao tác thất bại, cần xem đơn và các chi tiết liên quan còn được ghi một phần hay không. Kiểm tra chỉ ở giao diện có thể bỏ qua đường ghi khác đi thẳng vào dịch vụ hoặc tác vụ nền.

Không áp cùng một kỳ vọng giao dịch cho mọi hệ quản trị và mọi loại thay đổi cấu trúc. Cách bảo đảm tính nguyên vẹn phải được đối chiếu với hệ thống đang dùng, rồi thể hiện thành phép thử cụ thể.

Quay lui cấu trúc không hồi sinh dữ liệu đã bỏ

Một migration hạ phiên bản có thể tạo lại cột vừa xóa mà không phục hồi nội dung cũ. Vì vậy, chạy được bước “down” chưa đủ để nói có thể khôi phục.

Trước khi thử chuyển phiên bản, xác định chính xác đường phục hồi dự kiến: quay lui mã ứng dụng, sửa tiến tới hay khôi phục từ bản sao. Kiểm tra đường được chọn trên dữ liệu kiểm soát và ghi lại điểm nào cần can thiệp. Không biến một thao tác phá dữ liệu thành bài thử trên môi trường vận hành chưa được cho phép.

Đọc phần chậm cùng với phần đúng

Sau thay đổi, truy vấn có thể trả cùng dữ liệu nhưng làm nhiều việc hơn. Đối chiếu kế hoạch truy vấn, kích thước tập dữ liệu và điều kiện lọc giúp tìm nguyên nhân. Một thời gian chạy đơn lẻ trên dữ liệu nhỏ không đủ kết luận chỉ mục đã hữu ích hoặc hệ thống sẽ chịu tải tốt.

Báo cáo nên giữ phiên bản schema, migration, dữ liệu đại diện, phép đối chiếu trước sau và phần chưa kiểm tra. Với SQL do AI gợi ý, cần đọc lại phạm vi cập nhật và điều kiện lọc trước khi chạy. Bằng chứng tốt nhất là trạng thái dữ liệu đã được kiểm tra, chứ không phải một tệp script trông có vẻ đầy đủ.

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.