Uzticama pagaidu pastkastes API automatizācija

Neuzticamā e-pasta testa versija ir īsa: izveidot adresi, gaidīt piecas sekundes, nolasīt pirmo ziņojumu un cerēt, ka tas pieder šim izpildījumam.

Uzticamā versija joprojām ir vienkārša, bet tā uzskata piegādi par asinhronu. Tā izveido unikālu adresi, reģistrē sākuma laiku, veic aptauju līdz termiņam, saskaņo paredzēto ziņojumu, pārbauda produkta darbību un sniedz pietiekamu kontekstu, kad kaut kas neizdodas.

Turiet API atslēgu ārpus URL

Nosūtiet GPTMail atslēgu X-API-Key galvenē. Neievietojiet to ?api_key= vaicājuma parametru. URL bieži tiek saglabāti pārlūkprogrammas vēsturē, piekļuves žurnālos, uzraudzības sistēmās un atsauču datos.

X-API-Key: YOUR_API_KEY

Saglabājiet atslēgu savā CI slepeno vadības sistēmā un maskējiet to žurnālos. Publiska ikdienas atslēga ir ērta izpētei; kontrolētām automatizētām grupām vajadzētu izmantot atslēgu, kuras kvotu un lietojumu varat izsekot.

Pašreizējie galapunkti un atbildes piemēri tiek uzturēti GPTMail API dokumentācijas lapā.

Viena adrese uz izpildījumu

Ģenerējiet jaunu adresi katram neatkarīgi izpildāmam testam. Neizvērtējiet pareizību, balstoties uz pastkasti, ko koplieto visa testu grupa.

Reģistrējiet adresi, scenārija ID, vidi un testa sākuma laiku. Šīs vērtības ļauj noraidīt novecojušus ziņojumus un diagnosticēt sadursmes, neierakstot ziņojumu noslēpumus.

Veiciet aptauju līdz termiņam, nevis fiksētu gaidīšanu

E-pasta piegādes laiks mainās. Fiksēta piecu sekunžu gaidīšana ir gan izšķērdīga, ja piegāde ir ātra, gan neuzticama, ja tā ir lēna.

Izmantojiet ierobežotu ciklu:

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)

Termiņš pieder testa līgumam. Paroles atiestatīšanas plūsmai var būt vajadzīgs citādāks limits nekā masveida jaunumu izsūtīšanas priekšskatījumam. Saglabājiet limitu skaidru, lai lēna atkarība neizstieptu klusi visu CI uzdevumu.

Precīzi saskaņojiet

“Pirmais ziņojums pastkastē” nav noderīgs selektors. Saskaņojiet vairākus signālus:

• saņēmējs ir vienāds ar šim izpildījumam izveidoto adresi;
• izveides laiks ir vēlāk nekā izraisīšanas laiks;
• nosūtītājs pieder gaidītajam pakalpojumam;
• temats vai ziņojuma veids atbilst plūsmai;
• ziņojuma ID vēl nav izmantots.

Ja nosūtītājs var izsniegt vairākus kodus, izvēlieties jaunāko atbilstošo ziņojumu. Saglabājiet tā ID testa izvadē, lai atkārtojumi nejauši to neizmantotu.

Lasiet tikai pēc saraksta saskaņojuma

Pastkastes saraksts jābūt lētiem atklāšanas solim. Pilnu ziņojumu ielādējiet tikai izvēlētajam kandidātam. Tas samazina nevajadzīgu darbu un novērš neattiecīgu reklāmas e-pastu parsēšanu.

Pārbaudiet biznesa rezultātu, ne tikai sešu ciparu virknes klātbūtni. Iesniedziet kodu vai atveriet gaidāmo saiti, pēc tam pārliecinieties, ka konts sasniedz pareizo stāvokli.

Apstrādājiet ierobežojumu signālus kā signālus

Ja API atgriež kvotas vai ierobežojuma atbildi, pārtrauciet pašreizējo mēģinājumu un parādiet atiestatīšanas informāciju. Aggresīvi atkārtojumi pārvērš skaidru kapacitātes signālu troksnī un var kavēt neatbilstošus testus.

Ierobežojiet vienlaicīgo izpildes skaitu testu izpildītājā, īpaši, ja grupa vienlaicīgi izveido daudz adreses. Mazs darbinieku pulks ir vieglāk atkļūdot nekā simti vienlaicīgu aptaujas ciklu.

Tīrīšana, neatklājot kļūdas

Tīrīšana jāveic pēc pierādījumu savākšanas. Veiksmīgi noņemiet ziņojumus vai ļaujiet īsai saglabāšanas periodam tos apstrādāt. Neveiksmīgi saglabājiet adresi un ziņojuma ID aizsargātos CI artefaktos pietiekami ilgi, lai veiktu izmeklēšanu, pēc tam izdzēsiet tos.

Nekad neizvadiet verifikācijas kodus, privātas saites vai pilnus HTML saturus publiskajos būvēšanas žurnālos.

Padariet atkārtotus mēģinājumus idempotentus

Atkārtojiet testu kā jaunu izpildījumu ar jaunu adresi. Nepieņemiet, ka atkārtota viena un tā paša pieprasījuma izpilde pret to pašu kontu un pastkasti sākas no tīras stāvokļa. Nosūtītājs var anulēt vecos kodus, ierobežot atkārtotus pieprasījumus vai noraidīt dublētas ielūgumus.

Ja tīkla pieprasījums noiet pāri, atšķiriet “nav saņemta atbilde” no “darbība nenotika”. Pārbaudiet novērojamo stāvokli pirms izpildīt destruktīvu atkārtotu mēģinājumu.

Ziņojiet par neveiksmes punktu

Noderīga automatizācijas kļūda identificē vienu no šīm stadijām:

1. adrese ģenerēšana neizdevās;
2. produkta darbība neizdevās pirms e-pasta pievienošanas rindai;
3. neviens atbilstošs ziņojums neieradās pirms termiņa;
4. ziņojums ieradās, bet saturs neatbija;
5. verifikācijas darbība neizdevās;
6. tīrīšana neizdevās.

Šī klasifikācija pārvērš periodisku “e-pasta tests neizdevās” par uzdevumu, ko komanda var pārņemt.

Lielākam testu matricam izlasiet Reālu e-pasta testēšanas plānu. Piegādes diagnostikai izmantojiet Verifikācijas e-pasts neierodas: Atrodiet bojāto soli.