Ответ
Это три основных механизма хранения данных на стороне клиента, и понимание их различий критично для тестирования веб-приложений (функциональность, безопасность, кросс-табличные сценарии).
| Критерий | Cookies | LocalStorage | SessionStorage |
|---|---|---|---|
| Объем | ~4 КБ на домен | ~5-10 МБ на домен | ~5-10 МБ на домен |
| Время жизни | Задается параметрами Expires или Max-Age. Могут быть сессионными (до закрытия браузера). |
Сохраняются до явного удаления (JS или очистка браузера). | Удаляются при закрытии вкладки браузера. |
| Доступность | Доступны как на клиенте (document.cookie), так и на сервере (передаются в заголовках Cookie каждого HTTP-запроса). |
Доступны только в контексте клиентского JavaScript (window.localStorage). | Доступны только в контексте клиентского JavaScript (window.sessionStorage) и только в рамках одной вкладки. |
| Использование в тестировании | Аутентификация (токены), отслеживание сессии, персонализация. | Сохранение больших непередаваемых на сервер данных (настройки UI, кэш данных). | Временное хранение данных в рамках одной сессии/вкладки (например, данные формы при переходе между шагами). |
Практические сценарии для QA:
- Тестирование Cookies (безопасность): Проверка флагов
HttpOnly(защита от XSS),Secure(только по HTTPS),SameSite(защита от CSRF). - Тестирование LocalStorage:
// Проверка сохранения/загрузки данных localStorage.setItem('theme', 'dark'); console.assert(localStorage.getItem('theme') === 'dark'); // Проверка очистки при логауте logoutFunction(); // Должна вызывать localStorage.clear() или removeItem console.assert(localStorage.getItem('theme') === null); - Тестирование SessionStorage (изоляция вкладок):
- Открыть приложение в двух вкладках.
- В первой вкладке сохранить данные:
sessionStorage.setItem('wizardStep', '2'). - Убедиться, что во второй вкладке
sessionStorage.getItem('wizardStep')вернетnull. - Закрыть и заново открыть вкладку — данные должны быть утеряны.
- Очистка данных: Важно проверять, как приложение ведет себя после ручной очистки хранилища в настройках браузера — не должно приводить к критичным ошибкам.
Ответ 18+ 🔞
А, ну это ж классика, про которую каждый тестировщик должен знать, как свои пять пальцев. Смотри, тут три главных хранилища в браузере, и если их не различать — можно такого натестировать, что потом разработчики тебя самого в localStorage запрячут, чтоб не доставал.
Вот смотри, таблица, чтобы всё в голове разложилось, а не как попало.
| Критерий | Cookies | LocalStorage | SessionStorage |
|---|---|---|---|
| Объем | ~4 КБ на домен | ~5-10 МБ на домен | ~5-10 МБ на домен |
| Время жизни | Задается параметрами Expires или Max-Age. Могут быть сессионными (до закрытия браузера). |
Сохраняются до явного удаления (JS или очистка браузера). | Удаляются при закрытии вкладки браузера. |
| Доступность | Доступны как на клиенте (document.cookie), так и на сервере (передаются в заголовках Cookie каждого HTTP-запроса). |
Доступны только в контексте клиентского JavaScript (window.localStorage). | Доступны только в контексте клиентского JavaScript (window.sessionStorage) и только в рамках одной вкладки. |
| Использование в тестировании | Аутентификация (токены), отслеживание сессии, персонализация. | Сохранение больших непередаваемых на сервер данных (настройки UI, кэш данных). | Временное хранение данных в рамках одной сессии/вкладки (например, данные формы при переходе между шагами). |
А теперь, блядь, на пальцах, что с этим делать на практике:
-
Cookies — это святое, их трогать нужно в белых перчатках. Тут главное — безопасность, ёпта. Ты должен проверять, как будто ты хакер-неудачник. Есть ли у куки флаг
HttpOnly? Если нет — это прямая дорога для XSS, чтобы тебе скрипт твой же токен украл. ФлагSecureстоит? Или он по HTTP летает, как голый по проспекту? АSameSite? Без него любая сторонняя сайта может сделать запрос с твоими куками — вот тебе и CSRF, привет. В общем, доверия ебать ноль, проверяй всё. -
LocalStorage — это твой чердак, где можно хранить овердохуища хлама. Но следи, чтобы приложение не превратилось в свинарник. Вот смотри, как проверять:
// Проверка сохранения/загрузки данных localStorage.setItem('theme', 'dark'); console.assert(localStorage.getItem('theme') === 'dark'); // Проверка очистки при логауте logoutFunction(); // Должна вызывать localStorage.clear() или removeItem console.assert(localStorage.getItem('theme') === null);Главный сценарий: залогинился, накричал настроек, разлогинился. После этого зайди в DevTools, в Application, и посмотри — не осталось ли там чего? Если осталось — это пиздец, утечка данных. А ещё представь, что юзер — тот ещё распиздяй, и просто взял и очистил всё хранилище в настройках браузера. Приложение не должно накрыться медным тазом с ошибкой, а просто взять и перейти в дефолтное состояние.
-
SessionStorage — это как память золотой рыбки, только на одну вкладку. Тут хитрая жопа с изоляцией.
- Открой приложение в двух вкладках. В одной сохрани что-то:
sessionStorage.setItem('wizardStep', '2'). - Перейди на другую вкладку и попробуй это прочитать. Должно быть
null, ни хуя себе, да? Потому что это другая сессия. - Закрой вкладку и открой заново — всё, данные испарились, как твоя зарплата в конце месяца. Если не испарились — вот тебе и баг.
- Открой приложение в двух вкладках. В одной сохрани что-то:
Короче, суть в чём: нужно понимать, где что лежит, кто к этому имеет доступ и когда это всё сдохнет. И тогда ты не будешь, как тот чувак, искать в localStorage сессионный токен, который на сервере сидит в куках. Э, сабака сука, думай головой!