Meny

Test av e-postvalidering: Hur man testar e-postfunktionaliteten för en applikation

  • Huvud
  • Webbtestning
  • Test av e-postvalidering: Hur man testar e-postfunktionaliteten för en applikation

email validation testing

Prova Vårt Instrument För Att Eliminera Problem

Dagens handledning handlar om att testa e-postfunktionaliteten i alla applikationer.

I de flesta webb- och mobilapplikationer anses validering av e-postfunktionen vara en av de viktigaste delarna av testning för att säkerställa kvaliteten i e-postkomponenten liksom andra komponenter i systemet.

E-postmeddelanden som utlöses under olika scenarier anses vara validerade genom att kontrollera alla dess komponenter som innehåller en mall med e-post, länkar / knappar i fältet E-post, Från, Till, Cc, Bcc, bilagor, innehåll enligt e-postmeddelande etc.

E-postvalidering

Vad du kommer att lära dig:

Varför behöver vi e-posttestning?

Varje komponent i systemet (webb- / mobilapplikationer) kan ha olika syften att skicka e-post. Integration mellan komponenten / komponenterna och e-post spelar en viktig roll för att nå slutanvändaren med korrekta meddelanden. All vårdslöshet när vi validerar den här funktionen kommer att leda till missförstånd, dåligt namn hos kunderna, hacking etc.

Till exempel , föreställ dig en situation där en användare har fått ett e-postmeddelande för att återställa lösenordet. Vad händer om länken / knappen Återställ lösenord eller URL-adressen för att kopiera klistra in i en webbläsare inte fungerar? Det enda alternativet kvar här är att kontakta kundsupport, som kan bli en tråkig sak eller föreställa sig en situation där användaren fortsätter att få ett e-postmeddelande dagligen angående förfallodag för fakturering från 10-15 dagar tidigare eller får en påminnelse efter förfallodagen. passerade. - Irriterande är det inte ??

Det finns många scenarier där e-post har blivit en integrerad del av vårt liv eftersom de är avsedda att hålla användaren uppdaterad med exakt information.

Vanliga realtidsscenarier och valideringspunkter för e-post

Valideringspunkter vid testning av e-postmeddelanden varierar från typ till typ och igen från applikation till applikation. Vanligtvis ska alla e-postmeddelanden valideras för mallen (som inkluderar applikationslogotyp, applikationsnamn, adressering av användaren, sidfotsinnehåll - copyright, kundsupportinformation), datum och tidsstämpel för olika tidszoner.

Här kommer vi att diskutera några vanliga typer av e-post som nästan alla är medvetna om (alla valideringspunkter som anges nedan är den grundläggande kontrollen som testaren måste utföra när man testar e-postmeddelanden till applikationen).

# 1) Aktiveringsmeddelanden

När en användare registrerar sig för en applikation för första gången måste han / hon aktivera kontot genom att klicka på aktiveringslänken som skickas i e-post. Detta verifierar också att användarens angivna e-postadress är giltig och tillgänglig.

Valideringspunkterna är som följer:

  • Aktiveringslänk eller knapp - Om du klickar på den ska:
    • Ta användaren till respektive applikations sida med inloggat användarkonto
    • Användarens e-postkonto ska verifieras automatiskt om applikationssidan nås framgångsrikt via e-post
  • Varaktighet - Kontrollera hur länge länken måste klickas och verifieras.
    • Verifiera inom den angivna varaktigheten
    • Försök att verifiera efter att varaktigheten har passerat - Kontot ska inte aktiveras och e-postmeddelandet ska förbli obekräftat

Aktiverings-e-post

# 2) Glömt lösenordsmeddelanden

När en användare glömmer lösenordet för att logga in på applikationen kan glömt lösenordsflöde utföras för att få ett e-postmeddelande med länk för att återställa lösenordet (funktionen varierar från applikation till applikation. Detta är det allmänna).

