9 вопросов по теме «QA: Веб, мобильное и безопасность» на собеседовании

Короткий ответ: Cookies ограничены ~4 КБ и автоматически летят на сервер с каждым запросом, у них есть срок жизни и флаги httpOnly/secure. localStorage и sessionStorage вмещают ~5 МБ, на сервер сами не уходят и читаются только из JS; разница — localStorage живёт бессрочно, а sessionStorage стирается при закрытии вкладки.

Подробно:

1. Размер и отправка — cookie мал (~4 КБ) и добавляется в заголовок каждого HTTP-запроса, поэтому раздувать его нельзя; Web Storage крупнее и на сервер не передаётся.
2. Срок жизни — cookie живёт до Expires/Max-Age, localStorage — пока его явно не удалят, sessionStorage — до закрытия вкладки.
3. Доступ и безопасность — httpOnly-cookie недоступна из JS, поэтому её не украдёт XSS; localStorage читается любым скриптом на странице.

⚠️ Частая ошибка: хранить auth-токен в localStorage «для удобства». Токен сессии безопаснее в httpOnly+secure-cookie — localStorage вычитывается XSS-инъекцией за одну строку скрипта.

Короткий ответ: IDOR (Insecure Direct Object Reference) — уязвимость, когда сервер отдаёт чужой ресурс по прямому идентификатору из запроса, не проверяя, что пользователь имеет на него право (/orders/123 → /orders/124). Проверяют так: под пользователем A подставляют ID ресурса пользователя B и ждут 403/404, а не чужие данные.

Подробно:

1. Суть — приложение доверяет ID из URL/тела/параметра и не сверяет владельца объекта с текущей сессией.
2. Как тестировать — авторизуйтесь как A, перехватите его запрос, замените ID на принадлежащий B и повторите. Корректная реакция — отказ авторизации, а не 200 с чужими данными.
3. Где искать — числовые ID заказов, документов, счетов; параметры user_id, account; вложенные объекты (/users/B/cards).

GET /api/orders/124 HTTP/1.1
Host: shop.example.com
Cookie: session=<токен пользователя A>

→ ожидаем 403 Forbidden или 404 Not Found
→ уязвимо: 200 OK с заказом пользователя B

⚠️ Частая ошибка: проверять доступ только через интерфейс, где кнопки чужого заказа не видно. IDOR живёт на уровне API — проверять нужно прямыми запросами (Burp/Postman), а не кликами по UI.

Короткий ответ: Без пентеста и спецтулов тестировщик закрывает уровень awareness: ручные проверки на SQL-инъекцию, XSS, IDOR, отсутствие rate limiting и утечку чувствительных данных в URL/логах. Достаточно 1–2 конкретных проверок на пункт, а не полноценной эксплуатации.

Подробно:

1. Инъекции — подставить ' OR 1=1-- в поле логина/поиска и смотреть, не ломается ли запрос или не пускает ли внутрь.
2. XSS — ввести <script>alert(1)</script> в текстовое поле и проверить, экранируется ли вывод.
3. Контроль доступа (IDOR) — подмена чужого ID в запросе.
4. Аутентификация — брутфорс пароля без блокировки/капчи (нет rate limiting).
5. Утечки — токены, пароли, номера карт в URL, логах, ответах API.

⚠️ Частая ошибка: уходить в глубокую эксплуатацию и «взлом». От тестировщика ждут не отчёт пентестера, а системную привычку прогонять базовые проверки безопасности по каждой форме.

Короткий ответ: Мобилка добавляет целые классы рисков, которых нет в вебе: фрагментация устройств и версий ОС, нестабильная сеть, системные прерывания, работа в фоне и восстановление состояния, permissions, deep links, биометрия и расход батареи. «Экран меньше» — это лишь верхушка.

Подробно:

• Фрагментация — сотни моделей, разные разрешения, версии Android/iOS, вендорные прошивки.
• Сеть — офлайн, 2G, обрывы посреди операции, переключение Wi-Fi↔LTE.
• Прерывания — входящий звонок, будильник, пуш, сворачивание — приложение должно пережить и восстановиться.
• Жизненный цикл — фон/убийство процесса ОС, возврат к сохранённому состоянию.
• Платформенное — permissions, deep links, биометрия, установка/обновление из стора.
• Ресурсы — батарея, память, нагрев, производительность на слабых устройствах.

Веб:     браузер + сеть + вёрстка
Мобилка: + фрагментация устройств/ОС
         + прерывания и фон
         + permissions / deep links / биометрия
         + батарея / память / нестабильная сеть

⚠️ Частая ошибка: свести различия к «адаптивной вёрстке под маленький экран». Интервьюер ждёт именно прерывания, жизненный цикл процесса и фрагментацию — это и есть мобильная специфика.

Короткий ответ: Сначала уточните платформу, тип payload и состояние приложения: foreground, background, процесс завершён системой или приложение принудительно остановлено пользователем. Затем проверяйте отдельно реальную доставку через APNs/FCM, показ уведомления и переход по нажатию. Мок проверяет обработчик приложения, но не доставку провайдера.

Подробно:

1. Предусловия — валидный токен устройства, разрешения, настройки канала/уведомлений, сеть и ограничения энергопотребления. Запишите версию ОС и способ завершения приложения.
2. Состояния — сворачивание не завершает процесс; смахивание из списка задач не эквивалентно Android force-stop в настройках и зависит от платформы. После iOS swipe-away фоновые сообщения требуют повторного открытия; после Android force-stop приложение также нужно открыть снова для приёма сообщений. Не переносите ограничения фонового обработчика на все видимые уведомления iOS.
3. Payload — notification/alert и data-only/silent сообщения обрабатываются по-разному. Фоновая доставка не гарантируется. В foreground системный баннер не обязателен: проверьте согласованную политику приложения и настройки показа.
4. Переход — на реальном устройстве проверьте видимый текст, tap, cold/warm start, авторизацию, deep link, отсутствующий объект и повторное нажатие. Ожидаемое поведение задаётся контрактом для конкретного payload и состояния.
5. Автоматизация — юнит-/интеграционные тесты payload и маршрутизации дополните отдельной проверкой настоящей доставки в тестовом окружении. Восстановите приложение после force-stop, если следующий тест требует приёма сообщений.

⚠️ Частая ошибка: считать «приложение закрыто» одним воспроизводимым состоянием или требовать одинаковый баннер для любого сообщения. Проверяйте матрицу платформ, состояний и payload, а не только открытое приложение.

Короткий ответ: Deep link проверяют матрицей состояний приложения: холодный старт, уже запущено, свёрнуто в фон. Отдельно — восстановление: ОС убила процесс, а при возврате состояние (форма, корзина, позиция в списке) не потерялось; невалидная или устаревшая ссылка не роняет приложение, а ведёт на fallback.

Подробно:

1. Состояние при переходе — открыть ссылку при закрытом, запущенном и свёрнутом приложении — экран должен быть один и тот же.
2. Восстановление после kill — свернуть на середине заполнения формы, дать ОС выгрузить процесс, вернуться — введённые данные на месте.
3. Битые ссылки — невалидный/просроченный/чужой deep link ведёт на понятный fallback, а не падает.

⚠️ Частая ошибка: проверить только «ссылка открывает экран» на запущенном приложении. Баги прячутся в cold start и в восстановлении состояния после того, как ОС выгрузила процесс.

Короткий ответ: Проверка идёт по слоям: корректная семантика и ARIA-роли/лейблы в разметке, полная навигация с клавиатуры с логичным порядком фокуса и достаточным контрастом, затем автосканеры (axe-core/Lighthouse) в CI и обязательный ручной проход реальным скринридером (NVDA/VoiceOver).

Подробно:

1. Разметка — семантические теги, aria-label/aria-labelledby там, где нет видимого текста, роли для кастомных контролов, живые регионы для динамики.
2. Клавиатура — всё достижимо через Tab, порядок фокуса совпадает с визуальным, фокус виден, нет ловушек фокуса.
3. Инструменты — axe-core/Lighthouse отлавливают часть проблем автоматически и встают в CI.
4. Ручной проход — реальный скринридер: озвучиваются ли лейблы, состояния, ошибки формы.

Слой 1 · Разметка   → ARIA-роли, лейблы, alt, заголовки
Слой 2 · Клавиатура → Tab-порядок, видимый фокус, без ловушек
Слой 3 · Тулы       → axe-core / Lighthouse в CI
Слой 4 · Скринридер → NVDA / VoiceOver вручную

⚠️ Частая ошибка: свести доступность к «проставить alt у картинок». За это дожимают: скринридеру одинаково важны порядок фокуса, лейблы форм, озвучка ошибок и состояний — а не только alt-тексты.

Короткий ответ: Кроссбраузерное тестирование — проверка, что приложение одинаково работает в разных браузерах, версиях и ОС. Матрицу строят не «все браузеры», а от аналитики трафика аудитории и риска: полный перебор браузер × ОС × разрешение нереален, поэтому его сокращают приоритизацией и pairwise-подходом.

Подробно:

1. Отталкиваться от данных — аналитика (GA и т.п.) показывает реальные доли браузеров/ОС/устройств у вашей аудитории.
2. Приоритет по покрытию и риску — сначала комбинации, покрывающие большинство пользователей и критичные потоки (оплата, регистрация).
3. Сокращать перебор — pairwise/попарное тестирование даёт покрытие пар без комбинаторного взрыва.

⚠️ Частая ошибка: не суметь обосновать выбор матрицы («проверил, где было под рукой»). Интервьюер ждёт логику «данные аудитории + риск + pairwise», а не список любимых браузеров.

Короткий ответ: Сеть эмулируют троттлингом (DevTools, Charles/Proxyman) и авиарежимом посреди операции, а проверяют поведение: работают ли ретраи и таймауты, нет ли потери или дублирования данных при повторной отправке, и получает ли пользователь понятную ошибку вместо вечного спиннера.

Подробно:

1. Эмуляция условий — throttling до 2G/Slow 3G, потеря пакетов, высокий latency; авиарежим прямо во время запроса.
2. Устойчивость запроса — таймаут срабатывает, ретрай повторяет, идемпотентность не создаёт дубль заказа/платежа.
3. Обратная связь — вместо бесконечного лоадера — сообщение об ошибке и кнопка «Повторить».
4. Офлайн и синхронизация — данные копятся локально и корректно досылаются при возврате сети.

Момент флоу              Что проверяем
─────────────────────────────────────────
до запроса      → офлайн-баннер, блок кнопки
обрыв в запросе → таймаут + ретрай, нет дубля
медленный ответ → спиннер не вечный, есть отмена
возврат сети    → отложенное досылается, синк ок

⚠️ Частая ошибка: тестировать только на идеальном офисном Wi-Fi. Самые злые баги — потеря/дублирование данных и зависший спиннер — воспроизводятся именно на обрыве посреди операции.