hur man skriver testfall för födelsedatum: ditt gratis detaljerade Funktionstestexempel

i den här artikeln kommer jag att prata om hur man utformar testfall för födelsedatum (DOB) funktionalitet.

denna funktionalitet är mycket viktig eftersom den har många användningsområden.

några av dessa användningsområden inkluderar områden som säkerhet och identifiering.

använd gärna testfallet och ändra det i enlighet med dina behov.

nu innan du fortsätter kanske du vill lära dig mer om att skriva testfall.

vilka är de viktigaste sakerna du bör testa för födelsedatum funktionalitet?

födelsedatum är bara ett fält.

men enligt min mening är det ett av de viktigaste fälten när du registrerar en användares profil.

Låt oss bryta ner elementen;

1. dag (textfält)
2. månad (textfält)
3. år (textfält)
4. är alla element giltiga?

scenarier där du skulle använda födelsedatum funktionalitet

• konto / användarregistrering
• verifiera en användares ålder när de registrerar sig för en produkt eller tjänst
• återställa inloggningsuppgifter när en användare glömmer
• Admin Användare som en del av en serie säkerhetsfrågor

låt oss utarbeta scenarierna som nämns ovan

Scenario 1: testfall för födelsedatum – verifiera användarens ålder

åldersverifiering används på så många olika plattformar. Nedan följer några testscenarier som du kanske vill överväga.

• användaren vill skapa ett socialt media / e-postkonto och måste vara minst 13 år.
• användaren ansöker om ett brittiskt provisoriskt körkort. Lägsta ålder är 17.
• köpa en begränsad produkt eller tjänst online. Till exempel titta på begränsade YouTube-videor som kräver att du gör en ålderskontroll.
• att köpa alkohol eller speltjänster på nätet!

Scenario 2: Testfall för födelsedatum-återställa inloggningsuppgifter när en användare glömmer

• när en användare glömmer sina uppgifter kan systemet begära ytterligare verifiering för att bevisa användarens identitet.

Scenario 3: testfall för födelsedatum – en administratörsanvändare av ett System frågar DOB som en del av en serie säkerhetsfrågor

• liknande ovanstående scenario men med ett mänskligt element. Det här scenariot är där en Applikationsadministratörsanvändare vill verifiera att Användarsamtalet verkligen är vem de säger att de är och DOB är en del av en uppsättning säkerhetsverifieringsfrågor.

affärs-och funktionskrav

du bör alltid försöka få några krav om din testning kommer att vara av hög kvalitet.

jag säger alltid till mina icke-testande kollegor att vi som specifikationsbaserade testare bara är så bra som de krav vi har.

notera mina Affärsanalytikervänner.

Låt oss bryta ner några exempel krav som jag har skapat för dig.

jag har försökt att vara detaljerad men vill inte gå överbord.

om möjligt bör du alltid försöka skapa en Kravspårbarhetsmatris (RTM) där du kan lagra alla dina projektkrav.

krav-ID	Kravbeskrivning	anmärkningar
REQ-DOB-0001	systemet måste fånga födelsedatum.
REQ-DOB-0002	födelsedatum måste vara i Brittiskt format. till exempel måste datumformatet för fältet vara i ordningen nedan. DD / MM / ÅÅÅÅ D = dag (numeriskt format)M = månad (numeriskt format)Y = år (numeriskt format)	om ett rullgardinsalternativ krävs kan användargränssnittet uppdatera och visa det minsta startdatumet som = 13 år gammalt. det kan också acceptera manuell inmatning.
REQ-DOB-0003	Manuell DOB-Formulärinmatning systemet måste ge användaren möjlighet att ange födelsedatum manuellt	detta krav kan utökas till att inkludera ett datum/kalenderkontrollalternativ. men för enkelhetens skull kommer vi att använda alternativet Manuell form. ur ett användbarhetsperspektiv är datumväljaren mindre tråkig och benägen att mindre valideringsproblem uppstår.
REQ-DOB-0004	Användaråldersbegränsning minsta användarålder är 13. systemet bör automatiskt avvisa alla användare som är under 13 år från det aktuella datumet.
REQ-DOB-0005	Dagfältvalidering dagfältet måste vara ett giltigt nummer mellan 1 och 31. Dfbr1 – Day Field Business Rule 1 systemet bör avvisa något värde mindre än 1 och mer än 31.
REQ-DOB-0006	Månadsfältvalidering ett giltigt månadsfält kommer att vara ett tal från 1 till 12. månad 1 representerar januari och månad 12 representerar December. Mfbr1-Month Field Business Rule 1 när användaren anger månaden som ett numeriskt värde ska systemet validera om DAGVÄRDET är korrekt.
REQ-DOB-0007	år fält validering år fältet är en 4 tecken numeriskt värde som bör gå tillbaka längre än 125 år från innevarande år. till exempel om det idag är 1 September 2021, är det tidigaste datumet som systemet kan gå till 1 September 1896.	det finns ett antal människor som lever som är över 110 år gamla, som ett resultat har jag lagt till en men mer beredskap.
REQ-DOB-0008	validering av skottår om en person är född under ett skottår bör systemet validera; året de föddes var faktiskt ett skottår. standard deras födelsedatum till mars 1st på icke-skottår. om året de angav är felaktigt ska systemet visa ett felmeddelande.	Obs: i vissa länder anses det vara olagligt att göra ett skottår till 28 februari. i det här fallet kommer vi att använda det brittiska juridiska perspektivet som är att använda mars 1st.
REQ-DOB-0009	validera korrekt datum när en användare anger hela födelsedatumet bör systemet kontrollera dess giltighet. affärsregel 1: validera dagen överensstämmer med rätt månad.
REQ-DOB-0010	födelsedatum beräkning

