Сценарии регистрации пользователей и тестовые примеры

Многие веб-приложения, такие как веб-сайты электронной коммерции и веб-порталы, предоставляют своим пользователям функции регистрации и входа в систему.

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

Цель этой публикации - предоставить вам список распространенных сценариев и тестовых случаев, которые необходимо учитывать при тестировании функции регистрации пользователей.




Сценарии регистрации пользователей

Процесс регистрации является частью управление идентификацией и доступом , IDAM.

Предположим, у нас есть API регистрации, доступ к которому можно получить через /register конечная точка.


/register конечная точка принимает полезную нагрузку JSON в форме:

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

Теперь мы собираемся протестировать это /register конечная точка. Какие сценарии можно придумать?

Действительные полезные данные

Сценарий 1: Должна быть возможность регистрировать пользователя с действительной полезной нагрузкой запроса на регистрацию.

Полезная нагрузка:


  • Все поля
  • Все обязательные поля

Проверять:

  • Код состояния ответа API: 200
  • База данных: Пользователь должен существовать в базе данных
Примечание:Не забудьте использовать кириллические символы, апострофы и дефисы. Обычно это разрешенные и допустимые символы, но некоторые системы обрабатывают их по-другому.

Недействительные полезные данные

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

Полезная нагрузка:

  • Отсутствующие / пустые заголовки
  • Отсутствующие / пустые обязательные поля
  • Неправильные значения / неправильный формат обязательных полей
  • Различные комбинации недопустимых форматов электронной почты

Проверять:


  • Код состояния ответа API: 400
  • База данных: Запись в БД не создается

Проверить регистрацию пользователя

Довольно часто, когда пользователь зарегистрирован, на его адрес электронной почты отправляется ссылка для подтверждения, чтобы убедиться, что электронная почта действительна.

Обычно пользователям необходимо щелкнуть ссылку в электронном письме, чтобы подтвердить свою учетную запись электронной почты.

Мы можем протестировать с действующей и недействительной проверочной ссылкой.

Сценарий 3: Подтвердите регистрацию пользователя


Полезная нагрузка: Действительный запрос

Проверять:

  • Код состояния ответа API: 200
  • База данных: Проверить изменение статуса пользователя с непроверенного на проверенный

Сценарий 4: Подтвердите регистрацию пользователя

Полезная нагрузка: Неверный запрос


Проверять:

  • Код состояния ответа API: 400 или 403
  • База данных: Проверить статус пользователя не меняется. Пользователь по-прежнему не должен быть подтвержден.
  • Авторизоваться: Проверить, что пользователь не может войти в систему, если статус не подтвержден.

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

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

Полезная нагрузка: Действительный запрос

Проверять:

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

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

Пароли с ограниченным доступом - это те, которые уже были взломаны и установлены на pastebins. HIBP (HaveIBeenPawned.com) содержит список взломанных паролей.

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

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

Проверять:

  • Код состояния ответа API: 400
  • Ответное сообщение: Проверьте правильность сообщения об ошибке

Легко угадывать пароли

Существует список общих паролей, которые легко взломать, поэтому их следует избегать при регистрации пользователей.

Сценарий 7: Невозможно зарегистрировать пользователя с легко угадываемым паролем.

Полезная нагрузка: Все поля действительны, но пароль легко угадывается

Проверять:

  • Код состояния ответа API: 400
  • Ответное сообщение: Проверьте правильность сообщения об ошибке

Пароль такой же, как имя пользователя

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

Полезная нагрузка: Все поля действительны, но пароль такой же, как имя пользователя

Проверять:

  • Код состояния ответа API: 400
  • Ответное сообщение: Проверьте правильность сообщения об ошибке


Резюме

Требования к каждому приложению различны, и описанные выше сценарии могут или не могут быть применимы к функции регистрации, которую вы тестируете.

Но, надеюсь, эти сценарии могут дать вам некоторое представление о том, на что обращать внимание при тестировании процесса регистрации пользователей.