->
Еще одна замечательная особенность API-интерфейсов заключается в том, что они меньше, чем монолитное приложение, а это означает, что их можно развертывать часто. В компании, где я работаю, у каждой команды есть несколько API, и у нас есть восемь разных сред, в которые мы развертываем. Если бы мы полагались исключительно на ручное тестирование для проверки правильности развертывания API, нам пришлось бы запускать восемь наборов тестов для каждого выпуска API. И если бы мы развертывали более одного API одновременно, что мы часто делаем, потому что наши API работают вместе, мы могли бы запускать сотни тестов. И если мы будем развертывать его каждые две недели, эти тесты превратятся в утомительное повторяющееся тестирование!
Мы решили эту проблему, настроив автоматические дымовые тесты API, которые запускаются при каждом развертывании в любой среде. В этой статье я опишу, как мы решили, что тестировать, и как мы настроили дымовые тесты. Мы использовали Postman, Newman, Powershell и Octopus для настройки наших автоматических дымовых тестов, поэтому я опишу, что мы сделали с этими инструментами. Однако эти стратегии могут быть адаптированы к любому конвейеру непрерывного развертывания (CD).
Шаг первый: решите, что тестировать
Содержание
Основная цель дымовых тестов — выполнить несколько простых тестов высокого уровня, чтобы убедиться, что развертывание прошло успешно. Здесь не место тестировать каждую вещь, которую может сделать ваш API. Когда мы выбирали, что добавить в наши дымовые тесты, мы учитывали следующее:
- Мы настроили один тест «Счастливый путь» для каждой конечной точки, то есть один тест, который, как ожидается, будет успешным. Например, ожидается, что запрос GET для ресурса с определенным идентификатором вернет этот ресурс. Вы захотите протестировать каждую конечную точку один раз, чтобы убедиться, что каждая из них работает должным образом.
- Если были серьезные различия в том, как будет использоваться конкретная конечная точка, мы добавили один или несколько тестов для проверки этих вариантов. Например, у нас есть API для поиска файлов, в котором файл можно получить двумя разными способами. Конечная точка выглядит одинаково, но тела запросов разные. Поэтому мы добавили по одному тесту для каждого метода.
- Для конечных точек, которым требуется определенный уровень безопасности, мы добавили тест, чтобы проверить, что запрос без соответствующей аутентификации НЕ вернет информацию, а вместо этого вернет ошибку уровня 400.
- Мы не добавляли никаких других отрицательных тестов, таких как POST-запрос с данными за пределами разрешенных параметров, потому что мы не чувствовали, что они необходимы для обеспечения работы API. Вместо этого мы запускали эти тесты как часть ночного регрессионного набора.
Шаг второй: экспортируйте свои API тесты
Мы использовали Postman для создания наших тестов API, поэтому при создании тестов мы экспортировали и тестовую коллекцию, и файл тестовой среды в файлы JSON. Для тех, кто не знаком с Postman, тестовая среда — это группа переменных, на которые можно ссылаться в наборе тестов.
Шаг третий: напишите сценарий для запуска ваших тестов
У Postman есть инструмент командной строки под названием Newman, который можно использовать для запуска тестовой коллекции, поэтому мы использовали его для запуска наших тестов. Мы создали сценарий Powershell, который будет запускать команду Newman.
Шаг четвертый: создайте шаг развертывания для вызова вашего скрипта
После того, как сценарий Powershell был готов, мы настроили шаг развертывания в каждом проекте развертывания Octopus API, который будет запускать тестовый сценарий. Если сценарий завершится ошибкой, развертывание завершится ошибкой.
Шаг пятый: организуйте свои переменные
Переменные часто учитываются при выполнении дымовых тестов в разных средах. Например, в вашей среде QA ваш тестовый пользователь может иметь идентификатор 340, но в вашей тестовой среде ваш тестовый пользователь может иметь идентификатор 620. Другая проблема с переменными заключается в том, что иногда в целях безопасности у вас может не быть доступа. к паролям или ключам в производственных средах. Это было в случае с нашей командой, но, к счастью, у Octopus есть значения, которые нам нужны для запуска наших тестов в производственной среде, поэтому мы решили проблему, заставив Octopus передать значения, которые нам нужны, в наш тестовый скрипт.
Для нашего дымового теста требовалось три разных типа переменных:
- Тип 1: Неизменные для каждой тестовой среды переменные, такие как «firstName»: «Prunella». Эти переменные можно было поместить прямо в среду Postman, поэтому с ними больше ничего не нужно было делать.
- Тип 2: Переменные, которые менялись для каждой тестовой среды, но не нуждались в защите, такие как «userId»: 340. Эти переменные были добавлены как переменные Octopus следующим образом: «smoke.userId», и значение переменной было установлено для каждой среды; например, QA было установлено на 340, Staging — на 620, а Production — на 450.
- Тип 3: Переменные, которые менялись для каждой тестовой среды и должны быть защищены, например «apiKey»: «b20628a9-3c00-4dad-b38c-0a4d2d85ffab». Переменные типа 3 уже были установлены в библиотеке переменных Octopus.
Затем мы использовали переменные следующим образом:
- Когда мы вызывали скрипт Powershell в Octopus, мы отправляли в скрипт переменные, установленные в Octopus.
- В сценарии Powershell мы приняли отправленные переменные Octopus и присвоили их переменным Powershell.
- Когда мы использовали команду Newman в сценарии Powershell, мы отправляли переменные сценария в среду Postman.
- Ньюман использовал переменные, отправленные в сценарии Powershell, в сочетании с переменными среды Postman для запуска коллекции Postman.
Наши дымовые тесты API, запущенные в Octopus для каждого API и в каждой среде, позволяют нам быть уверенными, что любые серьезные проблемы с развертыванием API будут обнаружены сразу. Кроме того, мы можем тестировать в производственной среде, даже если у нас нет доступа к конфиденциальным ключам API. Автоматическое развертывание дымовых тестов освобождает нас для выполнения других типов тестирования, таких как ручное исследовательское тестирование и тестирование безопасности, а также для написания дополнительных средств автоматизации тестирования для ночных регрессий.
Для получения дополнительных руководств подпишитесь на Информационный бюллетень QA Lead.
