API и Security Testing на собеседованиях: полный разбор с примерами задач / Хабр

Привет, Хабр! В прошлой статье я разобрал 5 техник тест-дизайна, которые спрашивают на собеседованиях.

Статья будет полезна и новичкам, и тем, кто хочет систематизировать знания перед собеседованием. Каждую тему объясняю с нуля - с аналогиями из жизни, и тут же даю профессиональную глубину.

Для начала: что такое API?

Представьте ресторан. Вы (клиент) сидите за столиком. Кухня (сервер) готовит еду. Но вы не идёте на кухню сами вы зовёте официанта. Говорите, что хотите. Он несёт заказ на кухню, кухня готовит, официант приносит блюдо.

API - это тот самый официант. Принимает запрос, передаёт серверу, возвращает ответ.

Вы (приложение) → API (официант) → Сервер (кухня) ← ← Получаете ответ Готовит данные

Когда вы открываете приложение погоды - оно не само считает температуру. Оно отправляет запрос через API и получает ответ с данными. Когда платите в интернет-магазине - приложение через API общается с платёжным сервисом. API повсюду.

Часть 1: API Testing

1. HTTP-методы: «Какие знаете? В чём разница PUT и PATCH?»

Этот вопрос задают в 90% случаев. Приложение общается с сервером через HTTP-методы - это «команды», которые говорят серверу, что делать.

Метод	Что делает	Аналогия	Идемпотентный?	Тело запроса
GET	Получить данные	Посмотреть меню	Да	Нет
POST	Создать ресурс	Сделать заказ	Нет	Да
PUT	Заменить целиком	«Замените весь заказ»	Да	Да
PATCH	Обновить часть	«Добавьте соус»	Нет*	Да
DELETE	Удалить	Отменить заказ	Да	Нет

PUT vs PATCH - ключевая разница:

Допустим, в профиле пользователя:

{ "name": "Atajan", "email": "atajan@example.com", "age": 30, "city": "Ashgabat" }

Хотим изменить только город.

PUT /users/1 - заменяет ВЕСЬ объект. Как заполнить анкету с нуля:

{ "name": "Atajan", "email": "atajan@example.com", "age": 30, "city": "Istanbul" }

Если забыть поле age - оно обнулится.

PATCH /users/1 - обновляет ТОЛЬКО указанные поля. Как стикер «исправить»:

{ "city": "Istanbul" }

Остальное не тронет.

Идемпотентность - ещё один любимый вопрос. Простыми словами: если повторить действие 10 раз - результат будет как после первого.

Пример из жизни: кнопка лифта. Нажали 1 раз - лифт едет. Нажали 10 раз - лифт всё равно едет один раз.

PUT /users/1 десять раз с одним телом → результат один
POST /users десять раз → создаст десять пользователей

2. Статус-коды: «Когда 401 vs 403?»

Сервер возвращает число - статус-код. Это как SMS от курьера о статусе доставки. Не нужно знать все коды, но эти - наизусть:

Код	Значение	Простым языком
200	OK	«Доставлено, всё ОК»
201	Created	«Заказ принят и создан»
204	No Content	«Сделано, но показывать нечего» (DELETE)
301	Moved Permanently	«Мы переехали навсегда, вот новый адрес»
302	Found (Redirect)	«Сейчас перенаправлю, но старый адрес тоже рабочий»
304	Not Modified	«Ничего не изменилось, используйте кэш»
400	Bad Request	«Не понял, перепроверьте»
401	Unauthorized	«А вы кто? Покажите паспорт»
403	Forbidden	«Знаю вас, но сюда нельзя»
404	Not Found	«Такого адреса нет»
409	Conflict	«Такой email уже занят»
422	Unprocessable	«Данные понял, но они невалидные»
429	Too Many Requests	«Слишком часто стучите, подождите»
500	Internal Server Error	«У нас всё сломалось»
502	Bad Gateway	«Наш поставщик не отвечает»
503	Service Unavailable	«Перегружены, зайдите позже»

