Hogyan válasszunk teszt e-mail fiókot a minőségbiztosításhoz

Mi az a teszt e-mail fiók a QA-hoz?

A teszt e-mail fiók, vagyis a QA teszt e-mail cím olyan cím, amelyet a csapatod arra használ, hogy megkapja és ellenőrizze a saját alkalmazásod által küldött e-maileket. Manuális, nem érzékeny regisztrációs és OTP-ellenőrzésekhez használj ideiglenes postaládát. Megőrzendő üzenetekhez, válaszokhoz vagy mellékletekhez válassz vállalati postaládát, ha pedig az automatizált teszteknek emberi beavatkozás nélkül kell ellenőrizniük az e-maileket, használj SMTP sandboxot vagy hosztolt postaláda API-t.

Ezt a blogot a Tmailor üzemelteti, így itt a helye. A Tmailor egy ingyenes, csak fogadásra alkalmas ideiglenes e-mail szolgáltatás weben, Androidon, iOS-en és egy Telegram boton keresztül. Az első esethez illik: egy ember megnyit egy postaládát, elindít egy regisztrációt, és elolvassa, ami megérkezik. Az utolsó esethez a különálló Tmailor Temp Mail API lehetővé teszi, hogy az automatizált tesztek csak kapó címeket hozzanak létre, és üzeneteket olvassanak a kódból. Az üzenetek körülbelül 24 órán belül maradnak az érkezés után, a mellékletek nem érkeznek, és a cím nem tud küldeni vagy válaszolni. Ha új vagy az eldobható postaládákban, kezdd azzal , hogyan működik a ideiglenes levelezés.

• Nem kell e-mailnek megérkeznie (űrlapvalidáció, fixture-ök, unit tesztek): használj fenntartott példa domaint.
• Egy ember olvassa el az e-mailt, és semmi érzékeny nincs benne: az ideiglenes postaláda a leggyorsabb megoldás.
• Érzékeny adatok, válaszok, mellékletek vagy megőrzendő bizonyítékok: használj jóváhagyott, vállalati ellenőrzés alatt álló postaládát; plusz címkéket csak akkor adj hozzá, ha a levelezőrendszered és az alkalmazásod támogatja őket.
• Senki sem figyeli: használj SMTP catchert, ha te irányítod az alkalmazás kimenő levelezési beállításait, vagy hosztolt postaláda API-t, ha az alkalmazásnak a szokásos szolgáltatóján keresztül kell küldenie.

Manuális vs. automatizált e-mail-tesztelés: döntési fa

Négy kérdés dönti el, melyik teszt e-mail fiókra van szükség egy ellenőrzéshez: egyáltalán meg kell-e érkeznie egy e-mailnek, ember vagy kód olvassa-e, tartalmaz-e érzékeny adatokat, és te irányítod-e, hová küldi az alkalmazás a kimenő leveleit.

1. Meg kell érkeznie egy e-mailnek a teszthez? A formátumellenőrzésekhez, felületi állapotokhoz, fixture-ökhöz és unit tesztekhez általában nem. Használj example.com, example.org vagy example.net címeket. Ezek a domainek dokumentációra és példákra vannak fenntartva, így semmi sem jut el valódi személyhez. Kerüld véletlenszerű domainek kitalálását, mert lehet, hogy valaki birtokolja őket.
2. Egy ember fogja elolvasni az üzenetet a teszt során? A füsttesztek, a manuális UAT, a bemutatók és a felfedező tesztelések során ember van a folyamatban. A regressziós tesztcsomagok és a CI-feladatok általában nem ilyenek.
3. Ha egy ember olvassa el, van benne valami érzékeny? Valódi ügyféladatok, hitelesítő adatok, szabályozott adatok vagy auditbizonyítékként megőrzendő üzenetek nem valók ideiglenes postaládába. Ilyenkor használj vállalati postaládát. Ha a válasz nem, akkor az ideiglenes postaláda is elég.
4. Ha kód olvassa, el tudja küldeni a tesztkörnyezet a leveleit egy teszt SMTP szerverre? Ha igen, egy SMTP catcher minden üzenetet elkap, anélkül hogy kézbesítené. Ha nem, mert az alkalmazásnak a szokásos e-mail szolgáltatóján keresztül kell küldenie, használj olyan hosztolt postaládát, amelyet a tesztek API-n keresztül olvasnak.

