Brukerregistreringsscenarier og testtilfeller

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.




Brukerregistreringsscenarier

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?

Gyldige nyttelaster

Scenario 1: Bør kunne registrere bruker med gyldig nyttelast for registreringsforespørsel

Nyttelast:


  • Alle felt
  • Alle obligatoriske felt

Sjekk:

  • API-svar statuskode: 200
  • Database: Bruker skal eksistere i databasen
Merk:Ikke glem å teste med kyrilliske tegn, apostrofer og bindestrek. Disse er vanligvis tillatte og gyldige tegn, men noen systemer håndterer dem annerledes.

Ugyldige nyttelaster

Scenario 2: Bør ikke kunne registrere bruker med misdannet JSON-nyttelast

Nyttelast:

  • Manglende / tomme overskrifter
  • Manglende / tomme påkrevde felt
  • Feil verdier / Feil format for obligatoriske felt
  • Ulike kombinasjoner av ugyldige e-postformater

Sjekk:


  • API-svar statuskode: 400
  • Database: Det opprettes ingen poster i DB

Bekreft brukerregistrering

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:

  • API-svar statuskode: 200
  • Database: Sjekk brukerstatusendringer fra ubekreftet til bekreftet

Scenario 4: Bekreft brukerregistrering

Nyttelast: Ugyldig forespørsel


Sjekk:

  • API-svar statuskode: 400 eller 403
  • Database: Sjekk brukerstatus endres ikke. Brukeren skal fortsatt være ubekreftet.
  • Logg Inn: Sjekk brukeren kan ikke logge inn hvis statusen ikke er bekreftet.

Omregistrering

Scenario 5: Bør ikke kunne registrere samme bruker to ganger

Nyttelast: Gyldig forespørsel

Sjekk:

  • API-svar statuskode: Avhenger
  • Svarmelding: Feilmelding om at brukeren allerede eksisterer. Merk: Av sikkerhetsgrunner kan det hende at enkelte applikasjoner ikke returnerer denne meldingen.

Begrensede passord

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:

  • API-svar statuskode: 400
  • Svarmelding: Sjekk feilmeldingen er passende

Enkel å gjette passord

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:

  • API-svar statuskode: 400
  • Svarmelding: Sjekk feilmeldingen er passende

Passord Samme som brukernavn

Scenario 8: Bør ikke kunne angi passord som brukernavn

Nyttelast: Alle feltene er gyldige, men passordet er det samme som brukernavnet

Sjekk:

  • API-svar statuskode: 400
  • Svarmelding: Sjekk feilmeldingen er passende


Sammendrag

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.