PureTempMail

Test İçin Geçici E-posta: Geliştiriciler ve QA Ekipleri Kayıt Akışlarını Nasıl Kontrol Eder

Elle bir test turu, 12 maddelik kontrol listesi ve QA için açık bir geçici gelen kutusunun gerçek sınırları; ayrıca otomasyon ve gizli veriler için araçlar.

PureTempMail Ekibi

PureTempMail'i geliştiren ve işleten mühendisler

Kısa cevap

Geçici bir e-posta adresi, bir kayıt akışını elle kontrol etmenin hızlı bir yoludur: doğrulama, şifre sıfırlama ve hoş geldin e-postaları, kimsenin kişisel posta kutusuna dokunmadan, saniyeler içinde açık internetteki gerçek bir gelen kutusuna ulaşır. Otomatik testler, gerçek müşteri verileri ya da gizli bilgi taşıyan her şey için bunun yerine yerel bir posta yakalayıcı ya da bir test sandbox'ı kullanın.

E-posta gönderen her ürün, yeni bir adresle tekrar tekrar kaydolacak birine ihtiyaç duyar. Geliştiriciler artı etiketli kendi Gmail adreslerine başvurur, QA test uzmanları geçici hesapların tutulduğu bir tablo tutar, ürün yöneticileri bir iş arkadaşının gelen kutusunu ödünç alır. Test için geçici bir e-posta adresi, tek bir iş için bunların hepsinden hızlıdır: yeni bir kullanıcının üretim ya da staging posta altyapınızdan tam olarak ne aldığını görmek.

PureTempMail'in posta sunucularını biz işletiyoruz, bu yüzden aşağıdaki sınırlar tahmin değil, gerçek ayarlarımızdır. Bu rehber, herkese açık bir geçici gelen kutusunun test planında nereye oturduğunu, beş dakikada yapabileceğiniz elle bir test turunu, kendi kayıt e-postalarımızda kullanacağımız kontrol listesini ve başka bir araç kullanmanız gereken durumları anlatıyor.

Geçici gelen kutusunun test seçenekleriniz arasındaki yeri

Bir test hesabına adres vermenin beş yaygın yolu vardır. Çoğu ekip aynı sürümün farklı aşamalarında bunlardan iki ya da üçünü kullanır.

E-posta test seçeneklerinin neyde iyi olduklarına ve nerede yetersiz kaldıklarına göre karşılaştırması
SeçenekEn uygun olduğu işİnternet üzerinden gerçek teslimatOtomasyonDikkat edilmesi gerekenler
Herkese açık geçici gelen kutusu (PureTempMail gibi)Staging ya da üretim e-postalarının elle kontrolü, keşif testleri, demolarEvetBizim tarafımızda yok: gelen kutusunu bir tarayıcıda izlersinizAdresi öğrenen herkes postaları okuyabilir ve uzatılmazsa bir saat sonra süresi dolar
Yerel SMTP yakalayıcı (Mailpit gibi)Uygulamanın sahte bir SMTP sunucusuna gönderdiği geliştirme makineleri ve CIHayır: posta makinenizden ya da ağınızdan hiç çıkmazEvet, HTTP API'si üzerindenDNS, SPF, DKIM ya da gerçek sağlayıcıların postanıza nasıl davrandığı hakkında hiçbir şey söylemez
Barındırılan test sandbox'ı (Mailtrap ya da Mailosaur gibi)Staging ortamları ve uçtan uca test paketleriÜrüne bağlı: SMTP üzerinden yakalanır ya da sağlayıcının test alan adında alınırEvet, yaygın diller için SDK'larlaCiddi hacimler için ücretli planlar ve test verilerinizi tutan bir sağlayıcı daha
Ekip posta kutusunda artı adreslemeGelecek ay yeniden oturum açmanız gereken uzun ömürlü test hesaplarıEvetYalnızca o posta sağlayıcısının API'si üzerindenBirçok kayıt formu artı işaretini reddeder ve her test tek bir ortak gelen kutusuna düşer
Kendi catch-all test alan adınızKontrolünüzdeki çok sayıda kalıcı test hesabıEvetEvet, posta kutusunu IMAP ya da bir API üzerinden okursanızKurulması ve bakımı gereken DNS ve posta barındırma

Geçici gelen kutusu, diğerlerinin bıraktığı bir boşlukta yerini hak eder: gerçek posta sağlayıcınızın gönderdiği, kontrol etmediğiniz bir alan adına düşen ve saniyeler içinde tarayıcıda görüntülenen gerçek bir mesaj. Bir yerde yeni bir hesap daha açmadan, yeni bir müşterinin gördüğüne en çok bu kadar yaklaşabilirsiniz.

