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

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

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

Что такое тестирование API?

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

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

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

Что важно учитывать при тестировании API?

Процесс тестирования API начинается с четкого понимания того, как API будет работать. Прежде всего стратегия. Стратегия тестирования — это высокоуровневое описание требований к тестированию, из которого впоследствии может быть составлен подробный план тестирования с указанием отдельных тестовых сценариев и тестовых случаев. Главные вопросы на этом этапе:

• Какие конечные точки доступны для тестирования?
• Какие коды ответов ожидаются для успешных запросов?
• Какие коды ответов ожидаются при неудачных запросах?
• Какое сообщение об ошибке должно появиться в теле неудачного запроса?

• время ответа;
• качество данных;
• подтверждение авторизации;
• коды состояния HTTP;
• и коды ошибок.

Валидационные испытания анализируют проекты API на основе трех наборов критериев: удобство использования API как продукта, транзакционное поведение и операционная эффективность. Типовые вопросы, которыми задаются во время валидационного тестирования:

• Соответствует ли разработанный API бизнес-логике и заявленным целям?
• Этот метод ведет себя так, как ожидалось?
• Это метод использует ресурсы максимально независимо и эффективно?
• Получает ли API доступ к данным в соответствии с предопределенными политиками?
• Сохраняет ли API данные в соответствии с правилами безопасности или соответствия?

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

Тестирование надежности гарантирует, что API дает согласованные результаты, а соединение между платформами надежно.

Тестирование безопасности проверяет методы шифрования, которые использует API, а также дизайн управления доступом.

Тестирование безопасности включает в себя проверку авторизации для доступа к ресурсам и управления правами пользователей.

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

Почему важно тестирование API?

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

Тестирование API позволяет начать тестирование на ранних этапах цикла разработки, прежде чем пользовательский интерфейс будет готов. Любой запрос, который не отвечает заданным значениям на уровне сервера, не будет отображаться на уровне пользовательского интерфейса. Это позволит разработчикам устранить как минимум половину существующих ошибок до того, как они станут более серьезными проблемами. Это также позволяет тестировщикам делать запросы, которые невозможны через пользовательский интерфейс, что требуется для выявления недостатков безопасности.

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

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

Включение тестов API в процесс разработки, принесет пользу командам инженеров и разработчиков на протяжении всего жизненного цикла разработки.

Преимущества тестирования API

Тестирование API гарантирует надежность, безопасность и масштабируемость соединений между платформами. Конкретные преимущества включают в себя:

• Для автоматизации тестирования API требуется меньше кода, чем для автоматизированных тестов графического интерфейса. Это обеспечивает повышение скорости тестирования и меньшую общую стоимость разработки ПО.
• Тестирование API позволяет разработчикам получать доступ к приложению без пользовательского интерфейса. Это позволяет тестировщику выявить ошибки на ранних этапах жизненного цикла разработки, а не ждать, пока они станут серьезными проблемами. Это также помогает экономить бюджет.
• Тесты API не зависят от технологии и языка. Обмен данными осуществляется с использованием JSON или XML и содержит HTTP-запросы и ответы.
• Тесты API используют экстремальные условия и входные данные при анализе приложений. Это устраняет уязвимости и защищает приложение от некачественного кода и поломок.
• Тесты API можно интегрировать с тестами GUI. Например, интеграция может позволить создать новых пользователей в приложении до выполнения теста графического интерфейса.

• Выбор параметров требует проверки параметров, отправленных через API-запросы, — процесс, который может быть сложным. Необходимо, чтобы тестировщики гарантировали, что все данные параметров соответствуют критериям проверки, таким как использование соответствующих данных, диапазон присвоенных значений и соответствие ограничениям длины.
• Комбинация параметров сложная задача, поскольку каждую комбинацию необходимо проверить, чтобы увидеть, не содержит ли она проблем, связанных с конкретными конфигурациями.
• Последовательность вызовов также является сложной задачей, поскольку каждый вызов должен появляться в определенном порядке, чтобы обеспечить правильную работу системы. Это особенно проблемно при работе с многопоточными приложениями.