A táblázat az öt lehetőséget hasonlítja össze egymás mellett.

Mely címeket fogadjon el vagy utasítson el egy e-mail mező?

A tesztűrlap validálását különítsd el az üzenetküldéstől. Használj fenntartott címet, például az user@example.com címet egy érvényesnek látszó esethez, amely soha nem kézbesít, adj hozzá egy plusz címkés címet és egy aldomaines címet, valamint adj hozzá rosszul formált eseteket, például hiányzó helyi részt vagy hiányzó domaint. A várt eredményeket ahhoz a validátorhoz igazítsd, amelyet az éles rendszered valóban használ.

Amikor egy ideiglenes bejövő fiók elegendő

Az ideiglenes bejövő fiók akkor működik, amikor egy személy egyszerre egy folyamatot ellenőriz, és az üzenetben nincs semmi, amit egy nap után ne bánnál, ha elveszne. Ez az eldobható e-mail klasszikus minőségellenőrzési felhasználása: e-mail címre van szükséged egy űrlap kézi teszteléséhez, nem hosszú életű fiókra. Tipikus esetek a regisztrációs űrlap kiadás előtti füsttesztje, egy kézi UAT-kör egy új üdvözlő e-mailen, egy értékesítési demó a fióklétrehozásról, vagy egy feltáró munkamenet, ahol furcsa bemeneteket próbálsz ki, és figyeled, mit küld az alkalmazás.

A vonzerő a sebesség. Nincs fiók, amit az IT-tól kellene kérni, és nincs közös postaláda, amit takarítani kellene. A kompromisszum az irányítás: rövid üzenetablakot kapsz, nincs csatolmány, és az üzeneteket egy személy olvassa, nem kód.

Amikor SMTP catcherre vagy hosztolt bejövő API-ra van szükséged

Amint a tesztek felügyelet nélkül futnak, a bejövő postaládát kódnak kell olvasnia. Két eszközcsalád fedi le ezt az igényt, és különböző problémákat oldanak meg.

SMTP catcherek és sandboxok lecserélik az alkalmazásod kimenő levelezőszerverét egy tesztkörnyezetben, és minden üzenetet megőriznek ellenőrzésre ahelyett, hogy kézbesítenék őket.

• A Mailpit egy ingyenes, nyílt forráskódú eszköz, amelyet magad futtatsz. Alapértelmezés szerint elkapja a leveleket, és webes felületet valamint REST API-t kínál integrációs tesztekhez.
• A MailHog ugyanígy működik, de régebbi. A Mailpit karbantartói szerint már nem karbantartják, ezért nézd meg az állapotát, mielőtt bevezetnéd.
• A Mailtrap Email Sandbox ugyanennek az ötletnek a hosztolt változata, SMTP- és API-hozzáféréssel. Ez elkülönül a Mailtrap éles küldésre szolgáló termékétől.
• Az Ethereal egy ingyenes, hamis SMTP-szolgáltatás, amelyet főként a Nodemailerrel használnak. Az üzeneteket előnézetre rögzíti, és soha nem kézbesíti.

A hosztolt bejövőfiók-API-k valódi címeket adnak a teszteknek a szolgáltató domainjein, így az alkalmazásod a szokásos szolgáltatóján keresztül küld levelet, a teszt pedig egy API-n keresztül olvassa ki az eredményt. A Tmailor saját Temp Mail API-ja így működik, hivatalos SDK-kkal Pythonhoz, Node.js-hez és PHP-hoz.

