Menu

Test af e-mail-validering: Sådan testes en applikations e-mail-funktionalitet

  • Vigtigste
  • Webtest
  • Test af e-mail-validering: Sådan testes en applikations e-mail-funktionalitet

email validation testing

Prøv Vores Instrument Til At Fjerne Problemer

Dagens tutorial handler om at teste e-mail-funktionalitet i enhver applikation.

I de fleste web- og mobilapplikationer betragtes validering af e-mail-funktionen som en af ​​de vigtigste dele af testningen for at sikre kvaliteten i e-mail-komponenten såvel som andre komponenter i systemet.

E-mails, der udløses under forskellige scenarier, anses for at være validerede ved at kontrollere for alle dens komponenter, der inkluderer en skabelon med e-mail, links / knapper i felterne E-mail, Fra, Til, Cc, Bcc, Vedhæftede filer, Indhold pr. E-mail-meddelelse osv.

Validering af e-mail

Hvad du lærer:

Hvorfor har vi brug for e-mail-test?

Hver komponent i systemet (web- / mobilapplikationer) kan have forskellige formål at sende e-mails. Integration mellem komponenten / komponenterne og e-mail spiller en vigtig rolle i at nå slutbrugeren med korrekte meddelelser. Enhver uagtsomhed, når vi validerer denne funktion, vil føre til misforståelser, dårligt navn hos kunderne, hacking osv.

For eksempel Forestil dig en situation, hvor en bruger har modtaget en e-mail for at nulstille adgangskoden. Hvad hvis linket / knappen til Nulstil adgangskode eller URL'en, der er angivet til kopiering af pasta i en browser, ikke fungerer? Den eneste mulighed, der er her, er at kontakte kundesupport, som kan blive en kedelig ting eller forestille sig en situation, hvor brugeren fortsat modtager en e-mail dagligt vedrørende forfaldsdato for betaling af regning fra 10-15 dage tidligere eller modtager en påmindelse efter forfaldsdatoen er bestået. - Irriterende er det ikke ??

Der er mange scenarier, hvor e-mails er blevet en integreret del af vores liv, da de er beregnet til at holde brugeren opdateret med præcise oplysninger.

Almindelige realtidsscenarier og valideringspunkter for e-mails

Valideringspunkter i test af e-mails varierer fra type til type og igen fra applikation til applikation. Normalt skal alle e-mails valideres til skabelonen (som inkluderer applikationslogo, applikationsnavn, adressering af brugeren, sidefodsindhold - ophavsret, kundesupportoplysninger), dato og tidsstempel for forskellige tidszoner.

Her vil vi diskutere nogle almindelige typer e-mails, som næsten alle er opmærksomme på (alle nedenstående valideringspunkter er den grundlæggende kontrol, som testeren skal udføre under test af e-mails til applikationen).

# 1) Aktiverings-e-mails

Når en bruger tilmelder sig en applikation for første gang, skal han / hun aktivere kontoen ved at klikke på aktiveringslinket sendt i e-mail. Dette bekræfter også, at brugerens angivne e-mail-adresse er gyldig og tilgængelig.

Valideringspunkter er som nedenfor:

  • Aktiveringsknap eller -knap - At klikke på den skal:
    • Tag brugeren til den respektive applikations side med brugerkonto logget ind
    • Brugerens e-mail-konto skal automatisk bekræftes, hvis applikationssiden nås med succes via e-mail
  • Varighed - Kontroller, hvor længe linket skal klikkes og verificeres.
    • Bekræft inden for den angivne varighed
    • Prøv at bekræfte, når varigheden er gået - Kontoen bør ikke aktiveres, og e-mailen skal forblive ubekræftet

Aktiverings-e-mail

# 2) Glemt adgangskode-e-mails

Når en bruger glemmer adgangskoden for at logge ind på applikationen, kan glemt adgangskodestrøm udføres for at modtage en e-mail med link for at nulstille adgangskoden (funktionen varierer fra applikation til applikation. Dette er den generelle).

