Тестирование API: Полное руководство для QA Junior/Middle

Основы клиент-серверной архитектуры и анатомия HTTP-запроса

Добро пожаловать на курс «Тестирование API: Полное руководство для QA Junior/Middle». Мы начинаем наше погружение в мир API с фундаментальных понятий. Прежде чем открывать Postman или писать автотесты, необходимо четко понимать, как устроен интернет «под капотом».

В этой статье мы разберем, как взаимодействуют компьютеры в сети, из чего состоит это общение и почему HTTP — это основной язык веба.

Клиент-серверная архитектура: Как это работает?

Большинство современных веб-приложений и мобильных сервисов построено на базе клиент-серверной архитектуры. Это модель взаимодействия, в которой задачи распределены между поставщиками ресурсов или услуг, называемыми серверами, и заказчиками услуг, называемыми клиентами.

Чтобы понять это проще, давайте представим обычный ресторан.

Аналогия с рестораном

Клиент (Гость): Это вы. Вы сидите за столиком и хотите поесть. В мире IT клиентом выступает ваш веб-браузер (Chrome, Firefox), мобильное приложение на телефоне или даже «умный» чайник.

Сервер (Кухня): Это место, где готовят еду, хранят продукты и знают рецепты. В IT сервер — это мощный компьютер (или сеть компьютеров), который хранит базу данных, логику приложения и файлы сайта.

API (Официант): Вы не идете на кухню сами, чтобы пожарить стейк. Вы зовете официанта. Официант принимает ваш заказ (запрос), относит его на кухню, ждет приготовления и приносит вам еду (ответ). Официант — это интерфейс взаимодействия.

!Аналогия клиент-серверной архитектуры через процесс заказа еды в ресторане

Техническое определение

В контексте тестирования API:

* Клиент отправляет Запрос (Request) через сеть. * Сервер обрабатывает этот запрос, обращается к базе данных (если нужно), выполняет вычисления и отправляет обратно Ответ (Response).

Протокол HTTP

Как клиент и сервер понимают друг друга? Им нужен общий язык. В вебе таким языком является HTTP (HyperText Transfer Protocol — протокол передачи гипертекста).

HTTP — это протокол прикладного уровня. Он работает по принципу «запрос-ответ». Важно помнить, что HTTP является протоколом без сохранения состояния (stateless). Это означает, что сервер не запоминает предыдущие запросы от того же клиента. Каждый запрос — это новая, независимая история (хотя существуют механизмы, такие как Cookies и токены, чтобы имитировать «память», но об этом позже).

Анатомия HTTP-запроса (Request)

Когда вы, как QA-инженер, будете тестировать API, вы будете конструировать именно HTTP-запросы. Давайте разберем его «скелет».

HTTP-запрос состоит из трех основных частей:

Стартовая строка (Start Line)

Заголовки (Headers)

Тело запроса (Body) — необязательно

!Структура HTTP-запроса: метод, заголовки и тело

1. Стартовая строка

Она содержит метод запроса, URL (адрес) и версию протокола.

#### URL (Uniform Resource Locator) Это адрес ресурса, к которому мы обращаемся. Например: https://api.example.com/users/123

* https:// — протокол (с шифрованием). * api.example.com — домен (хост). * /users/123 — путь (path) к конкретному ресурсу (пользователю с ID 123).

#### Методы HTTP (Verbs) Метод указывает серверу, какое действие мы хотим совершить. Самые популярные методы часто называют аббревиатурой CRUD (Create, Read, Update, Delete):

GET (Read): Получить данные. Пример: Открыть страницу товара или получить список пользователей.* У этого метода обычно нет тела запроса. POST (Create): Создать новые данные. Пример: Регистрация пользователя или оформление заказа.* Данные передаются в теле запроса. PUT (Update): Полностью обновить существующие данные. Пример: Перезаписать всю информацию о товаре.* PATCH (Update): Частично обновить данные. Пример: Изменить только пароль пользователя.* DELETE (Delete): Удалить данные. Пример: Удалить товар из корзины.*

2. Заголовки (Headers)

Заголовки — это метаданные, служебная информация для сервера. Они передаются в формате Ключ: Значение.

Примеры важных заголовков: * Content-Type: application/json — сообщает серверу, что мы отправляем данные в формате JSON. * Authorization: Bearer <token> — ваш «пропуск» или паспорт. Подтверждает, что вы имеете право выполнять этот запрос. * User-Agent — информация о клиенте (например, версия браузера или Postman).

3. Тело запроса (Body)

Это полезная нагрузка (payload). Здесь находятся данные, которые мы хотим отправить на сервер. Тело есть у методов POST, PUT, PATCH, но обычно отсутствует у GET и DELETE.

Чаще всего в современных REST API данные передаются в формате JSON.

Пример тела запроса (создание пользователя):

Анатомия HTTP-ответа (Response)

После обработки запроса сервер отправляет ответ. Он также имеет структуру:

Стартовая строка (со статусом)

Заголовки

Тело ответа

Коды состояния (Status Codes)

Это трехзначные числа, которые сообщают результат операции. QA-инженер обязан знать основные классы кодов наизусть.

* 1xx (Информационные): Запрос получен, процесс продолжается. * 2xx (Успех): * 200 OK: Все прошло хорошо (стандартный ответ для GET). * 201 Created: Ресурс успешно создан (стандартный ответ для POST). * 3xx (Перенаправление): Ресурс перемещен, нужно перейти по другому адресу. * 4xx (Ошибка клиента): Вы (клиент) сделали что-то не так. * 400 Bad Request: Ошибка в синтаксисе запроса (например, отправили текст вместо числа). * 401 Unauthorized: Вы не авторизованы (нет паспорта). * 403 Forbidden: Доступ запрещен (паспорт есть, но визы нет). * 404 Not Found: Ресурс не найден (неверный URL). * 5xx (Ошибка сервера): Вы все сделали правильно, но сервер сломался. * 500 Internal Server Error: Внутренняя ошибка сервера (упала база, ошибка в коде разработчика). * 503 Service Unavailable: Сервер перегружен или на обслуживании.

Тело ответа

Сервер возвращает данные, которые вы запрашивали, или описание ошибки. Например, если мы запрашивали данные пользователя, сервер вернет:

Формат JSON

Вы заметили, что в примерах используется формат, похожий на объект в JavaScript. Это JSON (JavaScript Object Notation). Это стандарт де-факто для REST API.

Основные правила JSON: * Данные хранятся в парах "ключ": значение. * Ключи всегда в двойных кавычках. * Строковые значения всегда в двойных кавычках. * Поддерживаются типы: строка, число, булево значение (true/false), массив [], объект {} и null.

Инструменты: Postman и Swagger

В теории все выглядит логично, но как это «потрогать» руками? Для этого мы будем использовать специальные инструменты.

* Swagger (OpenAPI): Это документация к API. Представьте, что это меню в ресторане. Там написано, какие блюда (эндпоинты) есть, из чего они состоят (параметры) и сколько стоят (какие права нужны). * Postman: Это инструмент для отправки запросов. Это ваш пульт управления, с помощью которого вы можете сформировать любой запрос, добавить заголовки, тело и посмотреть, что ответит сервер, не создавая при этом графический интерфейс сайта.

В следующих уроках мы установим Postman и сделаем свой первый реальный запрос.

Заключение

Понимание структуры HTTP-запроса — это база, без которой невозможно качественное тестирование API. Вы должны уметь читать запрос как открытую книгу: видеть метод, понимать заголовки и анализировать тело ответа.

В следующем уроке мы подробно разберем, что такое REST, чем он отличается от SOAP, и начнем практическую работу.

Структура данных, форматы JSON/XML и работа с документацией Swagger

В предыдущем уроке мы разобрали анатомию HTTP-запроса и выяснили, что клиент и сервер обмениваются данными. Но как именно выглядят эти данные? Если HTTP — это конверт, в котором летит письмо, то форматы данных (JSON или XML) — это язык, на котором написано само письмо.

В этой статье мы углубимся в структуру данных, научимся читать и писать JSON, поймем, почему XML все еще жив, и разберем главный инструмент QA-инженера для изучения API — Swagger.

Зачем нужны форматы обмена данными?

Представьте, что сервер написан на языке Java, а клиент (браузер) понимает только JavaScript. Или мобильное приложение написано на Swift (iOS). У каждого языка программирования свои способы хранения данных в памяти.

Чтобы они могли понять друг друга, нужен универсальный текстовый формат. Процесс превращения программного объекта в текст для передачи по сети называется сериализацией, а обратный процесс — десериализацией.

Два самых популярных формата для этого — JSON и XML.

JSON: Король современного веба