Användarresa

testfallet innehåller vanligtvis positiv och negativ validering. Det kommer att se ut som följande;

• användaren navigerar till registreringssidan
• när du uppmanas anger användaren ett ogiltigt födelsedatum
• användaren anger ett giltigt födelsedatum (men av misstag under 13 år)
• systemet visar felmeddelande som informerar användaren om att de inte kan registrera sig om de är under 13 år
• användaren anger sitt korrekta datum för registrering födelse (som är över 13 år)
• systemprocesser och validerar datumet som korrekt.

testfall för födelsedatum exempel

stegnummer	teststeg	krav ID	förväntat resultat	faktiskt resultat	Status (godkänd / underkänd)	positivt / negativt Test
1	öppna sidan för användarregistreringsformulär för ansökan under Test (AUT)		användaren landar på användarregistreringssidan.			+
2	hoppa över fältet födelsedatum och fyll i giltiga uppgifter i resten av formuläret		giltiga data fylls i i alla fält utom fältet födelsedatum.			+
3	negativt testscenario i fältet’ dag ’ anger du ett ogiltigt tal som =>32.		fältet dag fylls i med en ogiltig post. till exempel: 32/MM/ååå notera: beroende på hur dina krav skrivs kan applikationen visa ett felmeddelande vid denna tidpunkt eller när alla datumfält har fyllts i.			–
4	i fältet månad anger användaren ett giltigt numeriskt värde.		ett giltigt numeriskt värde anges			+
5	i fältet år anger användaren rätt värde.		det korrekta födelseåret är inmatat.			+
6	användaren klickar på ’Skicka’		systemet visar ett felmeddelande som varnar för att Dagfältet är felaktigt. Obs: alla fält är fortfarande fyllda med manuell data som anges så att användaren kan göra en korrigering. Fält är fortfarande redigerbara..			+
7	negativt testfall i fältet dag anger användaren ett tomt utrymme.		alla andra fält är fortfarande befolkade och dagfältet uppdateras tomt			–
8	användarklick skicka		systemet visar ett felmeddelande som varnar för att Dagfältet är felaktigt. alla fält är fortfarande fyllda med manuell data som anges så att användaren kan göra en korrigering..			+
9	testning av affärsregel i fältet’ dag ’anger användaren värdet ’31’.		värdet ’ 31 ’ matas in i dag fält.			–
10	i fältet månad anger användaren värdet 09 Obs: 9 = September		värdet ’ 09 ’ fylls i fältet månad.
11	i fältet år anger användaren ett korrekt värde. t. ex. 1985		ett korrekt värde anges i fältet år.
12	användaren klickar på ’Skicka’		ett ’användbart’ felmeddelande visas. meddelandet informerar användaren om att September inte har 31 dagar. vänligen ändra detta.
13	användaren ändrar dagvärdet till 30		dag fält populagted med ’30’.
14	användaren klickar på ’Skicka’		systemet; a) bearbetar formuläret b) validerar födelsedatum c) validerar mot affärsreglerna omdirigerar användaren till registreringsbekräftelsesidan.

jag ville inte göra detta testfall för länge men du kan också lägga till några teststeg för att säkerställa;

• användaren är över 13 år
• användare som är född den 29 februari är standard till 1 mars som födelsedatum (utom på skottår).
• bekräfta att året inte går längre tillbaka än 125 år från det aktuella datumet.

om du har en kalenderkontroll, det ’sak’ där du väljer datum med en mus, testa detta bör vara mycket enklare.

detta beror på att det finns mindre funktionella tester och mindre testdata att förbereda.

som en del av registreringsprocessen kanske du också vill överväga testfall för ändringslösenordsfunktionalitet.

Gränsvärdesanalys

nedan finns några gränsvärden du kanske vill tänka på.

ålder

gräns 1	gräns 2
0 -13	13 >

ekvivalens partitionering

du har ett antal partitioner som en del av detta test, de är;

ålder

Partition 1	Partition 2
0-12	>13

ett bra komplement till din Regressionstestpaket

jag älskar ett detaljerat funktionellt test som detta. Varför?

eftersom jag kan lägga till det i mitt regressionstestpaket.

när du har alla invecklade detaljer kan du bokstavligen köra dessa tester när och när du behöver dem.

oavsett om de är manuella eller automatiserade tester.

sammanfattning

förhoppningsvis bör ovanstående vara ett bra testfall för födelsedatum funktionell testning.

jag älskar absolut dessa typer av black box testtekniker som jag minns att göra många i min karriär.

om du någonsin stöter på testdatumfält kan du också vara intresserad av att skriva testfall för en kalenderapplikation.

att arbeta i Kvalitetssäkringsarenan är inte lätt men det här är en av de många utmaningarna med att vara en mjukvarutestare.