• A Mailosaur teszt e-mail címeket, API-t és klienskönyvtárakat kínál, amelyek olyan keretrendszerekkel működnek együtt, mint a Cypress, a Playwright és a Selenium. SMS-kódokat is lefed.
• A MailSlurp igény szerint hoz létre bejövő fiókokat API-ján és SDK-in keresztül. A tesztek megvárhatnak egy üzenetet, majd kinyerhetik belőle a kódokat, linkeket és mellékleteket.

A szolgáltatók funkciói és csomagjai változnak, ezért mielőtt egy tesztcsomagot egyikükre építenél, ellenőrizd az aktuális részleteket minden hivatalos oldalon.

Mikor jobb választás egy céges postafiók plusz címkékkel

A plusz címkék lehetővé teszik, hogy egyetlen céges postafiók sok címváltozatot fogadjon. A céges domainen a qa+signup vagy qa+reset címre küldött levelek a qa postafiókba érkeznek, ahol címke szerint szűrheted őket. A Google Workspace támogatja ezt, a Microsoft pedig dokumentálja, hogy az Exchange Online-ban a plusz címzés alapértelmezés szerint be van kapcsolva, hacsak egy adminisztrátor ki nem kapcsolja.

Akkor válaszd ezt az utat, ha egy folyamat valódi ügyféladatokat visz, egy napnál tovább tart, válaszokat vagy mellékleteket igényel, vagy olyan bizonyítékot termel, amelyet egy auditor kérhet. Tartsd szem előtt a korlátokat. A címkék egyetlen postafiók változatai, nem külön bejövő fiókok, így a párhuzamos tesztek egymás üzeneteit is olvashatják. Egyes regisztrációs űrlapok elutasítják a pluszjelet, és egyes alkalmazások a címkézett változatokat ugyanannak a fióknak tekintik. Mindkét viselkedés megér egy saját tesztesetet.

Hogyan futtass manuális regisztrációs tesztet ideiglenes bejövő fiókkal

Egy manuális regisztrációs teszthez, amely ideiglenes e-mailt használ tesztelésre, három dolog kell: egy friss cím, a tesztelt build, és egy hely a bejövő fiókon kívül, ahol rögzítheted, mi érkezett. Csak olyan rendszereken futtasd, amelyek a sajátjaid, vagy amelyek tesztelésére jogosult vagy.

1. Nyiss meg egy bejövő fiókot. Hozz létre egy ingyenes ideiglenes bejövő fiókot a weben, vagy használd a Tmailor alkalmazást vagy a Telegram botot, és másold ki a címet. Asztali gépen a Tmailor böngészőbővítmény a tesztbuild e-mail mezőjébe is be tudja írni.
2. Regisztrálj a tesztbuildben. Használd a címet a staging vagy QA környezetben, és jegyezd fel, mikor küldted be az űrlapot.
3. Figyeld az e-mailt. Ellenőrizd, melyik üzenet érkezett meg, a feladó nevét és a From címet, a tárgyat, és hogy mennyi időbe telt.
4. Fejezd be a lépést. Kattints a linkre, vagy írd be a kódot. Erősítsd meg, hogy a fiók állapota egyszer változik meg, és hogy ugyanazon link újbóli használata egyértelmű hibaüzenettel meghiúsul.
5. A bizonyítékot máshol rögzítsd. Másold a linket, a kódot, az időbélyegeket és egy képernyőképet a tesztesetedbe. Az üzenetek az érkezéstől számítva körülbelül 24 órán át maradnak meg, így a bejövő fiók nem a teszt nyilvántartása.
6. Mentsd el az Access Tokent, ha újra tesztelni fogsz. A token később újra megnyitja ugyanazt a címet, például hogy újrafuttass egy jelszó-visszaállítást. Nem állítja vissza a már lejárt üzeneteket, és az elveszett token nem szerezhető vissza.