JSON (JavaScript Object Notation) — это текстовый формат обмена данными, основанный на синтаксисе объектов JavaScript. Несмотря на название, он используется практически во всех языках программирования (Python, Java, C#, PHP и др.).

Его главные преимущества:

Легковесность: Минимум лишних символов.

Читаемость: Человеку легко понять структуру.

Простота: Ограниченный набор правил.

Синтаксис и типы данных JSON

JSON строится на двух структурах: * Объект: Набор пар «ключ: значение», заключенный в фигурные скобки {}. * Массив: Упорядоченный список значений, заключенный в квадратные скобки [].

!Наглядная схема доступных типов данных и синтаксиса в JSON

Рассмотрим пример профиля пользователя в формате JSON:

Давайте разберем каждый элемент:

Строки (String): Всегда в двойных кавычках. "username": "qa_master". Одинарные кавычки запрещены.

Числа (Number): Целые или дробные. Пишутся без кавычек. "id": 105, "balance": 150.50.

Булевы значения (Boolean): Только true или false (без кавычек).

Массивы (Array): Список значений через запятую. "roles": ["user", "admin"].

Объекты (Object): Вложенные структуры. Значением ключа address является другой объект {...}.

Null: Пустое значение. "zip": null.

> Важное правило: В JSON ключи всегда должны быть строками в двойных кавычках. Последний элемент в объекте или массиве не должен иметь запятой после себя (хотя некоторые парсеры это прощают, стандарт это запрещает).

XML: Строгий ветеран

XML (eXtensible Markup Language) — это расширяемый язык разметки. Он похож на HTML, так как тоже использует теги.

Если JSON — это про простоту, то XML — про структуру и строгость. Он часто используется в банковской сфере, в крупных корпоративных системах (Enterprise) и в протоколе SOAP (о котором мы поговорим позже).

Структура XML

Тот же самый пример пользователя, но в XML:

Особенности XML:

Теги: Данные обернуты в открывающий <tag> и закрывающий </tag> теги.

Корневой элемент: Весь документ должен быть обернут в один главный тег (в примере это <user>).

Атрибуты: Дополнительная информация может храниться внутри открывающего тега (например, id="105").

Древовидная структура: Элементы строго вложены друг в друга.

Сравнение JSON и XML

| Характеристика | JSON | XML | | :--- | :--- | :--- | | Читаемость | Высокая, меньше «шума» | Ниже, много повторяющихся тегов | | Размер данных | Меньше (компактный) | Больше (из-за тегов) | | Типы данных | Поддерживает нативно (числа, массивы) | Все является текстом, типы нужно определять схемой | | Сфера применения | REST API, веб-сервисы, мобильные приложения | SOAP, сложные корпоративные системы, конфигурационные файлы |

Для современного QA-инженера знание JSON обязательно на 100%, знание XML — на уровне понимания структуры и умения прочитать данные.

Swagger (OpenAPI): Карта для тестировщика

Теперь, когда мы понимаем, как выглядят данные, нам нужно узнать, куда их отправлять и что ожидать в ответ. Здесь на сцену выходит Swagger.

Swagger (сейчас часто называемый спецификацией OpenAPI) — это интерактивная документация для REST API. Это веб-страница, которая автоматически генерируется на основе кода разработчиков и описывает все доступные эндпоинты (адреса).

Для тестировщика Swagger — это главный инструмент после Postman. Он позволяет:

Увидеть список всех запросов.

Узнать, какие параметры обязательны.

Посмотреть примеры тела запроса и ответа.

Отправить тестовый запрос прямо из браузера.

!Типичный интерфейс документации Swagger UI

Как читать Swagger?

Когда вы открываете Swagger, вы видите список ресурсов (например, Users, Products, Orders). Нажав на ресурс, вы увидите список методов.

Разберем структуру описания одного метода (эндпоинта):

#### 1. Метод и URL Например: POST /users. Рядом обычно есть краткое описание: Create a new user.

#### 2. Parameters (Параметры) Здесь описано, что можно или нужно передать вместе с запросом. Параметры бывают разных типов: * Query: Параметры в строке запроса (после знака ?). Пример: /users?role=admin. * Path: Часть пути URL. Пример: /users/{id}, где {id} — это path-параметр. * Header: Заголовки (например, токен авторизации).

В Swagger напротив каждого параметра стоит пометка required (обязательный) или нет, а также тип данных (integer, string).

#### 3. Request Body (Тело запроса) Для методов POST и PUT здесь будет показана схема JSON (Model или Example Value). Вы можете кликнуть на пример, и он скопируется в поле редактирования.

Пример схемы в Swagger:

Это подсказка: поле username ждет строку, а age — число.

#### 4. Responses (Ответы) Самая важная часть для проверки. Здесь перечислены возможные коды состояния и структуры ответов.

* 200 OK: Успешный ответ (показан пример JSON, который вернет сервер). * 400 Bad Request: Описание ошибки валидации. * 401 Unauthorized: Что будет, если не передать токен.

Практика: Кнопка «Try it out»

Swagger — это не просто текст, это инструмент. У каждого метода есть кнопка Try it out (Попробовать).

Алгоритм действий:

Нажимаем Try it out.

Поля параметров становятся активными для ввода.

Заполняем id, name или редактируем JSON в Request Body.

Нажимаем большую синюю кнопку Execute.

Смотрим вниз: там появится блок Server response.

* Code: Код ответа (например, 200). * Response body: Реальные данные, которые вернул сервер.

Это позволяет провести дымовое тестирование (Smoke Testing) API еще до того, как вы настроили Postman или написали автотесты.

Schemas (Схемы)

В самом низу страницы Swagger обычно есть блок Schemas или Models. Там описаны все объекты, которые используются в API. Если в методе вы видите ссылку на объект User, вы можете пролистать вниз и посмотреть детально, из каких полей состоит User, какие у них ограничения (например, maxLength, minimum).

Заключение

Понимание форматов данных — это база. Вы должны уметь взглянуть на JSON и сразу заметить ошибку: пропущенную кавычку или запятую. Вы должны уметь открыть Swagger и быстро понять, как составить запрос, чтобы получить нужные данные.

В следующем уроке мы перейдем от теории и документации к настоящей практике. Мы установим Postman, настроим рабочее окружение и сделаем свои первые запросы к реальному API, используя знания, полученные в этих двух статьях.

Практика в Postman: коллекции, переменные и написание тестов

Мы прошли большой путь: разобрали, как работает интернет, изучили анатомию HTTP-запросов и научились читать JSON. Теперь пришло время перейти от теории к практике. В этой статье мы познакомимся с Postman — главным инструментом любого QA-инженера, работающего с API.

Postman — это не просто программа для отправки запросов. Это мощная среда разработки API, которая позволяет организовывать запросы, автоматизировать проверки и даже создавать документацию. Сегодня мы научимся создавать коллекции, использовать переменные, чтобы не копировать один и тот же URL сто раз, и напишем свои первые автотесты на JavaScript.

Знакомство с интерфейсом Postman

После установки и запуска Postman (скачать его можно с официального сайта) вы увидите рабочий интерфейс. Он может показаться перегруженным, но нам важны три основные зоны:

Боковая панель (Sidebar): Слева находится навигация. Здесь живут ваши Коллекции (Collections), Окружения (Environments) и История (History).

Построитель запроса (Request Builder): Центральная часть. Здесь мы выбираем метод (GET, POST), вводим URL, добавляем заголовки и тело запроса.

Панель ответа (Response Section): Нижняя часть. Здесь отображается то, что вернул сервер: статус-код, время ответа и само тело ответа (JSON/XML).

!Основные рабочие зоны интерфейса Postman

Ваш первый запрос

Для практики мы будем использовать открытый тестовый API — ReqRes (https://reqres.in). Это идеальный «песочный» сервис, который имитирует работу реального бэкенда.

Давайте получим список пользователей.

Нажмите на + (плюс) в центральной панели, чтобы создать новую вкладку.

Убедитесь, что в выпадающем списке методов выбран GET.

В поле URL введите: https://reqres.in/api/users?page=2.

Нажмите синюю кнопку Send (Отправить).

В нижней части экрана вы увидите ответ. Обратите внимание на статус 200 OK и JSON с данными пользователей. Поздравляем, вы только что вручную выполнили работу, которую обычно делает браузер!

Коллекции: наводим порядок

Представьте, что вы тестируете интернет-магазин. У вас есть запросы для товаров, корзины, пользователей, оплаты. Если держать их просто в истории, вы быстро запутаетесь. Для организации запросов в Postman используются Коллекции.

Коллекция (Collection) — это папка, в которой хранятся запросы. Коллекции могут иметь вложенные папки, что позволяет выстраивать иерархию.

Как создать коллекцию?

В левой панели нажмите кнопку Collections.

Нажмите + или Create new collection.

Назовите её «ReqRes API Test».

Теперь сохраним наш первый запрос в эту коллекцию:

Вернитесь к вкладке с запросом GET https://reqres.in/api/users?page=2.

Нажмите кнопку Save (рядом с кнопкой Send).

Дайте запросу понятное имя, например, Get Users List.

Выберите созданную коллекцию «ReqRes API Test» и нажмите Save.

Теперь ваш запрос сохранен. Вы можете закрыть вкладку и открыть его снова в любой момент из боковой панели.

Переменные: принцип DRY

В программировании есть принцип DRY (Don't Repeat Yourself — не повторяйся). Представьте, что у вас в коллекции 50 запросов, и все они начинаются с https://reqres.in. Вдруг разработчики говорят: «Мы переехали на тестовый сервер https://dev.reqres.in». Вам придется менять адрес в 50 местах. Это долго и чревато ошибками.

Чтобы этого избежать, мы используем переменные.

Типы переменных

В Postman есть несколько уровней видимости переменных (Scopes), но чаще всего используются два:

Global (Глобальные): Доступны во всех коллекциях.

Collection (Переменные коллекции): Доступны только внутри конкретной коллекции.

Environment (Переменные окружения): Наборы переменных для переключения между средами (Dev, Stage, Prod).

!Иерархия областей видимости переменных в Postman

Создание переменной коллекции

Давайте заменим часть URL на переменную.

Нажмите на название вашей коллекции «ReqRes API Test» в боковой панели.

Перейдите на вкладку Variables в открывшемся окне.

Добавьте новую переменную:

* Variable: baseUrl * Initial value: https://reqres.in * Current value: https://reqres.in

Нажмите Save (Ctrl+S / Cmd+S).

Использование переменной

Теперь вернемся к нашему запросу Get Users List. Замените адрес https://reqres.in на конструкцию {{baseUrl}}.

Ваш URL должен выглядеть так: {{baseUrl}}/api/users?page=2

Двойные фигурные скобки {{...}} говорят Postman'у: «Возьми значение из переменной с этим именем». Если вы наведете курсор на переменную, Postman покажет её текущее значение. Нажмите Send — запрос должен работать так же, как и раньше.

Написание тестов (Tests)

Самая важная часть для QA. Просто отправить запрос мало, нужно проверить, что ответ соответствует ожиданиям. В Postman для этого есть вкладка Tests.

Здесь мы пишем скрипты на языке JavaScript, которые выполняются после получения ответа от сервера. Не пугайтесь, если вы не знаете JS — Postman предоставляет готовые фрагменты кода (Snippets).

Ваш первый тест: Проверка статус-кода

Откройте запрос Get Users List.

Перейдите на вкладку Tests (под строкой URL).

Справа вы увидите панель Snippets. Найдите там пункт Status code: Code is 200 и кликните по нему.

В редакторе появится код:

Разберем, что здесь написано: * pm — это объект Postman, дающий доступ к данным запроса и ответа. * pm.test — функция, создающая тест-кейс. Первым аргументом мы пишем название теста (оно отобразится в отчете), вторым — функцию с проверками. * pm.response.to.have.status(200) — это утверждение (assertion). Мы буквально говорим: «Ожидаю, что ответ имеет статус 200».

Нажмите Send. Теперь перейдите во вкладку Test Results (внизу, рядом с Body). Вы увидите зеленую надпись: PASS Status code is 200.

Проверка тела ответа (JSON)

Давайте проверим, что сервер вернул именно вторую страницу данных, как мы просили в параметре page=2.

Добавьте следующий код во вкладку Tests:

Разбор:

var jsonData = pm.response.json(); — мы берем весь ответ сервера и превращаем его в JavaScript-объект, чтобы с ним можно было работать.

pm.expect(jsonData.page).to.eql(2); — мы ожидаем, что поле page в этом объекте равно 2.

Динамические тесты и сохранение данных

Часто бывает нужно взять данные из одного запроса и использовать их в другом. Например, создать пользователя, получить его ID и затем проверить его профиль.

Предположим, мы хотим сохранить id первого пользователя из списка в переменную, чтобы использовать её потом.

После выполнения этого запроса в вашей коллекции появится новая переменная currentUserId, которую можно использовать в следующем запросе как {{currentUserId}}.

Окружения (Environments)

Ранее мы создавали переменную прямо в коллекции. Но что, если у вас есть тестовый стенд (Test) и боевой (Prod)?

Для этого создают Environments (Окружения). Вы можете создать окружение «Test» с переменной baseUrl = https://test-api.com и окружение «Prod» с baseUrl = https://api.com.

В правом верхнем углу Postman есть выпадающий список (обычно там написано No Environment). Выбирая нужное окружение, вы мгновенно подменяете значения всех переменных. Это позволяет запускать одну и ту же коллекцию тестов на разных серверах без изменения кода.

Collection Runner

Когда у вас накопится много запросов с тестами, запускать их по одному станет утомительно. Для этого существует Collection Runner.

Нажмите правой кнопкой мыши на вашу коллекцию.

Выберите Run collection.

Вы увидите настройки запуска: порядок выполнения, количество итераций, задержку.

Нажмите Run.

Postman пробежится по всем запросам, выполнит все скрипты из вкладки Tests и выдаст красивый отчет: сколько тестов прошло, сколько упало.

Заключение

Сегодня мы превратили Postman из «просто программы для запросов» в мощный инструмент автоматизации. Мы научились: * Структурировать работу через Коллекции. * Использовать Переменные, чтобы легко менять конфигурацию. * Писать Тесты на JavaScript, проверяя статус-коды и содержимое JSON.

Это база, на которой строится работа QA Automation. В следующих статьях мы углубимся в более сложные темы, такие как авторизация и цепочки зависимых запросов.

Теперь ваша задача — закрепить материал на практике, выполнив домашнее задание.

Основы баз данных и SQL для верификации данных API

Мы уже прошли большой путь: разобрали архитектуру веба, научились читать JSON и отправлять запросы через Postman. Вы умеете проверять статус-коды и тело ответа. Но есть один нюанс.

Представьте, что вы тестируете регистрацию. Вы отправляете POST /register, сервер отвечает 201 Created и возвращает красивый JSON с данными пользователя. Тест пройден? Вроде бы да. Но что, если сервер обманул вас? Что, если он вернул успешный ответ, но не сохранил пользователя в системе из-за сбоя на диске?

Чтобы быть уверенным на 100%, QA-инженер должен проверить «сердце» приложения — Базу Данных (БД). В этой статье мы разберем, как устроены базы данных, и выучим основы языка SQL, чтобы проверять API по-настоящему.

Роль Базы Данных в тестировании API

Вспомним нашу аналогию с рестораном. Клиент — это гость, API — это официант, Сервер — это кухня. А что такое База Данных?

База Данных (БД) — это огромная кладовая с продуктами и книга рецептов. Кухня (Сервер) не хранит информацию в своей оперативной памяти вечно. Если сервер перезагрузится, все данные в памяти исчезнут. Поэтому сервер записывает все важное (пользователей, заказы, товары) в базу данных для долговременного хранения.

!Схема потока данных от Клиента через Сервер к Базе Данных

Зачем тестировщику доступ к БД?

Верификация сохранения: Убедиться, что данные после POST запроса действительно появились в таблице.

Проверка обновлений: Убедиться, что после PUT запроса старые данные заменились на новые, а не создалась дублирующая запись.

Подготовка тестовых данных: Иногда проще создать пользователя прямым запросом в БД, чем проходить долгую регистрацию через API.

Поиск причин багов: API может вернуть ошибку 500 Internal Server Error. Заглянув в БД, вы можете увидеть, что, например, поле phone переполнено.

Реляционные базы данных и таблицы

Существует много видов баз данных, но в 90% случаев вы будете сталкиваться с реляционными базами данных (RDBMS). Самые популярные из них: PostgreSQL, MySQL, Oracle, MS SQL Server.

Слово «реляционная» происходит от relation (отношение). Данные в таких базах хранятся в таблицах, которые связаны друг с другом.

Это очень похоже на Excel. У таблицы есть: * Название: Например, users (пользователи). * Колонки (Columns): Атрибуты данных (ID, имя, email, дата рождения). * Строки (Rows): Конкретные записи (Пользователь Иван, Пользователь Мария).

Первичный ключ (Primary Key)

У каждой строки должен быть уникальный идентификатор, чтобы мы могли отличить одного Ивана от другого. Это поле называется Primary Key (обычно это колонка id).

SQL: Язык общения с базой

Чтобы сервер (или вы) могли что-то взять из базы или положить туда, нужен специальный язык. Это SQL (Structured Query Language — язык структурированных запросов).

Для QA-инженера важно понимать связь между методами HTTP (которые мы используем в Postman) и командами SQL.

Связь HTTP и SQL (CRUD)

| Действие | HTTP Метод | SQL Команда | Описание | | :--- | :--- | :--- | :--- | | Create (Создать) | POST | INSERT | Добавляет новую строку в таблицу | | Read (Читать) | GET | SELECT | Выбирает данные из таблицы | | Update (Обновить) | PUT / PATCH | UPDATE | Изменяет существующие данные | | Delete (Удалить) | DELETE | DELETE | Удаляет строку из таблицы |

Как тестировщики, мы чаще всего используем команду SELECT, чтобы проверить, что натворили наши API-запросы.

Основные команды SQL для тестировщика

Давайте разберем синтаксис на примерах. Представим, что у нас есть таблица users.

1. SELECT — Чтение данных

Самый простой запрос выглядит так:

* SELECT — команда «выбери». (звездочка) — означает «все колонки». * FROM users — из таблицы users. * ; — конец запроса.

Этот запрос вернет вообще всех пользователей. Если их миллион, ваш компьютер может зависнуть. Поэтому мы уточняем запрос.

2. WHERE — Фильтрация

Мы хотим найти конкретного пользователя, которого только что создали через Postman. Допустим, мы создавали пользователя с email test_qa@example.com.

Теперь база вернет только одну строку. Мы можем сверить данные из этой строки с тем, что мы отправляли в JSON.

Условия могут быть разными: * WHERE id = 5 (поиск по ID) * WHERE age > 18 (поиск по возрасту больше 18) * WHERE name LIKE 'A%' (имя начинается на букву А)

3. INSERT — Создание данных

Иногда вам нужно создать тестовые данные вручную, минуя API. Например, чтобы протестировать, как API реагирует на пользователя с отрицательным балансом (чего через интерфейс сделать нельзя).

4. UPDATE — Обновление данных

Используется для подготовки состояния системы. Например, нужно проверить, как работает вход для заблокированного пользователя.

> Внимание! Всегда используйте WHERE при обновлении или удалении. Если вы напишете просто UPDATE users SET is_active = false, база данных заблокирует всех пользователей в системе. Это классическая ошибка новичка, которая может «уронить» продакшн.

5. DELETE — Удаление данных

Полезно для очистки системы после автотестов.

JOIN: Объединение таблиц

В реальной жизни данные редко лежат в одной таблице. Это называется нормализацией.

Например: * Таблица users хранит имена. * Таблица orders хранит заказы.

В таблице orders нет имени заказчика, там есть только user_id — ссылка на таблицу пользователей. Это называется Foreign Key (Внешний ключ).

Если мы хотим получить список заказов с именами клиентов, нам нужно объединить таблицы. Для этого используется JOIN.

!Визуализация связи двух таблиц через внешний ключ

Пример запроса:

Этот запрос говорит: «Возьми заказы, присоедини к ним пользователей там, где ID совпадают, и покажи мне покупки Ивана».

Практический кейс верификации

Давайте соберем все знания в один реальный сценарий тестирования.

Задача: Протестировать создание заказа.

Шаг 1. Postman Отправляем запрос: POST /api/orders Body:

Шаг 2. Ответ API Получаем ответ: 201 Created

Шаг 3. Верификация в БД (SQL) Теперь мы идем в базу данных (используя клиент, например, DBeaver) и выполняем запрос:

Шаг 4. Сравнение Смотрим на результат SQL-запроса: * Есть ли запись с ID 555? (Если нет — баг). * Совпадает ли user_id с тем, что мы отправляли (10)? * Совпадает ли product ("Laptop")? * Верный ли статус ("pending")?

Если API вернул 201 OK, но в базе записи нет, или цена записалась как 0 — это критический баг, который вы бы не нашли, просто глядя на JSON-ответ.

Инструменты для работы с БД

Так же, как для HTTP-запросов мы используем Postman, для работы с базами данных нужны свои клиенты. Самые популярные:

DBeaver: Универсальный бесплатный инструмент. Поддерживает почти все типы баз данных (PostgreSQL, MySQL, SQLite и др.). Рекомендуется для новичков.

pgAdmin: Специализированный клиент для PostgreSQL.

DataGrip: Мощный платный инструмент от JetBrains (создателей IntelliJ IDEA).

Заключение

SQL — это второй по важности язык для тестировщика после языка, на котором вы пишете автотесты (или даже первый, если вы занимаетесь только ручным тестированием).

Умение заглянуть «под капот» API и проверить фактическое состояние данных отличает сильного Middle QA от Junior-специалиста. Не доверяйте слепо ответам сервера — доверяйте данным в базе.

В следующем уроке мы вернемся к Postman и изучим продвинутые техники: цепочки запросов и автоматизацию прогонов коллекций.

Сложные сценарии тестирования и реальные примеры интеграций

Добро пожаловать на финальный этап нашего курса «Тестирование API: Полное руководство для QA Junior/Middle». Мы прошли долгий путь: от понимания того, как работает интернет, до написания SQL-запросов и автотестов в Postman.

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

В этой статье мы разберем, как тестировать сложные бизнес-сценарии, работать с асинхронными API, проверять идемпотентность и справляться с интеграциями.

Цепочки запросов (Chained Requests)

Одиночный запрос — это как проверка одной детали автомобиля. Но чтобы проверить, едет ли машина, нужно завести двигатель, включить передачу и нажать на газ. Это и есть End-to-End (E2E) сценарий.

В контексте API это означает, что выходные данные одного запроса становятся входными данными для следующего.

Пример: Покупка товара в интернет-магазине

Типичный путь пользователя (User Journey) выглядит так:

Авторизация: POST /login -> получаем токен.

Поиск товара: GET /products?search=laptop -> получаем product_id.

Добавление в корзину: POST /cart (используем product_id).

Оформление заказа: POST /order -> получаем order_id.

Проверка статуса: GET /order/{order_id}.

!Поток данных в цепочке зависимых API-запросов

Реализация в Postman

Мы уже касались переменных в прошлых уроках, но здесь они критически важны. Вы не должны копировать ID руками.

В тесте (Tests) первого запроса вы сохраняете данные:

В следующем запросе (Добавление в корзину) вы используете эту переменную в теле запроса (Body):

Такой подход позволяет запускать коллекцию одной кнопкой (через Collection Runner), и тест пройдет успешно, даже если ID товаров в базе изменятся.

Тестирование асинхронных операций

Не все операции в вебе происходят мгновенно. Если вы загружаете видео на YouTube или запрашиваете генерацию тяжелого отчета за год, сервер не может заставить вас ждать 5 минут с открытым соединением — браузер просто выдаст ошибку тайм-аута.

Для таких задач используется асинхронная обработка.

Как это работает?

Клиент отправляет запрос: «Сгенерируй отчет». POST /reports/generate.

Сервер отвечает мгновенно: «Задачу принял, номер задачи 123». Код ответа обычно 202 Accepted (Принято).

Сервер в фоновом режиме начинает тяжелую работу.

Клиент периодически спрашивает: «Ну что, готово?» (Polling).

Стратегия тестирования (Polling)

Ваша задача как тестировщика — проверить не только то, что задача принята (202 код), но и дождаться реального результата.

Алгоритм проверки:

Отправить запрос на создание задачи.

Проверить, что статус 202.

Сохранить task_id.

В цикле отправлять запрос GET /tasks/{task_id}.

Проверять поле status в ответе.

* Если status: "processing" — ждем и повторяем запрос. * Если status: "completed" — проверяем результат (ссылку на отчет). * Если status: "failed" — тест провален.

!Принцип работы Polling (опроса) при асинхронных запросах

Идемпотентность API

Это страшное слово означает простую вещь: сколько бы раз вы ни повторили один и тот же запрос, результат (состояние системы) должен быть одинаковым.

Это критически важно для платежей и создания заказов. Представьте, что у пользователя плохой интернет. Он нажал кнопку «Оплатить», колесико крутится, ничего не происходит. Он нажимает еще 5 раз. Спишутся ли деньги 6 раз?

Правила идемпотентности методов HTTP

* GET: Идемпотентен. Сколько бы раз вы ни запрашивали список товаров, товары от этого не меняются. * PUT: Идемпотентен. Если вы 10 раз отправите запрос «Установить имя пользователя = Иван», имя останется «Иван». * DELETE: Идемпотентен. Если вы удалили товар с ID 100, первый запрос вернет 200 (OK), остальные — 404 (Not Found), но состояние системы не изменится — товара нет. * POST: НЕ идемпотентен. Если вы 10 раз отправите запрос «Создать заказ», создастся 10 разных заказов.

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

Для методов POST (особенно платежей) разработчики часто внедряют механизм ключей идемпотентности (Idempotency-Key). Это уникальный заголовок, который клиент генерирует перед отправкой.

Тест-кейс:

Отправить POST /payment с заголовком Idempotency-Key: unique-uuid-123 и суммой 100.

Повторить тот же самый запрос с тем же ключом. Результат: 200 OK (или специальный код), но деньги не списаны повторно, а возвращен результат первой операции.

Отправить запрос с новым ключом. Результат: 200 OK, списано еще 100$$.

Интеграция со сторонними сервисами

Современные приложения похожи на конструктор LEGO. Регистрация — через Google, оплата — через Stripe, SMS — через Twilio, карты — через Google Maps.

Тестирование таких интеграций — головная боль, потому что вы не контролируете чужой сервис.

Проблемы:

* Сторонний сервис может упасть, а виноватым будет казаться ваше приложение. * У стороннего сервиса есть лимиты на запросы (Rate Limits). * Нельзя использовать реальные деньги для тестов оплаты.

Решения:

Sandbox (Песочница): Почти все крупные провайдеры (PayPal, Stripe) предоставляют тестовую среду. Там используются специальные номера карт (например, 4242 4242 4242 4242), которые имитируют успешную оплату или отказ, но не списывают деньги.

Mocking (Мокирование): Если песочницы нет или она нестабильна, мы создаем «чучело» сервиса. Мы настраиваем специальный сервер (Mock Server), который на запрос «Оплатить» всегда отвечает «Ок», не проводя реальной логики. В Postman есть встроенные Mock Servers.

Важно: В E2E тестах на Staging-окружении старайтесь использовать Sandbox реального сервиса. Моки хороши для Unit-тестов и ранней разработки, но они не покажут, если сторонний API изменил формат ответа.

Аутентификация и сложные сценарии безопасности

В простых тестах мы часто используем Basic Auth (логин/пароль). Но в реальности правит бал OAuth 2.0 и JWT (JSON Web Token).

Жизненный цикл токена

Токен доступа (Access Token) — это ваш временный пропуск. Он живет недолго (например, 15 минут). Когда он протухает, приложение должно использовать Refresh Token (токен обновления), чтобы получить новый пропуск без ввода пароля пользователем.

Сценарий тестирования Refresh Token:

Залогиниться (POST /login), получить пару access_token и refresh_token.

Подождать время жизни токена (или использовать специально протухший токен).

Попытаться сделать запрос к защищенному ресурсу (GET /profile).

Ожидаемый результат: Ошибка 401 Unauthorized.

Отправить запрос на обновление (POST /refresh) с refresh_token.

Ожидаемый результат: 200 OK и новая пара токенов.

Повторить запрос к профилю с новым токеном. Результат: 200 OK.

Это обязательный сценарий для проверки стабильности мобильных приложений и фронтенда.

Работа с базой данных в сложных сценариях

В предыдущей статье мы научились делать простые SELECT. В сложных интеграциях БД — это главный арбитр правды.

Пример: Тестирование транзакции. Вы переводите деньги с счета А на счет Б.

API вернул 200 OK.

Проверка в БД:

* Баланс А уменьшился на сумму X. * Баланс Б увеличился на сумму X. * В таблице transactions появилась запись.

Если API вернул успех, деньги у А списались, а у Б не появились (сбой посередине) — это критическая ошибка потери целостности данных. Такое можно поймать только проверкой базы данных, JSON-ответ API вам об этом не скажет.

Заключение курса

Поздравляем! Вы прошли путь от новичка до специалиста, понимающего суть тестирования API. Мы разобрали: * Как устроен HTTP и форматы данных. * Как использовать Postman на полную мощность. * Как проверять данные в SQL. * Как подходить к сложным сценариям и интеграциям.

Тестирование API — это «невидимый фронт» качества. Именно здесь отлавливаются самые дорогие и критичные ошибки. Пользователь может простить съехавшую кнопку, но он никогда не простит, если при оплате деньги списались дважды.

Дальнейшее развитие для вас лежит в области автоматизации (изучение Python/Java/JS для написания автотестов без Postman) и внедрении тестов в CI/CD пайплайны. Но фундамент у вас уже есть. Удачи в поиске багов!