Contents
Attach file
Вебинар в рамках курса по подготовке на собеседования
Вебинар в рамках курса по подготовке на собеседования
План Вебинара:
О себе
Что такое кэш?
Что такое куки?
Чем отличаются кэш ( cache ) и куки ( cookie )?
Как очистить кэш и куки в разных браузерах и устройствах?
Как тестировать кэш ( cache ) и куки ( cookie )?
Разбор практического примера использования cookie на сайте
Разбор практического примера использования cookie в Postman
Redis как инструмент работы с кешированием - пример
Разбор ситуационного вопроса
Дополнительная литература
Ваши вопросы
Кэш (Cache):
Браузерный кэш: Хранит статические ресурсы (картинки, CSS, JS файлы). Управляется HTTP-заголовками (Cache-Control, Expires, ETag, Last-Modified). Ускоряет загрузку страниц при повторных визитах.
Серверный кэш (например, Redis): Хранит результаты запросов к базе данных, вычисленные данные, фрагменты страниц. Снижает нагрузку на сервер и базу данных.
Local Storage / Session Storage: Это Web Storage API, не совсем кэш в классическом понимании статических ресурсов. Используются для хранения пар ключ-значение на стороне клиента. Local Storage хранит данные постоянно (до ручной очистки), Session Storage – на время сессии (до закрытия вкладки/браузера). Часто используются для хранения пользовательских настроек, состояния UI, временных данных форм.
Куки (Cookies):
Небольшие текстовые файлы, хранящиеся в браузере, отправляемые с каждым HTTP-запросом к соответствующему домену.
Используются для: аутентификации (сессионные куки, токены), персонализации (настройки), отслеживания (аналитика).
Атрибуты куки:
Expires: Абсолютная дата истечения срока действия.
Max-Age: Время жизни в секундах с момента установки. Если оба (Expires и Max-Age) установлены, Max-Age имеет приоритет.
Domain: Домен, для которого куки действительны.
Path: Путь на сервере, для которого куки действительны.
HttpOnly: Запрещает доступ к куки через JavaScript (защита от XSS).
Secure: Куки будут отправляться только по HTTPS-соединению.
SameSite (Strict, Lax, None): Контролирует, когда куки отправляются с межсайтовыми запросами (защита от CSRF).
Тестирование:
Очистка: Важный первый шаг при отладке многих веб-проблем.
DevTools: Основной инструмент для проверки кэша и куки (Network, Application).
Postman: Удобен для API-тестирования, автоматически управляет куками (можно отключить), позволяет инспектировать заголовки.
Redis: Для тестирования серверного кэша нужны инструменты типа Redis Insight или команды Redis CLI для проверки наличия ключей, их значений и TTL.
Видео можно смотреть на 1,5x скорости)
Краткое содержание лекции в текстовом формате.
Всем добрый день! Сегодня я хочу рассказать про разбор вопросов на кэш и куки в рамках собеседований и вне их. Мы тестируем кэш и куки, но редко задают вопрос, как именно мы это делаем на проектах. Хочется углубленно затронуть эту тему, чтобы у вас было понимание. Возможно, такой вопрос скоро встретится на собеседовании: не просто чем отличаются кэш и куки и их основные определения, а как именно тестировать кэш и куки в DevTools, в Postman, либо с использованием каких-то инструментов.
На основании сегодняшнего вебинара мы разберем с вами немного Redis, Postman, и сейчас будет немного теории, связанной с определениями "кэш" и "куки".
Немного о себе.
Что такое кэш?
Что такое куки?
Чем отличаются кэш и куки?
Как очистить кэш и куки в разных браузерах и устройствах (покажу примеры).
Как тестировать кэш и куки.
Разбор практического примера использования куки на сайте.
Разбор практического примера использования куки в Postman.
Redis как инструмент работы с кэшированием (и не только, а также с сессиями). В FinTech, где я работаю, при авторизации в систему генерируется ID сессии, и этот ID сессии мы используем в других запросах. То есть бывает авторизация через куки, соответственно, через сессии.
Разбор ситуационного вопроса (пару примеров, потом самостоятельно ознакомитесь).
Дополнительная литература.
Если успеем, ваши вопросы.
Я 6 лет была преподавателем по физике. Почти 10 лет в тестировании – как раз 15 июня, когда собираюсь провести следующий вебинар, у меня будет 10 лет в этой сфере. Сейчас я мама в декрете, текущая должность – главный инженер по тестированию в Сбер. Веду блог по тестированию "protestinginfo". Мне нравится собирать информацию по тестированию, делиться знаниями с людьми, сочинять тесты (скоро будут тесты на канале).
Хочу напомнить про самый главный файл с вопросами, который я разбираю в соцсетях. Там есть уже большая часть разобранных вопросов, поэтому предлагаю зайти потом в этот файлик и посмотреть вопрос и ответ к нему. Также есть часть вопросов, которые еще являются неразобранными, и я буду потихоньку их разбирать и отвечать, как правильно, по моим рекомендациям, какой ответ хочет услышать собеседующий.
Здесь чисто теория. Ответ, который я здесь предоставляю, мне в целом нравится.
Что такое кэш?
Кэш – это временное хранилище данных, которое позволяет ускорить доступ к часто используемой информации. Когда система, приложение или браузер обращается к данным, которые уже были получены ранее, кэш позволяет не запрашивать их заново, а использовать сохраненную копию. Это снижает нагрузку на сеть или сервер и ускоряет работу. Кэш применяется для сохранения временных данных веб-страниц, таких как изображения, HTML-код, стили и скрипты. Кэш ускоряет повторную загрузку сайта.
В целом, такой ответ хотят услышать. Можно сказать и общими словами: когда пользователь впервые заходит на веб-страницу, браузер сохраняет часть ее ресурсов локально. При следующем визите эти данные подгружаются из кэша, а не запрашиваются повторно с сервера. Это ускоряет загрузку сайта и снижает нагрузку.
Что такое куки?
Это небольшие текстовые файлы, которые веб-сайты сохраняют в браузере пользователя. Они служат для хранения информации, связанной с посещением сайта, чтобы в будущем упростить и персонализировать взаимодействие пользователя с этим сайтом. Куки предназначены для сохранения небольших объемов данных, позволяющих сайту распознавать пользователя при повторных визитах. Это может быть информация об авторизации, пользовательских настройках, предпочтениях, содержимом корзины и других параметрах, которые делают работу с сайтом более удобной и индивидуальной.
Первой части определения по кукам будет достаточно.
Если разбирать в рамках ситуационных вопросов, то когда задают любой такой вопрос, хотят услышать, что первым делом вы пойдете чистить кэш и куки. У нас на тестировании на стендах (в финтехе), когда мы тестируем какую-то функциональность, обязательно нужно почистить кэш, потому что иногда возвращаются ошибки, и для их устранения достаточно это сделать. Либо бывают проблемы, что сохраняются куки (данные о пользователе), и эти данные имеют разные логины, но одинаковые пароли. Это частая проблема на тестовых стендах: мы заходим под одним пользователем, а видим, что нужная функциональность недоступна, потому что на самом деле мы зашли под другим. Поэтому также важно чистить куки.
Я подобрала соответствующие пункты:
Кэш:
Основная цель: Сохранить копии файлов сайта (изображения, стили, скрипты) для ускорения повторной загрузки страниц.
Где хранится: В локальной папке браузера (покажу обязательно).
Срок хранения: Устанавливается сервером через специальные заголовки. По истечении срока данные обновляются.
Используется для: Ускорения загрузки и снижения нагрузки на сервер.
Пример: Вы заходите на сайт во второй раз, и он открывается быстрее, потому что браузер использует ранее загруженные ресурсы.
Куки:
Основная цель: Хранят небольшие данные (например, логин, настройки пользователя, содержимое корзины).
Где хранится: В виде текстовых записей на компьютере пользователя.
Срок хранения: Задается сервером. Куки бывают временными (до закрытия браузера) и постоянными (с датой истечения). Покажу, как это выглядит в DevTools.
Используются для: Аутентификации, запоминания настроек, отслеживания сессий.
Пример: После входа на сайт вас не просят логин и пароль снова; сайт узнает вас по сохраненной куке.
Здесь краткая заметка. На мобильном устройстве, если рассмотреть Telegram, вы заходите в настройки, находите "Данные и Память", там "Использование памяти" и "Очистить весь кэш".
Мы связаны с тестированием, поэтому первым делом покажу, как я в целом очищаю кэш и куки. Мы сегодня будем разбирать сайтик, связанный с тортиками, потому что здесь авторизация происходит через куки.
Очистка кэша (Google Chrome):
Нажимаем на значок обновления странички правой кнопкой мыши.
Выбираем "Очистка кэша и жесткая перезагрузка".
Происходит очистка кэша для соответствующего сайта.
Быстрая очистка куки (Google Chrome):
Нажимаем на значок замка слева от URL.
Выбираем "Файлы cookie и данные сайтов" -> "Управлять данными сайтов на устройстве".
Находим нужный сайт и нажимаем на корзиночку "Удалить".
Нажимаем "Готово" и перезагружаем страницу.
Страница вернется к состоянию по умолчанию.
Можно почистить полностью кэш и куки через историю браузера ("История" -> "Очистить историю" -> выбрать кэш и куки), но это дольше.
Очистка через DevTools (Google Chrome):
Открываем DevTools (F12).
Переходим на вкладку "Application".
Здесь есть "Local Storage" и "Session Storage".
Local Storage: Хранит данные почти всегда.
Session Storage: Хранит данные в рамках определенной сессии; очищается при закрытии вкладки.
Для очистки: правая кнопка мыши на хранилище -> "Clear".
Также есть раздел "Cookies", где можно их чистить. Они появятся после авторизации.
Очистка в Firefox:
Открываем инструменты разработчика.
Вкладка называется "Хранилище" (Storage).
Есть "Локальное хранилище" (Local Storage) и "Сессионное хранилище" (Session Storage). Очищаем через "Delete All".
Для куки: нажимаем на значок замочка левой кнопкой мыши -> "Очистить куки и данные сайтов" -> "Удалить".
Что важно проверить (теория):
Создание куки: Устанавливаются ли куки при входе пользователя? Создаются ли нужные значения (например, токен авторизации, идентификатор сессии)? Сегодня вы это увидите.
Чтение и передача куки: Передаются ли куки обратно на сервер при каждом запросе? Отправляются ли только нужные куки, нет ли лишнего мусора?
Жизненный цикл: Удаляются ли куки после выхода из системы? Работают ли временные (сессионные) куки? Учитывается ли срок действия (Expires, Max-Age)? Знаю, что сейчас спрашивают такие вопросы именно по кукам: что такое куки, чем отличаются от кэша, и где можно посмотреть Expires (время жизни кук). Покажу несколько мест.
Безопасность:
Проставлены ли флаги безопасности?
HttpOnly: куки недоступны через JavaScript.
Secure: куки передаются только по HTTPS.
SameSite (Strict или Lax): защита от CSRF (Cross-Site Request Forgery). Это редко проверяется, но это в рамках безопасности.
Хранение пользовательских предпочтений: Запоминается ли выбранная тема, язык, настройки.
Как тестировать куки в браузере (практика):
Открыть DevTools.
Выбрать вкладку "Application", раздел "Cookies", выбрать домен.
Изучить список куки: проверить имя, значение, дату истечения (Expires), путь (Path), домен (Domain), флаги (HttpOnly, Secure, SameSite). Обычно эти куки и их названия описываются в документации.
Удалить или изменить куки вручную.
Обновить страницу и проверить реакцию сайта.
Практический пример с сайтом "тортиков":
Я сейчас переключусь на локаль. Этот сайтик я демонстрирую в рамках курса для исследовательского тестирования.
Есть форма логина. Прежде чем авторизоваться, нужно зарегистрировать нового пользователя.
Открою вкладку "Network" в DevTools, чтобы отслеживать запросы.
Регистрируюсь (ввожу данные, нажимаю "Создать аккаунт").
В Network появляется запрос на регистрацию (URL, метод, статус, полезная нагрузка – тело запроса, ответ от сервера).
Если на сайте используются куки, формируется дополнительная вкладка "Cookies" в DevTools (в информации о запросе) и в "Application" -> "Cookies".
В таблице куки видим: Name, Value, Domain, Path, Expires (время жизни), HttpOnly, Secure, SameSite.
Авторизуюсь.
После регистрации происходит запрос на авторизацию.
В ответе от сервера (Response Headers) формируются два заголовка Set-Cookie: Token и SessionId. Эти значения и есть данные для входа в систему.
Эти же куки (Token и SessionId) появляются на вкладке "Application" -> "Cookies" со своими значениями и Expires.
Дальнейшее использование кук:
Делаю запрос на поиск магазина в городе (например, Стокгольм).
В DevTools -> Network нахожу этот запрос.
В Request Headers этого запроса значения Token и SessionId передаются в заголовке Cookie (обычно все куки для домена передаются в одном заголовке Cookie, разделенные точкой с запятой).
Тестирование куки в Postman:
Postman сейчас стал "умным" и автоматически управляет куками.
Создаю запрос на логин (авторизацию).
Отправляю запрос. В ответе, в разделе "Cookies" (или в "Headers" как Set-Cookie), видны установленные куки. Postman также сохраняет их в своем менеджере кук (Cookie manager).
При выполнении следующего запроса (например, на получение продуктов) Postman автоматически подставляет сохраненные куки в заголовок Cookie этого запроса.
Можно вручную очистить куки в Postman (через Cookie manager). После этого, если сессия на сервере еще не истекла или если нет другой формы авторизации, запрос без кук должен вернуть ошибку авторизации.
Я отмечаю, что после очистки кук в Postman запрос все равно проходит – возможно, сессия еще жива, или куки подхватываются из другого места, или в запросе есть какой-то скрипт авторизации. Это требует дополнительного исследования.
Что важно проверить:
Скорость загрузки: Поведение при повторных визитах. Загружаются ли изображения, скрипты или стили из кэша? Страница открывается быстрее при повторном посещении?
HTTP-заголовки: Редко когда нужно вручную проверять, используются ли правильные HTTP-заголовки для управления кэшированием (например, Cache-Control, Expires).
Инструменты: В основном для детального тестирования кэша (особенно серверного) используется не только DevTools, но и инструменты вроде Redis.
В DevTools: Вкладка "Application" -> "Cache Storage". Можно посмотреть, какие ресурсы кэшируются, и использовать кнопку "Clear storage" для очистки. Также "Local Storage" может использоваться для кэширования некоторых данных.
Кэш необходим, чтобы, если на сайте много данных (например, фильтрация, большие таблицы), которые долго загружаются из базы данных, пользователь не ждал по несколько секунд.
Многие IT-компании стали использовать Redis. Redis – это инструмент, который позволяет работать и с сессиями, и с кэшированием.
Алгоритм работы с Redis для сессий (пример):
Пользователь делает HTTP-запрос (открывает страницу, выполняет действие).
Сервис (stateless server) получает запрос и обращается в Redis, чтобы извлечь данные сессии пользователя (ID пользователя, SessionId, права).
Если нужных данных в Redis нет или сессия устарела, сервис делает запрос к основной базе данных для получения информации.
Алгоритм работы с Redis для кэширования (пример):
Приложение делает попытку прочитать данные из Redis.
Если данные там есть, они берутся оттуда быстро и эффективно.
Если данных нет в Redis, приложение обращается в обычную базу данных (например, PostgreSQL).
После получения данных из БД, приложение записывает их обратно в Redis (с определенным временем жизни, TTL), чтобы в следующий раз прочитать из кэша.
Пример на курсе спикера:
Redis используется как быстрый инструмент для временного хранения данных в оперативной памяти. Его основное предназначение – ускорять работу приложения и снижать нагрузку на сервер.
У каждого кэша есть время жизни (TTL). На курсе это 20 секунд для кэша.
PostgreSQL – основная база данных, долговременно хранит информацию.
Redis – "помощник" PostgreSQL, временно хранит результаты часто повторяющихся запросов.
Процесс получения данных без Redis (проблема):
Пользователь отправляет запрос (например, на получение информации о пользователе).
Сервер обращается к основной БД (PostgreSQL), получает данные, отправляет пользователю.
Если запросы часто повторяются, каждый раз сервер идет в БД, тратя ресурсы, что замедляет работу.
Процесс с Redis:
При первом запросе данные берутся из PostgreSQL и сохраняются в Redis.
При последующих повторных запросах (в течение TTL) данные берутся уже из Redis.
Пример в Redis Insight (инструмент для работы с Redis):
Авторизуюсь в систему, информация о пользователе (токен, логин, данные) может кэшироваться в Redis.
Запрашиваю список пользователей (например, 100).
Первый раз данные приходят из БД (PostgreSQL) и записываются в Redis. В Redis Insight можно увидеть ключ (например, task:list) и его значение (список пользователей).
При повторном запросе (в течение TTL, например, 6-20 секунд) данные берутся из кэша Redis. Это происходит быстрее.
Если пользователь часто обновляет страницу, данные будут быстро подгружаться из кэша.
По истечении TTL данные из Redis удаляются. При следующем запросе снова будет обращение к БД.
Пример бага на курсе: при запросе информации о конкретном пользователе, если данные берутся из кэша (второй запрос в течение 20 секунд), возвращается 500-я ошибка, хотя данные должны корректно подгрузиться. Это ошибка, которую должны найти студенты.
Задача на локализацию бага: Если, например, при обновлении странички возникает 500-я ошибка, первым делом всегда предлагайте почистить кэш и куки.
Дополнительная литература: рекомендация своего поста и видео про Redis.
Свои вопросы можно написать @nadin_qa