La nefidinda versio de retpoŝta testado estas mallonga: krei adreson, dormi kvin sekundojn, legi la unuan mesaĝon, kaj esperi ke ĝi apartenas al ĉi tiu rulado.
La fidinda versio ankoraŭ estas simpla, sed ĝi traktas liveron kiel asinkrona. Ĝi kreas unikajn adreson, registras komencan tempon, enketas ene de limtempo, kongruas la celitan mesaĝon, validigas la produktan agon, kaj raportas sufiĉan kuntekston kiam io malsukcesas.
Tenadu la API-ŝlosilon for de la URL
Sendu la GPTMail-ŝlosilon en la kapo X-API-Key. Ne metu ĝin en la demando‑parametrojn ?api_key=. URL‑oj ofte estas konservitaj en retumila historio, aliraj protokoloj, monitoraj sistemoj, kaj referencaj datumoj.
X-API-Key: YOUR_API_KEYKonservu la ŝlosilon en via CI sekreta administranto kaj masku ĝin en protokoloj. Publika ĉiutaga ŝlosilo estas oportuna por esplorado; kontrolitaj aŭtomataj serioj devus uzi ŝlosilon kies kvoto kaj uzo estas spureblaj.
La aktualaj finpunktoj kaj respondo-ekzemploj estas prizorgataj sur la GPTMail API-dokumenta paĝo.
Unu adreso por ĉiu rulado
Generu novan adreson por ĉiu sendepende plenumebla testado. Ne derivu korektecon de enirkesto dividita de tuta testaro.
Registru la adreson, scenarion-ID, medio, kaj testan komencan tempon. Tiuj valoroj permesas al vi malakcepti malnovajn mesaĝojn kaj diagnozi koliziojn sen registri mesaĝajn sekretojn.
Enketu kontraŭ limtempo, ne kontraŭ fiksita dormo
La tempo de retpoŝta livero varias. Fiksita kvinsekunda dormo estas malŝpara kiam livero estas rapida kaj nefidinda kiam ĝi estas malrapida.
Uzu limigitan buklon:
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)La limtempo apartenas al la testkontrakto. Pasvort-reagorda fluo povas postuli alian limon ol amasletera novaĵletero-antaŭrigardo. Tenadu la limon eksplicite por ke malrapida dependo ne silente etendu la tutan CI-taskon.
Kongruu precize
“Unua mesaĝo en la enirkesto” ne estas utila elektilo. Kongruu plurajn signalojn:
- ricevanto egalas al la adreso kreita por ĉi tiu rulado;
- kreotempo estas post la ekiga tempo;
- sendanto apartenas al la atendita servo;
- temo aŭ mesaĝa tipo kongruas kun la fluo;
- la mesaĝo-ID ankoraŭ ne estas konsumita.
Kiam la sendanto povas elsendi plurajn kodojn, elektu la plej novan kongruan mesaĝon. Konservu ĝian ID en la testa eligo por ke provoj ne reuzas ĝin accidente.
Legu nur post listo-kongruo
Listigo de enirkesto devus esti la malmultekosta malkovra paŝo. Elŝutu la plenan mesaĝon nur por la elektita kandidato. Ĉi tio reduktas nenecesan laboron kaj evitas analizi nesamajn reklamajn retpoŝtojn.
Validigu la komercan rezulton, ne nur la ĉeeston de ses-cifera ĉeno. Sendu la kodon aŭ malfermu la atenditan ligilon, poste asertu ke la konto atingas la ĝustan staton.
Traktu rapidlimitojn kiel signalon
Se la API resendas kvotan aŭ rapidlimitan respondon, haltigu la aktualan provon kaj elmontru la restarigan informon. Agresivaj provoj transformas klaran kapacitan signalon en bruon kaj povas prokrasti nesamajn testojn.
Limigu konkurencon ĉe la testkuranto, precipe kiam serio kreas multajn adresojn samtempe. Eta laborista grupeto estas pli facila por senerarigi ol centoj da samtempaj enketaj bukloj.
Purigu sen kaŝi malsukcesojn
Purigado devus ruli post kiam pruvoj estas kaptitaj. En sukceso, forigu mesaĝojn aŭ lasu ke mallonga reteno prizorgas ilin. En malsukceso, retenu la adreson kaj mesaĝo-ID en protektitaj CI-artikoloj sufiĉe longe por esplorado, poste forigu ilin.
Neniam presu kontrolkodojn, privatajn ligilojn, aŭ kompletajn HTML‑korpojn en publikaj konstruaj protokoloj.
Faru provoj idempotentaj
Reprovu la teston kiel nova rulado kun nova adreso. Ne supozu ke ripetado de la sama peto kontraŭ la sama konto kaj enirkesto komenciĝas de pura stato. La sendanto povas invalidigi malnovajn kodojn, limigi ripetajn petojn, aŭ rifuzi duplikatajn invitojn.
Se retkonekta peto eltempiĝas, distinguu “neniu respondo ricevita” de “operacio ne okazis”. Kontrolu la observatan staton antaŭ ol fari detruantan reprovon.
Raportu la punkton de malsukceso
Utila aŭtomata malsukceso identigas unu el ĉi tiuj stadioj:
- adreso-generado malsukcesis;
- produkt-agado malsukcesis antaŭ retpoŝta enmetado;
- neniu kongrua mesaĝo alvenis antaŭ la limtempo;
- mesaĝo alvenis sed enhavo ne kongruis;
- kontrol-agado malsukcesis;
- purigado malsukcesis.
Tiu klasifiko transformas intermitan “retpoŝta testado malsukcesis” en laboro kiun teamo povas posedigi.
Por la pli granda testmatrico, legu Realan Retpoŝtan Testplanon. Por livera diagnozo, uzu Kontrolretpoŝto Ne Alvenas: Trovu la Rompitan Paŝon.