Meniu

Testare validare e-mail: Cum se testează funcționalitatea e-mailului unei aplicații

  • Principal
  • Testare Web
  • Testare validare e-mail: Cum se testează funcționalitatea e-mailului unei aplicații

email validation testing

Încercați Instrumentul Nostru Pentru Eliminarea Problemelor

Tutorialul de astăzi se referă la testarea funcționalității e-mail a oricărei aplicații.

În majoritatea aplicațiilor web și mobile, validarea funcției de e-mail este considerată una dintre cele mai importante părți ale testării, pentru a asigura calitatea componentelor de e-mail, precum și a altor componente ale sistemului.

E-mailurile declanșate în diferite scenarii sunt considerate a fi validate prin verificarea tuturor componentelor sale, care include un șablon de e-mail, linkuri / butoane în câmpurile E-mail, De la, Către, Cc, Cco, atașamente, Conținut conform notificării prin e-mail etc.

Validare e-mail

Ce veți învăța:

De ce avem nevoie de testarea prin e-mail?

Fiecare componentă din sistem (aplicații web / mobile) poate avea scopuri diferite de a trimite e-mailuri. Integrare între componentă (componente) iar e-mailul joacă un rol vital în a ajunge la utilizatorul final cu notificări adecvate. Orice neglijență atunci când validăm această caracteristică va duce la neînțelegeri, nume rău pentru clienți, hacking etc.

De exemplu , imaginați-vă o situație în care un utilizator a primit un e-mail pentru a reseta parola. Ce se întâmplă dacă linkul / butonul Resetare parolă sau adresa URL furnizată pentru a copia lipirea într-un browser nu funcționează? Singura opțiune rămasă aici este să contactați serviciul de asistență pentru clienți, care poate deveni un lucru obositor sau imagina o situație în care utilizatorul continuă să primească zilnic un e-mail referitor la data scadenței pentru plata facturilor cu 10-15 zile mai devreme sau să primească un memento după data scadenței a trecut. - Iritant nu-i așa ??

Există o mulțime de scenarii în care e-mailurile au devenit o parte integrantă a vieții noastre, deoarece sunt menite să mențină utilizatorul la curent cu informații precise.

Scenarii comune în timp real și puncte de validare pentru e-mailuri

Puncte de validare în testarea e-mailurilor variază de la tip la tip și din nou de la aplicație la aplicație. În mod obișnuit, toate e-mailurile trebuie validate pentru șablon (care include sigla aplicației, numele aplicației, adresarea utilizatorului, conținutul subsolului - drepturi de autor, detalii de asistență pentru clienți), data și marcajul de timp pentru diferite fusuri orare.

Aici vom discuta despre câteva tipuri obișnuite de e-mail pe care aproape toată lumea le cunoaște (toate punctele de validare date mai jos sunt verificarea de bază pe care testatorul trebuie să o efectueze în timp ce testează e-mailurile aplicației).

# 1) E-mailuri de activare

Când un utilizator se înregistrează la o aplicație pentru prima dată, el / ea trebuie să activeze contul făcând clic pe linkul de activare trimis în e-mail. Aceasta verifică, de asemenea, adresa de e-mail dată a utilizatorului este validă și accesibilă.

Punctele de validare sunt următoarele:

  • Link de activare sau buton - Faceți clic pe acesta ar trebui:
    • Duceți utilizatorul la pagina aplicației respective cu contul de utilizator conectat
    • Contul de e-mail al utilizatorului ar trebui să fie verificat automat dacă pagina aplicației este accesată cu succes prin e-mail
  • Durata - Verificați durata în care trebuie să faceți clic și să verificați linkul.
    • Verificați în perioada specificată
    • Încercați să verificați după ce a trecut durata - Contul nu ar trebui să fie activat și e-mailul să rămână neverificat

E-mail de activare

# 2) E-mailuri uitate de parolă

Atunci când un utilizator uită parola pentru a se conecta la aplicație, fluxul de parole uitate poate fi efectuat pentru a primi un e-mail cu link pentru a reseta parola (caracteristica variază de la aplicație la aplicație. Aceasta este cea generală).

