取消訂閱測試是狀態變更測試。從客戶訊息複製 URL 並將其發佈到該訊息中可以將該客戶從真實清單中刪除。安全的測試計劃始於受控的身份、已知的訂閱狀態以及本地模擬和生產驗證之間的明確界限。
在發出請求之前建立測試矩陣
使用兩個受控收件人和至少兩個不同的清單。記錄每個收件者/清單對的初始狀態、為它們產生的令牌以及每個操作後的預期狀態。不要使用真實客戶的令牌作為方便的樣本。使測試資料集與客戶匯出和活動受眾隔離。
例如，將 Alice 定義為“新聞和警報”，將 Bob 定義為“新聞”。使用 Alice 的新聞令牌的請求應該僅刪除該對。 Alice 的警報和 Bob 的新聞應該保持不變。這是一個說明性的範圍設計；這些標籤是假設的，不是真正的訂閱。
驗證訊息到令牌的映射
檢查確切的授權測試訊息並提取公佈的 HTTPS URI 和List-Unsubscribe-Post值。確認 DKIM簽名 在信任所公佈的操作之前，覆蓋這兩個欄位都是有效的。 RFC 8058要求 URI 來識別收件者和列表，並禁止依賴 cookie 或先前的上下文。 RFC 8058第 3 節和第 4 節.
不要用可見的「收件者」位址取代訂閱標識。訊息可能會被轉發，可能會涉及別名，並且顯示標頭不是端點的授權資料庫。透過受控測試映射或授權系統證據來解析令牌，而不是猜測它將影響哪個位址。
練習正反面案例
測試非破壞性 GET、格式錯誤或未知的令牌、正確的 POST 以及重複的正確 POST。記錄 HTTP 狀態、重新導向、回應處理和產生的訂閱狀態。新增兩種允許的請求編碼、缺失或不正確的正文值以及沒有瀏覽器會話的請求的情況。
在假設矩陣中，Alice 的 News 代幣預計只會更改 Alice/News。如果請求同時刪除 Alice/News 和 Alice/Alerts，則即使傳回成功狀態，測試也會暴露過多的範圍。如果 Bob/News 發生變化，請調查收件者對應。這兩種結果都與請求失敗且未更改的資料庫不同。
不要僅從 HTTP 狀態推斷出任何這些結果。檢查每個受控對的授權前後記錄。這些是範例解釋和預期檢查，而不是觀察到的端點執行。 HTTPS 傳輸、編碼和下游資格仍然是獨立的測試維度。
檢查下次發送決定
如果活動系統使用過時的匯出或緩存，則資料庫標誌是不夠的。在授權的暫存環境中，建立下一個受眾選擇並驗證已刪除的對是否不存在，而未受影響的對仍然符合資格。檢查橋接首選項服務和發送方的任何複製或同步佇列。
對於生產金絲雀，請獲得所需的權限並僅使用指定的測試訂閱。保留準確的目標和預期範圍。不要將測試從一份新聞通訊擴大到每一份訂閱，因為端點提供了「所有清單」選項。停下來調查觀察到的狀態是否與測試矩陣不同。
保留有用的證據而不保留能力令牌
保留經過編輯的請求描述、時間戳記、狀態和之前/之後的狀態標識符。避免將即時取消訂閱 URL 放置在一般支援票證、共享日誌或螢幕截圖中。僅將敏感的操作證據儲存在授權團隊可以存取的位置，並套用組織的保留規則。
最後列出已通過的案例、未經測試的層和任何糾正措施。真實的報告可能會說本地處理程序是正確的，而生產TLS 、抑制傳播和提供程序顯示仍然懸而未決。這種區別可以防止小型成功測試被誤認為是端到端認證。
在意外範圍內停止
如果測試更改了另一個清單或收件人，請停止其他狀態變更請求並保留經過編輯的證據。讓所有者調查映射並通過批准的流程恢復測試狀態，然後再繼續。過去的幸福之路並不能消除失敗的負面案例。