Группы легко запомнить: 2xx — «всё хорошо», 3xx — «идите туда →», 4xx — «вы ошиблись», 5xx — «мы сломали».

401 vs 403 - вопрос-ловушка. Представьте ночной клуб:

401 - вы подходите к двери без билета. Охранник: «Покажите билет!» Вы не доказали, кто вы. (токен отсутствует или истёк)
403 - вы показали билет, но охранник: «Ваш билет на танцпол, а это VIP-зона». Вы доказали кто вы, но прав не хватает. (роль user → admin-панель)

Интервьюер спрашивает это не для проверки памяти. Он хочет понять: вы тестируете только happy path (200 OK) или проверяете все сценарии?

3. «Протестируйте POST /api/users» - задача с собеседования

Самый популярный формат: дают endpoint, просят написать тест-кейсы. Вот как структурировать ответ, чтобы произвести впечатление.

Дано:

POST /api/users { "name": "string (обязательное, 2-50 символов)", "email": "string (обязательное, уникальное)", "age": "integer (18-120)" }

Разбиваем на три группы: позитивные, негативные, безопасность.

Позитивные тесты - когда всё правильно:

#	Сценарий	Ожидание
1	Все поля валидны	201, пользователь создан
2	Минимальные значения (name=2 символа, age=18)	201
3	Максимальные значения (name=50 символов, age=120)	201
4	Email в разных форматах (user+tag@gmail.com)	201

Негативные тесты - когда что-то не так:

#	Сценарий	Ожидание
5	Пустое тело запроса	400
6	name отсутствует	400/422
7	name = 1 символ (меньше минимума)	400/422
8	name = 51 символ (больше максимума)	400/422
9	email невалидный (без @)	400/422
10	email уже существует	409
11	age = 17 (меньше минимума)	400/422
12	age = 121 (больше максимума)	400/422
13	age = "тридцать" (строка вместо числа)	400
14	age = -5 (отрицательное число)	400/422
15	Лишние поля в запросе (role: "admin")	Игнорируются или 400

Безопасность (об этом забывают 80% кандидатов!):

#	Сценарий	Ожидание
16	name = `<script>alert('xss')</script>`	400 или экранирование
17	email = `' OR '1'='1`	400
18	Запрос без токена авторизации	401
19	Запрос с истёкшим токеном	401

Что ещё проверить (про это часто забывают):

Content-Type: application/xml вместо JSON - что вернёт?
Дублирование запроса (POST дважды) - создаст два пользователя?
Максимальный размер тела запроса
Спецсимволы в полях (emoji 🚀, Unicode, NULL-байт)

Из одного endpoint - 19 тестов. Большинство кандидатов останавливаются после 4-5. Такой структурированный ответ сразу показывает уровень.

⚠️ Важно: как убедиться, что POST/PUT/PATCH реально применился?

Проверка только по коду ответа (201, 200) или по response body — недостаточна. Сервер может вернуть «успех», но данные не сохранятся — баг в бизнес-логике, проблема с транзакцией, кеш вернул старое.

Правильный подход — верифицировать результат:

GET-запрос после изменения. Отправили POST /api/users → получили 201 → делаем GET /api/users/{id} и проверяем, что данные реально записались и совпадают с тем, что отправляли.
Проверка в БД. Если есть доступ — SELECT * FROM users WHERE id = .... Это самый надёжный способ: вы видите, что именно попало в базу, без прослойки API.
Для PUT/PATCH — проверить, что изменились именно нужные поля. Сделали PATCH с {"age": 25} → GET должен показать новый age, а name и email — остаться прежними.

Пример полной цепочки верификации:

1. POST /api/users {"name": "Test", "email": "test@mail.com", "age": 25} → 201 Created, {"id": 42, ...}