Punctele de validare sunt următoarele:

  • Resetați linkul parolei:
    • Dacă faceți clic pe acesta, utilizatorul va ajunge la pagina aplicației respective pentru a reseta parola
    • Unele aplicații îi vor cere utilizatorului să răspundă la întrebarea de securitate înainte de a afișa pagina de resetare a parolei, iar altele vor avea întrebarea de securitate integrată cu pagina de resetare a parolei, iar unele nu vor avea deloc această caracteristică
    • Dacă utilizatorul resetează parola cu succes, linkul din e-mailul de parolă uitat care a fost primit ar trebui să fie dezactivat și nefuncțional
    • Dacă utilizatorul anulează fluxul de resetare a parolei, linkul din e-mailul de parolă uitat care a fost primit ar trebui să rămână activat
  • Durata - Verificați durata în care trebuie să faceți clic pe link pentru resetarea parolei
    • Faceți clic pe link și resetați parola cu succes în perioada specificată
    • Încercați să faceți clic pe link după ce a trecut durata - Linkul ar trebui să fie dezactivat și expirat

Resetați parola de e-mail

tehnici de eliberare a cerințelor în ingineria software

# 3) Notificări la scadență

Aceasta este pentru a reaminti utilizatorului acțiunea pe care trebuie să o întreprindă într-un anumit număr de zile. Aceasta este de obicei plățile facturilor, luând măsuri cu privire la articolele în așteptare (exemplu: acceptarea sau respingerea invitației la un anumit eveniment într-un anumit număr de zile, trimiterea formularelor etc.).

Punctele de validare sunt următoarele:

  • Numărul de zile scadente / Data scadenței
    • Dacă prin e-mail se anunță un număr de zile scadente, atunci numărul ar trebui să fie zero sau mai mult, zero zile menite să fie data curentă. Nu ar trebui să fie în număr negativ. Dacă prin e-mail se anunță o dată de scadență (data calendaristică), atunci data ar trebui să fie fie cea actuală, fie cea viitoare.
  • Tipul acțiunii
    • Verificați care este tipul de acțiune necesar. Ar trebui să precizeze foarte clar ce fel de acțiune trebuie să întreprindă acel utilizator. Fie că este vorba de plata facturilor, trimiteri, feedback-uri etc.

E-mail la scadență

Notificare prin e-mail la scadență

# 4) Notificări restante

Aceasta este pentru a informa utilizatorul despre data scadentă a trecut. Aceasta este de obicei pentru a informa utilizatorul că nu a luat măsuri cu privire la articole în termenul limită.

bash compara fișiere linie cu linie
  • Numărul de zile restante
    • Verificați dacă numărul de zile restante trebuie să fie unul sau mai multe. Nu ar trebui să fie niciodată zero sau numere negative
  • Frecvență
    • Puține aplicații vor avea posibilitatea de a personaliza e-mailurile restante care urmează să fie trimise zilnic / săptămânal / lunar, odată cu scadența, până când utilizatorul finalizează acțiunea. Puține aplicații vor avea notificarea standard care urmează să fie trimisă o singură dată numai după ce a trecut data scadenței.

# 5) Abonamente

Acest lucru variază în funcție de cerințele utilizatorului. Utilizatorul poate selecta unul dintre următoarele abonamente zilnice, săptămânale, bilunare sau lunare. Acest lucru va fi de obicei pentru buletine informative, actualizări, oferte etc.

  • Frecvență
    • E-mailurile trebuie trimise conform alegerii utilizatorului pentru un abonament. Dacă este zilnic, atunci e-mailul cu abonament trebuie trimis o dată pe zi. Dacă este săptămânal, atunci o dată pe săptămână. Și continuă ...
  • Link-uri
    • Orice linkuri din e-mail ar trebui să navigheze la pagina respectivă a aplicației. Dacă e-mailul este destinat actualizărilor, atunci link-ul ar trebui să redirecționeze către pagina în care trebuie să fie afișate actualizările. Dacă e-mailul este pentru oferte, atunci linkul ar trebui să redirecționeze către pagina Oferte a aplicației. Depinde de tipul de abonament selectat de utilizator.

E-mail de abonament

Ecran de e-mail de abonament

# 6) Formulare

E-mailurile de aici intenționează utilizatorul să ofere feedback prin intermediul formularelor / link către formulare. Punctele de validare sunt următoarele:

  • Link-uri
    • Linkul din e-mail ar trebui să redirecționeze utilizatorul către pagina de trimitere a formularului a cererii conform tipului de formular pe care trebuie să îl trimită utilizatorul
    • Odată trimis, făcând clic din nou pe link, ar trebui să se anunțe utilizatorul că formularul a fost deja trimis. Nu ar trebui să permită utilizatorului să trimită din nou formularul

E-mail de sondaj

Pagina sondajului

