# Основы API ### **Этапы тестирования API** Каждый тест состоит из тестовых шагов. Это отдельные атомарные действия, которые тест должен выполнять в каждом потоке тестирования API. Для каждого запроса API тест должен будет выполнить следующие действия: 1. **Проверьте корректность кода состояния HTTP**. Например, создание ресурса должно возвращать 201 CREATED, а запрещенные запросы должны возвращать 403 FORBIDDEN и т. Д. 2. **Проверьте полезную нагрузку ответа**. Проверьте правильность тела JSON, имен, типов и значений полей ответа, в том числе в ответах на ошибочные запросы. 3. **Проверьте заголовки ответа.** Заголовки HTTP-сервера влияют как на безопасность, так и на производительность. 4. **Проверьте правильность состояния приложения**. Это необязательно и применяется в основном к ручному тестированию или когда пользовательский интерфейс или другой интерфейс можно легко проверить. 5. **Проверьте базовую работоспособность**. Если операция была завершена успешно, но заняла неоправданно много времени, тест не пройден. ### **Категории тестовых сценариев** Наши тест-кейсы делятся на следующие общие группы *тестовых сценариев*: * Основные позитивные тесты (прохождение успешного сценария по умолчанию) * Расширенное позитивное тестирование с дополнительными параметрами * Негативное тестирование с валидными входными данными * Негативное тестирование с недопустимыми входными данными * Деструктивное тестирование * Тесты безопасности, авторизации и доступности (которые выходят за рамки этой статьи) **Тестирование успешного сценария по умолчанию** проверяет базовую функциональность и критерии приемки API. Позже мы расширим положительные тесты, чтобы включить дополнительные параметры и дополнительные функции. Следующая группа тестов - это **негативное тестирование**, при котором мы ожидаем, что приложение будет корректно обрабатывать проблемные сценарии как с валидным вводом пользователя (например, попытка добавить существующее имя пользователя), так и с недопустимым вводом пользователя (попытка добавить имя пользователя, которое имеет значение null). **Деструктивное тестирование** - это более глубокая форма негативного тестирования, когда мы намеренно пытаемся сломать API, чтобы проверить его надежность (например, отправляя заведомо большое тело запроса в попытке переполнить систему). ### **Тестовые потоки** Давайте разделим и обозначим три вида потоков тестирования, которые составляют наш план тестирования: 1. **Изолированное тестирование запросов** - выполнение одного запроса API и соответствующая проверка ответа. Такие базовые тесты - это минимальные строительные блоки, с которых мы должны начинать. И нет смысла продолжать тестирование, если эти тесты упадут. 2. **Многоступенчатый рабочий поток с несколькими запросами** - тестирование серии запросов, которые являются обычными действиями пользователя, поскольку одни запросы могут зависеть от других. Например, мы выполняем запрос POST, который создает ресурс и возвращает автоматически сгенерированный идентификатор в своем ответе. Затем мы используем этот идентификатор, чтобы проверить, присутствует ли этот ресурс в списке элементов, полученных запросом GET. Затем мы используем PATCH для обновления новых данных и снова вызываем запрос GET для проверки этого обновления. И в завершении, мы УДАЛЯЕМ этот ресурс и снова используем GET, чтобы убедиться, что записи больше нет. 3. **Комбинированные тесты API и тесты веб-интерфейса** - это в основном относится к ручному тестированию, при котором мы хотим обеспечить целостность данных и согласованность между пользовательским интерфейсом и API. Мы выполняем запросы через API и проверяем действия через пользовательский интерфейс веб-приложения и наоборот. Цель этих потоков проверки целостности состоит в том, чтобы гарантировать, что, хотя на ресурсы влияют различные механизмы, система по-прежнему поддерживает ожидаемую целостность и согласованный поток данных. ### **Пример API и тестовая матрица** Теперь мы можем отобразить все в виде матрицы и использовать ее для написания подробного плана тестирования (для автоматизации тестирования или ручных тестов). Предположим, что подмножеством нашего API является конечная точка /users, которая включает следующие вызовы API: [Untitled](https://www.notion.so/8ca135676ea8429b8f7a3974bbd4bbe0) Где {id} - это UUID, а все конечные точки GET позволяют фильтровать, сортировать, исключать и ограничивать дополнительные параметры запроса для фильтрации, сортировки и разбивки на страницы тела ответа. ![https://habrastorage.org/r/w1560/getpro/habr/upload\_files/144/434/89f/14443489f79294c9b690e812db0a21a6.jpg](https://habrastorage.org/r/w1560/getpro/habr/upload_files/144/434/89f/14443489f79294c9b690e812db0a21a6.jpg) Основные позитивные тесты (позитивный путь по умолчанию) ![https://habrastorage.org/r/w1560/getpro/habr/upload\_files/614/b82/247/614b8224709115b646710d81056fafcd.jpg](https://habrastorage.org/r/w1560/getpro/habr/upload_files/614/b82/247/614b8224709115b646710d81056fafcd.jpg) Позитивные тесты + необязательные параметры проверок ![https://habrastorage.org/r/w1560/getpro/habr/upload\_files/d24/5a4/4ef/d245a44ef62ad3d881d350e0faf6a212.jpg](https://habrastorage.org/r/w1560/getpro/habr/upload_files/d24/5a4/4ef/d245a44ef62ad3d881d350e0faf6a212.jpg) Негативное тестирование – валидный ввод данных ![https://habrastorage.org/r/w1560/getpro/habr/upload\_files/fd1/ab5/6cd/fd1ab56cd64060cd08312aa4c1b4761a.jpg](https://habrastorage.org/r/w1560/getpro/habr/upload_files/fd1/ab5/6cd/fd1ab56cd64060cd08312aa4c1b4761a.jpg) Негативное тестирование - неверные входные данные ![https://habrastorage.org/r/w1560/getpro/habr/upload\_files/cfa/82f/42b/cfa82f42b4a17d6e3bbb5a3f5106854e.jpg](https://habrastorage.org/r/w1560/getpro/habr/upload_files/cfa/82f/42b/cfa82f42b4a17d6e3bbb5a3f5106854e.jpg) Деструктивное тестирование Тест-кейсы, полученные из приведенной выше таблицы, должны охватывать различные потоки тестирования в соответствии с нашими потребностями, ресурсами и приоритетами ([перевод таблицы в формате xls](https://drive.google.com/file/d/1ePHKuEw_QErn9g5TzgA4UGaQJ4OG3jTp/view?usp=sharing)). #### **Выходим за рамки функционального тестирования** Следуя приведенной выше тестовой матрице, вы должны сгенерировать достаточно тест-кейсов, чтобы было что тестировать некоторое время и обеспечить хорошее функциональное покрытие API. Прохождение всех функциональных тестов подразумевает хороший уровень зрелости API (про зрелость [тут](https://blog.restcase.com/4-maturity-levels-of-rest-api-design/). *прим. переводчика*), но этого недостаточно для обеспечения высокого качества и надежности API. ![https://habrastorage.org/r/w1560/getpro/habr/upload\_files/f3b/d6d/2ce/f3bd6d2ce45c0be3be9b24e97899fbac.png](https://habrastorage.org/r/w1560/getpro/habr/upload_files/f3b/d6d/2ce/f3bd6d2ce45c0be3be9b24e97899fbac.png) Уровни зрелости API В следующем разделе этой статьи мы рассмотрим следующие нефункциональные подходы к тестированию, которые необходимы для проверки качества API. #### **Безопасность и авторизация** * Убедитесь, что API разработан в соответствии с правильными принципами безопасности: отказ по умолчанию, безопасное падение сервиса, принцип наименьших привилегий, отклонение всех невалидных данных в запросе и т. д. * Позитивные тесты: убедитесь, что API отвечает на правильную авторизацию всеми согласованными методами аутентификации - ответный токен auth 2.0, файлы cookie, дайджест и т. д. - как определено в вашей спецификации. * Негативные тесты: убедитесь, что API отклоняет все несанкционированные вызовы. * Ролевые доступы: убедитесь, что определенные конечные точки доступны пользователю в зависимости от роли. API должен отклонять вызовы конечных точек, которые не разрешены для роли пользователя. * Проверка протокола: проверьте HTTP / HTTPS в соответствии со спецификацией * Утечки данных: убедитесь, что представления внутренних данных, которые должны оставаться внутри компании, не просачиваются за пределы общедоступного API в данных ответа. * Политики ограничения скорости, троттлинга и политики контроля доступа #### **Производительность** * Проверка времени ответа API, задержки, TTFB / TTLB в различных сценариях (изолированно и под нагрузкой) #### **Нагрузочные тесты (позитивные), стресс-тесты (негативные)** * Найдите точки ограничения производительности и убедитесь, что система работает должным образом под нагрузкой и корректно выходит из строя под нагрузкой. #### **Юзабилити-тесты пользователей API** * Для общедоступных API: ручной тест на уровне продукта, который проверяет весь путь разработчика от документации, входа в систему, аутентификации, примеров кода и т. д., Чтобы гарантировать удобство использования API для пользователей, не знакомых с вашей системой.