1. Tóm tắt nhanh & bức tranh hệ thống bạn sẽ kiểm thử
Chào bạn! Khi một hệ thống nội bộ nâng cấp, mọi thứ đơn giản: bạn kiểm soát cả server lẫn client, deploy đồng thời là xong. Nhưng với một nền tảng SaaS mở API công khai cho đối tác bên ngoài — như PayHub cho các điểm bán POS, ví điện tử, sàn thương mại điện tử — bạn KHÔNG kiểm soát được code phía đối tác. Họ có thể chưa cập nhật app trong nhiều tháng, thậm chí nhiều năm. Kiểm thử tương thích ngược và versioning là kỹ năng nâng cao giúp bạn — với vai trò tester — đảm bảo mỗi lần server nâng cấp, hàng nghìn tích hợp đang chạy ngoài kia không bị 'sập' theo.
2. Vì sao tương thích ngược là sống còn với SaaS có API công khai
Với một website nội bộ, một lỗi giao diện có thể được sửa và deploy lại trong vài phút. Nhưng với một API công khai, 'client' của bạn là code đã được BIÊN DỊCH VÀ TRIỂN KHAI bên trong hệ thống của hàng nghìn đối tác khác nhau — bạn không thể 'sửa và deploy lại' hộ họ. Một breaking change không báo trước có thể khiến hàng trăm điểm bán ngừng nhận thanh toán cùng lúc, như sự cố PH-7742 trong bài này khiến ~640 điểm bán của đối tác VinaPOS ngừng hoạt động 47 phút.
Ngoài thiệt hại tức thời, sự cố tương thích ngược còn phá hủy NIỀM TIN của đối tác — thứ khó xây dựng lại hơn nhiều so với một dòng code. Một đối tác từng bị 'gãy' tích hợp không báo trước sẽ luôn dè chừng, yêu cầu kiểm thử thủ công kỹ hơn ở mọi lần nâng cấp sau, làm chậm cả tốc độ phát triển sản phẩm của chính PayHub. Vì vậy, đầu tư vào kiểm thử tương thích ngược không chỉ là phòng lỗi kỹ thuật — đó là bảo vệ mối quan hệ kinh doanh.
Đây cũng là lý do vì sao kiểm thử tương thích ngược thuộc nhóm kỹ năng nâng cao: nó đòi hỏi tư duy vượt ra ngoài 'hệ thống của tôi có chạy đúng không' để trả lời 'MỌI PHIÊN BẢN đang tồn tại ngoài kia có còn chạy đúng không' — một phạm vi kiểm thử rộng hơn hẳn kiểm thử chức năng thông thường.
3. Breaking change vs Non-breaking change — phân loại rõ ràng
Trước khi viết được ca kiểm thử tốt, bạn cần phân loại chính xác một thay đổi API là BREAKING (phá vỡ client cũ) hay NON-BREAKING (an toàn). Quy tắc cốt lõi: thêm mới một cách CỘNG THÊM (additive) thường an toàn; đổi hoặc xóa cái ĐANG TỒN TẠI mà client cũ phụ thuộc vào luôn tiềm ẩn rủi ro phá vỡ.
Nhìn bảng trên, bạn thấy các thay đổi rủi ro cao đều rơi vào 4 nhóm: đổi TÊN field, XÓA field, đổi KIỂU dữ liệu, và đổi MÃ LỖI/hành vi mà client cũ đang dựa vào để rẽ nhánh xử lý. Ngược lại, thêm field mới tùy chọn hoặc thêm endpoint hoàn toàn mới hầu như luôn an toàn — vì các bộ parse JSON tiêu chuẩn (và client được viết đúng chuẩn) sẽ bỏ qua field lạ mà không lỗi.
4. Chuẩn bị: chiến lược versioning cho API công khai
Trước khi kiểm thử, bạn cần hiểu PayHub đang dùng chiến lược versioning nào, vì mỗi chiến lược sinh ra một bộ ca kiểm thử khác nhau.
▶ Bước 1: Versioning theo URL path ('/v1/payments', '/v2/payments'): rõ ràng, dễ log, dễ giới hạn traffic riêng từng phiên bản — PayHub dùng chiến lược này cho phiên bản chính.
▶ Bước 2: Versioning theo header ('Api-Version: 2026-07-01'): dùng cho các thay đổi nhỏ, thử nghiệm dần mà không cần đổi URL — kết hợp với feature flag.
💬 Bình luận (0)
Chưa có bình luận nào. Hãy là người đầu tiên!