При выполнении теста API разработчики могут либо написать свою собственную структуру, либо выбрать готовый к использованию инструмент тестирования API.

Разработка собственной среды тестирования API позволяет разработчикам гибко настраивать тест, поскольку они не ограничены возможностями конкретного инструмента и его внешних модулей. Тестировщики могут добавить любую библиотеку, которую они считают подходящей для выбранной среды разработки, создавать уникальные и удобные стандарты отчетности и включать в тесты сложную логику. Однако для этого потребуются сложные навыки кодирования.

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

Доступно большое количество инструментов для тестирования API. Это могут быть инструменты с платной подпиской или предложениями с открытым исходным кодом. Вот некоторые примеры инструментов тестирования API:

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

Когда пользователь открывает приложение социальной сети, например, Twitter или ВКонтакте, его просят войти в систему. Это можно сделать в приложении или через сторонний сервис, например, Google. Это означает, что приложение социальной сети имеет действующее соглашение с Google о доступе к определенному уровню пользовательской информации, уже предоставленной этим двум источникам. Необходимо провести тест API, чтобы убедиться, что приложение для социальных сетей может взаимодействовать с Google для получения необходимой информации, которая предоставит пользователю доступ к приложению с использованием данных для входа из других источников.

Другой пример — системы бронирования билетов, например, Aviasales. Пользователи ожидают, что самые дешевые варианты перелетов на определенные даты будут доступны и показаны им по запросу. Это требует, чтобы приложение связывалось со всеми авиакомпаниями, чтобы найти наилучшие варианты перелета — это делается через API. В данном случае необходимо выполнить тесты API, чтобы убедиться, что система бронирования билетов успешно взаимодействует с другими компаниями и предоставляет пользователям правильные результаты в соответствующие сроки. Кроме того, если пользователь бронирует рейс и оплачивает его с помощью стороннего платежного сервиса, то должны быть выполнены тесты API, чтобы гарантировать, что платежный сервис и системы бронирования путешествий могут эффективно взаимодействовать, обрабатывать платеж и сохранять конфиденциальные данные пользователя в безопасности.

7 советов при тестировании API

Существует множество передовых методов тестирования API. Мы выделили следующие важные моменты:

• При определении тестовых случаев группируйте их в разрезе тестируемых методов и категорий.
• Разработайте тестовые примеры для каждой потенциальной комбинации входных данных API.
• Автоматизируйте часто повторяемые тесты для ускорения проверок и постоянного мониторинга состояния API
• Используйте нагрузочные тесты c повышенным количеством запросов API для проверки нагрузки на систему.
• Используйте коллекции с последовательным вызовом методов следовательно плану тестирования
• Упростите тестирование, установив приоритеты вызовов функций API.
• Держите каждый тестовый пример автономным и отдельным от зависимостей, если это возможно.

Как тестировать API, или Postman для чайников

Привет! Меня зовут Игорь Гросс, я руководитель проектов в Test IT — это такая система управления тестированием. В этом посте я расскажу об одном интересном инструменте тестировщика — Postman — а также о том, как с его помощью решать распространённый тип задач — тестирование API.

Что это вообще такое?

API — это Application Programming Interface, или программный интерфейс приложения, с помощью которого одна программа может взаимодействовать с другой. API позволяет слать информацию напрямую из одной программы в другую, минуя интерфейс взаимодействия с пользователем.

Как это работает? Представьте, что вы сидите в ресторане, выбираете блюдо в меню. Подходит официант, и вы делаете заказ. Официант передаёт ваш заказ на кухню, там происходит магия, и через некоторое время перед вами появляется готовое блюдо. API работает по такому же принципу — принимает ваш запрос, передаёт информацию системе, обрабатывает её и возвращает ответ.

