i denne artikkelen vil jeg snakke om hvordan å designe testtilfeller for fødselsdato (DOB) funksjonalitet.
dette stykke funksjonalitet er svært viktig som den har mange bruksområder.
Noen av disse bruksområdene inkluderer områder som sikkerhet og identifikasjon.
Bruk gjerne testsaken og endre den tilsvarende for å dekke dine behov.
Nå før du fortsetter, vil du kanskje lære mer om å skrive testtilfeller.
Innholdsfortegnelse
Hva er de viktigste tingene du bør teste For Fødselsdato Funksjonalitet?
fødselsdato er bare ett felt.
Men etter min mening er det et av de viktigste feltene når du registrerer en brukers profil.
La oss bryte ned elementene;
- Dag (tekstfelt)
- Måned (tekstfelt)
- År (tekstfelt)
- er alle elementene gyldige?
Scenarier der Du vil bruke Funksjonalitet For Fødselsdato
- Konto – / Brukerregistrering
- Verifisere Alderen Til En Bruker når De registrerer seg for et produkt eller en tjeneste
- Tilbakestille påloggingsinformasjon når en bruker glemmer
- Administratorbruker som en del av en serie sikkerhetsspørsmål
la oss utdype scenariene nevnt ovenfor
Scenario 1: Testtilfeller For Fødselsdato-Verifisering Av En Brukers Alder
Aldersverifisering brukes på så Mange forskjellige plattformer. Nedenfor er noen testscenarier som du kanskje vil vurdere.
- Brukeren ønsker å opprette en sosial media / e-postkonto og må være minst 13 år gammel.
- Bruker søker OM ET britisk foreløpig førerkort. Minstealderen er 17 år.
- Kjøpe et begrenset produkt eller en tjeneste på nettet. For eksempel å se på begrensede YouTube-videoer som krever at du utfører en alderskontroll.
- Kjøpe alkohol eller spilltjenester på nettet!
Scenario 2: Testtilfeller For Fødselsdato-Tilbakestilling av påloggingsinformasjon når en bruker glemmer
- når en bruker glemmer legitimasjonen, kan systemet be om ytterligere verifisering for å bevise brukerens identitet.
Scenario 3: Testtilfeller For Fødselsdato-En Administratorbruker av Et System spør DOB som en del av en serie sikkerhetsspørsmål
- Ligner på scenariet ovenfor, Men med et menneskelig element. Dette scenariet er der Et Program Admin Brukeren ønsker å bekrefte Brukeren ringer er faktisk som de sier de er og DOB er en del av et sett med sikkerhetsverifisering spørsmål.
Forretnings-Og Funksjonelle Krav
du bør alltid prøve å få noen krav hvis testingen skal være av høy kvalitet.
jeg forteller alltid mine ikke-testkollegaer at vi som spesifikasjonsbaserte testere bare er like gode som kravene vi har.
Legg merke Til Mine Forretningsanalytikervenner.
La oss bryte ned noen eksempelkrav som jeg har laget for deg.
jeg har prøvd å være detaljert, men vil ikke gå overbord.
der det er mulig, bør du alltid prøve å lage EN Kravsporbarhetsmatrise (RTM) der du kan lagre alle prosjektkravene dine.
| Krav-ID | Kravbeskrivelse | Merknader |
| REQ-DOB-0001 | systemet må fange fødselsdato. | |
| REQ-DOB-0002 | fødselsdatoen må være I britisk format. datoformatet for feltet må For eksempel være i rekkefølgen nedenfor. DD/MM / ÅÅÅÅ D = Dag (numerisk format)M = Måned (numerisk format)Y = År (numerisk format) |
HVIS et rullegardinalternativ kreves, KAN BRUKERGRENSESNITTET oppdatere og vise minimum startdato som = 13 år gammel. det kan også godta manuell inngang. |
| REQ-DOB-0003 | Manuell DOB-Skjema systemet må gi brukeren muligheten til å angi fødselsdato manuelt |
dette kravet kan utvides til å inkludere et dato / kalenderkontrollalternativ. Men for enkelhet vil vi bruke det manuelle skjemaet. fra Et Brukbarhetsperspektiv er datovelgeren mindre kjedelig og utsatt for mindre valideringsproblemer som oppstår. |
| REQ-DOB-0004 | Begrensning Av Brukeralder minste brukeralder er 13. systemet skal automatisk avvise enhver bruker som er under 13 år fra gjeldende dato. |
|
| REQ-DOB-0005 | Validering Av Dagsfelt dag-feltet må være et gyldig tall mellom 1 og 31. DFBR1-Dagers Field Business Rule 1 systemet bør avvise en verdi mindre enn 1 og mer enn 31. |
|
| REQ-DOB-0006 | Validering Av Månedsfelt et gyldig månedsfelt vil være et tall fra 1 til 12. Måned 1 representerer januar Og måned 12 representerer desember. Mfbr1 – Månedsfelt Forretningsregel 1 når brukeren angir Måneden som en numerisk verdi, skal systemet validere HVIS dagverdien er riktig. |
|
| REQ-DOB-0007 | År Felt Validering år feltet er en 4 tegn numerisk verdi som bør gå tilbake lenger enn 125 år fra inneværende år. for eksempel hvis i dag er 1. September 2021, er den tidligste datoen systemet kan gå til 1. September 1896. |
det er en rekke mennesker i live som er over 110 år gamle, som et resultat har jeg lagt til en, men mer beredskap. |
| REQ-DOB-0008 | Skuddår Validering hvis en person er født i et skuddår, bør systemet validere; året de ble født var faktisk Et Skuddår. Standard deres fødselsdato Til 1. Mars på ikke-skuddår. hvis året de skrev inn er feil, skal systemet vise en feilmelding. |
Merk: i noen land anses mislighold av et skuddår Til 28. Februar å være ulovlig. i dette tilfellet vil VI bruke DET Britiske Juridiske perspektivet som skal brukes 1. Mars. |
| REQ-DOB-0009 | Valider Riktig Dato når en bruker går inn i hele fødselsdatoen, bør systemet sjekke gyldigheten. Forretningsregel 1: Valider dagen i samsvar med riktig måned. |
|
| REQ-DOB-0010 | Beregning Av Fødselsdato |
Brukerreise
testtilfellet vil typisk inkludere positiv og negativ validering. Det vil se ut som følgende;
- Bruker navigerer til registreringssiden
- Når du blir bedt Om Det, går Brukeren inn en ugyldig fødselsdato
- Bruker angir en gyldig fødselsdato (men under 13 år ved en feil)
- Systemet viser feilmelding som informerer brukeren om at de ikke kan registrere seg hvis de er under 13 år
- Bruker angir riktig dato for fødsel (som er over 13 år)
- system behandler og validerer datoen som riktig.
Test Tilfelle For Fødselsdato Eksempel
| Trinnnummer | Testtrinn | Krav-ID | Forventet Resultat | Faktisk Resultat | Status(Bestått / Ikke Bestått) | Positiv / Negativ Test |
| 1 | Tilgang til brukerregistreringsskjema side For Søknad Under Test (AUT) | Bruker lander på brukerregistreringssiden. | + | |||
| 2 | Hopp Over Fødselsdato-feltet og fyll ut gyldige data i resten av skjemaet | Gyldige data er fylt UT I alle felt UNNTATT Fødselsdato feltet. | + | |||
| 3 | Negativt testscenario i feltet dag skriver du inn et ugyldig tall, for eksempel = > 32. |
dag-feltet fylles ut med en ugyldig oppføring. For eksempel: 32/MM/ÅÅÅ Merk: avhengig av hvordan dine krav er skrevet, kan programmet vise en feilmelding på dette punktet eller når alle datofeltet er fylt ut. |
– | |||
| 4 | I feltet’ måned ‘ angir Brukeren en gyldig numerisk verdi. | en gyldig numerisk verdi er angitt | + | |||
| 5 | I Feltet År angir Brukeren riktig verdi. | Det riktige fødselsåret er lagt inn. | + | |||
| 6 | Brukeren klikker På ‘Send’ | systemet viser en feilmelding advarsel Om At Dag-feltet er feil. Merk: alle felt er fortsatt fylt ut med de manuelle dataene som er angitt, slik at brukeren kan korrigere. Feltene kan fortsatt redigeres.. |
+ | |||
| 7 | Negativt Testtilfelle i dag-feltet angir brukeren et tomt område. |
Alle andre felt er fortsatt fylt og dag-feltet oppdateres tomt | – | |||
| 8 | Brukerklikk send | systemet viser en feilmelding advarsel Om At Dag-feltet er feil. alle felt er fortsatt fylt ut med de manuelle dataene som er angitt, slik at brukeren kan korrigere.. |
+ | |||
| 9 | Testing av forretningsregel i feltet’ dag ‘angir brukeren verdien ’31’. |
verdien ‘ 31 ‘ er angitt I Dag-feltet. | – | |||
| 10 | i den måned angir brukeren verdien 09 Merk: 9 = September |
verdien 09 fylles ut I Måned-feltet. | ||||
| 11 | i den år angir brukeren en riktig verdi. F. eks. 1985 |
en korrekt verdi legges inn i Feltet ‘År’. | ||||
| 12 | Brukeren klikker På ‘Send’ | en’ nyttig ‘ feilmelding vises. meldingen informerer brukeren om at September ikke har 31 dager. vennligst endre tilsvarende. |
||||
| 13 | Bruker endrer dagverdien til 30 | Dag feltet er populagted med ’30’. | ||||
| 14 | Brukeren klikker På ‘Send’ | systemet; a) behandler skjemaet b) validerer fødselsdato c) validerer mot forretningsreglene Omdirigerer brukeren til registreringsbekreftelsessiden. |
jeg ville ikke gjøre dette testsaken for lenge, men du kan også legge til noen testtrinn for å sikre;
- Bruker er over 13 år
- Bruker som er født på 29 februar er standard til 1 Mars som sin fødselsdato (unntatt på skuddår).
- Bekreft At Året ikke går lenger tilbake enn 125 år fra gjeldende dato.
hvis du har en kalenderkontroll, den tingen der du velger datoen med en mus, bør det være mye enklere å teste dette.
Dette skyldes at det er mindre funksjonstester og mindre testdata å forberede.
som en del av registreringsprosessen, kan det være lurt å også vurdere testtilfeller for endre passord funksjonalitet.
Analyse Av Grenseverdier
Nedenfor er noen grenseverdier du kanskje vil tenke på.
Alder
| Grense 1 | Grense 2 |
| 0 -13 | 13 > |
Ekvivalenspartisjonering
du har en rekke partisjoner som en del av denne testen, de er;
Alder
| Partisjon 1 | Partisjon 2 |
| 0-12 | >13 |
Et Flott Tillegg til Regresjonstesting Suite
jeg elsker en detaljert funksjonell test som dette. Hvorfor?
Fordi Jeg kan legge den til min regresjonstestpakke.
når du har alle de intrikate detaljene, kan du bokstavelig talt kjøre disse testene når og når du trenger dem.
Uansett om de er manuelle eller automatiserte tester.
Sammendrag
Forhåpentligvis bør ovennevnte være et godt testfall for fødselsdato funksjonell testing.
jeg elsker absolutt disse typer black box testing teknikker som jeg husker å gjøre mange i min karriere.
hvis du noen gang kommer over testdatofelt, kan du også være interessert i å skrive testtilfeller for et kalenderprogram.
Å Jobbe I Kvalitetssikringsarenaen er ikke lett, men dette er en av de mange utfordringene ved å være en programvaretester.