PureTempMail ile elle bir test turu

Bir kayıt akışını elle kontrol etmek için önerdiğimiz tur budur. Her geçiş yaklaşık beş dakika sürer.

  1. Her test kullanıcısı için yeni bir posta kutusu açın

    PureTempMail'i ayrı bir tarayıcı penceresinde açın. Sayfa yüklendiğinde yeni bir adres oluşturulur. Posta kutusu tarayıcı başına hatırlanır; bu yüzden her test kullanıcısı için Yeni düğmesine basın ya da iki test uzmanı aynı makineyi paylaşıyorsa gizli pencere kullanın.

  2. Adresi test senaryosunun yanına kaydedin

    Adresi kullanmadan önce test senaryonuza ya da kaydınıza yapıştırın. Daha sonra bir test uzmanı sıfırlama e-postasının neden hiç gelmediğini sorarsa, hangi posta kutusuna gittiğini bilmeniz gerekir.

  3. Kaydı tamamlayın ve tetikleyebildiğiniz her e-postayı tetikleyin

    Formu doldurun, ardından yeni bir kullanıcının ilk oturumunda tetikleyebileceği e-postaları isteyin: doğrulamayı yeniden gönderme, şifremi unuttum, sihirli bağlantıyla giriş, e-posta değiştirme talebi. Her biri kendi başına bozulabilen ayrı bir şablondur.

  4. Gelen kutusunu yenilemeden izleyin

    Yeni posta, sunucumuz onu kabul ettiği anda canlı bir bağlantı üzerinden sayfaya iletilir; bu yüzden bir mesajın görünme zamanı gerçek teslim zamanına yakındır. Her birinin ne kadar sürdüğünü not edin. Nasıl çalışır sayfası teslimat yolunu açıklar.

  5. Her mesajı iki görünümde de açın

    Önce HTML görünümünde okuyun, sonra Düz Metin görünümüne geçin. Düz görünüm, bazı istemcilerin ve ekran okuyucuların başvurduğu görünümdür; eksik bir metin bölümü ya da okunamayan bir kod ilk olarak orada ortaya çıkar. Her bağlantıya tıklayın ve nereye gittiğini doğrulayın.

  6. Akış yavaşsa süreyi uzatın

    Damla dizileri, gecikmeli onaylar ve ikinci gün hatırlatmaları daha fazla zaman ister. Sayacı tam bir saate sıfırlamak için +1 sa düğmesine basın. Bunu posta kutusu oluşturulduktan sonraki 24 saate kadar yapmaya devam edebilirsiniz.

  7. Süresinin dolmasını bekleyin, sonra geri dönmeyi test edin

    Süre dolduktan sonra sunucumuz o adrese gelen postayı SMTP aşamasında kalıcı bir "No such mailbox" hatasıyla reddeder. Adrese bir e-posta daha gönderin ve uygulamanızın ya da posta sağlayıcınızın bir kalıcı geri dönme (hard bounce) kaydettiğini ve o kullanıcıya posta göndermeyi bıraktığını kontrol edin.

Kayıt e-postası test kontrol listesi