Ha egy munkamenethez egyszerre több személyiségre van szükség, például egy ingyenes felhasználóra, egy próbaidős felhasználóra és egy meghívott csapattársra, a több bejövő fiók nézete akár öt címet is egymás mellett tart egyetlen böngészőfülön. Minden személyiség saját címet kap, így láthatod, melyik e-mail melyik fiókhoz tartozik.

Ez a nézet továbbra is manuális. A bejövő fiókokat egy ember hozza létre böngészőben, nem kód biztosítja őket, így nem helyettesíti a hosztolt bejövőfiók-API-t párhuzamos, felügyelet nélküli futtatásokhoz.

Egy bejövő fiók vagy egy cím tesztenként?

Egyetlen közös postafiók megfelel egy gyors füstteszthez, de hamar zajossá válik. Ha egyszerre több teszt fut, a hasonló tárgysorok miatt nehéz megállapítani, melyik e-mail melyik szkripthez tartozik, és a hibakeresés találgatássá válik.

Ha tesztenként egy címet használunk, ez megoldódik. A naplók, képernyőképek és e-mailek összeillenek, és egy hiányzó üzenet egyetlen forgatókönyvre mutat, nem az összesre. A több ideiglenes postafiók futtatásához útmutató részletesebben tárgyalja ezt a munkafolyamatot.

Egyes folyamatokban napokkal később ismét szükség van ugyanarra a címre, például egy próbaidőszakból fizetőssé váló előfizetésnél vagy egy lemorzsolódás után visszatérő felhasználónál. Egy újrahasználható ideiglenes e-mail cím az Access Token segítségével elérhetővé teszi a címet, de a leveleket nem. Minden lépés futása közben mentsd el a szükséges linkeket és kódokat, és minden olyan lépést, amely régebbi üzenetekre támaszkodik, helyezz át egy céges postafiókba. Ha egy tesztelő bejelentkezik egy ingyenes Tmailor fiókba, mielőtt személyicímeket hozna létre, mindegyik a Létrehozott e-mailek alatt van elmentve, így az elveszett token már nem jelent elveszett címet.

Mit érdemes ellenőrizni a regisztrációs és onboarding e-mailekben

Kezdd azzal, hogy számba veszed az összes e-mailt, amelyet a folyamat küldhet, majd döntsd el, mit ellenőrizzen az egyes tesztek. A csapatok gyakran csak akkor fedeznek fel további e-maileket, amikor azok a teszt közben megjelennek, miután egy növekedési kísérlet vagy egy biztonsági változtatás hozzáadott egyet, amelyet senki sem dokumentált.

E-mailek egy tipikus regisztrációs folyamatban

• Ellenőrző link vagy egyszeri kód
• Üdvözlő e-mail és az esetleges gyorsindítási sorozat
• Magic-link bejelentkezés
• Jelszó-visszaállítás
• E-mail-címváltás, a régi és az új címre egyaránt elküldve
• Biztonsági riasztás új eszközről vagy új helyszínről
• Emlékeztetők a be nem fejezett regisztrációkról

Mindegyikhez írd le a kiváltó okot, a várható időzítést és az azt módosító feltételeket, például a csomagot, a régiót vagy a nyelvet. Az engedélyezett kézbesítési időablakot a termék dokumentált követelményéből állítsd be, ne feltételezz általános küszöbértéket; egy azonnali ellenőrző üzenet és egy ütemezett üdvözlő sorozat eltérő elvárásokat igényel. Ha ezek az elvárások megvannak, minden tesztnek van konkrét ellenőriznivalója.

Mit érdemes ellenőrizni minden teszte-mailben

