Mange webapplikasjoner som e-handelsnettsteder og nettportaler gir brukerregistrering og påloggingsfunksjonalitet for brukerne.
Når vi blir bedt om å teste en brukerregistreringsflyt, må vi ha et sett med scenarier som vi lett kan bruke til å utøve registreringsfunksjonen.
Målet med dette innlegget er å gi deg en liste over vanlige scenarier og testtilfeller som må vurderes når du tester en brukerregistreringsfunksjonalitet.
Registreringsprosessen er en del av identitets- og tilgangshåndtering , IDAM.
La oss vurdere at vi har en registrerings-API som er tilgjengelig via /register
endepunkt.
/register
endepunkt tar en JSON-nyttelast av skjemaet:
{
'username': '',
'password': '',
'first_name': '',
'last_name': '',
'email': '' }
Nå skal vi teste dette /register
endepunkt. Hvilke scenarier kan vi tenke oss?
Scenario 1: Bør kunne registrere bruker med gyldig nyttelast for registreringsforespørsel
Nyttelast:
Sjekk:
Scenario 2: Bør ikke kunne registrere bruker med misdannet JSON-nyttelast
Nyttelast:
Sjekk:
Ofte, når en bruker er registrert, sendes en bekreftelseskobling til brukerens e-postadresse for å sikre at e-postadressen er gyldig.
Brukere må normalt klikke på lenken i e-postmeldingen for å bekrefte e-postkontoen.
Vi kan teste med gyldig og ugyldig bekreftelseskobling.
Scenario 3: Bekreft brukerregistrering
Nyttelast: Gyldig forespørsel
Sjekk:
Scenario 4: Bekreft brukerregistrering
Nyttelast: Ugyldig forespørsel
Sjekk:
Scenario 5: Bør ikke kunne registrere samme bruker to ganger
Nyttelast: Gyldig forespørsel
Sjekk:
Begrensede passord er de som allerede har blitt hacket og lagt på pastebins. HIBP (HaveIBeenPawned.com) har en liste over hackede passord.
Scenario 6: Bør ikke kunne registrere bruker med begrensede passord
Nyttelast: Alle felt er gyldige, men begrensede passord
Sjekk:
Det er en liste over passord som er vanlige og enkle å hacke, så det bør unngås ved brukerregistrering.
Scenario 7: Skal ikke kunne registrere bruker med lett å gjette passord
Nyttelast: Alle felt er gyldige, men enkle å gjette passord
Sjekk:
Scenario 8: Bør ikke kunne angi passord som brukernavn
Nyttelast: Alle feltene er gyldige, men passordet er det samme som brukernavnet
Sjekk:
Kravene til hver applikasjon er forskjellige, og de ovennevnte scenariene kan, eller ikke, gjelde for registreringsfunksjonen du tester.
Men forhåpentligvis kan disse scenariene gi deg litt veiledning om hva du skal se etter når du tester en brukerregistreringsflyt.