Valideringspunkterna är som följer:

  • Återställ lösenordslänk:
    • Om du klickar på det bör användaren gå till respektive applikations sida för att återställa lösenordet
    • Vissa applikationer kommer att be användaren att svara på säkerhetsfrågan innan sidan för återställning av lösenord visas, och vissa kommer att ha säkerhetsfråga integrerad med sidan för återställning av lösenord, och vissa har inte den här funktionen alls
    • Om användaren återställer lösenordet framgångsrikt bör länken i det glömda lösenordets e-postmeddelande tas emot och deaktiveras och inte fungerar
    • Om användaren avbryter återställningen av lösenordet, ska länken i det glömda lösenordets e-postmeddelande förbli aktiverad
  • Varaktighet - Kontrollera hur länge länken måste klickas för att återställa lösenordet
    • Klicka på länken och återställ lösenordet inom angiven varaktighet
    • Försök att klicka på länken efter varaktigheten har gått - Länken ska inaktiveras och upphöra att gälla

Återställ lösenordets e-post

bästa gratis borttagning av virus och skadlig kod

# 3) Meddelanden om förfallodatum

Detta för att påminna användaren om den åtgärd som ska vidtas under ett visst antal dagar. Detta är vanligtvis räkningen betalningar, vidta åtgärder på väntande objekt (exempel: acceptera eller avvisa inbjudan till någon händelse under ett visst antal dagar, skicka formulär, etc ..).

Valideringspunkterna är som följer:

  • Antal förfallodagar / förfallodatum
    • Om e-post meddelar om ett antal förfallodagar ska numret vara antingen noll eller mer, noll dagar menade att vara det aktuella förfallodagen. Det borde inte vara i negativa siffror. Om e-post meddelar ett förfallodatum (kalenderdatum) ska datumet vara antingen det aktuella eller framtiden.
  • Typ av åtgärd
    • Kontrollera vilken typ av åtgärd som krävs. Det bör mycket tydligt ange vilken typ av åtgärder användaren måste vidta. Vare sig det är räkningen, inlämningar, återkopplingar etc.

Förfallodatum E-post

E-postmeddelande om förfallodatum

# 4) Försenade meddelanden

Detta för att informera användaren om förfallodatum. Detta är vanligtvis för att informera användaren om att han / hon inte har vidtagit åtgärder på föremålen inom förfallodagen.

  • Antal försenade dagar
    • Kontrollera att antalet försenade dagar bör vara antingen en eller flera. Det ska aldrig vara noll eller negativa siffror
  • Frekvens
    • Få applikationer har möjlighet att anpassa försenade e-postmeddelanden som ska skickas dagligen / vecka / månad, när förfallodagen har passerat tills användaren slutför åtgärden. Få ansökningar kommer att ha standardmeddelandet som ska skickas bara en gång efter förfallodagen.

# 5) Prenumerationer

Detta varierar beroende på användarkraven. Användaren kan välja ett av följande prenumerationer per dag, vecka, två månader eller månad. Detta gäller vanligtvis för nyhetsbrev, uppdateringar, erbjudanden etc.

  • Frekvens
    • E-postmeddelanden ska skickas enligt användarval för en prenumeration. Om dagligen ska prenumerations-e-post skickas en gång om dagen. Om varje vecka, då en gång i veckan. Och fortsätter ...
  • Länkar
    • Alla länkar i e-postmeddelandet ska navigera till programmets respektive sida. Om e-postmeddelandet är för uppdateringar ska länken omdirigera till sidan där uppdateringarna är avsedda att visas. Om e-postmeddelandet gäller erbjudanden ska länken omdirigeras till applikationssidan. Det beror på vilken typ av prenumeration som användaren har valt.

Prenumerations-e-post

E-postskärm för prenumeration

# 6) Blanketter

E-post här avser användaren att ge feedback via formulär / länk till formulär. Valideringspunkterna är som följer:

  • Länkar
    • Länk i e-postmeddelandet ska omdirigera användaren till ansökningsformulärets sida enligt typ av formulär som användaren måste skicka
    • När du väl har skickat in klickar du på länken igen för att meddela användaren att formuläret redan har skickats. Det bör inte tillåta användaren att skicka in formuläret på nytt