• Feladó és címzett: a feladó neve és címe, a Reply-To fejléc, valamint a pontos To (címzett) cím.
• Tárgy és szövegtörzs: a HTML- és a sima szöveges változat is, helyes nevekkel, csomagadatokkal és nyelvvel.
• Linkek: a cél, és hogy a megfelelő környezetre mutat-e. Egy staging e-mail, amely a produkciós környezetre mutató linket tartalmaz, valódi hiba.
• Kódok: formátum, hossz, a lejáratra vonatkozó szöveg, és hogy a megadott lejárat megegyezik-e azzal, amit a szerver érvényesít.
• Időzítés: mennyi idő telt el, mire az üzenet megérkezett a kiváltás után.
• Mellékletek: ha egy folyamat PDF-et vagy számlát küld, azt céges postaládában vagy teszteszközben teszteld. A Tmailor nem fogad mellékleteket.

Egy figyelmeztetés a megjelenítésről. Egy ideiglenes postaláda azt mutatja meg, hogyan jeleníti meg a HTML-edet egyetlen webes megjelenítő. Nem árulja el, hogyan néz ki ugyanaz az e-mail a Gmailben, az Outlookban, az Apple Mailben, sötét módban vagy egy kis telefonképernyőn, ezért ha ezek számítanak, tervezz külön megjelenítési ellenőrzéseket.

E-mail-címváltás és fiók-helyreállítási folyamatok

A helyreállítási folyamatok csendesebb módon hibásodnak meg, mint a regisztráció. Ellenőrizd, hogy az e-mail-címváltás megerősítést küld az új címre és értesítést a régire, hogy egy már felhasznált visszaállítási link nem használható újra, hogy egy régebbi visszaállítási link érvénytelenné válik, miután újabbat küldtek, és hogy egy második eszközön megnyitott link értelmes állapotba juttatja a felhasználót. Az OTP-folyamatok külön kockázati felülvizsgálatot érdemelnek; a QA és UAT OTP kockázatellenőrzőlistája a mérőszámokat, az újraküldési időablakokat és a felelősségi köröket tárgyalja.

Hogyan teszteljük az OTP és az ellenőrzés szélsőséges eseteit

Teszteld az OTP- és ellenőrzési folyamatokat késleltetett kézbesítés, újraküldés, lejárt és hibás kódok, valamint másik eszközön megnyitott linkek esetére. Minden esetben ellenőrizni kell a szerver eredményét és a felhasználónak megjelenített üzenetet is. Ezeket a teszteket csak olyan rendszereken végezd, amelyek a sajátjaid, vagy amelyek tesztelésére jogosult vagy. A jó OTP-tesztek szándékosan megtörik a folyamatot:

• Lassú érkezés: várj a postaláda ellenőrzése előtt, és erősítsd meg, hogy a felület elmagyarázza, mi történik, és egyértelmű módot kínál az újraküldésre.
• Újraküldési viselkedés: kérj egy második kódot, és ellenőrizd, hogy az első érvénytelenné vált-e vagy továbbra is elfogadott.
• Lejárat: adj meg egy kódot a megadott élettartama után, és erősítsd meg, hogy a hibaüzenet megfelel a történteknek.
• Hibás kód: erősítsd meg, hogy a próbálkozások korlátja és a várakozási időre vonatkozó szöveg értelmes az ember számára.
• Eszközök közötti mágikus linkek: kérj linket egy laptopon, nyisd meg a telefonon, és nézd meg, hová kerül a felhasználó.

Ha szélesebb képet szeretnél arról, mely kódok jutnak el egy ideiglenes postaládába és melyek nem, lásd ezt az útmutatót az ideiglenes levelezésről az OTP kódokhoz.

Ha a terméked szándékosan elutasítja az eldobható e-mail-domaineket, teszteld közvetlenül ezt az utat. Erősítsd meg, hogy az elutasítási üzenet egyértelmű, és hogy egy valós vagy cég által ellenőrzött cím továbbra is végigviszi a regisztrációt. Ne válts más ideiglenes domainekre, hogy megkerüld a blokkolást – sem a saját termékeden, sem másén. A blokkolás működésének megerősítése a teszt, annak megkerülése nem. Ez a magyarázó cikk arról szól, hogy miért blokkolják a weboldalak a ideiglenes levelező domaineket mi áll e szűrők hátterében.

