Основной ресурс
Разбор технических вопросов
Дудник Н.В.
Контакты:
План вебинара
  1. О себе
  1. Разбор вопроса - Авторизация: верный логин + неверный пароль или наоборот
  1. Разбор вопроса - SQL: что вернёт запрос…
  1. Разбор вопроса - API: валидация JSON с адресом доставки, ожидаемые ошибки и базовые тест-сценарии
  1. Разбор вопроса - Kafka: E2E-проверка цепочки к примеру следующих сервисов Publisher → Processor → Observer
  1. Дополнительная литература
  1. Ваши вопросы
О себе
Образование
Высшее: ОмГУ им. Ф.М. Достоевского, Физический факультет.
Опыт преподавания
6 лет преподавательской деятельности по физике (2009-2015 гг.).
Опыт в тестировании
10 лет в сфере тестирования (старт: июнь 2015 г.).
Значимые проекты
  • Luxoft (проекты для Boeing, DHL, Drawback)
  • Wiley (Wiley Online Library)
Текущая должность
Главный инженер по тестированию в Сбере (платформа ЕФС).
Блог и сообщество
Веду блог по тестированию Protestinginfo, где делюсь знаниями и собираю актуальную информацию для специалистов.
Задания и вопросы на собесах
Самый главный файл с вопросами, который разбираю в соцсетях.
Разбор вопроса на форму авторизации
Сценарий:
Рассмотрим типичный сценарий веб-формы авторизации (логин и пароль). Пользователь вводит существующий логин и неверный пароль, нажимает кнопку "Sign in", после чего интерфейс пользователя (UI) отображает ошибку.
Задача:
Объясните:
  • Что это может означать на стороне системы (клиент, сервер, безопасность).
  • Какие проверки обычно выполняет сервер в данном случае.
  • Какие артефакты и логи должен запросить QA-специалист для подтверждения поведения системы.
Ответ: Сценарий авторизации с неверным паролем или неверным логином
Рассмотрим сценарий, когда пользователь вводит существующий логин, но неверный пароль в веб-форме авторизации или наоборот. При нажатии кнопки "Sign in" или "Войти" UI отображает ошибку. Ниже представлен анализ данного поведения системы.
Значение на стороне системы
Неудачная попытка авторизации по существующему логину и неверному паролю может указывать на несколько системных реакций:
Неверный пароль/Неверный логи
Самый очевидный случай, когда введенный пароль/логин не соответствует учетным данным пользователя.
Временная блокировка аккаунта
После нескольких неудачных попыток входа система может временно заблокировать аккаунт или ограничить дальнейшие попытки. В таком случае, пользователю обычно отображается общая ошибка.
Защита от перечисления пользователей
Для предотвращения раскрытия информации о существовании логина злоумышленникам, система часто возвращает общее сообщение об ошибке (например, "Неверный логин или пароль"), не уточняя, что именно является некорректным.
Ответ: Сценарий авторизации с неверным паролем или неверным логином
Действия сервера при неверном пароле/логине
При получении запроса на авторизацию с неверным паролем/логином сервер выполняет следующий порядок действий:
Валидация входящих данных
Проверка формата и наличия обязательных полей (логина и пароля).
Поиск и верификация учетных данных
Сервер ищет пользователя по предоставленному логину. В случае обнаружения пользователя, происходит сравнение хеша введенного пароля с хешем, хранящимся в базе данных.
Регистрация неудачной попытки
Фиксация факта неуспешной попытки входа, включая IP-адрес, время и логин. Эта информация критична для реализации механизмов безопасности, таких как блокировка аккаунтов при превышении лимита попыток.
Формирование ответа об ошибке
Поскольку пароль/логин неверен, сервер генерирует соответствующее сообщение об ошибке, указывающее на сбой аутентификации.
Отправка HTTP-ответа
Клиенту отправляется ответ с соответствующим кодом состояния HTTP. Наиболее часто используется 401 Unauthorized. В некоторых реализациях могут применяться 400 Bad Request или 403 Forbidden в зависимости от специфики API.
Пример страницы авторизации: https://try.vikunja.io/login
Ваши рассуждения
Для тщательной проверки поведения системы в сценарии с неверным паролем/логином QA-специалисту необходимо запросить и проанализировать следующие артефакты и логи:
HTTP-статус и тело ответа
  • Какой HTTP-статус возвращается (например, 401, 403 или 400)?
  • Какое сообщение об ошибке содержится в теле ответа?
  • Убедиться, что сообщения об ошибке для "неверного логина" и "неверного пароля" идентичны, если реализована защита от перечисления пользователей.