Какие бывают? API может быть внутренним, частным — когда программные компоненты связаны между собой и используются внутри системы. А может быть открытым, публичным — в таком случае он позволяет внешним пользователям или другим программам получать информацию, которую можно интегрировать в свои приложения.

Чтобы программам общаться между собой, их API нужно построить по единому стандарту. Одним из них является REST — стандарт архитектуры взаимодействия приложений и сайтов, использующий протокол HTTP. Особенность REST в том, что сервер не запоминает состояние пользователя между запросами. Иными словами, идентификация пользователя (авторизационный токен) и все параметры выполнения операции передаются в каждом запросе. Этот подход настолько прост и удобен, что почти вытеснил все другие.

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

Тестирование API проводят, основываясь на бизнес-логике программного продукта. Тестирование API относится к интеграционному тестированию, а значит в ходе него можно отловить ошибки взаимодействия между модулями системы или между системами. Для тестирования используют специальные инструменты, где можно отправить входные данные в запросе и проверить точность выходных данных. Одним из таких инструментов как раз и является Postman. Вот что он умеет:

• Составлять и отправлять запросы;
• Сохранять запросы в папки и коллекции;
• Параметризовать запросы;
• Добавлять к вызову API контрольные точки;
• Создавать разные окружения для одних и тех же запросов;
• Запускать коллекции с помощью Collection Runner и использовать их как автоматизированные тесты.

Чтобы рассказать, как использовать Postman, напишем несколько тестов на базе реального проекта, используя для этого API системы управления тестированием Test IT.

Работа с запросами и отправка запросов в Postman

У Postman есть графический интерфейс, что выгодно отличает его от ряда других инструментов тестирования. Чтобы создать запрос, нужно нажать на кнопку New и выбрать пункт Request.

Запросы Postman хранятся в коллекциях, поэтому нужно не только придумать название и описание запроса, но и создать коллекцию, где он будет храниться.

Создадим запрос на получение проектов. Назовём его соответственно: /api/v2/projects

По умолчанию открывается форма создания GET-запроса:

Для удобства мы указали на иллюстрации выше пункты, соответствующие порядку действий:

1. Выбираем тип запроса. Postman предлагает внушительный список, нам нужен GET.

2. Указываем URL запроса. Первая часть ссылки должна содержать адрес сервера, где развёрнута наша TMC. Мы используем публичное API Test IT, а при составлении запросов опираемся на Swagger-документацию. В нашем случае полная ссылка будет выглядеть так: https://testit.geekbrains.ru/api/v2/projects.

3. На вкладке параметров указываем ключи и значения запроса. Мы хотим получить только удалённые проекты, и API Test IT предоставляет нам такую возможность. Укажем в параметрах isDeleted=true.

4. Переходим на вкладку Authorization, указываем данные для идентификации пользователя. Postman поддерживает множество типов авторизации, параметры для каждого из них отличаются. Используем авторизацию по API Key, полученному из личного кабинета в Test IT.

Мы заполнили все необходимые данные. Теперь выполним запрос, нажав кнопку Send.

Видим, что запрос прошёл успешно: код 200, тело ответа, время ответа и сколько занимают полученные данные. Правда, в нашем случае тело ответа будет пустое, поскольку удалённых проектов у нас нет. Советуем в ключ isDeleted ставить значение true.

Отправляемый запрос или ответ мы можем сохранить с помощью меню справа:

Параметризация запросов, переменные окружения

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

В меню создания выбираем Environment

В ранее созданном запросе выделим в переменные два параметра — URL стенда, к которому мы обращаемся, и токен для авторизации. Назовём наше окружение Test Environment. Создаём две переменные url и token и укажем их значения. На скриншоте ниже их значения скрыты из соображений безопасности.

Сохраняем созданное окружение кнопкой Add. Мы всегда сможем вернуться и отредактировать окружение с помощью кнопки Manage Environments (шестерёнка в правом верхнем углу основного экрана).

