i denne artikel vil jeg tale om, hvordan man designer testsager til fødselsdato (DOB) – funktionalitet.
dette stykke funktionalitet er meget vigtigt, da det har mange anvendelser.
nogle af disse anvendelser omfatter områder som sikkerhed og identifikation.
du er velkommen til at bruge testsagen og ændre den i overensstemmelse hermed, så den passer til dine behov.
før du fortsætter, vil du måske lære mere om at skrive testcases.
Indholdsfortegnelse
Hvad er de vigtigste ting, du skal teste for Fødselsdato funktionalitet?
fødselsdatoen er kun et felt.
men efter min mening er det et af de vigtigste felter, når du registrerer en brugers profil.
lad os nedbryde elementerne;
- dag (tekstfelt)
- måned (tekstfelt)
- år (tekstfelt)
- er alle elementer gyldige?
scenarier, hvor du vil bruge Fødselsdatofunktionalitet
- konto / brugerregistrering
- bekræftelse af en brugers alder, når de tilmelder sig et produkt eller en tjeneste
- nulstilling af loginoplysninger, når en bruger glemmer
- Adminbruger som en del af en række sikkerhedsspørgsmål
lad os uddybe scenarierne nævnt ovenfor
Scenario 1: Test Cases for Fødselsdato – verificering af en brugers alder
aldersbekræftelse bruges på tværs af så mange forskellige platforme. Nedenfor er nogle testscenarier, som du måske vil overveje.
- bruger ønsker at oprette en social media/e-mail-konto og skal være mindst 13 år.
- bruger ansøger om et britisk foreløbigt kørekort. Minimumsalderen er 17 år.
- køb af et begrænset produkt eller en tjeneste online. For eksempel at se begrænsede YouTube-videoer, der kræver, at du foretager en alderskontrol.
- køb af alkohol eller spiltjenester online!
scenarie 2: Testsager for Fødselsdato-nulstilling af loginoplysninger når en bruger glemmer
- når en bruger glemmer deres legitimationsoplysninger, kan systemet bede om yderligere verifikation for at bevise brugerens identitet.
Scenario 3: Test Cases for Fødselsdato – en Admin bruger af et System spørger DOB som en del af en række sikkerhedsspørgsmål
- svarende til ovenstående scenario dog med et menneskeligt element. Dette scenario er, hvor en Applikationsadministratorbruger ønsker at bekræfte, at Brugeropkaldet faktisk er, hvem de siger, de er, og DOB er en del af et sæt sikkerhedsverifikationsspørgsmål.
forretnings-og funktionskrav
du bør altid prøve at få nogle krav, hvis din test skal være af høj kvalitet.
jeg fortæller altid mine ikke-testkolleger, at vi som specifikationsbaserede testere kun er så gode som de krav, vi har.
vær opmærksom på mine Forretningsanalytikervenner.
lad os nedbryde nogle eksempelkrav, som jeg har oprettet til dig.
jeg har forsøgt at være detaljeret, men vil ikke gå overbord.
hvor det er muligt, skal du altid prøve at oprette en Kravsporingsmatrice (RTM), hvor du kan gemme alle dine projektkrav.
| krav-ID | Kravbeskrivelse | noter |
| DOB-0001 | systemet skal registrere fødselsdatoen. | |
| DOB-0002 | fødselsdato skal være i Britisk format. for eksempel skal datoformatet for feltet være i nedenstående rækkefølge. DD / MM / ÅÅÅÅ D = Dag (numerisk format)m = måned (numerisk format)Y = år (numerisk format) |
hvis en rullemenu er påkrævet, kan brugergrænsefladen opdatere og vise den mindste startdato, der = 13 år gammel. det kan også acceptere manuel input. |
| DOB-0003 | manuel indtastning af DOB-formular systemet skal give brugeren mulighed for at indtaste fødselsdatoen manuelt |
dette krav kan udvides til at omfatte en dato/kalender kontrolindstilling. men for enkelhed bruger vi den manuelle formularindstilling. fra et Brugbarhedsperspektiv er datovælgeren mindre kedelig og tilbøjelig til mindre valideringsproblemer, der opstår. |
| DOB-0004 | begrænsning af Brugeralder den mindste brugeralder er 13. systemet skal automatisk afvise enhver bruger, der er under 13 år fra den aktuelle dato. |
|
| DOB-0005 | Dagfeltvalidering dagfeltet skal være et gyldigt tal fra mellem 1 og 31. DFBR1 – dages Feltforretningsregel 1 systemet bør afvise enhver værdi mindre end 1 og mere end 31. |
|
| DOB-0006 | validering af Månedsfelt et gyldigt månedsfelt vil være et tal fra 1 til 12. måned 1 repræsenterer januar og Måned 12 repræsenterer December. Mfbr1-måneders Feltforretningsregel 1 når brugeren angiver måneden som en numerisk værdi, skal systemet validere, om dagsværdien er korrekt. |
|
| DOB-0007 | validering af Årsfelt feltet år er en numerisk værdi på 4 tegn, som ikke skal gå længere tilbage end 125 år fra det indeværende år. for eksempel hvis I dag er 1. September 2021, er den tidligste dato, systemet kan gå til, 1. September 1896. |
der er et antal mennesker i LIVE, der er over 110 år gamle, som et resultat har jeg tilføjet en men mere beredskab. |
| kV-DOB-0008 | skudår Validering hvis en person er født i et skudår, skal systemet validere; det år, de blev født, var faktisk et skudår. Standard deres fødselsdato til 1. Marts på ikke-skudår. hvis det år, de indtastede, er forkert, skal systemet vise en fejlmeddelelse. |
Bemærk: i nogle lande betragtes misligholdelse af et skudår til 28.Februar som ulovligt. i dette tilfælde vil vi bruge det britiske juridiske perspektiv, som skal bruge 1.Marts. |
| Dob-0009 | Valider korrekt Dato når en bruger indtaster hele fødselsdatoen, skal systemet kontrollere dens gyldighed. forretningsregel 1: Valider dagen i overensstemmelse med den korrekte måned. |
|
| DOB-0010 | beregning af fødselsdato |
brugerrejse
testcasen vil typisk omfatte positiv og negativ Validering. Det vil se ud som følgende;
- bruger navigerer til registreringssiden
- når brugeren bliver bedt om det, indtaster brugeren en ugyldig fødselsdato
- bruger indtaster en gyldig fødselsdato (men ved en fejl under 13 år)
- System viser fejlmeddelelse, der informerer brugeren om, at de ikke kan registrere, hvis de er under 13 år
- bruger indtaster deres korrekte fødselsdato fødsel (som er over 13 år)
- system behandler og validerer datoen som korrekt.
Test tilfælde for Fødselsdato eksempel
| trinnummer | Testtrin | krav-ID | forventet resultat | faktisk resultat | Status (Pass / Fail) | positiv / negativ Test |
| 1 | adgang Bruger registrering formular side for ansøgning under Test (AUT) | bruger lander på brugerregistreringssiden. | + | |||
| 2 | Spring feltet fødselsdato over, og udfyld gyldige data i resten af formularen | gyldige data udfyldes i alle felter undtagen feltet fødselsdato. | + | |||
| 3 | negativt testscenarie i feltet’ dag ‘ indtastes et ugyldigt tal som => 32. |
feltet dag udfyldes med en ugyldig post. for eksempel: 32 / MM / ÅÅÅ Bemærk: afhængigt af hvordan dine krav er skrevet, kan applikationen vise en fejlmeddelelse på dette tidspunkt, eller når hele datofeltet er udfyldt. |
– | |||
| 4 | i feltet’ måned ‘ angiver brugeren en gyldig numerisk værdi. | en gyldig numerisk værdi indtastes | + | |||
| 5 | i feltet’ år ‘ indtaster brugeren den korrekte værdi. | det korrekte fødselsår er indtastet. | + | |||
| 6 | bruger klikker på ‘Send’ | systemet viser en fejlmeddelelse, der advarer om, at feltet dag er forkert. Bemærk: Alle felter udfyldes stadig med de indtastede manuelle data, så brugeren kan foretage en korrektion. felter kan stadig redigeres.. |
+ | |||
| 7 | negativ Test Case i feltet dag indtaster brugeren et tomt mellemrum. |
alle andre felter er stadig udfyldt, og dagfeltet opdateres tomt | – | |||
| 8 | bruger klik Send | systemet viser en fejlmeddelelse, der advarer om, at feltet dag er forkert. alle felter udfyldes stadig med de indtastede manuelle data, så brugeren kan foretage en korrektion.. |
+ | |||
| 9 | test af forretningsregel i feltet’ dag ‘indtaster brugeren værdien’31’. |
værdien ‘ 31 ‘ indtastes i feltet dag. | – | |||
| 10 | i feltet måned indtaster brugeren værdien 09 Bemærk: 9 = September |
værdien ‘ 09 ‘ udfyldes i feltet måned. | ||||
| 11 | i feltet år angiver brugeren en korrekt værdi. E. g. 1985 |
en korrekt værdi indtastes i feltet ‘år’. | ||||
| 12 | bruger klikker på ‘Send’ | en’ nyttig ‘ fejlmeddelelse vises. meddelelsen informerer brugeren om, at September ikke har 31 dage. ændr venligst i overensstemmelse hermed. |
||||
| 13 | bruger ændrer dagsværdi til 30 | dag felt er populagted med ’30’. | ||||
| 14 | bruger klikker på ‘Send’ | systemet; a) behandler formularen b) validerer fødselsdatoen c) validerer mod forretningsreglerne omdirigerer brugeren til registreringsbekræftelsessiden. |
jeg ønskede ikke at gøre denne test sag for lang, men du kan også tilføje nogle test trin for at sikre;
- bruger er over 13 år
- bruger, der er født den 29.Februar, er standardiseret til 1. marts som fødselsdato (undtagen på skudår).
- Bekræft, at året ikke går længere tilbage end 125 år fra den aktuelle dato.
hvis du har en kalenderkontrol, den ‘ting’, hvor du vælger datoen med en mus, skal det være meget lettere at teste dette.
dette skyldes, at der er mindre funktionelle tests og mindre testdata at forberede.
som en del af registreringsprocessen kan du også overveje testcases for ændring af adgangskodefunktionalitet.
Boundary Value Analysis
nedenfor er nogle grænseværdier, du måske vil tænke på.
alder
| grænse 1 | grænse 2 |
| 0 -13 | 13 > |
Ækvivalenspartitionering
du har et antal partitioner som en del af denne test, de er;
alder
| Partition 1 | Partition 2 |
| 0-12 | >13 |
en fantastisk tilføjelse til din Regressionstestpakke
jeg elsker en detaljeret funktionstest som denne. Hvorfor?
fordi jeg kan tilføje det til min regressionstestpakke.
når du har alle de indviklede detaljer, kan du bogstaveligt talt køre disse tests, når og når du har brug for dem.
uanset om de er manuelle eller automatiserede tests.
Resume
forhåbentlig skal ovenstående være en god testsag for fødselsdato funktionel test.
jeg elsker absolut disse typer af sorte boks testteknikker, da jeg husker at gøre mange i min karriere.
hvis du nogensinde støder på testdatofelter, er du måske også interesseret i at skrive testcases til en kalenderapplikation.
det er ikke let at arbejde i kvalitetssikringsarenaen, men dette er en af de mange udfordringer ved at være en programtester.