Механизмы защиты
  • Существует ли лимит на количество попыток входа до временной блокировки аккаунта?
  • Как система реагирует на превышение этого лимита (например, временная блокировка, требование CAPTCHA)?
  • Корректно ли сбрасывается счетчик неудачных попыток после успешного входа или по истечении установленного времени?
Логирование и аудит
  • Какие события фиксируются в серверных логах при каждой неуспешной попытке входа?
  • Критически важно убедиться, что пароль/логин пользователя никогда не логируется в явном или зашифрованном виде.
  • Проверить, фиксируются ли данные, необходимые для аудита безопасности (например, IP-адрес, дата/время попытки, имя пользователя).
Разбор вопроса по SQL
Есть две таблицы в БД: a и b.​ Таблица a содержит 4 строки и 2 столбца, таблица b содержит 3 строки и 4 столбцов.​ Нужно выполнить запрос
SELECT * FROM a, b;
и описать результат.
или вопрос: select * from a join b on 1=1
Анализ SQL-запроса: SELECT * FROM a,b;
Что это такое: Декартово произведение
Запрос SELECT * FROM a, b; является классическим примером неявного декартова произведения (или CROSS JOIN) между двумя таблицами. Он создаёт комбинацию каждой строки из первой таблицы со всеми строками из второй таблицы, без каких-либо условий соединения.
Характеристики результата
Количество строк: Результат будет содержать количество строк, равное произведению числа строк в таблице a на число строк в таблице b. В данном случае это 4 * 3 = 12 строк.
Количество столбцов: Общее число столбцов будет суммой столбцов из обеих таблиц. Для таблиц a (2 столбца) и b (4 столбца) это 2 + 4 = 6 столбцов.
Структура выходных данных
Строки: Каждая строка результата представляет собой уникальную комбинацию одной строки из таблицы a и одной строки из таблицы b. Условия соединения отсутствуют, поэтому будут сгенерированы все возможные пары.
Столбцы: Сначала будут выведены все 2 столбца из таблицы a, затем все 4 столбца из таблицы b.

sqliteonline.com

SQL Online IDE - Fast SQL Editor | SQL Compiler

SQL OnLine - SQLite, DuckDB, PGLite, MariaDB / MySQL, PostgreSQL, MS SQL Server. AI error analysis, User-friendly interface for Data Science. No registration for start, No DownLoad, No Install. | sql compiler, federated queries, temporal query federation, BI Analytics

CREATE TABLE a ( a_id INT PRIMARY KEY, a_name TEXT NOT NULL );
CREATE TABLE b ( b_id INT PRIMARY KEY, b_type TEXT NOT NULL, b_amount INT NOT NULL, b_city TEXT NOT NULL );
INSERT INTO a (a_id, a_name) VALUES (1, 'Ann'), (2, 'Boris'), (3, 'Chen'), (4, 'Dina');
INSERT INTO b (b_id, b_type, b_amount, b_city) VALUES (10, 'card', 100, 'Zagreb'), (20, 'transfer', 200, 'Split'), (30, 'cash', 50, 'Rijeka');
Пример всех комбинаций
Чтобы продемонстрировать декартово произведение, рассмотрим все 12 возможных комбинаций:
  • (A1, B1)
  • (A1, B2)
  • (A1, B3)
  • (A2, B1)
  • (A2, B2)
  • (A2, B3)
  • (A3, B1)
  • (A3, B2)
  • (A3, B3)
  • (A4, B1)
  • (A4, B2)
  • (A4, B3)
Анализ обработки JSON-запросов доставки
В рамках тестирования API сервиса оформления заказа необходимо проанализировать обработку JSON-объектов с адресом доставки.
Ключевые аспекты
Валидация данных
Определить необходимые проверки валидности JSON-структуры и бизнес-валидации полей адреса.
Обработка ошибок
Описать ожидаемые ответы (статусы и сообщения об ошибках) при получении невалидного JSON и при наличии некорректных полей в валидном JSON.
Пример невалидного JSON
Привести пример некорректной структуры JSON и детализировать процесс обработки такой ошибки сервером.
Тестовые сценарии
Разработать три важных тестовых сценария для проверки указанных аспектов.
Пример структуры JSON, которую смогут дать на собесе
POST /order
{
  "orderId": 12345,
  "address": {
    "country": "HR",
    "city": "Moscow",
    "postalCode": 121206,
  }
}
Анализ валидации JSON для адреса доставки
Для надежности API сервиса оформления заказа, критически важна правильная обработка JSON-объектов с адресом доставки.
Валидация JSON-запросов
Обеспечьте корректность входящих JSON-запросов по структуре и данным.
  • Синтаксис: JSON-объект должен быть синтаксически корректным (без "trailing commas" и ошибок парсинга).
  • Заголовки: Запрос требует Content-Type: application/json и кодировку UTF-8.
  • Схема: Проверяйте наличие обязательных полей (orderId, address) и соответствие типов данных (число для orderId)
  • id для address, строки для country, city, street).
  • "date": "number" // Ожидаемая дата доставки
  • "is_leave_at_door": "boolean" // оставить у двери