Valideringspunkter er som nedenfor:

  • Nulstil adgangskode link:
    • Hvis du klikker på det, skal brugeren gå til den respektive applikations side for at nulstille adgangskoden
    • Nogle applikationer vil bede brugeren om at besvare sikkerhedsspørgsmål, før de viser siden med nulstillet adgangskode, og andre vil have sikkerhedsspørgsmål integreret med selve siden med nulstillet adgangskode, og andre vil slet ikke have denne funktion
    • Hvis brugeren nulstiller adgangskoden med succes, skal linket i den glemte adgangskode-e-mail, der er modtaget, deaktiveres og ikke-funktionelt
    • Hvis brugeren annullerer nulstillingen af ​​adgangskoden, skal linket i den glemte adgangskode-e-mail, der er modtaget, forblive aktiveret
  • Varighed - Kontroller, hvor længe der skal klikkes på linket for at nulstille adgangskoden
    • Klik på linket, og nulstil adgangskoden med succes inden for den angivne varighed
    • Prøv at klikke på linket, når varigheden er gået - Link skal deaktiveres og udløbe

Nulstil adgangskode E-mail

hvad er den bedste YouTube-videokonverter

# 3) Notifikationer om forfaldsdato

Dette er for at minde brugeren om den handling, der skal udføres inden for et bestemt antal dage. Dette er normalt regningsbetalingerne, der tager skridt til at afvente varer (eksempel: acceptere eller afvise invitationen til en begivenhed inden for et bestemt antal dage, indsende formularer osv.).

Valideringspunkter er som nedenfor:

  • Antal forfaldsdage / forfaldsdato
    • Hvis e-mail giver besked om et antal forfaldsdage, skal antallet være enten nul eller mere, nul dage betød at være den aktuelle forfaldsdato. Det skal ikke være i negative tal. Hvis e-mail underretter om en forfaldsdato (kalenderdato), skal datoen enten være den aktuelle eller fremtiden.
  • Type handling
    • Kontroller, hvilken type handling der kræves. Det skal meget tydeligt angive, hvilken slags handling brugeren skal foretage. Det være sig regningsbetalingen, indsendelser, feedback osv.

Forfaldsdato E-mail

Forfaldsdato E-mail-underretning

# 4) Forfaldne meddelelser

Dette er for at informere brugeren om forfaldsdato, der er gået. Dette er normalt for at informere brugeren om, at han / hun ikke har handlet med varerne inden forfaldsdatoen.

  • Antal forfaldne dage
    • Kontroller, at antallet af forsinkede dage enten skal være en eller flere. Det bør aldrig være nul eller negative tal
  • Frekvens
    • Få applikationer har mulighed for at tilpasse forfaldne e-mails, der skal sendes dagligt / ugentligt / månedligt, når forfaldsdatoen er gået, indtil brugeren gennemfører handlingen. Få ansøgninger vil have den standardmeddelelse, der skal sendes kun én gang, efter forfaldsdatoen er gået.

# 5) Abonnementer

Dette varierer efter brugerens krav. Brugeren kan vælge et af følgende daglige, ugentlige, to-månedlige eller månedlige abonnementer. Dette gælder normalt for nyhedsbreve, opdateringer, tilbud osv.

  • Frekvens
    • E-mails skal sendes pr. Brugervalg til et abonnement. Hvis dagligt, skal e-mail-abonnementet sendes kun en gang om dagen. Hvis ugentligt, så en gang om ugen. Og fortsætter ...
  • Links
    • Alle links i e-mailen skal navigere til applikationens respektive side. Hvis e-mailen er til opdateringer, skal linket omdirigere til den side, hvor opdateringerne skal vises. Hvis e-mailen er for tilbud, skal linket omdirigere til siden Tilbud i applikationen. Det afhænger af, hvilken type abonnement brugeren har valgt.

Abonnements-e-mail

Abonnements-e-mail-skærm

# 6) Formularer

E-mails her har til hensigt, at brugeren skal give feedback gennem formularer / link til formularer. Valideringspunkter er som nedenfor:

  • Links
    • Link i e-mailen skal omdirigere brugeren til ansøgningsformularens side i henhold til typen af ​​formularbruger, der skal indsende
    • Når det er sendt, skal du klikke på linket igen meddele brugeren, at formularen allerede er sendt. Det bør ikke tillade brugeren at sende formularen igen