Устанавливаем Test Environment в качестве текущего окружения: выбираем из выпадающего списка и вносим параметры в запрос. Переменные указываются в двух фигурных скобках. Postman подсказывает названия переменных окружения при вводе.

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

Запрос вновь прошёл успешно, значит, всё сделали правильно.

Теперь создадим другое окружение, с другими URL и token, и поменяем их с помощью переключения в выпадающем списке. Протестируем продукт на двух разных окружениях, используя одну коллекцию запросов.

Создание тестов в Postman

Мы познакомились с отправкой и параметризацией запросов, а когда же приступим к тестированию? Мы на пороге написания первого теста в Postman.

Уже в знакомом нам запросе находим вкладку Tests и переходим в неё.

Открывается окошко для написания кода на JavaScript. Postman предлагает множество готовых сниппетов, которые можно применить для тестирования API. Здесь можно валидировать коды и содержание ответов, парсить и сохранять значения в переменные окружения или глобальные переменные, проверять их соответствие заданным значениям и т.д. Подробнее о написании тестовых скриптов в Postman можно прочитать в документации или статье на Хабре.

Остановимся на создании простого тестового скрипта: проверим, что код ответа 200. Для этого используем готовый сниппет.

Postman автоматически добавил код на JS, который проверяет, что код ответа равен 200.

Помимо этого, напишем проверку. В списке, который мы получили в данном запросе, отсутствуют проекты с параметром isDeleted = false. Надо парсить ответ, в цикле проходить все объекты полученного массива и проверять, что isDeleted = true.

Вот какой код теста получился:

pm.test("All projects is deleted", function ()  var jsonData = JSON.parse(responseBody); for (var i = 0; i  jsonData.length; i++)  pm.expect(jsonData[i].isDeleted).to.eql(false) > >);

Мы написали в коде false, а не true, потому что у нас есть только созданные проекты, а удалённых нет. Если оставить true, тест будет провален. Если поменять значение на false — тест будет пройден. Отправим запрос и проверим, что тесты прошли. Результаты тестов и их названия отображаются на вкладке Test Results.

В тренировочном запросе два теста. Чтобы создать ещё один GET-запрос, данные для авторизации и проверку на код ответа 200 нужно продублировать. Чтобы сэкономить время, внесём эти данные на уровень всей коллекции.

Переходим в редактирование коллекции.

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

А на вкладку Tests перемещаем проверку, что код ответа равен 200.

В запросе убираем продублированную проверку, а на вкладке авторизации укажем «Inherit auth from parent». Сохраняем запрос и отправляем.

Запрос прошёл: с авторизацией всё в порядке, и у нас отображаются 2 теста, хотя один из них мы удалили. Мы вынесли авторизацию и один тест на уровень всей коллекции, и теперь авторизация и тест на код ответа 200 будут применяться ко всем тестам внутри этой коллекции.

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

Запуск коллекций тестов в Postman

В Postman есть встроенный компонент Collection Runner, с его помощью можно запустить наполненную запросами и тестами коллекцию.

Нажимаем пиктограмму треугольника на коллекции. Открывается дополнительное окно, в котором выбираем Run. В открывшемся окне выбираем окружение, количество итераций в запуске и задержку между отправкой запросов. Также здесь стоит настроить логирование запросов, хранение переменных и cookies.

Укажем значение Iterations равным 10 и пройдём наши тесты.

Далее можно посмотреть на результаты тестов по каждому запросу, экспортировать результаты по кнопке Export Results либо пролистать их в кратком виде по кнопке Run Summary.

Заключение

Итак, мы познакомились с базовыми возможностями инструмента Postman:

• Составили и отправили запросы;
• Задали параметры в запросах;
• Создали и переключались между окружениями;
• Написали базовые тесты;
• Создали и отредактировала коллекции;
• Выполнили запуск тестов.

Это только малая часть полезных и интересных функций Postman, при помощи которых можно тестировать API. Понравилась статья — поделитесь с коллегами 😉