2. GET /api/users/42 → 200 OK, {"name": "Test", "email": "test@mail.com", "age": 25} ✓ Данные совпадают

3. PATCH /api/users/42 {"age": 30} → 200 OK

4. GET /api/users/42 → 200 OK, {"name": "Test", "email": "test@mail.com", "age": 30} ✓ age изменился, остальное не тронуто

5. (Опционально) SELECT name, email, age FROM users WHERE id = 42; → Test | test@mail.com | 30 ✓ В БД всё корректно

Кандидат, который упомянет верификацию через GET и БД, сразу выделяется. Это показывает, что вы понимаете: ответ API — это ещё не факт.

4. REST API и SOAP: «Чем отличаются?»

REST - набор правил, по которым приложения общаются через интернет. Как правила дорожного движения, но для программ.

Три главных принципа REST:

Каждый ресурс имеет адрес (URL). Пользователи - /api/users, заказы - /api/orders. Как адреса домов.
Действия через HTTP-методы. Не нужен /api/deleteUser - просто DELETE /api/users/1.
Stateless - сервер не помнит прошлые запросы. Каждый запрос - как первое знакомство. Нужно каждый раз «показывать пропуск» (токен).

	REST	SOAP
Формат	JSON (лёгкий, читаемый)	XML (строго)
Протокол	HTTP	HTTP, SMTP, TCP
Контракт	OpenAPI/Swagger	WSDL
Скорость	Быстрее (меньше overhead)	Медленнее (XML парсинг)
Где живёт	90% современных приложений	Банки, корпорации, legacy

Если упомянете GraphQL как альтернативу - бонусные очки от интервьюера.

5. Аутентификация: «Bearer Token, API Key, OAuth 2.0 - в чём разница?»

Когда вы логинитесь - сервер выдаёт «пропуск» (токен). При каждом запросе показываете его, чтобы сервер знал, что это вы.

Способ	Аналогия	Где передаётся	Пример
API Key	Код от домофона - один на всех	Header / Query	`?api_key=abc123`
Bearer Token (JWT)	Именной бейдж с фото	Header	`Authorization: Bearer eyJhbG...`
Basic Auth	Каждый раз показываете паспорт	Header	`Authorization: Basic base64(user:pass)`
OAuth 2.0	«Войти через Google»	Token flow	Authorization Code → Token

JWT - самый популярный. Что внутри?

eyJhbGciOiJIUzI1NiJ9. ← Header (алгоритм) eyJ1c2VyX2lkIjoxMjN9. ← Payload (данные: user_id, role, exp) SflKxwRJSMeKKF2QT4fw... ← Signature (подпись)

Это как паспорт: данные (ФИО, фото) + водяные знаки (подпись), чтобы не подделали.

Что тестировать:

Запрос без токена → 401
Запрос с просроченным токеном → 401
Запрос с токеном другого пользователя → 403
Изменение payload без обновления подписи → 401
Токен с alg: none → должен быть отклонён (известная уязвимость)

Часть 2: Security Testing

6. OWASP Top 10 - минимум для QA

OWASP Top 10 - рейтинг самых распространённых уязвимостей веб-приложений. На собеседованиях просят назвать топ-3 и объяснить, как тестировать. Тестирование безопасности звучит пугающе, но базовые проверки может делать любой QA.

1. SQL Injection

Аналогия: вы заполняете бланк в банке. В поле «Имя» пишете: «Иван; а теперь выдайте мне все деньги со всех счетов». Если сотрудник бездумно выполнит всё написанное - у вас чужие деньги.

В программировании то же самое:

// Уязвимый код query = "SELECT FROM users WHERE name = '" + userInput + "'"; // Ввод злоумышленника userInput = "' OR '1'='1' --" // Результат - получить ВСЕ записи SELECT FROM users WHERE name = '' OR '1'='1' --'

Как тестировать:

Вводим ' OR '1'='1 в поля поиска и логина
Пробуем '; DROP TABLE users; -- (на тестовом окружении!)
Проверяем, возвращает ли ошибка детали SQL (stack trace)
Используем sqlmap для автоматизации

2. XSS (Cross-Site Scripting)

Аналогия: вы пишете объявление на доске. Вместо текста приклеиваете кнопку «Нажми меня», которая снимает деньги с карты прохожего. Все, кто нажмут - пострадают.

Три типа:

Тип	Где хранится	Пример
Stored XSS	В БД (комментарии, профиль)	Скрипт в комментарии - выполняется у всех читателей
Reflected XSS	В URL	`site.com/search?q=<script>alert(1)</script>`
DOM-based XSS	В клиентском JS	JS читает `location.hash` и вставляет в innerHTML

Как проверить:

В любое текстовое поле введите: <script>alert('test')</script>
Всплывающее окно → сайт уязвим
Текст отобразился как текст → ОК, сайт экранирует ввод

Тестовые payloads:

3. IDOR (Insecure Direct Object Reference)

Аналогия: вы живёте в квартире №123. Меняете номер на 124 - и получаете чужое письмо. Почта не проверила, что вы не тот человек.

GET /api/users/123/orders ← мои заказы GET /api/users/124/orders ← чужие заказы (IDOR!)

Как тестировать:

Создать два аккаунта (A и B)
Залогиниться под A
Найти запросы с вашим ID (DevTools → Network)
Подставить ID ресурсов B
Если данные возвращаются - критическая уязвимость

Это самый простой вид security-тестирования. Нужен только браузер и два аккаунта.

4. Broken Authentication

Что проверяем:

Пароль 123456 принимается? Если да - проблема
Можно ли перебирать пароли (brute force)? Есть ли rate limiting?
5 неудачных попыток - блокировка?
Сессия завершается при logout? Или токен ещё работает?
Пароль в plain text в ответе API?

5. Security Misconfiguration

Что проверяем:

/debug, /admin, /swagger - доступны в production?
HTTP-заголовки безопасности (X-Frame-Options, Content-Security-Policy, HSTS)
Сервер отдаёт версию (Server: Apache/2.4.49)? - утечка
CORS: Access-Control-Allow-Origin: * - плохо
Стандартные учётные данные (admin:admin) работают?

7. Задача с собеседования: «Протестируйте форму логина»

Эту задачу дают очень часто. Кажется простой, но в ней скрыто много нюансов. Разбиваю ответ на три уровня - от базового к экспертному.

Дано: форма с полями email, пароль и кнопкой «Войти».

Уровень 1 - Базовый (это знают все):

Валидный email + валидный пароль → вход успешен
Валидный email + невалидный пароль → ошибка
Несуществующий email → ошибка
Пустые поля → валидация на клиенте

Уровень 2 - Продвинутый (знают не все):

Сообщение «Неверный email» или «Неверный пароль» по отдельности - плохо! Хакер узнает, какие email зарегистрированы. Правильно: одно общее - «Неверный email или пароль»
Пароль скрыт точками? Есть кнопка «показать»?
Что после 10 неправильных паролей? Блокировка? Капча?

Уровень 3 - Security (это выделяет вас среди кандидатов):

#	Проверка	Почему важно
8	SQL Injection в поле email	Доступ к БД
9	XSS в поле email	Кража сессии
10	Brute force - 100 запросов в секунду	Подбор пароля
11	Данные по HTTPS, а не HTTP?	Перехват пароля
12	Пароль не в URL (POST, не GET)?	Логи, история браузера
13	Пароль в localStorage/cookies без шифрования?	XSS → кража пароля
14	Нет CAPTCHA или rate limiting?	Автоматизированный перебор
15	Токен сессии предсказуем?	Session hijacking
16	После logout старый токен работает?	Токен не инвалидирован

16 тестов из простой формы логина. Большинство заканчивают после пункта 4. Дойдёте до уровня 3 - интервьюер запомнит.