Undersøgelses e-mail

Undersøgelsesside

youtube video converter til mp4 format

# 7) Bekræftelses-e-mails

E-mails her skal give brugeren besked om bekræftelsen af ​​den udførte handling. Dette er normalt reservationsbekræftelser, ordrebekræftelser, forespørgselsbekræftelser osv.

Valideringspunkter er som nedenfor:

  • Bekræftelsesoplysninger:
    • Ordrenummer / reservationsnummer skal være korrekt og matche det nummer, der vises i applikations-UI. Da det er identifikatoren til at spore ordrer / bookinger, skal den være unik (skal valideres i backend - DB) i hele applikationen. Ingen ordrer / booking skal have samme identifikator.
    • Sammen med nummeret skal det også valideres for typen af ​​ordre, brugeroplysninger, faktureringsadresse, leveringsadresse og pris. Alle oplysninger skal svare nøjagtigt til det, som brugeren har angivet i applikationsgrænsefladen.
  • Links:
    • Et link i e-mailen skal føre en bruger til ordrens detaljeringsside i applikations-UI. Der skal være nøjagtig matchning mellem oplysninger i e-mail og applikations-UI

Bekræftelses-e-mail

# 8) Chatudskrift

Her modtager en bruger hele chatudskriften som e-mail. Dette sker normalt, når Live Chat med kundesupport er afsluttet.

Valideringspunkter er som nedenfor

  • detaljer
    • Se efter navnet på den person, der leverede online support. Kontroller, at hele chatten er til stede i e-mailen med afsenderoplysninger for hver chatindtastning (Personnavn, dato og klokkeslæt, hvor chatbeskeden blev sendt osv.)

# 9) E-mails med vedhæftet fil

Brugeren modtager e-mails med vedhæftet fil. Vedhæftede filer kan være adgangskodebeskyttet / ubeskyttet. Dette er normalt udsagn fra økonomiske domæner, slutbrugerlicensaftale til reference, vilkår og betingelser for reference osv. Dette varierer igen fra applikation til applikation.

Valideringspunkter er som nedenfor:

  • Type af vedhæftet fil
    • Gyldige filtyper skal sendes som en vedhæftet fil. Alle vedhæftede filer, der åbnes, skal virusscannes, før de downloades / åbnes. Dette kan igen tilpasses på applikationsniveau i backend, ligesom virusscanning kun skal udføres ved download, kun når du åbner, både til download og åbning.
    • Adgangskodebeskyttede vedhæftede filer skal downloades uden at bede om adgangskoden. Men mens du åbner den enten fra e-mailen selv eller åbner den downloadede kopi, skal du altid bede om adgangskoden. Forkerte adgangskodeposter her vil være ubestemt, da den lokale kopi ikke kan spores online for at låse vedhæftet fil

E-mail med vedhæftet fil

Adgangskodebeskyttet vedhæftet fil

Typer af e-mails

E-mail-typen kan være enten HTML (farverig og attraktiv for brugerne, som interesserer brugeren for at læse e-mails fuldt ud) eller Almindelig tekst (bare en tekst).

HTML er mest foretrukne og indstilles normalt som standard i næsten alle applikationer i backend. Hvis det er nødvendigt, kan applikationer vælge at sende almindelig tekst-e-mails til brugerne, igen kræver dette ændringer i backend.

E-mail-udløserpunkter:

E-mails kan sendes enten straks eller som resumé / batch. Umiddelbare e-mails udløses af brugerens handling. Disse vil normalt være aktiverings-e-mails, nulstillede adgangskode-e-mails, chat-transskriptioner, bekræftelses-e-mails osv., Dvs., Sammendrag / batch-e-mails udløses baseret på indstillingerne i programmets backend.

E-mail-triggerpunkter vil blive defineret til at udløse på det specifikke tidspunkt ( for eksempel 3rddag i hver uge kl. 12.00). Disse vil normalt være udsagn fra finansielle domæner (kontoudtog), forfaldsdato for regninger, forfaldne meddelelser, abonnementer osv.,