Bir sürümden önce herhangi bir ürünün kayıt e-postalarında yapacağımız kontroller bunlardır. Her biri gerçek bir gelen kutusunda kolayca fark edilir ve kod incelemesinde kolayca gözden kaçar.

  • Doğrulama kodu ya da bağlantısı. Gelir, kod düz metinde okunabilir, bağlantı bir kez çalışır ve ikinci tıklama bir hata sayfası yerine açık bir mesaj gösterir.
  • Sihirli bağlantılar ve tek kullanımlık kodlar. Yeni bir bağlantı eskisini geçersiz kılar, süresi dolmuş bir bağlantı sonra ne yapılacağını açıklar ve bağlantıyı başka bir tarayıcıda açmak amaçladığınız gibi davranır.
  • Şifre sıfırlama. E-posta hangi hesap için olduğunu söyler, bağlantının süresi dolar ve kayıtlı olmayan bir adres için sıfırlama istemek, o adresin bir hesabı olup olmadığını açığa çıkarmaz.
  • Hoş geldin ve damla e-postaları. İlki doğrulamadan önce değil sonra gelir ve sonraki adımlar hiç onay vermemiş kullanıcılar için tetiklenmez.
  • HTML ve düz metin bölümleri. İkisi de vardır, ikisi de aynı şeyi söyler ve önemli hiçbir şey yalnızca bir görselin içinde değildir. Uzak görseller HTML görünümümüzde yüklenir; onları orada kontrol edebilir, mesajı görseller olmadan görmek için Düz Metin görünümünü kullanabilirsiniz.
  • Ekler. Faturalar ve PDF'ler anlamlı dosya adları ve içerik türleriyle gelir. Test dosyalarını mesaj başına 1 MB'ın altında tutun ya da bir indirme bağlantısı gönderin; bu zaten gerçek kullanıcılar için de daha iyidir.
  • Bağlantı hedefleri. Üretim e-postasındaki hiçbir bağlantı localhost'a, dahili bir ana bilgisayar adına ya da bir staging alan adına gitmez ve izleme yönlendirmeleri doğru sayfaya çıkar.
  • Abonelikten çıkma başlıkları. Pazarlama ve damla e-postaları çalışan bir abonelikten çıkma bağlantısı ve toplu göndericiler için RFC 8058 ile tanımlanan tek tıklamalı List-Unsubscribe başlığını taşır; Google'ın gönderici yönergeleri bunu toplu göndericilerden ister. Sıfırlama gibi işlemsel e-postalar abonelikten çıkma nedeniyle engellenmemelidir.
  • Teslim süresi. Bir iki dakikadan uzun süren doğrulama e-postaları kullanıcı kaybettirir. Biri yavaşsa uygulamanızın postayı başka işlerin arkasında kuyruğa alıp almadığını ya da sağlayıcının yeni göndericileri kısıtlayıp kısıtlamadığını kontrol edin.
  • Kendi hız sınırlarınız. Yeniden gönder düğmesine art arda basın. Uygulama on kod göndermek ya da sessizce başarısız olmak yerine bir sınır koymalı ve kullanıcıya beklemesini söylemelidir.
  • Bir adresi yeniden kullanma. Aynı oturumda aynı adresle iki kez kaydolun ve ikinci denemeyi kontrol edin: açık bir "zaten kayıtlı" yolu olmalı ve ikinci bir hesap oluşmamalı.
  • Tek kullanımlık alan adı kuralınız. Ürününüz geçici adresleri engelliyorsa hata mesajının açık olduğunu ve yanlışlıkla gerçek sağlayıcıları da engellemediğini doğrulayın. Bununla ilgili ayrıntılar aşağıda.

Sınırlarımız ve bir test için anlamları

Bunlar sunucularımızdaki gerçek ayarlardır. Test turlarını bunlara göre planlayın.

Ömür
Oluşturulmadan itibaren bir saat. +1 sa süreyi, oluşturulmadan sonraki 24 saate kadar, tam bir saate sıfırlar. Bir oturum için yeterli, bir sonraki sprintte yeniden kullanacağınız bir test hesabı için değil.
Mesajlar
Posta kutusu başına en fazla 50 mesaj ve 5 MB. Sınırlardan birine ulaşıldığında yeni posta geri çevrilir; bu yüzden tek bir adrese yönelik bir yük testi kısa sürede saymayı bırakır. Her test kullanıcısı için yeni bir posta kutusu açın.
Mesaj boyutu
Ekler dahil e-posta başına en fazla 1 MB. Yalnızca ilk 10 ek saklanır.
Yalnızca alım
Adres gönderemez ve yanıt veremez. Destek talebi yazışmaları gibi kullanıcının e-postayla yanıt vermesini gerektiren akışlar burada uçtan uca test edilemez.
Alan adı
Tüm adresler için tek bir alan adı. Ürününüz bilinen geçici alan adlarını engelliyorsa bizimkini de engeller; test etmek istediğiniz davranış buysa bu işe yarar.
Yeni posta kutuları
Tek bir IP adresinden dakikada beş yeni posta kutusu. Tek bir ofis bağlantısının arkasındaki bir QA ekibi bu kotayı paylaşır.
Silme
Süre dolduktan sonra her beş dakikada bir çalışan bir temizlik işlemi posta kutusunu, mesajlarını ve eklerini siler. Bir hata raporu için kanıta ihtiyacınız varsa sayaç bitmeden ekran görüntüsü alın.
Otomasyon
Posta kutularına betikle erişim için herkese açık bir API yoktur. PureTempMail, tarayıcıya bakan bir insan için tasarlanmıştır; otomatik test paketlerinin aşağıdaki araçlara ait olmasının nedeni budur.

Test e-postalarınızda SPF, DKIM ve DMARC kontrolü