Если вы хотите освоить не только Postman, но также и другие инструменты ручного и автоматизированного тестирования ПО — приглашаем вас на факультет тестирования ПО GeekUniversity!

Стратегия тестирования REST API: что именно вам нужно тестировать?

Слой API любого приложения — один из важнейших программных компонентов системы. Это канал, который соединяет клиента с сервером (или один микросервис с другим), управляет бизнес-процессами и представляет сервисы, которые приносят пользу пользователям.

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

Знаменитая пирамида тестов Майка Кона помещает тесты API на сервисный уровень (интеграционный), что предполагает, что около 20% или более всех наших тестов должны быть сосредоточены на уровне API (точный процент зависит от наших потребностей).

Когда у нас уже есть прочный фундамент из модульных тестов, охватывающих отдельные функции, тесты API обеспечивают более высокую надежность. Они проверяют интерфейс, более близкий к пользователю, но не имеют недостатков тестов пользовательского интерфейса.

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

Становится понятно, что важность тестирования API очевидна. Некоторые методологии и ресурсы помогают нам узнать КАК тестировать API — вы можете использовать ручное тестирование, автоматическое тестирование, тестовые среды, инструменты, библиотеки и фреймворки. Однако, независимо от того, чем вы будете пользоваться — Postman, supertest, pytest, JMeter, mocha, Jasmine, RestAssured или любыми другими инструментами — прежде чем открывать любой инструмент тестирования, вам необходимо определить, что тестировать.

Стратегия тестирования API

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

Основными задачами функционального тестирования API являются:

• убедиться, что реализация API работает правильно, как и ожидалось — без ошибок!

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

• предотвратить регрессий между написанным кодом(merge) и релизом.

API как соглашение — сначала проверьте спецификацию!

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

• эндпоинты правильно именованы;
• ресурсы и их типы правильно отражают объектную модель;
• нет отсутствующей или дублирующей функциональности;
• отношения между ресурсами правильно отражаются в API.

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

Если у вас общедоступный API, ориентированный на клиента, такое тестирование может быть вашим последним шансом убедиться, что все требования соглашения выполнены. После публикации и использования API любые внесенные вами изменения могут внести ошибки в код клиента.(Конечно, когда-нибудь вы сможете опубликовать новую версию API (например, /api/v2 /), но даже в этом случае обратная совместимость скорее всего будет обязательной).

Итак, какие аспекты API мы должны протестировать?

После того как мы проверили соглашение 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:

Вызов API

Действие

Просмотреть всех пользователей

Как тестировать методы REST API

Спокойно. Без паники =) Я уже рассказывала на простом языке, что такое API. А сегодня я расскажу о том, как его тестировать. На самом деле почти также, как GUI: в первую очередь это тест-дизайн и придумывание проверок, а потом уже всякие API-штучки. Но и про них не стоит забывать.

Я дам вам чек-лист, к которому вы сможете обращаться потом — «так, это проверил, и это, и это. А вот это забыл, пойду посмотрю!». А потом мы обсудим каждый пункт — зачем это проверять и как.

После теории будет практика! Для неё возьмем метод doRegister системы Users — он находится в открытом доступе, можете дергать по ходу чтения и проверять =)

Чек-лист проверок

1. Правильное тело (пример)
2. Бизнес-логика: позитив, негатив
3. Различные параметры (обязательность, работа параметров)
4. Перестановка мест слагаемых (заголовки, тело)
5. Регистрозависимость (заголовки, тело)
6. Ошибки: не well formed xml / json

Где искать параметры:

• В URL
• В заголовках
• В теле запроса
• Комбинация

1. Правильный параметр (из примера)
2. Обязательность (что, если параметр не указать?)
3. Бизнес-логика (тест-дизайн)
4. Регистрозависимость (если параметр текстовый)
5. Перестановка местами

То есть берём REST-часть и обычную, применяем тест-дизайн, словно это параметр в графическом интерфейсе.