Bouncebacks:

Det er et meget almindeligt scenario, at e-mails hopper, når de sendes til en ugyldig e-mail-adresse. Normalt er den e-mail-adresse, der er deaktiveret / ikke længere er i brug og slet ikke findes - de kandidater, der springer tilbage.

Serveren forsøger normalt et bestemt antal gange at sende e-mail til den tilsigtede adresse. Når den ikke når den tilsigtede e-mail-adresse, springes den tilbage og foretager en post på serveren for dens fiasko. Der vil være en anden server, der opretholder denne type aktiviteter og kaldes normalt bounce back-servere. Der kan være flere grunde til, at en e-mail mislykkes ved at nå sin bruger.

Nedenfor er nogle få andre punkter for fiasko:

hvilken enhed udfører oversættelse af netværksadresse (nat)?
  • E-mail-serveren er nede i lang tid
  • Algoritmen til at finde en kort rute for at nå ud til brugeren fungerer ikke korrekt og tager meget lang tid at nå ud til brugeren, på det tidspunkt ville det måske have krydset det angivne tidsrum for at nå ud til brugeren. Dette kaldes normalt øget antal humle
  • Brugerens e-mail-domæne er nede i lang tid
  • Brugerens konto til applikationen er ikke aktiveret til at modtage e-mails

Lokaliseringsomfang for e-mail-test

Når applikationen understøtter flere sprog, skal understøttelsen også omfatte e-mails.

Alle sendte e-mails skal være på brugerprofilsproget. Hvis en bruger har indstillet engelsk som profilsprog, skal alle de e-mails, der sendes til ham / hende, være på engelsk. Hvis brugerens profilsprog er fransk, skal alle de e-mails, der sendes til ham / hende, være på fransk. Brugerprofilsprog kan være engangsindstillinger eller kan ændres efter behov, hvilket afhænger af programmets indstillinger.

E-mail skal sendes på det sprog, som brugeren har på det tidspunkt, hvor den udløses.

Almindelige valideringspunkter til lokaliseringstest af e-mails er som nedenfor:

  • Emnelinje
  • E-mailens krop
    • Indhold - tekst i kroppen
    • Linknavn / knapnavn
    • Oplysninger om ophavsret
    • Oplysninger om kundesupport

Standard / Tilpasning af e-mails

E-mails kan tilpasses i backend.

For eksempel , få applikationer understøtter brugeren til at tilpasse e-mails, når de sendes. Brugeren kan her ændre emnelinjen og / eller brødteksten i e-mailen til sin bekvemme eller med det formål let at genkende. I dette tilfælde skal testteamet udføre grundig test, da chancerne for at trænge ind er store.

Test skal udføres for injektioner - send HTML-kode, Java-kode, SQL osv. Alt dette skulle mislykkes for at øge sikkerhedsniveauerne. Hvis applikationen ikke understøtter tilpasning af e-mails, følger alle e-mails, der sendes, standardemne / -tekst som angivet af en applikation.

Konklusion

Test af e-mails er en vigtig aktivitet, da de fleste af applikationens komponenter er integreret med denne funktionalitet.

Det skal være hele holdets support og indsats for fuldstændigt at teste e-mail-funktionaliteten i applikationen. Dette skal være godt planlagt meget inden den egentlige test starter og skal gå hånd i hånd, mens du tester hver komponent / tilhørende komponent.

E-mail-test skal have de separate testcases skrevet til hver e-mail-type, der dækker alle de aspekter, der skal testes. Dette skal udføres i alle typer test Regressionstest, Adhoc-test, Lokaliseringstest, UAT-test og Produktionstest.

Alt, hvad der går galt i e-mail i realtid, vil efterlade et dårligt indtryk på applikationen, kunder, og til sidst videreføres det til testere af denne applikation. Så e-mail-valideringer er meget vigtig og meget krævet aktivitet i softwaretest.

Om forfatteren: Dette indlæg er skrevet af STH-forfatter Nandini K. Hun har 7+ års erfaring med softwaretest hovedsageligt inden for webapplikationstest.

Fortæl os, hvis du har spørgsmål / forslag.

Anbefalet læsning

^