Phiên bản không đáng tin cậy của một bài kiểm tra email rất ngắn gọn: tạo một địa chỉ, chờ năm giây, đọc tin nhắn đầu tiên và hy vọng nó thuộc về lần chạy này.
Phiên bản đáng tin cậy vẫn đơn giản, nhưng nó coi việc giao nhận là bất đồng bộ. Nó tạo một địa chỉ duy nhất, ghi lại thời gian bắt đầu, thực hiện polling trong thời hạn, khớp tin nhắn mong muốn, xác thực hành động sản phẩm và báo cáo đủ ngữ cảnh khi có lỗi.
Giữ khóa API ra khỏi URL
Gửi khóa GPTMail trong header X-API-Key. Không đặt nó trong tham số truy vấn ?api_key=. URL thường được lưu trong lịch sử trình duyệt, nhật ký truy cập, hệ thống giám sát và dữ liệu referrer.
X-API-Key: YOUR_API_KEYLưu khóa trong trình quản lý bí mật CI của bạn và ẩn nó trong nhật ký. Một khóa công khai hàng ngày tiện lợi cho việc khám phá; các bộ kiểm thử tự động được kiểm soát nên sử dụng khóa có thể theo dõi hạn ngạch và việc sử dụng.
Các endpoint hiện tại và ví dụ phản hồi được duy trì trên trang tài liệu API GPTMail.
Một địa chỉ cho mỗi lần chạy
Tạo một địa chỉ mới cho mỗi bài kiểm tra có thể thực thi độc lập. Đừng suy ra tính đúng đắn từ một hộp thư được chia sẻ bởi toàn bộ bộ kiểm thử.
Ghi lại địa chỉ, ID kịch bản, môi trường và thời gian bắt đầu kiểm thử. Những giá trị này cho phép bạn loại bỏ các tin nhắn cũ và chẩn đoán va chạm mà không cần ghi nhật ký bí mật tin nhắn.
Thực hiện polling dựa trên thời hạn, không phải ngủ cố định
Thời gian giao nhận email thay đổi. Việc ngủ cố định năm giây vừa lãng phí khi giao nhận nhanh, vừa không ổn khi chậm.
Sử dụng vòng lặp có giới hạn:
deadline = now + 90 seconds
delay = 2 seconds
while now < deadline:
messages = list inbox
candidate = newest message matching sender, subject, and start time
if candidate exists:
read candidate and continue the product test
wait delay with a small random jitter
delay = min(delay * 1.5, 10 seconds)Thời hạn là một phần của hợp đồng kiểm thử. Quy trình đặt lại mật khẩu có thể cần giới hạn khác so với việc xem trước bản tin hàng loạt. Giữ giới hạn rõ ràng để một phụ thuộc chậm không làm kéo dài âm thầm toàn bộ công việc CI.
Khớp chính xác
“Tin nhắn đầu tiên trong hộp thư” không phải là bộ chọn hữu ích. Khớp nhiều tín hiệu:
- người nhận bằng địa chỉ được tạo cho lần chạy này;
- thời gian tạo muộn hơn thời gian kích hoạt;
- người gửi thuộc dịch vụ mong đợi;
- tiêu đề hoặc loại tin nhắn khớp với quy trình;
- ID tin nhắn chưa được tiêu thụ trước đó.
Khi người gửi có thể phát hành nhiều mã, chọn tin nhắn mới nhất phù hợp. Giữ lại ID của nó trong đầu ra kiểm thử để các lần thử lại không vô tình sử dụng lại.
Chỉ đọc sau khi danh sách khớp
Liệt kê hộp thư nên là bước khám phá chi phí thấp. Lấy toàn bộ tin nhắn chỉ cho ứng cử viên đã chọn. Điều này giảm công việc không cần thiết và tránh phân tích các email quảng cáo không liên quan.
Xác thực kết quả kinh doanh, không chỉ có mặt của một chuỗi sáu chữ số. Gửi mã hoặc mở liên kết mong đợi, sau đó khẳng định tài khoản đạt trạng thái đúng.
Xử lý giới hạn tốc độ như một tín hiệu
Nếu API trả về phản hồi về hạn ngạch hoặc giới hạn tốc độ, dừng nỗ lực hiện tại và hiển thị thông tin reset. Các lần thử lại quá mức sẽ biến tín hiệu khả năng rõ ràng thành tiếng ồn và có thể làm trì hoãn các bài kiểm tra không liên quan.
Giới hạn đồng thời ở trình chạy kiểm thử, đặc biệt khi một bộ tạo nhiều địa chỉ cùng lúc. Một pool worker nhỏ dễ gỡ lỗi hơn so với hàng trăm vòng polling đồng thời.
Dọn dẹp mà không che giấu lỗi
Quá trình dọn dẹp nên chạy sau khi đã thu thập bằng chứng. Khi thành công, xóa tin nhắn hoặc để thời gian lưu trữ ngắn xử lý chúng. Khi thất bại, giữ lại địa chỉ và ID tin nhắn trong các artifact CI được bảo vệ đủ thời gian để điều tra, sau đó xóa chúng.
Không bao giờ in mã xác minh, liên kết riêng tư hoặc toàn bộ nội dung HTML vào nhật ký xây dựng công khai.
Làm cho các lần thử lại không thay đổi trạng thái (idempotent)
Thử lại kiểm thử như một lần chạy mới với địa chỉ mới. Đừng giả định rằng việc lặp lại cùng một yêu cầu đối với cùng tài khoản và hộp thư sẽ bắt đầu từ trạng thái sạch. Người gửi có thể vô hiệu hoá các mã cũ, hạn chế các yêu cầu lặp lại, hoặc từ chối lời mời trùng lặp.
Nếu một yêu cầu mạng hết thời gian, phân biệt “không nhận được phản hồi” và “hoạt động không xảy ra”. Kiểm tra trạng thái có thể quan sát trước khi thực hiện một lần thử lại gây hủy.
Báo cáo điểm thất bại
Một lỗi tự động hoá hữu ích sẽ xác định một trong các giai đoạn sau:
- tạo địa chỉ thất bại;
- hành động sản phẩm thất bại trước khi email được đưa vào hàng đợi;
- không có tin nhắn phù hợp nào đến trước thời hạn;
- tin nhắn đã đến nhưng nội dung không khớp;
- hành động xác minh thất bại;
- dọn dẹp thất bại.
Phân loại này biến một “bài kiểm tra email thất bại” ngắt quãng thành công việc mà đội ngũ có thể chịu trách nhiệm.
Đối với ma trận kiểm thử lớn hơn, đọc Kế hoạch kiểm thử email thực tế. Để chẩn đoán giao nhận, sử dụng Email xác minh không tới: Tìm bước bị hỏng.