İyi görüntülenen bir mesaj yine de kimlik doğrulamasından geçemeyip gerçek kullanıcılar için spama düşebilir. Kontrol etmek için aynı e-postayı Gmail'in Orijinali göster seçeneği gibi ham kaynağı gösteren bir posta kutusuna gönderin ve başlıkları e-posta başlığı analiz aracımıza yapıştırın. Araç SPF, DKIM ve DMARC'ın geçip geçmediğini gösterir, farklı bir alan adındaki Reply-To'yu işaretler ve teslimatın nerede yavaşladığını gösterir. Analiz tarayıcınızda çalışır, bu yüzden başlıklar bize gönderilmez.

Kendi tek kullanımlık alan adı engelinizi test etmek

Pek çok ekip kayıt formuna tek kullanımlık e-posta kontrolü ekler ve onu gerçek bir geçici adresle hiç test etmez. Geçici bir gelen kutusu, en bariz test girdisidir.

  • Metni kontrol edin. Ret mesajı, kullanıcılara bunun yerine ne kullanmaları gerektiğini söylemelidir; örneğin "Lütfen kişisel ya da iş adresinizi kullanın". Yalnızca "Geçersiz e-posta" demek, dürüst kullanıcıları olmayan bir yazım hatasını aramaya gönderir.
  • Yanlış pozitifleri kontrol edin. Küçük bölgesel sağlayıcılardaki ve özel şirket alan adlarındaki adresleri deneyin. Örüntüye göre eşleşen engel listeleri bazen bunları da yakalar.
  • Her giriş noktasını kontrol edin. Aynı kural kayıt formu, e-posta değiştirme ayarı, davetler ve API için geçerli olmalıdır; aksi halde insanlar unuttuğunuz yolu kullanır.
  • Engele gerçekten ihtiyacınız olup olmadığına karar verin. Web sitelerinin tek kullanımlık e-postayı neden engellediğini anlatan yazımız, engeli haklı çıkaran maliyetleri ve size yalnızca dürüst kullanıcı kaybettirdiği durumları ele alıyor.

Herkese açık geçici gelen kutusunun yanlış araç olduğu durumlar

Bu durumlarda başka bir şey kullanın.

  • Gerçek gizli bilgi ya da müşteri verisi taşıyan her şey. Üretim token'ları, gerçek faturalar, yönetici davetleri. Yalnızca ekibinizin okuyabildiği bir sandbox kullanın.
  • Otomatik testler ve CI. Geliştirmede ve CI'da uygulamayı Mailpit gibi yerel bir yakalayıcıya, testlerin yayındaki bir ortamda çalışması gerektiğinde ise Mailtrap ya da Mailosaur gibi barındırılan bir sandbox'a yönlendirin. Eski yerel yakalayıcı MailHog artık bakımı yapılmıyor ve yerine genellikle Mailpit kullanılıyor.
  • Gerçek kullanıcı verilerinin kopyalarını içeren staging ortamları. Oradaki hata, kopyalanmış verinin kendisidir. Onu temizleyin ve staging postalarını bir yakalayıcıya yönlendirin ki bir test asla gerçek bir müşteriye e-posta göndermesin.
  • Saklamanız gereken test hesapları. Satış için bir demo hesabı ya da bir uygulama mağazası için bir inceleme hesabı, gelecek ay da çalışan bir adrese ihtiyaç duyar. Ekip posta kutusunda artı adresleme ya da sahibi olduğunuz bir test alan adında catch-all kullanın.
  • Asla teslim edilmemesi gereken test verileri. Seed verileri ve birim testleri için example.com gibi ayrılmış alan adlarını ve RFC 2606 ile ayrılan .test üst düzey alan adını kullanın. Bunlara gönderilen posta tasarım gereği hiçbir yere gitmez.

Sonuç

Bir kişinin gerçek bir göndericiden gelen gerçek bir e-postayı sahte verilerle, hızlıca görmesi gerektiğinde test için geçici bir e-posta adresi kullanın: sürüm kontrolleri, keşif testleri ve demolar. Otomasyonu bir yakalayıcı ya da sandbox ile yapın, gizli bilgileri herkese açık gelen kutularından uzak tutun ve geçici bir adresin başka nerelerde işe yaradığına karar veriyorsanız diğer kullanım alanları sayfamıza bakın. Bir mesaj bize ulaştıktan sonra ne olduğunu görmek için bir geçici e-posta hizmetinin içeride nasıl çalıştığını okuyun.

Kaynaklar