Kiểm thử SMS OTP bị trễ, trùng và sai thứ tự

Kiểm thử SMS OTP bị trễ, trùng và sai thứ tự

Kiểm thử SMS/OTP cho app của chính mình không nên dừng ở việc nhập đúng sáu chữ số. Lỗi khó bắt thường xuất hiện khi tin nhắn đến trễ, bị lặp, đến sai thứ tự hoặc không đến trong thời gian chờ. Cách đáng tin cậy là ghi thời điểm trước khi gửi mã, gắn mã với đúng phiên kiểm thử, đặt thời gian chờ hữu hạn và dọn dữ liệu sau mỗi lượt.

Bài hướng dẫn này dành cho đội phát triển và QA có quyền kiểm thử ứng dụng của mình. Bạn sẽ thấy khi nào nên dùng sandbox/mock OTP, khi nào cần hộp thư SMS thật, cùng cách kiểm tra retry/rate limit mà không gửi tin nhắn thử tới người dùng thật.

Vì sao mã OTP đến trễ hoặc bị trùng?

Tin nhắn SMS là dữ liệu bất đồng bộ. Ứng dụng có thể đã nhận phản hồi “đã xếp hàng”, nhưng nhà cung cấp, nhà mạng và thiết bị vẫn xử lý ở các thời điểm khác nhau. Vì vậy, trạng thái gửi thành công chưa chứng minh mã đã nằm trên điện thoại.

Một bộ kiểm thử tốt phải phân biệt bốn mốc: yêu cầu được ứng dụng tạo ra, nhà cung cấp chấp nhận, tin nhắn được ghi nhận, và người dùng xác minh thành công. Nếu chỉ kiểm tra màn hình “Đã gửi mã”, bạn bỏ qua phần dễ hỏng nhất.

Ví dụ, test bắt đầu lúc 10:00:00 và mã cũ từ 09:58 vẫn nằm trong hộp thư. Nếu truy vấn 20 tin gần nhất rồi lấy mã đầu tiên, test có thể nhập nhầm mã cũ. Ghi since = 10:00:00 trước thao tác gửi, sau đó chỉ nhận tin có thời điểm từ mốc này, sẽ loại được trường hợp đó.

Sơ đồ ghi thời điểm, gửi mã, lọc mã mới và dọn dữ liệu khi kiểm thử SMS OTP

Sandbox/mock OTP hay SMS thật?

Sandbox/mock OTP cho phần lớn bài test

Trong môi trường phát triển và CI, sandbox/mock OTP thường phù hợp hơn SMS thật. Ứng dụng gửi nội dung đến một máy chủ giả lập, máy chủ lưu lại tin nhắn, còn test đọc mã từ kho dữ liệu nội bộ. Không phát sinh cước tin nhắn, không phụ thuộc nhà mạng và kết quả lặp lại dễ hơn.

Hãy đặt mã cố định hoặc bộ sinh mã chỉ trong môi trường kiểm thử. Chẳng hạn, mã 000000 chỉ được chấp nhận khi cờ môi trường là staging và tài khoản test đã nằm trong danh sách cho phép. Production phải từ chối cơ chế này, đồng thời log không được ghi mã đầy đủ.

SMS thật cho smoke test có kiểm soát

SMS thật vẫn cần thiết để phát hiện lỗi tích hợp với nhà cung cấp, định dạng số, độ trễ và nội dung hiển thị. Chỉ dùng số thuộc quyền kiểm soát của đội QA hoặc có ủy quyền bằng văn bản. Một hoặc hai lượt smoke test theo lịch là đủ cho nhiều hệ thống; không dùng production để kích hoạt mã cho khách hàng thật.

Hãy lưu thời điểm trước khi nhấn nút gửi. Khi đọc hộp thư, lọc theo số nhận, thời điểm và một mã định danh của phiên test nếu hệ thống có hỗ trợ. Regex \b(\d{6})\b chỉ phù hợp với mã sáu chữ số; nếu nội dung còn nhiều con số, nên neo mẫu vào câu như Mã của bạn là (\d{6}).

Cách kiểm thử SMS OTP bị trễ, mất hoặc đảo thứ tự

  1. Ghi mốc bắt đầu: lấy thời gian UTC ngay trước yêu cầu gửi. Trừ một khoảng đệm nhỏ nếu đồng hồ giữa các hệ thống có thể lệch.
  2. Gửi một mã duy nhất: lưu ID phiên, số test đã che bớt và mã phiên, không lưu dữ liệu cá nhân không cần thiết.
  3. Chờ có giới hạn: thử lại mỗi 2–3 giây trong tối đa 60 giây cho smoke test, hoặc dùng thời hạn ngắn hơn trong mock. Hết hạn thì trả lỗi rõ ràng, không quay vòng vô hạn.
  4. Lọc tin mới: bỏ tin trước mốc bắt đầu, sai số nhận, sai phiên hoặc đã được test đánh dấu là đã dùng.
  5. Kiểm tra thứ tự: gửi mã A rồi mã B, xác nhận mã B mới nhất được chấp nhận và mã A bị từ chối nếu chính sách chỉ cho phép mã cuối cùng.
  6. Dọn dữ liệu: xóa tin nhắn, fixture và phiên test sau mỗi lượt; kiểm tra cả bản sao trong log và kho tạm.