Бизнес-валидация адреса
В дополнение к структурной валидации, внедрите проверки на основе бизнес-логики:
  • Согласованность: Проверяйте соответствие страны и города (например, "Москва" не может быть в "Хорватии").
  • Почтовый код: Валидируйте формат postalCode (длина, тип, диапазон).
  • Улица: Поле street не должно быть пустым.
  • Номер дома: house должен быть положительным числом.
Ожидаемые ответы API
API должен возвращать четкие и информативные ответы при ошибках:
  • Невалидный JSON (ошибка парсинга): Вернуть 400 Bad Request. Прекратить обработку.
  • Валидный JSON с некорректными данными (семантические/бизнес-ошибки): Вернуть 422 Unprocessable Entity с детальным описанием некорректных полей.
Анализ валидации JSON для адреса доставки
Пример невалидного JSON
JSON с синтаксической ошибкой (например, "trailing comma") не будет распарсен:
{
  "orderId": 12345,
  "address": {
    "country": "HR",
    "city": "Moscow",
    "postalCode": 121206,
    "street": "Ilica",
    "house": 10,  /* Эта запятая делает JSON невалидным */
  }
}
Сервер должен ответить 400 Bad Request и не обрабатывать запрос далее.
Ключевые тестовые сценарии
Разработайте следующие сценарии для всесторонней проверки API:
  • Сценарий 1: Синтаксически невалидный JSON
  • Действие: Отправить JSON с синтаксической ошибкой.
  • Ожидаемый результат: Получить 400 Bad Request.
  • Сценарий 2: Валидный JSON с некорректными типами данных
  • Действие: Отправить JSON с неверным типом данных (например, address как массив).
  • Ожидаемый результат: Получить 422 Unprocessable Entity (или 400 Bad Request) с ошибками валидации схемы.
  • Сценарий 3: Бизнес-валидация страны/города
  • Действие: Отправить JSON с несоответствием country и city (например, "HR" и "Moscow").
  • Ожидаемый результат: Получить 422 Unprocessable Entity с сообщением о бизнес-ошибке.
E2E-тестирование цепочки Kafka: Publisher → Processor → Observer
Как тестировать сквозной сценарий: Publisher записывает событие в Kafka, Processor обрабатывает его и публикует результат, Observer фиксирует уведомление. Какие типичные риски Kafka (потеря, дублирование сообщений, нарушение порядка) необходимо проверить?
Описание E2E-сценария
Цепочка взаимодействия включает три ключевых сервиса:
Publisher
Сервис инициирует процесс, записывая событие в Kafka-топик.
Processor
Сервис считывает событие, обрабатывает его и публикует результат в другой топик.
Observer
Сервис принимает уведомление о завершении обработки, фиксируя результат.
E2E-тестирование цепочки Kafka: Publisher → Processor → Observer
Подход к E2E-тестированию
Разработайте комплексные end-to-end тесты для надежности системы, охватывающие весь путь сообщения.
Основные этапы:
  • Инициируйте событие: Эмулируйте отправку через Publisher.
  • Мониторьте Kafka: Проверьте наличие события во всех топиках.
  • Валидируйте обработку: Убедитесь в корректной работе Processor и ожидаемом результате.
  • Верифицируйте результат: Подтвердите получение и фиксацию финального уведомления Observer.
Типичные риски Kafka и их проверка
Критически важно проверять сценарии, связанные с особенностями распределенного обмена сообщениями в Kafka:
  • Потеря сообщений: Проверьте доставку на всех этапах с подтверждениями и тайм-аутами.
  • Дублирование: Тестируйте идемпотентность Processor и Observer.
  • Нарушение порядка: Проверьте сохранение порядка для критичных сценариев Processor и Observer.
  • Задержки: Измерьте сквозное время обработки (end-to-end latency) и сравните с SLA.
  • Ошибки сериализации/десериализации: Проверьте устойчивость к различным и невалидным форматам данных.
  • Backpressure/переполнение: Имитируйте пиковые нагрузки на Publisher, оценивая поведение Processor и Kafka.
Эти тесты помогут выявить и устранить проблемы, обеспечивая стабильность системы.
Симулятор:
Инструкция:
Стратегия E2E-тестирования Kafka-цепочки
Подход к End-to-End тестированию
Для E2E-тестирования задействуем Kafka UI-клиенты (например, AKHQ или Offset Explorer) для мониторинга топиков и групп консьюмеров.
  • Инициировать событие через Publisher.
  • Мониторить топики для верификации содержимого и метаданных сообщения.
  • Анализировать логи Processor для подтверждения успешной обработки.
  • Проверять публикацию результата Processor'ом в выходной топик.
  • Верифицировать получение и обработку уведомления Observer'ом.
  • Мониторить Consumer Group Processor для отслеживания лага и офсетов.
