Glavni Qa Scenariji in primeri preizkušanja uporabnikov

Scenariji in primeri preizkušanja uporabnikov

Številne spletne aplikacije, kot so spletna mesta za e-poslovanje in spletni portali, svojim uporabnikom omogočajo registracijo in prijavo uporabnikov.

Ko smo pozvani, da preizkusimo tok registracije uporabnika, moramo imeti nabor scenarijev, ki jih lahko uporabimo za izvajanje funkcije registracije.

Cilj te objave je zagotoviti seznam pogostih scenarijev in testnih primerov, ki jih je treba upoštevati pri preizkušanju funkcionalnosti registracije uporabnikov.

Scenariji za registracijo uporabnikov

Postopek registracije je del upravljanje identitete in dostopa , IDAM.

Upoštevajmo, da imamo registracijski API, do katerega je mogoče dostopati preko /register končna točka.

The /register endpoint prevzame JSON koristni tovor v obliki:

{
'username': '',
'password': '',
'first_name': '',
'last_name': '',
'email': '' }

Zdaj bomo to preizkusili /register končna točka. Katerih scenarijev si lahko omislimo?

Veljavni tovor

1. scenarij: Moral bi biti sposoben registrirati uporabnika z veljavno koristno zahtevo za registracijo

Nosilnost:

Vsa področja
Vsa obvezna polja

Preverite:

Koda stanja odziva API: 200
Baza podatkov: Uporabnik bi moral obstajati v bazi podatkov

Opomba:Ne pozabite preizkusiti s cirilicami, apostrofi in vezaji. To so običajno dovoljeni in veljavni znaki, vendar jih nekateri sistemi obravnavajo drugače.

Neveljaven tovor

2. scenarij: Uporabnik ne bi mogel registrirati z nepravilno oblikovanim tovorom JSON

Nosilnost:

Manjkajoče / prazne glave
Manjkajoča / prazna obvezna polja
Napačne vrednosti / Napačna oblika za obvezna polja
Različne kombinacije neveljavnih oblik e-pošte

Preverite:

Koda stanja odziva API: 400
Baza podatkov: V DB ni ustvarjen noben zapis

Preverite registracijo uporabnika

Ko je uporabnik registriran, se pogosto pošlje povezava za preverjanje na uporabnikov e-poštni naslov, da se zagotovi veljavnost e-pošte.

Uporabniki običajno morajo klikniti povezavo v e-poštnem sporočilu, da preverijo svoj e-poštni račun.

Testiramo lahko z veljavno in neveljavno povezavo za preverjanje.

Scenarij 3: Preverite registracijo uporabnika

Nosilnost: Veljavna zahteva

Preverite:

Koda stanja odziva API: 200
Baza podatkov: Preverite spremembe stanja uporabnika iz nepreverjene v preverjeno

4. scenarij: Preverite registracijo uporabnika

Nosilnost: Neveljavna Zahteva

Preverite:

Koda stanja odziva API: 400 ali 403
Baza podatkov: Preverite, da se stanje uporabnika ne spremeni. Uporabnik mora biti še vedno nepreverjen.
Vpiši se: Preverite, ali se uporabnik ne more prijaviti, če stanje ni preverjeno.

Ponovna registracija

5. scenarij: Ne bi mogel dvakrat registrirati istega uporabnika

Nosilnost: Veljavna zahteva

Preverite:

Koda stanja odziva API: Odvisno
Odzivno sporočilo: Sporočilo o napaki pravi, da uporabnik že obstaja. Opomba: iz varnostnih razlogov nekateri programi morda ne bodo vrnili tega sporočila.