• Заголовки из документации работают (в целом)
• А если какой-то не передать? (обязательность)
• А если передать, но неправильно? (текст ошибки)
• Позитивные тесты по доке
• Регистронезависимость заголовков

Что смотрим в ответе:

1. Какие поля вернулись в ответе?
2. Значения в полях
3. Текст ошибок

Поля в ответе нужно:

• сравнить с ТЗ
• сравнить между собой SOAP \ REST

Кратко прошлись, теперь разберемся в деталях и с примерами.

Позитив или негатив?

Я учу начинающих тестировщиков так: ВСЕГДА сначала позитивное тестирование, а потом негативное. Иначе вы успеете проверить всякий треш, а с нормальными данными система работать не будет.

Однако в случае тестирования интеграции негатив может оказаться приоритетнее. На одном из рабочих проектов обсуждала это с архитектором, который разрабатывает системы для интеграции — как заказное ПО, так и общедоступное. Он учил меня так:

Сначала надо проверить негатив. Потому что разработчики продукта, которые подключают наше API, всегда будут напарываться на грабли. Не прочитали документацию / прочитали криво — получили ошибку.

И нужно, чтобы по сообщению об ошибке они поняли:

— Что они сделали не так

— Как это исправить

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

Так что проверьте сначала всякие извращения, а потом, пока разработчик чинит найденные баги, сидите со своими позитивными тестами и позитивными сценариями.

В целом, есть логика в его словах. Ну и плюс всё зависит от времени, если вам позитивные тесты погонять займет полчасика, то проще начать с них. А если там куча сценариев + обязательные автотесты часа на 4, то можно сначала погонять руками, выдать пачку замечаний и сидеть спокойно писать свои тесты.

Обсудите со своими разработчиками, как им будет удобнее — чтобы вы сначала потыкали “на слом” и прислали очевидные баги, или вдумчиво проверили всё и прислали результат одним файлом. Как им удобнее, так и делайте.

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

В каком порядке тестируем

1. Примеры в ТЗ

Самое простое, что можно сделать — дернуть пример из документации, чтобы посмотреть, как метод вообще работает. А потом уже писать обвязку в коде.

Это пойдут делать тестировщики, получив от вас новый функционал. И это же сделает разработчик интеграции / другой пользователь API.

Отсюда вытекают следующие выводы:

а) Примеры в документации должны быть! Причем желательно не один, а на каждый интересный кейс. Чтобы на него точно обратили внимание!

б) Примеры тестируем в первую очередь, потому что именно их дернут первыми. И потом будут делать по аналогии.

Практика на примере Users

В Users есть только один пример:

Его и попробуем отправить!

• Тип запроса — POST
• URL — http://users.bugred.ru/tasks/rest/doregister
• Тело — из примера

Упс, ошибочка… Читаем её внимательно:

" email milli@mail.ru уже есть в базе"

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

Имя и емейл должны быть уникальными

Значит, метод не идемпотентный… Нельзя просто взять пример из ТЗ и отправить не глядя.

Справка

Метод HTTP является идемпотентным, если повторный идентичный запрос, сделанный один или несколько раз подряд, имеет один и тот же эффект, не изменяющий состояние сервера. Корректно реализованные методы GET, HEAD, PUT и DELETE идемпотентны, но не метод POST. © developer.mozilla.org

Нужно взять пример и отредактировать его так, чтобы данные стали уникальными. Можно от руки дописать несколько циферок:

А можно использовать функционал Postman, который позволяет указать рандомные значения — динамические переменные. Пожалуй, мне хватит $randomInt. Но так как я отправляю запрос в JSON-формате, то надо обернуть переменную в фигурные скобки, иначе постман считает её как простой текст:

< "email": "milli>@mail.ru", "name": " Машенька>", "password": "1" >

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

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

И чем больше у вас пользователей, тем больше таких вопросов будет. Заводить ли тут баг на правку документации? Можно предложить дописать в ТЗ как-то так:

Запрос (для проверки запроса исправьте имя пользователя и email, чтобы они были уникальными): .

То есть заранее подсказываем, что надо изменить, чтобы запрос сработал AS IS. Можно было бы и пример с рандомными переменными постмана дать, но тут надо понимать, что через постман его будут дергать тестировщики и аналитики со стороны заказчика.

Разработчики же должны написать код, используя ваш пример. А они тоже любят копипастить))) И если дать пример, заточенный под постман, то к вам снова придут с вопросом, почему ваш пример не работает, но уже в коде. И тут опять или писать около примера, что “$randomInt — переменная Postman, она тут для того-то”, или всё же примеры оставить в покое.

Я не вижу особой проблемы в текущем описании, это не повод ставить баг на документацию. Пример нормальный и рабочий. А если принесет головную боль поддержке, тогда и замените.

В нашей доке всего 1 пример. Если бы их было больше, надо было бы вызвать все. Именно на примерах пользователи учатся работать с системой. Дернули, получили такой же ответ, изучили его, осознали, запомнили =)

2. Основной позитивный сценарий

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

В идеале он берет этот сценарий из примера. Если примеров нет, будет дергать метод наобум, как он считает правильным. Знаете, как с новым девайсом — сначала попробовал сам, если не получилось, пошел читать инструкцию.

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

Практика на примере Users

А у нас есть пример, так что основной позитивный сценарий мы уже почти проверили!

Почему “почти”? Мы проверили, что система вернула в ответе «успешно создалась Машенька562», но точно ли она создалась? Может быть, разработчик сделал заглушку и пока метод в разработке, он всегда возвращает ответ в стиле “успешный успех”, ничего при этом не делая.

Так что идем и проверяем, есть ли наша Машенька в GUI — http://users.bugred.ru/. Ищем поиском — есть!

Проверяем все поля:

• Емейл правильный, какой мы отправляли.
• Автор «rest», что логично.
• Дата изменения — сегодня, что тоже правильно.

Значит, пользователь правда создан! Хотя постойте… Я же выполняла не метод CreateUser, а doRegister. Его основная цель — не создать карточку, а зарегистрировать пользователя в системе. Просто при регистрации карточка автоматом создается, поэтому её тоже зацепили проверкой.

А как проверить, что регистрация прошла успешно? Правильно, попробовать авторизоваться!

Нажимаем «Войти» и вводим наши данные: milli754@mail.ru / 1

Вошли! Ура, значит, регистрация правда сработала. Вот теперь мы закончили с основным позитивным сценарием.

3. Альтернативные сценарии

На самом деле если в ТЗ нет отдельно выделенного сценария использования, то можно объединить пункты “альтернативные сценарии” и “негативное тестирование”, потому что по факту после базового теста мы:

1. Читаем каждое предложение из ТЗ, «Особенности использования» или как этот раздел у вас называется
2. Продумываем, как его проверить: как позитивно, так и негативно.

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

Практика на примере Users

Читаем особенности использования:

Пользователь создается и появляется в системе.

Это мы уже проверили. Дальше:

Автор у него всегда будет «SOAP / REST», изменять его можно только через соответствующий-метод.

Автора тоже проверили, но только вот в ТЗ он указан капсом, а по факту создается в нижнем регистре. Это уже небольшой баг, скорее всего документации, так как некритично и проще доку обновить. Сделали заметочку / сами исправили доку, если есть доступ.

А дальше видим, что изменять только только через соответствующий метод. Ага, то есть если создали через REST, менять можно тоже только через REST, через SOAP нельзя. И наоборот. Это и проверим.

Для начала под Машенькой в ГУИ посмотрим, есть ли возможность отредактировать собственную карточку — нету. Ок. Открываем в SOAP Ui WSDL проекта — http://users.bugred.ru/tasks/soap/WrapperSoapServer.php?wsdl, и смотрим, каким методом можно вносить изменения.

