100 тест-кейсов для страницы входа в систему

Страница входа – это не просто место, где пользователи получают доступ к своей учетной записи. Это критически важная страница, на которой должны соблюдаться требования безопасности, конфиденциальности и лучшие практики персонализации. На эту страницу всегда обращают особое внимание при проведении тестирования программного обеспечения или веб-тестирования. Если вы пытаетесь протестировать свою страницу входа в систему и не знаете, с чего начать, рекомендуем продолжить чтение, чтобы ознакомиться с тест-кейсами для страницы входа в систему, которые вы можете использовать в своей работе.

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

Друзья, поддержите нас вступлением в наш телеграм канал QaRocks. Там много туториалов, задач по автоматизации и книг по QA.

1. Позитивное тестирование страницы входа

Позитивные тест-кейсы следуют по “счастливому пути” (happy path), то есть проверяют, функционирует ли страница входа в систему так, как ожидается, при правильных входных данных. В этих тестах рассматриваются сценарии, в которых пользователи делают то, что должны делать, например:

Правильная комбинация имени пользователя и пароля успешно регистрирует пользователя
Тестирование с минимально допустимой длиной имени пользователя и пароля
Тестирование с именем пользователя и паролем, содержащим буквенно-цифровые символы
Успешный вход в систему с выбранной опцией “Запомнить меня”
Тестирование входа в систему с именем пользователя, содержащим как заглавные, так и строчные символы
Успешный вход в систему с использованием действительного адреса электронной почты в качестве имени пользователя
Успешный вход в систему с использованием действительного номера телефона в качестве имени пользователя
Успешный вход в систему с включенной многофакторной аутентификацией (MFA)
Проверка входа в систему с именем пользователя, содержащим специальные символы (например, @, #, $)
Успешный вход в систему с помощью аккаунтов в социальных сетях (если применимо)
Успешный вход в систему с использованием биометрической аутентификации (например, отпечаток пальца, распознавание лица)
Проверка входа в систему после сброса пароля, чтобы убедиться, что новый пароль работает
Успешный вход в систему после процесса восстановления учетной записи
Успешный вход в систему с настройками локализации (тестирование на разных языках)
Тестирование входа в систему с помощью различных браузеров (например, Chrome, Firefox, Edge).

2. Негативное тестирование страницы входа

Напротив, негативное тестирование страницы входа направлено на изучение сценариев, которые отклоняются от этого “счастливого пути”. Пользователи не всегда делают то, чего мы от них хотим. Иногда они делают неожиданные вещи, и хороший тестировщик понимает эту непредсказуемость, чтобы тестировать соответствующим образом. Некоторые распространенные негативные сценарии, которые вы должны протестировать на странице входа в систему, включают:

Ввод неправильного пароля для действительного имени пользователя
Ввод неправильного имени пользователя для правильного пароля.
Ввод пустого поля имени пользователя
Ввод пустого поля для пароля
Ввод имени пользователя, не существующего в системе
Ввод пароля, который не соответствует требованиям к надежности пароля
Тестирование входа в систему с использованием имен и паролей чрезмерной длины
Тестирование входа в систему с неправильным регистром (верхний/нижний регистр) в имени пользователя
Тестирование входа в систему с истекшими или деактивированными учетными записями пользователей
Тестирование входа в систему с приостановленными учетными записями пользователей
Несколько неудачных попыток входа в систему подряд приводят к блокировке учетной записи
Проверка входа в систему после того, как сессия истекла из-за неактивности
Проверка входа в систему с использованием неверных кодов многофакторной аутентификации (MFA)
Ввод недопустимых символов (например, скриптов) в поле имени пользователя или пароля
Тестирование входа в систему с ошибкой проверки CAPTCHA.

При негативном тестировании вам придется проявить творческий подход. Чем сложнее процесс входа в систему и аутентификации, тем больше тест-кейсов вам придется выполнить. Поставьте себя на место пользователя, который никогда раньше не взаимодействовал с системой. Станьте человеком, который постоянно совершает ошибки, и просто подумайте обо всех “плохих” возможностях, которые могут произойти в вашей системе или, в частности, на странице входа в систему.

3. Тестирование производительности

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

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

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

Вот несколько тестов производительности для страницы входа:

Измерьте и задокументируйте среднее время загрузки страницы входа в систему.
Проведите нагрузочное тестирование, чтобы определить максимальное количество одновременных авторизаций пользователей, которое может выдержать система.
Оцените время отклика страницы входа в систему в часы пиковой нагрузки.
Отслеживайте загрузку ресурсов сервера (процессор, память, пропускная способность) во время попыток входа в систему.
Протестируйте работу страницы входа в систему на различных браузерах и устройствах.
Проверьте работу страницы входа в систему при медленном интернет-соединении.
Измерьте время, необходимое для восстановления после неудачной попытки входа в систему.
Оцените производительность страницы входа в систему при высокой нагрузке на базу данных.
Проверьте работу страницы входа в систему во время распределенных атак типа “отказ в обслуживании” (DDoS).
Оцените способность системы обрабатывать большое количество одновременных попыток входа в систему.
Измерьте влияние ограничения скорости входа на производительность.
Проведите тестирование производительности с использованием различных методов аутентификации (например, пароль, MFA).
Проверьте работу страницы входа в систему с большим количеством неактивных учетных записей.
Оцените влияние валидации CAPTCHA на производительность страницы входа в систему.
Измерьте время, необходимое пользователю для получения кода аутентификации (MFA), если это применимо.

4. Тестирование безопасности

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

Например, на сайтах с различными уровнями доступа страница входа может быть “воротами”, разделяющими подписчиков и не подписчиков. У членов команды есть отдельная страница входа, на которой они могут ввести свои учетные данные для доступа к бэкенду системы. Поэтому тестирование безопасности страницы входа особенно важно.

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

Ниже приведены 15 популярных тестов безопасности для страницы входа в систему:

Проверьте систему на устойчивость к SQL-иньекциям, попытавшись внедрить SQL-код в поля имени пользователя и пароля.
Проверьте наличие уязвимостей межсайтового скриптинга (XSS), введя теги сценариев в полях для входа в систему.
Убедитесь, что на странице входа в систему используется HTTPS для шифрования передачи данных.
Проверьте уязвимость фиксации сеанса, попытавшись перехватить сеанс пользователя.
Убедитесь, что пароли пользователей надежно хешируются в базе данных.
Проверьте на кликджекинг (clickjacking) уязвимость путем наложения на страницу входа вредоносного содержимого.
Проверьте наличие механизмов защиты от атак грубой силы (блокировка аккаунта, ограничение скорости).
Убедитесь, что страница входа в систему не раскрывает информацию об имени пользователя.
Проверьте страницу на наличие уязвимости к атаке перечислением имен пользователя.
Убедитесь, что токены сессий и файлы cookie безопасно генерируются и хранятся.
Проверьте безопасность процессов сброса паролей и восстановления учетных записей.
Оцените устойчивость страницы входа в систему к DDoS-атакам.
Проверьте наличие небезопасных политик паролей (password policy), например, слабых требований к паролям.
Убедитесь, что сообщения об ошибках не содержат слишком много информации о сбое (например, “Неверное имя пользователя” вместо “Неверное имя пользователя и пароль”).
Оцените соответствие системы стандартам безопасности (например, OWASP Top Ten).

5. Как протестировать SQL-инъекцию на странице входа

SQL-инъекция – это когда вредоносный SQL-код вставляется в поля данных или данные веб-приложения, чтобы разрушить вашу базу данных. Это одна из самых распространенных техник веб-взлома в настоящее время, хотя она существует уже более 2 десятилетий.

Предположим, имеется страница входа на сайт, которая проверяет введенные имя пользователя и пароль по базе учетных данных пользователей с помощью SQL-запросов. URL страницы входа в систему имеет вид: “https://example.com/login”.

Бэкэнд-код, не проверяющий должным образом вводимые пользователем данные, будет очень уязвим для таких атак. Вот упрощенное представление уязвимого кода, написанного на Python с использованием SQL:

username = get_user_input()  # Simulated user input
password = get_user_input()  # Simulated user input
# Constructing the SQL query
query = "SELECT * FROM users WHERE username='" + username + "' AND password='" + password + "'"
 Click to copy

В приведенном выше фрагменте кода есть две уязвимости:

Переменные имени пользователя и пароля получаются из полей ввода пользователя на форме входа в систему без дополнительной проверки.
SQL-запрос строится путем конкатенации вводимых пользователем данных непосредственно в строку запроса. Это означает, что злоумышленник может манипулировать полями ввода, чтобы внедрить вредоносный SQL-код.

Злоумышленник может использовать эти уязвимости для обхода авторизации и потенциального получения несанкционированного доступа к системе в 2 этапа::

В поле “Имя пользователя” злоумышленник вводит действительное имя пользователя (например, “user”).
В поле для ввода пароля злоумышленник вводит следующие данные: ‘ OR ‘1’=’1′

Построенный SQL-запрос будет выглядеть так:

SELECT * FROM users WHERE username='user' AND password='' OR '1'='1'
 Click to copy

В SQL ‘1’=’1′ всегда истинно, поэтому этот модифицированный запрос эффективно обходит проверку пароля. Приложение извлекает все записи, где имя пользователя равно ‘user’ и где ‘1’ равно ‘1’, что соответствует всем строкам.

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

Вот несколько тестов на SQL-инъекции, которые вы можете опробовать на своей странице входа в систему:

1=1 кавычки: в полях имени пользователя и пароля попробуйте ввести одинарные кавычки (‘ или ‘1=1’), чтобы проверить, уязвимо ли приложение к SQL-инъекции. Часть ‘1=1’ является распространенной полезной нагрузкой SQL Injection, которая часто возвращает true, эффективно обходя логин.
Union SQL-инъекции: в поле имени пользователя или пароля попробуйте использовать оператор UNION SELECT, чтобы проверить, можно ли извлечь данные из базы данных. Например, вы можете ввести что-то вроде ‘ UNION SELECT username, password FROM users–.
SQL-инъекции, основанные на ошибке (Error-Based SQL Injection): попробуйте ввести данные, которые, как вы знаете, вызовут SQL-ошибку. Например, ‘ OR 1=1; — должен быть обработан без вывода сообщений об ошибках базы данных. Если приложение отображает подробные SQL-ошибки, оно может быть уязвимо.
Слепые SQL-инъекции, основанные на времени (Time-Based Blind SQL Injection): проверка на слепую SQL-инъекцию с использованием полезной нагрузки, основанной на времени. Например, ‘ OR IF(1=1, SLEEP(5), 0); –. Если при использовании этой полезной нагрузки задержка входа в систему будет заметна, это может свидетельствовать о наличии уязвимости слепой SQL-инъекции.
Кодирование ввода: попытка обойти проверку ввода путем кодирования полезных нагрузок SQL-инъекций. Например, попробуйте кодировку URL, HTML или двойную кодировку URL.
Советуйтесь с OWASP: обратитесь к руководству и методологии тестирования OWASP (Open Web Application Security Project) для разработки комплексных стратегий тестирования на SQL-инъекции.

6. Тестирование страницы входа в Gmail

Тесты для страницы входа в Gmail аналогичны любым другим типам страниц входа:

Убедитесь, что страница входа в Gmail доступна с главной страницы Gmail.
Проверьте вход в систему с помощью действительных учетных данных Gmail.
Протестируйте вход с неверным паролем учетной записи Gmail.
Протестируйте вход с неправильным именем пользователя/почтой учетной записи Gmail.
Протестируйте вход в систему с помощью учетной записи Gmail, в которой включена двухфакторная аутентификация (2FA).
Убедитесь, что на странице входа в Gmail опция “Оставаться в системе” работает как положено.
Проверьте ссылку “Забыли пароль?” на функциональность восстановления пароля.
Протестируйте вход в систему, используя опцию “Войти с помощью Google” (если она доступна).
Убедитесь, что страница входа в Gmail поддерживает несколько языков.
Протестируйте отзывчивость страницы входа на различных устройствах (десктопных, мобильных, планшетных).
Проверьте наличие функций безопасности, таких как CAPTCHA или механизмы защиты от ботов.
Проверьте производительность страницы входа в Gmail в периоды пиковой нагрузки.
Убедитесь, что управление сеансами на странице входа в Gmail безопасно.
Проверьте поведение страницы входа в систему при отключенном JavaScript.
Протестируйте поведение ссылки “Создать аккаунт” при регистрации нового аккаунта Gmail.

7. Тестирование страницы входа в мобильное приложение

Здесь мы переходим к области мобильного тестирования, которое сопряжено со своими уникальными сложностями. Например, эти устройства имеют широкий спектр моделей, разрешений экранов, а также технологий, используемых только в мобильных устройствах, которые тестировщикам необходимо учитывать. Вот несколько примеров тестирования страницы входа в систему, в частности, для мобильных приложений:

Протестируйте макет и элементы страницы входа в систему на различных мобильных устройствах (например, телефонах, планшетах).
Убедитесь, что страница входа в мобильное приложение поддерживает книжную и альбомную ориентацию.
Протестируйте вход с действительными учетными данными на странице входа в мобильное приложение.
Протестируйте вход с неверными учетными данными на странице входа в мобильное приложение.
Протестируйте вход в систему, используя специальные символы и знаки в полях имени пользователя и пароля.
Протестируйте функцию “Забыли пароль?” на странице входа в мобильное приложение.
Убедитесь, что страница входа в мобильное приложение адаптируется к различным размерам экрана.
Протестируйте поведение опции “Запомнить меня” на странице входа в мобильное приложение.
Протестируйте поведение опции “Оставаться в системе” на странице входа в мобильное приложение.
Протестируйте вход в систему с помощью многофакторной аутентификации (MFA) на странице входа в мобильное приложение.
Убедитесь, что страница входа в мобильное приложение интегрируется с биометрической аутентификацией устройства (например, отпечаток пальца, распознавание лица).
Проверьте работу страницы входа в систему мобильного приложения в различных мобильных сетях (3G, 4G, Wi-Fi).
Протестируйте страницу входа в мобильное приложение на разных версиях мобильной операционной системы (например, Android, iOS).
Убедитесь, что страница входа в мобильное приложение корректно работает, когда устройство находится в авиарежиме.
Протестируйте поведение страницы входа в систему мобильного приложения, когда на устройстве ограничено место для хранения данных.

8. Тест-кейсы BDD для страницы входа

BDD-тестирование (Behavior Driven Development, разработка через поведение) – это подход, при котором тестировщики пишут тестовые примеры на простом языке (обычно Геркин), который может понять даже человек без технических знаний. Обычно тестовый пример BDD состоит из 3 утверждений:

Утверждение Given (Дано) задает исходный контекст поведения и определяет начальную точку системы.
Утверждение When (Когда) описывает триггер, который приводит к изменению или поведению системы.
Утверждение Then (Тогда) определяет ожидаемый результат, который должен наблюдаться после события, упомянутого в утверждении When.

Вот 10 тест-кейсов для страницы входа в систему, написанных в формате Gherkin:

Тест-кейс 1: успешный вход

При вводе правильных имени пользователя и пароля,