Разработчики и тестировщики API часто выбирают путь ручного тестирования, когда дело доходит до отладки и тестирования сервисов. Как им начать свой путь к автоматизации и с какими проблемами они могут столкнуться при автоматизации набора тестов API?
Подпишитесь на наш ТЕЛЕГРАМ КАНАЛ ПО АВТОМАТИЗАЦИИ ТЕСТИРОВАНИЯ
Ручной труд не всегда продуктивен
Для разработчика, создающего микросервис, “ручной труд” означает постоянную отправку запросов в Postman для обращения к разрабатываемому им сервису и просмотр ответов, чтобы убедиться, что получены желаемые данные.
Для инженера по тестированию это означает нечто очень похожее. Только ему обычно предоставляется URL-адрес сервиса для взаимодействия, а также документация, которую приходится тестировать по частям.
Для системного инженера, создающего конвейер доставки приложения, это означает ручное выполнение запросов к нескольким точкам интеграции с разнообразной документацией и попытки настроить цепочку развертывания с правильными зависимостями. Сценарий усложняется по мере увеличения количества взаимодействующих между собой сервисов.
Да, в краткосрочной перспективе такой ручной подход позволяет добиться желаемого результата. Но он не масштабируется, он трудозатратный и требует слишком много времени, а к тому же не приносит удовольствия персоналу, вовлеченному в процесс.
Postman – это полноценная среда разработки API с такими функциями, как создание сценариев, автоматическое документирование API, имитация серверов и мониторы.
Однако многие пользователи работают с Postman как с инструментом ручного тестирования. Зачастую это не меняется даже после того, как команда успешно интегрировала Postman с другими инструментами тестирования и создала наборы автоматизированных тестов.
Помимо Postman, существуют и другие инструменты для автоматизации тестирования API. Также есть общедоступная документация, учебные пособия, курсы, книги, статьи, выступления и семинары по автоматизации тестирования.
И все же, почему так много людей сталкиваются с различными трудностями при переходе от ручного тестирования к автоматизированному?
Как правило основная проблема заключается не в нехватке ресурсов, а в нахождении нужных ресурсов, которые сочетались бы в нужной последовательности, чтобы дать целостное понимание стратегии тестирования.
Главное препятствие на пути от ручного тестирования к автоматизированному – отсутствие четкого понимания того, как весь процесс будет работать от начала до конца.
Коллекции Postman
Если вы разработчик, создающий микросервисы, или инженер, создающий инструмент для внутреннего использования, или член команды, работающей над предоставлением API, то коллекции в Postman помогут вам сократить количество рутинных ручных задач.
Коллекции позволяют упорядочить запросы, выполняемые в Postman. Они также являются основой для других полезных функций, таких как моки, мониторы и документация.
Вы можете написать тесты в Postman для каждого запроса с помощью скриптов. Написанные скрипты могут управлять рабочим процессом и порядком выполнения запросов. Также в Postman-скриптах можно использовать такие популярные библиотеки, как MomentJS или Lodash.
Если сохранить эти запросы в коллекции и организовать их в папках, то в итоге получится исполняемый, многократно используемый набор тестов для ваших API.
Примечание редакции: также предлагаем почитать “Негативное тестирование API в Postman”.
Изучение существующих коллекций
В Postman API network есть несколько отличных коллекций, созданных другими компаниями.
Коллекции, опубликованные компаниями Box, Auth0 и Imgur являются отличными ориентирами для всех, кто пытается опубликовать свои коллекции, как внутри компании, так и за ее пределами. Вы можете просмотреть их документацию и воспользоваться кнопками “Run in Postman” для загрузки соответствующих коллекций в приложение Postman.
Вот как выглядит документация Imgur:
Коллекции Auth0 документируют конечные точки своих API. Эти коллекции служат документацией для разработчиков, создающих пользовательские интеграции в своих приложениях с API Auth0.
Вот как в документации Auth0 рассказывается об использовании Postman для тестирования созданных ими коллекций:
Запуск коллекций
Запуск коллекции подразумевает последовательное выполнение всех сохраненных в ней запросов.
Коллекции можно запускать непосредственно из приложения Postman или в его облаке с помощью мониторов. Вы также можете запускать коллекции в командной строке с помощью newman. Если вы создаете CI-конвейер или уже используете его, с помощью newman вы можете запускать коллекции при каждой сборке.
Локальный запуск
При разработке сервиса на локальной машине или при локальном тестировании сервиса можно инициировать запуск коллекции с помощью приложения Postman. Таким образом можно не создавать отдельные запросы при каждом тестировании, а запускать весь набор в нужной последовательности.
Для повторного использования одной и той же коллекции на разных машинах можно использовать переменные и окружения. Например, обычной практикой является использование плейсхолдера {{base_url}} в URL запроса и переключение окружений для обращения либо к локально работающему серверу, либо к службе, работающей на удаленной машине.
По мере группировки запросов в коллекции в папки, вы можете запустить только часть коллекции, выбрав конкретную папку. Это позволяет избежать запуска всего набора, если необходимо протестировать только определенную группу конечных точек.
Запуск в CI
newman может запускать коллекцию по URL-адресу. Вы можете вводить переменные окружения и файлы данных в рамках newman-запуска, точно так же, как это делается в приложении. Есть несколько способов настроить newman в зависимости от того, как настроены ваши CI-пайплайны:
- Скрипты CI могут извлекать коллекцию, используя API Postman, а затем запускать ее с помощью newman.
- Можно вставить URL-адрес коллекции в переменную окружения в CI-программе. Если ваша система CI работает исключительно на закрытой и защищенной инфраструктуре, вам необходимо внести домены Postman в белый список, чтобы разрешить
newmanдоступ к ним.
newman может создавать различные типы отчетов, включая HTML и JSON. Эти отчеты можно сохранить как часть артефактов билда, чтобы получить к ним доступ после завершения сборки.
Автоматизация до начала разработки
Автоматизацию можно начинать уже на этапе проектирования API. Создайте отдельную коллекцию, в которой будут задокументированы все необходимые конечные точки. Затем вы можете использовать эту коллекцию для создания макетных серверов для разработчиков и тестировщиков.
Таким образом вы, как QA, можете начать писать свои тестовые наборы на основе ожидаемых ответов. Как фроентенд-инженер, вы можете начать создавать свои приложения, не дожидаясь, пока бэкендеры создадут сервис.
Вам даже не нужно с самого начала создавать систему непрерывной интеграции. Вы можете использовать Postman Monitors для периодического запуска ваших коллекций. При каждом запуске монитора выполняются тесты, входящие в состав запросов вашей коллекции, что позволяет получить представление о ее актуальности.
Заключение
В итоге вы автоматизируете не только тесты, но и рабочий процесс. При небольшом предварительном планировании и использовании правильных инструментов ваш путь от ручного к автоматизированному тестированию API становится заметно проще и понятнее. Вы высвобождаете ресурсы, которые в противном случае были бы потрачены на выполнение ручных задач. Эти ресурсы вы можете потратить на более продуктивные цели – как индивидуально, так и в команде.
Перевод статьи «From manual to automated testing: The roadblocks and the journey».