Undersökningens e-post

Undersökningssida

# 7) Bekräftelsemeddelanden

E-postmeddelanden här är för att meddela användaren om bekräftelsen av den vidtagna åtgärden. Detta är vanligtvis bokningsbekräftelser, orderbekräftelser, förfrågningsbekräftelser osv.

Valideringspunkterna är som följer:

.net intervjufråga och svar
  • Bekräftelsedetaljer:
    • Ordernummer / bokningsnummer ska vara korrekt och matcha numret som visas i applikationsgränssnittet. Eftersom det är identifieraren att spåra beställningar / bokningar bör den vara unik (för att valideras i backend - DB) i hela applikationen. Inga beställningar / bokningar ska dela samma identifierare.
    • Tillsammans med numret ska det också valideras för typen av beställning, användarinformation, faktureringsadress, leveransadress och pris. All information ska vara exakt lik den som användaren har angett i applikationsgränssnittet.
  • Länkar:
    • En länk i e-postmeddelandet ska ta en användare till beställningens informationssida i applikationsgränssnittet. Det bör finnas exakt matchning mellan information i e-post och applikationsgränssnittet

Bekräftelsemail

# 8) Chattranskript

Här får en användare hela chattutskriften som e-post. Detta är vanligtvis när livechatten med kundsupport är avslutad.

Valideringspunkterna är som nedan

  • Detaljer
    • Sök efter namnet på den person som tillhandahöll support online. Kontrollera att hela chatten finns i e-postmeddelandet med avsändarens uppgifter för varje chattpost (Personnamn, Datum och tid då chattmeddelandet skickades osv.)

# 9) E-postmeddelanden med bilaga

Användaren tar emot e-postmeddelanden med bilaga. Bilagor kan vara lösenordsskyddade / oskyddade. Detta är vanligtvis uttalanden från finansiella domäner, slutanvändarlicensavtal för referens, villkor och villkor för referens, etc., detta varierar igen från applikation till applikation.

Valideringspunkterna är som följer:

  • Typ av tillbehör
    • Giltiga filtyper ska skickas som en bilaga. Alla bilagor som öppnas ska genomsöks innan de laddas ner / öppnas. Detta igen kan anpassas på applikationsnivå i backend, som virussökning som endast ska utföras vid nedladdning, bara när du öppnar, för både nedladdning och öppning.
    • Lösenordsskyddade bilagor ska laddas ner utan att fråga efter lösenordet. Men när du öppnar den antingen från e-posten själv eller öppnar den nedladdade kopian bör du alltid be om lösenordet. Felaktiga lösenordsposter här kommer att vara obestämda eftersom den lokala kopian inte kan spåras online för att låsa bilagan

E-post med bilaga

Lösenordsskyddad bilaga

Typer av e-post

E-posttypen kan vara antingen HTML (färgstark och attraktiv för användarna, som intresserar användaren att läsa e-postmeddelandena helt) eller vanlig text (bara en text).

HTML är mest föredragna och ställs vanligtvis in som standard i nästan alla applikationer i backend. Om det behövs kan applikationer välja att skicka e-postmeddelanden med vanlig text till användarna, igen kräver detta ändringar i backend.

E-post Triggerpoäng:

E-postmeddelanden kan skickas antingen omedelbart eller som sammanfattning / batch. Omedelbara e-postmeddelanden utlöses av användarens handling. Dessa är vanligtvis aktiverings-e-postmeddelanden, återställ lösenord-e-postmeddelanden, chattranskriptioner, bekräftelsemeddelanden osv., Dvs Sammanfattning / batch-e-postmeddelanden utlöses baserat på inställningarna i programmets backend.