Ví dụ kiểm tra thời gian chờ: đặt timeout 60 giây, poll mỗi 3 giây. Số lần hỏi tối đa xấp xỉ 60 / 3 = 20 lượt, chưa tính lượt đầu tiên. Kết quả đúng là test kết thúc bằng mã hợp lệ nếu tin đến ở giây 12, hoặc báo timeout gần giây 60 nếu không có tin; test không được chờ vô hạn chỉ vì nhà cung cấp chưa trả lời.

Checklist retry/rate limit và mã đã dùng

Đừng chỉ kiểm tra đường đi thành công. Với retry/rate limit, hãy thử gửi liên tiếp vượt ngưỡng trong môi trường được cô lập, xác nhận hệ thống trả lỗi ổn định và không tạo hàng loạt tin nhắn. Kiểm tra thời gian chờ giữa hai lần gửi, số lần nhập sai, khóa tạm thời và thông báo không làm lộ tài khoản nào tồn tại.

  • Mã hết hạn phải bị từ chối sau thời điểm quy định.
  • Mã đã dùng lần hai phải bị từ chối.
  • Mã cũ phải bị từ chối sau khi mã mới được phát hành, nếu đó là chính sách của ứng dụng.
  • Nhiều yêu cầu gửi phải có giới hạn theo tài khoản, số điện thoại test, IP và phiên.
  • Webhook hoặc bộ đọc hộp thư phải xử lý sự kiện lặp mà không xác minh hai lần.

Ví dụ, nếu chính sách cho phép 5 lần nhập trong 10 phút, lần thứ 6 phải bị chặn dù mã đó đúng. Ghi nhận kết quả theo từng lần: lần 1 đến 5 được xử lý, lần 6 trả trạng thái giới hạn, sau 10 phút bộ đếm mới được mở lại. Con số này chỉ là ví dụ kiểm thử; hãy thay bằng chính sách thật của ứng dụng.

Kiểm tra an toàn dữ liệu trong môi trường QA

Số điện thoại và nội dung SMS có thể là dữ liệu cá nhân. Dùng số tổng hợp hoặc số được ủy quyền, che bớt khi log và đặt thời hạn xóa cho fixture. Không đưa mã OTP, khóa API hay token vào mã nguồn, ảnh chụp màn hình, URL hoặc báo cáo CI.

Ảnh minh họa trong bài chỉ mô tả quy trình, không phải ảnh chụp hệ thống thật và không chứng minh tỷ lệ nhận mã. Với bài test thật, lưu bằng chứng tối thiểu: ID chạy, thời điểm, trạng thái và lý do thất bại đã được che dữ liệu.

FAQ về kiểm thử SMS OTP

Có nên dùng SMS thật cho mọi bài test không?

Không. Dùng mock cho kiểm thử chức năng và lỗi lặp lại, sau đó dành SMS thật cho smoke test tích hợp có kiểm soát.

Có nên đọc mã từ tin nhắn cũ không?

Không. Lọc theo thời điểm, phiên và số nhận để tránh nhập nhầm mã của lượt trước.

Thuê số điện thoại ảo có thay thế sandbox không?

Không trong mọi trường hợp. Số thật hoặc số ảo nhận SMS có thể kiểm tra đường đi bên ngoài, còn sandbox/mock OTP phù hợp hơn cho CI và dữ liệu tổng hợp; việc dùng số phải đúng quyền kiểm soát và điều khoản liên quan.

Kết luận

Hãy bắt đầu bằng sandbox/mock OTP, rồi bổ sung smoke test SMS thật cho đường đi tích hợp. Ghi thời điểm trước khi gửi, lọc tin mới, giới hạn retry, kiểm tra mã trùng và xóa fixture sau lượt chạy. Cách này giúp đội QA bắt được lỗi bất đồng bộ mà vẫn giữ môi trường kiểm thử an toàn.

Để quản lý dữ liệu và quyền truy cập tốt hơn, bạn có thể đọc thêm cách quản lý khóa API an toàn cho đội nhỏMFA là gì và giới hạn của SMS OTP.

Thuê SIM nhận OTP từ 500đ
Dùng thử