Сценарии за регистрация на потребители и тестови случаи

Много уеб приложения, като уебсайтове за електронна търговия и уеб портали, осигуряват функционалност за регистрация на потребители и вход за своите потребители.

Когато бъдете помолени да тестваме поток на регистрация на потребител, трябва да имаме набор от сценарии, които можем лесно да използваме за упражняване на функцията за регистрация.

Целта на тази публикация е да ви предостави списък с често срещани сценарии и тестови случаи, които трябва да бъдат взети предвид при тестване на функционалност за регистрация на потребител.




Сценарии за регистрация на потребителите

Процесът на регистрация е част от управление на самоличността и достъпа , IDAM.

Нека помислим, че имаме API за регистрация, който може да бъде достъпен чрез /register крайна точка.


/register крайната точка приема JSON полезен товар от формата:

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

Сега ще тестваме това /register крайна точка. Какви сценарии можем да измислим?

Валидни полезни товари

Сценарий 1: Трябва да може да регистрира потребител с валиден полезен товар при заявка за регистрация

Полезен товар:


  • Всички полета
  • Всички задължителни полета

Проверете:

  • Код на състоянието на отговора на API: 200
  • База данни: Потребителят трябва да съществува в базата данни
Забележка:Не забравяйте да тествате с кирилични символи, апострофи и тирета. Това обикновено са разрешени и валидни символи, но някои системи ги обработват по различен начин.

Невалидни полезни товари

Сценарий 2: Не бива да може да регистрира потребител с неправилен JSON полезен товар

Полезен товар:

  • Липсващи / празни заглавки
  • Липсващи / празни задължителни полета
  • Неправилни стойности / Неправилен формат за задължителни полета
  • Различни комбинации от невалидни имейл формати

Проверете:


  • Код на състоянието на отговора на API: 400
  • База данни: В DB не се създава запис

Проверете регистрацията на потребителя

Доста често, когато потребител е регистриран, на имейл адреса на потребителя се изпраща връзка за потвърждение, за да се гарантира, че имейлът е валиден.

Потребителите обикновено трябва да щракнат върху връзката в имейла, за да потвърдят своя имейл акаунт.

Можем да тестваме с валидна и невалидна връзка за потвърждение.

Сценарий 3: Проверете регистрацията на потребителя


Полезен товар: Валидна заявка

Проверете:

  • Код на състоянието на отговора на API: 200
  • База данни: Проверете промените в състоянието на потребителя от непроверени в потвърдени

Сценарий 4: Проверете регистрацията на потребителя

Полезен товар: Невалидна заявка


Проверете:

  • Код на състоянието на отговора на API: 400 или 403
  • База данни: Проверка на състоянието на потребителя не се променя. Потребителят все още трябва да е непроверен.
  • Влизам: Проверете дали потребителят не може да влезе, ако състоянието е непроверено.

Пререгистрация

Сценарий 5: Не бива да може да регистрира два пъти един и същ потребител

Полезен товар: Валидна заявка

Проверете:

  • Код на състоянието на отговора на API: Зависи
  • Съобщение за отговор: Съобщение за грешка казва, че потребителят вече съществува. Забележка: от съображения за сигурност някои приложения може да не върнат това съобщение.

Ограничени пароли

Ограничени пароли са тези, които вече са хакнати и поставени на pastebins. HIBP (HaveIBeenPawned.com) има списък с хакнати пароли.

Сценарий 6: Не бива да може да регистрира потребител с ограничени пароли

Полезен товар: Всички полета са валидни, но ограничена парола

Проверете:

  • Код на състоянието на отговора на API: 400
  • Съобщение за отговор: Проверете дали съобщението за грешка е подходящо

Лесни за отгатване пароли

Има списък с пароли, които са често срещани и лесни за хакване, така че трябва да се избягват при регистрацията на потребителя.

Сценарий 7: Не бива да може да регистрира потребител с лесни за отгатване пароли

Полезен товар: Всички полета са валидни, но лесни за отгатване парола

Проверете:

  • Код на състоянието на отговора на API: 400
  • Съобщение за отговор: Проверете дали съобщението за грешка е подходящо

Парола Същата като потребителското име

Сценарий 8: Не бива да може да задава парола, същата като потребителското име

Полезен товар: Всички полета са валидни, но паролата е същата като потребителското име

Проверете:

  • Код на състоянието на отговора на API: 400
  • Съобщение за отговор: Проверете дали съобщението за грешка е подходящо


Обобщение

Изискванията на всяко приложение са различни и горните сценарии могат или не могат да бъдат приложими за функцията за регистрация, която тествате.

Но се надяваме, че тези сценарии могат да ви дадат насоки за това какво да търсите при тестване на потребителски поток за регистрация.