Mi változik, ha az e-mailes tesztek felügyelet nélkül futnak

Amikor senki sem figyeli, a tesztnek olyan postafiókra van szüksége, amelyet kódból is olvasni tud. Ez egy SMTP catcher API-ját vagy egy hosztolt postafiók API-ját jelenti. A Tmailor webes postafiókja nem ez az eszköz, de a Tmailor Temp Mail API igen: a tesztek csak fogadásra szolgáló címeket hozhatnak létre, listázhatják és olvashatják az üzeneteket, valamint megkaphatják az API által megtalált egyszeri kódot vagy ellenőrző linket. Egy MCP szerver lehetővé teszi, hogy az olyan AI-ügynökök, mint a Claude, a Cursor vagy a VS Code Copilot, ugyanezt tegyék azoknál a regisztrációs folyamatoknál, amelyek a tieid, vagy amelyeket engedélyezett tesztelned.

Néhány szokás stabilan tartja a felügyelet nélküli e-mailes teszteket, bármelyik eszközt is választod:

• Minden tesztfutás kapjon saját címet és egy korrelációs azonosítót, hogy egy korábbi futásból késve érkező e-mail ne teljesíthesse a rossz állítást.
• Használj külön várakozást az e-mail megérkezésére, ésszerű újrapróbálkozási időközökkel, az általános teszt-időkorláttól elkülönítve, és naplózd, mennyi ideig tartott az egyes üzenetek megérkezése.
• A pontos üzenetet a címzett és a tárgy alapján azonosítsd, ne „a legfrissebb e-mailt” olvasd ki.
• Maszkold a kódokat és a mágikus linkeket a CI-naplókban, mivel a naplók gyakran tovább élnek, mint a postafiók.

Légy tisztában azzal is, mit bizonyít egy sikeres teszt. „Az alkalmazás előállította és átadta az e-mailt”, „egy hosztolt tesztdomain megkapta a nyilvános e-mail-infrastruktúrán keresztül” és „a Gmail a beérkező mappába tette, nem a spambe” három különböző tény. Az SMTP catcher az elsőt bizonyítja, egy hosztolt postafiók API az első kettőt, a harmadikat pedig egyik sem. A GitHub Actions, GitLab CI és CircleCI pipeline-beállításaihoz lásd a e-mail teszteléshez útmutatót a CI/CD pipelines-ban.

Tartsd biztonságban a tesztadatokat, és maradj a szabályokon belül

Használj szintetikus identitásokat és nem érzékeny tartalmat az ideiglenes tesztpostafiókokban, és csak olyan rendszereken futtass regisztrációs teszteket, amelyek a tieid, vagy amelyek vizsgálatára engedélyed van. Tartsd távol a QA-fiókokat a termelési analitikától, tartsd tiszteletben a sebességkorlátokat, a szabályozott adatokat, hitelesítő adatokat, mellékleteket és a megőrzött bizonyítékokat pedig helyezd át jóváhagyott, cég által ellenőrzött rendszerekbe.

• Semmilyen valódi adat ne kerüljön ideiglenes postafiókba. Soha ne irányíts valódi ügyféladatokat, hitelesítő adatokat, API-kulcsokat vagy szabályozott adatokat ideiglenes e-mail-címre. Használj szintetikus felhasználókat nyilvánvalóan hamis nevekkel.
• Csak azt teszteld, amit szabad. Csak a saját termékeden vagy olyan rendszeren futtass regisztrációs teszteket, amelynek tesztelésére engedélyed van, és tartsd tiszteletben az adott szolgáltatás sebességkorlátait és feltételeit. Ne használj ideiglenes levelezést arra, hogy tömegesen hozz létre fiókokat harmadik felek oldalain. A volumen- és terheléstesztelés a saját staging környezetedbe való, SMTP catcherrel vagy hosztolt postafiók API-val.
• Tartsd távol a QA-forgalmat a termelési számoktól. Jelöld egyértelműen a tesztfiókokat, és zárd ki őket az analitikai és növekedési irányítópultokból. Kerüld nagy mennyiségű tesztlevél küldését a termelési küldő domainedről, ahol a visszapattanások és panaszok árthatnak a hírnevének.
• Írd le a szabályzatot. Rögzítsd, mely folyamatok használhatnak ideiglenes postafiókot, melyekhez kell céges postafiók, mennyi ideig őrzitek meg a tesztadatokat, és ki fér hozzájuk. A biztonsági és megfelelőségi felülvizsgálatok gyorsabban haladnak, ha a határok már papíron vannak.

