Собес: 19.1 Как протестировать истечение срока токена (Token Expiration)
#QA #тестирование #токены #собеседованиеQA #безопасность #API #тестировщик #обучениеIT #качествоПО 19.1 Привести пример тесткейса для проверки истечения срока токена В этом ролике мы разберем один из самых популярных вопросов на собеседовании для QA-инженеров — *проверку просроченных токенов* . Вы узнаете, как составить структурированный и глубокий ответ, который покажет ваше понимание безопасности и архитектуры приложений. Мы разберем универсальную логику из трех шагов: 1. *Получили* — аутентификация и проверка валидного токена. 2. *Подождали* — как управлять временем жизни токена в тестовой среде. 3. *Проверили отказ* — ожидаемая реакция системы. В видео мы обсудим: * *API-тестирование* : почему это самый надежный способ проверки бэкенда, и на какие коды ошибок (401 или 403) стоит смотреть. * *UI-тестирование* : как должен выглядеть пользовательский опыт при истечении сессии (редирект на логин). * *Безопасность* : почему в теле ответа с ошибкой не должно быть ни байта защищенных данных. [00:00] — Почему проверка истечения токена — это критический тест на безопасность [01:08] — Фундаментальная логика: Получили — Подождали — Проверили отказ [01:55] — Практика на уровне API: самый прямой и надежный способ проверки [02:40] — Ожидаемый результат: коды 401/403 и отсутствие утечки данных [03:29] — Практика на уровне UI: тестируем пользовательский опыт (UX) [04:14] — Ожидаемый результат: вежливый «выход» и редирект на страницу входа [04:53] — Идеальный структурированный ответ для собеседования [05:22] — Шпаргалка: 5 ключевых тезисов, которые нужно запомнить [05:55] — Бонусный вопрос для Senior: автоматизация в CI/CD без ожидания Пример покажу в формате, который можно почти дословно рассказывать на собеседовании и использовать как основу для реального тест‑кейса. *** ## Идея теста простыми словами Цель: убедиться, что после истечения срока действия токена пользователь теряет доступ к защищённым ресурсам и система просит его перелогиниться. Можно тестировать через API или через UI, но логика одна и та же: 1) получили токен; 2) подождали, пока он «протухнет» (или подменили время/конфигурацию); 3) проверили, что с этим токеном запрос больше не принимается. *** ## Вариант 1: API‑тест (pytest) Название: «Проверка отказа в доступе по истёкшему токену (API)». Предусловия: - Есть тестовый пользователь с валидным логином/паролем. - Для тестового окружения известен короткий срок жизни access‑токена (например, 1–2 минуты) или есть возможность выдать токен с кастомным временем жизни. Шаги: 1. Отправить запрос на логин `/auth/login` с валидными логином и паролем. 2. Из ответа сохранить `access_token` и зафиксировать текущее время. 3. Убедиться, что с этим токеном защищённый эндпоинт (например, `GET /profile`) пока доступен: отправить запрос с заголовком `Authorization: Bearer `, получить успешный ответ (200). 4. Подождать дольше, чем срок жизни токена (например, 2–3 минуты) или искусственно сдвинуть время, если это предусмотрено тестовой конфигурацией. 5. Повторно вызвать тот же защищённый эндпоинт `GET /profile` с тем же токеном. Ожидаемый результат: - Шаг 3: ответ 200, данные профиля возвращаются. - Шаг 5: ответ 401 (Unauthorized) или 403 (Forbidden) — в зависимости от дизайна API, тело содержит информацию о том, что токен просрочен/недействителен. - Никаких данных, предназначенных только для авторизованных пользователей, в ответе нет. *** ## Вариант 2: UI‑тест (Playwright) Название: «Проверка автоматического разлогина после истечения токена (UI)». Предусловия: - На стенде включён короткий TTL для токена (например, 5–10 минут). - Есть страница личного кабинета, доступная только авторизованным пользователям. Шаги: 1. Открыть страницу логина и войти под тестовым пользователем. 2. Убедиться, что открылась страница личного кабинета (например, проверкой заголовка или элемента профиля). 3. Не выполнять никаких действий, дождаться истечения срока токена (или имитировать бездействие заданное время; можно параллельно отслеживать network‑запросы). 4. После истечения срока: - обновить страницу; - либо перейти на другой защищённый раздел (напр. «Мои заказы»). Ожидаемый результат: - До истечения срока пользователь остаётся авторизованным. - После истечения срока: - пользователь перенаправляется на страницу логина, либо - появляется сообщение о необходимости повторной авторизации, а доступ к защищённому контенту блокируется. *** ## Что можно проговорить как senior QA Когда тебя попросят «пример тесткейса», можно кратко резюмировать: «Для проверки истечения срока токена я делаю сценарий в два этапа. Сначала через API или UI получаю валидный токен, убеждаюсь, что с ним доступ к защищённому ресурсу есть. Затем жду, пока срок жизни истечёт (или использую тестовый токен с очень маленьким TTL), и повторяю тот же запрос. Ожидаю, что сервер вернёт 401/403, а UI перекинет пользователя на логин или покажет сообщение о необходимости войти заново. Важно дополнительно убедиться, что никаких защищённых данных при этом не возвращается.»
#QA #тестирование #токены #собеседованиеQA #безопасность #API #тестировщик #обучениеIT #качествоПО 19.1 Привести пример тесткейса для проверки истечения срока токена В этом ролике мы разберем один из самых популярных вопросов на собеседовании для QA-инженеров — *проверку просроченных токенов* . Вы узнаете, как составить структурированный и глубокий ответ, который покажет ваше понимание безопасности и архитектуры приложений. Мы разберем универсальную логику из трех шагов: 1. *Получили* — аутентификация и проверка валидного токена. 2. *Подождали* — как управлять временем жизни токена в тестовой среде. 3. *Проверили отказ* — ожидаемая реакция системы. В видео мы обсудим: * *API-тестирование* : почему это самый надежный способ проверки бэкенда, и на какие коды ошибок (401 или 403) стоит смотреть. * *UI-тестирование* : как должен выглядеть пользовательский опыт при истечении сессии (редирект на логин). * *Безопасность* : почему в теле ответа с ошибкой не должно быть ни байта защищенных данных. [00:00] — Почему проверка истечения токена — это критический тест на безопасность [01:08] — Фундаментальная логика: Получили — Подождали — Проверили отказ [01:55] — Практика на уровне API: самый прямой и надежный способ проверки [02:40] — Ожидаемый результат: коды 401/403 и отсутствие утечки данных [03:29] — Практика на уровне UI: тестируем пользовательский опыт (UX) [04:14] — Ожидаемый результат: вежливый «выход» и редирект на страницу входа [04:53] — Идеальный структурированный ответ для собеседования [05:22] — Шпаргалка: 5 ключевых тезисов, которые нужно запомнить [05:55] — Бонусный вопрос для Senior: автоматизация в CI/CD без ожидания Пример покажу в формате, который можно почти дословно рассказывать на собеседовании и использовать как основу для реального тест‑кейса. *** ## Идея теста простыми словами Цель: убедиться, что после истечения срока действия токена пользователь теряет доступ к защищённым ресурсам и система просит его перелогиниться. Можно тестировать через API или через UI, но логика одна и та же: 1) получили токен; 2) подождали, пока он «протухнет» (или подменили время/конфигурацию); 3) проверили, что с этим токеном запрос больше не принимается. *** ## Вариант 1: API‑тест (pytest) Название: «Проверка отказа в доступе по истёкшему токену (API)». Предусловия: - Есть тестовый пользователь с валидным логином/паролем. - Для тестового окружения известен короткий срок жизни access‑токена (например, 1–2 минуты) или есть возможность выдать токен с кастомным временем жизни. Шаги: 1. Отправить запрос на логин `/auth/login` с валидными логином и паролем. 2. Из ответа сохранить `access_token` и зафиксировать текущее время. 3. Убедиться, что с этим токеном защищённый эндпоинт (например, `GET /profile`) пока доступен: отправить запрос с заголовком `Authorization: Bearer `, получить успешный ответ (200). 4. Подождать дольше, чем срок жизни токена (например, 2–3 минуты) или искусственно сдвинуть время, если это предусмотрено тестовой конфигурацией. 5. Повторно вызвать тот же защищённый эндпоинт `GET /profile` с тем же токеном. Ожидаемый результат: - Шаг 3: ответ 200, данные профиля возвращаются. - Шаг 5: ответ 401 (Unauthorized) или 403 (Forbidden) — в зависимости от дизайна API, тело содержит информацию о том, что токен просрочен/недействителен. - Никаких данных, предназначенных только для авторизованных пользователей, в ответе нет. *** ## Вариант 2: UI‑тест (Playwright) Название: «Проверка автоматического разлогина после истечения токена (UI)». Предусловия: - На стенде включён короткий TTL для токена (например, 5–10 минут). - Есть страница личного кабинета, доступная только авторизованным пользователям. Шаги: 1. Открыть страницу логина и войти под тестовым пользователем. 2. Убедиться, что открылась страница личного кабинета (например, проверкой заголовка или элемента профиля). 3. Не выполнять никаких действий, дождаться истечения срока токена (или имитировать бездействие заданное время; можно параллельно отслеживать network‑запросы). 4. После истечения срока: - обновить страницу; - либо перейти на другой защищённый раздел (напр. «Мои заказы»). Ожидаемый результат: - До истечения срока пользователь остаётся авторизованным. - После истечения срока: - пользователь перенаправляется на страницу логина, либо - появляется сообщение о необходимости повторной авторизации, а доступ к защищённому контенту блокируется. *** ## Что можно проговорить как senior QA Когда тебя попросят «пример тесткейса», можно кратко резюмировать: «Для проверки истечения срока токена я делаю сценарий в два этапа. Сначала через API или UI получаю валидный токен, убеждаюсь, что с ним доступ к защищённому ресурсу есть. Затем жду, пока срок жизни истечёт (или использую тестовый токен с очень маленьким TTL), и повторяю тот же запрос. Ожидаю, что сервер вернёт 401/403, а UI перекинет пользователя на логин или покажет сообщение о необходимости войти заново. Важно дополнительно убедиться, что никаких защищённых данных при этом не возвращается.»