# 7) E-mailuri de confirmare

Aici e-mailurile sunt destinate notificării utilizatorului cu privire la confirmarea acțiunii întreprinse. Aceasta este de obicei confirmările rezervării, confirmările comenzii, confirmările interogării etc.

Punctele de validare sunt următoarele:

  • Detalii confirmare:
    • Numărul comenzii / numărul rezervării trebuie să fie corecte și să se potrivească cu numărul afișat în interfața de utilizare a aplicației. Deoarece este identificatorul pentru a urmări comenzile / rezervările, acesta ar trebui să fie unic (pentru a fi validat în backend - DB) pe tot parcursul aplicației. Nicio comandă / rezervare nu trebuie să aibă același identificator.
    • Împreună cu numărul, acesta ar trebui validat și pentru tipul comenzii, informațiile utilizatorului, adresa de facturare, adresa de expediere și prețul. Toate informațiile ar trebui să fie exact similare cu cele furnizate de utilizator în interfața de utilizare a aplicației.
  • Link-uri:
    • Un link din e-mail ar trebui să ducă un utilizator la pagina de detalii a comenzii din interfața de utilizare a aplicației. Ar trebui să existe o potrivire exactă între informațiile din e-mail și interfața de utilizare a aplicației

E-mail de confirmare

# 8) Transcriere de chat

Aici, un utilizator primește întreaga transcriere a chat-ului ca e-mail. Acest lucru se întâmplă, de obicei, odată ce chatul live cu asistența pentru clienți este încheiat.

Punctele de validare sunt cele de mai jos

  • Detalii
    • Verificați numele persoanei care a oferit asistență online. Verificați dacă întregul chat este prezent în e-mail cu detaliile expeditorului pentru fiecare intrare de chat (numele persoanei, data și ora la care a fost trimis mesajul de chat etc.)

# 9) E-mailuri cu atașament

Utilizatorul primește e-mailuri cu atașament. Atașamentele pot fi protejate / neprotejate prin parolă. Acestea sunt de obicei declarațiile din domeniile financiare, Acordul de licență pentru utilizatorul final pentru referință, Termenii și condițiile pentru referință etc., aceasta variază din nou de la o aplicație la alta.

Punctele de validare sunt următoarele:

  • Tipul atașamentului
    • Tipurile de fișiere valide trebuie trimise ca atașament. Toate atașamentele deschise ar trebui scanate antivirus înainte de descărcare / deschidere. Acest lucru poate fi personalizat din nou la nivel de aplicație în backend, cum ar fi, scanarea antivirus pentru a fi efectuată numai la descărcare, numai la deschidere, atât pentru descărcare, cât și pentru deschidere.
    • Atașamentele protejate prin parolă trebuie descărcate fără a solicita parola. Dar, în timp ce îl deschideți fie din e-mail sau deschideți copia descărcată, ar trebui să solicitați întotdeauna parola. Intrările de parolă incorecte aici vor fi nedeterminate, deoarece copia locală nu poate fi urmărită online pentru a bloca atașamentul

E-mail cu atașament

Atașament protejat prin parolă

Tipuri de e-mailuri

Tipul de e-mail poate fi HTML (colorat și atractiv pentru utilizatori, care îi interesează pe utilizatori să citească complet e-mailurile) sau text simplu (doar un text).

HTML este cel mai preferat și de obicei setat ca implicit în aproape toate aplicațiile din backend. Dacă este necesar, aplicațiile pot opta pentru a trimite e-mailuri text simplu utilizatorilor, iar acest lucru necesită modificări în backend.

Puncte de declanșare prin e-mail:

E-mailurile pot fi trimise fie imediat, fie ca sumar / lot. E-mailurile imediate sunt declanșate de acțiunea utilizatorului. Acestea vor fi de obicei e-mailuri de activare, e-mailuri de resetare a parolei, transcrieri de chat, e-mailuri de confirmare etc., adică e-mailurile sumare / lot sunt declanșate pe baza setărilor din backend-ul aplicației.

Punctele de declanșare a e-mailului vor fi definite pentru a se declanșa la momentul specific ( de exemplu 3rdzi din fiecare săptămână la 12:00 AM). Acestea vor fi de obicei declarațiile din domeniile financiare (extrase bancare), notificarea la scadență a facturilor, notificările restante, abonamentele etc.,

Bouncebacks:

Este un scenariu foarte obișnuit ca e-mailurile sări atunci când sunt trimise la o adresă de e-mail nevalidă. De obicei, adresa de e-mail care este dezactivată / nu mai este utilizată și nu există deloc - sunt candidații care revin.

Serverul încearcă, de obicei, de un număr specificat de ori să trimită e-mailuri la adresa dorită. Când nu ajunge la adresa de e-mail intenționată, atunci va fi recuperată și va face o intrare în server pentru eșecul acesteia. Va exista un server diferit pentru a menține acest tip de activități și sunt denumite de obicei servere de revenire. Ar putea exista mai multe motive pentru care un e-mail să eșueze prin contactarea utilizatorului său.

Mai jos sunt câteva alte puncte pentru eșec:

  • Serverul de e-mail este oprit pentru o lungă perioadă de timp
  • Algoritmul pentru a găsi un traseu scurt pentru a ajunge la utilizator nu funcționează corect și durează foarte mult pentru a ajunge la utilizator, până la acel moment poate că ar fi trecut timpul stabilit pentru a ajunge la utilizator. Aceasta se numește de obicei un număr crescut de hamei
  • Domeniul de e-mail al utilizatorului este defect mult timp
  • Contul utilizatorului pentru aplicație nu este activat pentru a primi e-mailuri

Localizare Domeniu de aplicare pentru testarea e-mailurilor

Când aplicația acceptă mai multe limbi, atunci suportul ar trebui să se extindă și pentru e-mailuri.

Toate e-mailurile trimise trebuie să fie în limba profilului utilizatorului. Dacă un utilizator a setat limba engleză ca limbă de profil, atunci toate e-mailurile care i-au fost trimise ar trebui să fie în engleză. Dacă limba profilului utilizatorului este franceza, toate e-mailurile trimise către acesta ar trebui să fie în franceză. Limba profilului utilizatorului poate fi setată o singură dată sau poate fi modificată după cum este necesar, ceea ce depinde de setările aplicației.

E-mailul trebuie trimis în limba pe care o are utilizatorul în momentul declanșării.

Punctele comune de validare pentru testarea localizării e-mailurilor sunt următoarele:

  • Linia de subiect
  • Corpul e-mailului
    • Conținut - textul corpului
    • Numele linkului / numele butonului
    • Informații privind drepturile de autor
    • Detalii de asistență pentru clienți

Standard / Personalizare e-mailuri

E-mailurile pot fi personalizate pe backend.

De exemplu , puține aplicații acceptă utilizatorul să personalizeze e-mailurile atunci când sunt trimise. Utilizatorul poate schimba aici subiectul și / sau corpul e-mailului în locul său convenabil sau în scopul de a recunoaște cu ușurință. În acest caz, echipa de testare trebuie să facă teste amănunțite, deoarece șansele de a pătrunde sunt mari.

Testarea trebuie efectuată pentru injecții - trimiteți cod HTML, cod Java, SQL etc. Toate acestea ar trebui să eșueze pentru a crește nivelurile de securitate. Dacă aplicația nu acceptă personalizarea e-mailurilor, atunci toate e-mailurile trimise vor urma subiectul / corpul standard, așa cum este stabilit de o aplicație.

Concluzie

Testarea e-mailurilor este o activitate importantă, deoarece majoritatea componentelor aplicației sunt integrate cu această funcționalitate.

site-uri web care vă permit să descărcați videoclipuri YouTube

Ar trebui să fie sprijinul și efortul întregii echipe să testeze complet funcționalitatea e-mail a aplicației. Acest lucru ar trebui să fie bine planificat mult înainte de începerea testării reale și ar trebui să meargă mână în mână în timp ce se testează fiecare componentă / componentă asociată.

Testarea prin e-mail ar trebui să conțină cazurile de testare separate scrise pentru fiecare tip de e-mail care să acopere toate aspectele de testat. Acest lucru ar trebui efectuat în toate tipurile de testare Testarea regresiei, testarea adhoc, testarea localizării, testarea UAT și testarea producției.

Orice lucru care greșește în e-mail în timp real, va lăsa o impresie proastă asupra aplicației, clienților și, în cele din urmă, va fi transmisă testerilor acelei aplicații. Deci, validările prin e-mail sunt o activitate foarte importantă și foarte necesară în testarea software-ului.

Despre autor: Această postare este scrisă de autorul STH Nandini K. Are o experiență de peste 7 ani în testarea software, în principal în testarea aplicațiilor web.

Spuneți-ne dacă aveți întrebări / sugestii.

Lectură recomandată

^