Amikor a biztonsági csapat azt kérdezi, hogyan kezeli az adatokat egy szolgáltató, nézd meg, mit gyűjt, mennyi ideig őrzi meg az üzeneteket, és hogyan működik a hozzáférés. Ez a ideiglenes levelezés és az online adatvédelem áttekintése a felhasználói oldalról válaszolja meg ezeket a kérdéseket. Annak eldöntése, hogy mely folyamatok használhatnak eldobható postafiókokat, továbbra is a saját jogi, adatvédelmi és biztonsági csapataid feladata.

Korlátok, amelyekkel számolni kell

A Tmailor webes postafiókja rövid, manuális ellenőrzésekre való nem érzékeny bejövő e-mailek esetén (az automatizálásra a Temp Mail API szolgál). Mielőtt ezt választanád, döntsd el, hogy a munkafolyamatnak szüksége van-e kimenő műveletekre, mellékletekre, hosszú távon megőrzendő bizonyítékokra vagy tartós cím-visszaállításra. E követelmények bármelyike cég által ellenőrzött postafiókot vagy speciális teszteszközt igényel; az alábbi ellenőrzőlista elmagyarázza, miért.

• A Tmailor csak fogadásra képes. Ellenőrizheted vele a bejövő regisztrációs, ellenőrző és OTP-leveleket, de a válaszfolyamatokat vagy bármit, ami a címről küld, nem.
• A Tmailor nem fogad mellékleteket, ezért a számlákkal, szerződésekkel vagy dokumentumküldéssel kapcsolatos e-mailekhez céges postafiók vagy teszteszköz szükséges.
• Az üzenetek a megérkezéstől számítva körülbelül 24 órán át maradnak meg. Exportáld azokat a linkeket, kódokat és időbélyegeket, amelyekre egy hosszabb vizsgálathoz szükség lesz.
• Egy access token újranyit egy címet, de a lejárt üzeneteket nem hozza vissza, és az elveszett token nem szerezhető vissza.
• A webes postafiókot egy ember olvassa. A felügyelet nélküli postafiók-olvasáshoz SMTP catcher vagy hosztolt inbox API szükséges, például a Tmailor Temp Mail API.
• Egyes szolgáltatások blokkolják az eldobható e-mail domaineket. Ha egy tesztelt folyamat szándékosan így tesz, ellenőrizd valós vagy cég által ellenőrzött címmel.

A megfelelő tesztpostafiók kiválasztása

Aszerint válaszd ki a postafiókot, hogy mit kell bizonyítania a tesztnek. Használj fenntartott példadomaint, ha a kézbesítés nem szükséges, ideiglenes postafiókot a manuális, nem érzékeny ellenőrzésekhez, céges postaládát a megőrzendő vagy érzékeny folyamatokhoz, SMTP catcheret, ha te irányítod a kimenő beállításokat, és hosztolt inbox API-t a felügyelet nélküli, végponttól végpontig tartó tesztekhez.

A manuális esetekhez nyiss meg egy ideiglenes bejövő dobozt, és kezdd azzal a regisztrációs folyamattal, amelyet legközelebb élesítesz. Az ideiglenes levelezésnek bőven van rengeteg gyakorlati felhasználása van a minőségellenőrzésen túl is.