Проверка типовых рисков Kafka
Критически важно охватить сценарии, связанные с особенностями распределенного обмена сообщениями.
Потеря сообщений
  • Цель: Убедиться, что сообщения не теряются на пути Publisher → Processor → Observer, особенно при сбоях.
  • Сценарий: Отправить сообщение с уникальным ID. Имитировать отказ Processor'а во время обработки (остановка/перезапуск). После восстановления проверить, что сообщение обработано повторно (при корректном offset commit). Отсутствие результата указывает на потерю, если offset ошибочно закоммичен.
Дублирование сообщений (идемпотентность)
  • Цель: Проверить устойчивость системы к повторной доставке и идемпотентность обработки.
  • Сценарий: Повторно отправить идентичное событие (с тем же ID) или спровоцировать повторное чтение Processor'ом (например, падение до коммита offset). Проверить: должен быть зафиксирован только один результат для данного ID. Если дубли допустимы, убедиться, что повторная обработка не приводит к некорректным состояниям.
Функциональное тестирование
Чек-лист проверок
Базовый сценарий
  • Сквозное прохождение сообщения.
  • Сохранение ID сущности на всех этапах.
  • Корректность изменения статусов.
Массовая обработка
  • Обработка 10 и 100 сообщений без потерь.
  • Все сообщения с уникальным ID.
Тестирование партиций
  • Сообщения с одинаковым ключом: в одной партиции.
  • Сохранение порядка внутри партиции.
  • Порядок между партициями не гарантируется.
Особенности тестирования брокеров сообщений по моему опыту
Подготовка к Техническим Собеседованиям
Превратите неуверенность в своих силах на технических собеседованиях в уверенность. Наш курс поможет вам пройти отбор и успешно проявить себя на каждом этапе. Вы получите необходимые знания, практические навыки и стратегии для успешного трудоустройства.
Ваш путь к успеху включает:
Вебинары и Q&A
Ежемесячные интерактивные встречи для разбора реальных кейсов, получения ответов на вопросы и обсуждения актуальных тем индустрии.
Неограниченный Доступ к Материалам
Полные записи вебинаров и регулярно обновляемые учебные материалы доступны в любое время. Учитесь в своем темпе, возвращайтесь к материалам без ограничений.
Интенсивная Практика (по тарифу)
Превратите теорию в результат. Этот блок включает:
  • Ревью баг-репортов и тест-дизайна.
  • Освоение API (REST, GraphQL, gRPC по запросу).
  • Работа с SQL и инструментами (Postman, DBeaver, PostgreSQL).
Карьерная Поддержка (по тарифу)
Получите экспертную проверку и рекомендации по улучшению резюме, а также помощь в составлении портфолио.
Мгновенная Поддержка в Чате
Оперативная поддержка в чате CoreApp и телеграм для решения любых вопросов в процессе обучения.
Подготовка к Техническим Собеседованиям
6 месяцев доступа
Полный доступ ко всем материалам и поддержке предоставляется на 6 месяцев.
Скидка 20%
Используйте промокод PROMO20. Предложение ограничено.
Для выпускников
Свяжитесь с @nadin_qa в Telegram для индивидуальных условий продления.
Выбери свой тариф
Детальная информация и выбор тарифа на сайте: protestinginfo.ru/#pricing
Ознакомьтесь с историями успеха и отзывами наших выпускников: https://protestinginfo.ru/#testimonials
Контакты Telegram:
Дополнительная литература

Google Docs

Топ вопросов на собеседованиях.pdf

Google Docs

К собесу

Google Docs

Задания и вопросы на собесах

Знакомство Меня зовут Надежда Дудник. Я главный инженер по тестированию ПО и ментор по тестированию ПО Веду блог про тестирование ПО, также обучаю и направляю людей, провожу консультации по тестированию ПО. Мне нравится передавать свои знания, сочинять тесты для закрепления знаний, делиться свои ...

Google Docs

Вопросы на собес

ВОПРОСЫ на собеседовании на позицию QA Engineer: Небольшие ответы - обновляю список и добавляю ответы: Не забываем еще про файл Тестирование Это процесс проверки программного обеспечения на соответствие требованиям и выявление ошибок (багов). Включает различные виды тестирования, такие как фун...

Ваши вопросы
Спасибо за внимание
Свои вопросы пишите на @nadin_qa
Made with