E-postutlösarpunkter definieras så att de utlöses vid den specifika tidpunkten ( till exempel 3rdvarje vecka klockan 12:00. Detta kommer vanligtvis att vara uttalanden från finansiella domäner (bankutdrag), förfallodatum för räkningar, försenade meddelanden, prenumerationer etc.,

Bouncebacks:

Det är ett mycket vanligt scenario att e-postmeddelanden studsar när de skickas till ogiltig e-postadress. Vanligtvis är e-postadressen som är avaktiverad / inte längre används och inte existerar alls - kandidaterna som studsar tillbaka.

Servern försöker vanligtvis ett visst antal gånger att skicka e-post till den avsedda adressen. När den inte når den avsedda e-postadressen, studsar den tillbaka och gör en post på servern för dess misslyckande. Det kommer att finnas en annan server för att upprätthålla denna typ av aktiviteter och kallas vanligtvis en bounce back-servrar. Det kan finnas flera anledningar till att ett e-postmeddelande misslyckas genom att nå sin användare.

Nedan följer några andra punkter för fel:

  • E-postservern är nere under lång tid
  • Algoritmen för att hitta en kort väg för att nå användaren fungerar inte korrekt och det tar mycket lång tid att nå användaren, vid den tiden kanske det skulle ha passerat den angivna tidsinställningen för att nå användaren. Detta kallas vanligtvis ökat antal humle
  • Användarens e-postdomän är nere under lång tid
  • Användarens konto för programmet är inte aktiverat för att ta emot e-post

Lokaliseringsomfattning för e-posttestning

När applikationen stöder flera språk bör stödet även omfatta även e-post.

Alla skickade e-postmeddelanden ska vara på användarprofilspråket. Om en användare har angett engelska som profilspråk ska alla e-postmeddelanden som skickas till honom / henne vara på engelska. Om användarens profilspråk är franska, ska alla e-postmeddelanden som skickas till honom / henne vara på franska. Användarprofilspråk kan vara engångsinställningar eller kan ändras efter behov, vilket beror på programmets inställningar.

E-post ska skickas på det språk som användaren har när den utlöses.

Vanliga valideringspunkter för lokaliseringstestning av e-postmeddelandena är som följer:

vad är den bästa mjukvaran för taligenkänning
  • Ämnesrad
  • E-postens kropp
    • Innehåll - kroppens text
    • Länknamn / knappnamn
    • Upphovsrättsinformation
    • Information om kundsupport

Standard / anpassning av e-post

E-post kan anpassas i backend.

Till exempel , få applikationer stöder användaren att anpassa e-postmeddelanden när de skickas. Användaren kan här ändra ämnesraden och / eller brödtexten till e-postmeddelandet så att det är bekvämt eller i syfte att lätt känna igen. I det här fallet måste testteamet göra noggranna tester eftersom chansen att inkräkta är hög.

Testning måste utföras för injektioner - skicka HTML-kod, Java-kod, SQL, etc. Alla dessa skulle misslyckas för att öka säkerhetsnivåerna. Om applikationen inte stöder anpassning av e-postmeddelanden, kommer alla e-postmeddelanden som skickas att följa standardämne / inställning enligt inställningen av en applikation.

Slutsats

Testa e-post är en viktig aktivitet eftersom de flesta komponenterna i applikationen är integrerade med denna funktionalitet.

Det borde vara hela teamets stöd och ansträngning att helt testa applikationens e-postfunktionalitet. Detta bör vara välplanerat mycket innan den faktiska testningen startar och ska gå hand i hand när du testar varje komponent / tillhörande komponent.

E-posttestning bör ha separata testfall för varje e-posttyp som täcker alla aspekter som ska testas. Detta bör utföras vid alla typer av test Regressionstest, Adhoc-testning, Lokaliseringstest, UAT-testning och Produktionstestning.

Allt som går fel i e-post i realtid kommer att lämna ett dåligt intryck på applikationen, kunderna och så småningom fortsätter den till testare av den applikationen. Så e-postvalideringar är mycket avgörande och mycket nödvändig aktivitet i programvarutestning.

Om författaren: Det här inlägget är skrivet av STH-författaren Nandini K. Hon har 7+ års erfarenhet av mjukvarutestning främst inom testning av webbapplikationer.

Låt oss veta om du har några frågor / förslag.

Rekommenderad läsning

^