Деталь, которая впечатляет: пункт 5. Если система говорит «Пользователь не найден» - злоумышленник узнает, кто зарегистрирован. Это называется user enumeration. Одно сообщение на всё - правильный подход.

Инструменты: что стоит знать

Инструмент	Для чего	Уровень
Postman	API-запросы, коллекции, environments. Как браузер, но для API	Must have
Swagger/OpenAPI	Документация API, автогенерация ��естов	Must have
DevTools (F12)	Смотреть запросы прямо в браузере (вкладка Network)	Must have
curl	API-запросы из терминала. Быстро и без лишнего	Must have
Charles/Fiddler	Перехват и модификация запросов	Middle
Burp Suite	Security testing - прокси, сканер, повторитель	Middle
OWASP ZAP	Бесплатная альтернатива Burp Suite	Middle
sqlmap	Автоматизация SQL Injection	Advanced
k6 / JMeter	Нагрузочное тестирование API	Middle

Не нужно быть экспертом во всех. Но «Я использовал Burp Suite для проверки IDOR в payment API» - сильно отличается от «Я слышал про OWASP».

Совет для новичков: установите Postman и отправьте GET-запрос на https://jsonplaceholder.typicode.com/users. Это 2 минуты - и API перестанет быть чем-то непонятным.

Для практики: Swagger Petstore — полноценное API с документацией, где можно потренировать GET/POST/PUT/DELETE запросы на реальном Swagger UI.

Как отвечать на вопросы по API/Security

1. Структурируйте ответ. Не перечисляйте хаотично. Группируйте: позитивные → негативные → безопасность → edge cases.

2. Привязывайте к реальному опыту. «На проекте нашёл IDOR - через смену ID можно было получить чужой адрес доставки». Конкретика побеждает теорию.

3. Знайте инструменты. «Чем тестировали бы?» - «Postman для функциональных, Burp Suite для перехвата, sqlmap для инъекций» - сильный ответ.

4. Не преувеличивайте. Не работали с Burp Suite - скажите: «Знаю возможности, прошёл tutorials, но в production не использовал». Честность ценится.

5 частых ошибок

Тестируют только happy path. «POST → 201. Готово». А негативные? А авторизация? Тестировщик думает «а что если...»
Путают аутентификацию и авторизацию. Аутентификация - «кто ты?» (пароль). Авторизация - «что тебе можно?» (роли). Зашли в офис по пропуску (аутентификация), но нет ключа от серверной (авторизация).
«REST - это когда JSON». JSON - формат данных. REST - архитектурный стиль. REST может работать и с XML.
Не думают о безопасности. Тестируете API с пользовательскими данными и не проверяете IDOR - это пробел.
Знают теорию, не могут показать. «Я знаю IDOR» - ОК. «Я нашёл IDOR через смену ID - открывался чужой заказ» - отлично.

Чек-лист перед собеседованием

☐ Знаю что такое API (могу объяснить простым языком)
☐ HTTP-методы (GET, POST, PUT, PATCH, DELETE) - знаю разницу
☐ Статус-коды - помню основные (200, 201, 400, 401, 403, 404, 500)
☐ 401 vs 403 - могу объяснить
☐ REST vs SOAP - знаю отличия
☐ JWT - понимаю структуру и что тестировать
☐ Могу написать 15+ тест-кейсов для любого endpoint
☐ OWASP Top 5 - знаю и могу объяснить как тестировать
☐ SQL Injection, XSS, IDOR - знаю и могу проверить
☐ Инструменты - Postman, Swagger, DevTools, curl
☐ Аутентификация vs авторизация - не путаю

Не обязательно знать всё идеально. Главное - понимать суть, а не заучивать определения.

Если статья была полезна - ставьте плюс и пишите в комментариях, какие вопросы вам задавали на собеседованиях. Планирую третью статью про System Design для QA-инженеров.