Нам вполне подойдет UpdateUserOneField, он обновляет одно любое поле пользователя. А как понять, какие поля есть? Покопаться в документации. В Users описаны не все методы, но есть описание CreateUser, где можно взять названия полей. Допустим, хочу обновить кличку кошки — cat. Получается запрос:

    milli754@mail.ru cat Еночка   

Поле cat успешно изменено на Еночка у пользователя с email milli754@mail.ru

Проверяем в интерфейсе, находим карточку пользователя и жмем “Просмотр” (прямую ссылку давать бесполезно, база дропается каждую ночь, тут только самому создать и посмотреть). Значение обновилось:

Значит, условие из ТЗ не выполнено, можно ставить баг!

А мы пока читаем дальше:

Имя и емейл должны быть уникальными

Раз должны, то будет ошибка в случае неуникальности. А мы решили вынести тестирование негативных сценариев отдельно. Видите, решение тестировать альтернативы отдельно от негативного сразу оказалось не самым удобным — куда лучше просто читать ТЗ и каждый пункт проверять. Так хоть не запутаешься, что проверил, а что ещё нет… Однако в рамках статьи мы всё-таки рассмотрим негативные тесты отдельно.

Пока же смотрим дальше — а всё, кончилось ТЗ, метод то простенький. Тогда переходим к негативу!

4. Негативные сценарии

По факту это проверка сообщений об ошибках. Смотрим на метод и думаем, как его можно сломать? Сначала бизнесово, а потом API-шно…

С бизнесовой точки зрения очень удобно, когда все ошибки прописывают прямо в ТЗ. Получается руководство к действию! Это можно быть разделение на «Особенности использования» и «Исключительные ситуации», как в Folks (логин для входа тут). Тогда тестируем блок «Исключительные ситуации».

Или вот описание Jira Cloud REST API, выберем в левом навигационном меню какой-нибудь метод, например «Delete avatar». Там есть описание метода, а потом в блоке Responces переключалки между кодами ответов.

Ну так вот все желтые коды — это ошибки. Открываем каждую, читаем «Returned if» и выполняем это условие, очень удобно:

В общем, если есть отдельно про ошибки — класс, проверяем по ТЗ. А потом ещё думаем сами, что там могло быть пропущено.

Плюс проверяем логику ошибок в API, но о ней чуть позже. Сначала бизнес-логика, потом уже серебряная пуля типа well formed json.

Практика на примере Users

Ограничение в ТЗ:

Имя и емейл должны быть уникальными

Для проверки нам надо сделать неуникальным:

Можем взять за основу наш исходный запрос, который 1 раз создался:

И варьируем его

1. Уникальный емейл, дубликат имени

< "email": "milli>@mail.ru", "name": " Машенька562", "password": "1" >

2. Уникальное имя, дубликат емейл

< "email": "milli754@mail.ru", "name": " Машенька>", "password": "1" >

3. Дубликаты сразу имени и емейл

И смотрим на ответ. Понятно ли нам из сообщения об ошибке, что именно пошло не так? А статус-код соответствует типу ошибки?

5. Параметры запроса

На входе мы передаем какие-то параметры. И теперь нам нужно взять каждый параметр и проверить отдельно. Как проверяем:

1. Обязательность
2. Перестановка мест слагаемых
3. Бизнес-логика

Про первые 2 пункта мы поговорим чуть позже, сейчас сосредоточимся на бизнес-логике.

Вот у вас есть параметры запроса. Как их проверять? Если вы впали в ступор сейчас, то просто представьте себе, что это не API, а GUI. Что у вас в интерфейсе есть форма ввода с этими полями? Как будете тестировать? Вот ровно так и тестируйте, выкинув разве что попытку убрать ограничение на клиенте (снять с поля maxlenght).

Практика на примере Users

По ТЗ входные параметры:

Имя параметра

Тип

Обязательный?

Описание