Home

Автор: Кристин Джеквони (Kristin Jackvony)
Оригинал статьи
Перевод: Ольга Алифанова

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

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

Для начала давайте поговорим об окружениях. Если вы помните из прошлой статьи, то окружение – это коллекция переменных в Postman. Настраивать окружения можно двумя способами, и чтобы их разъяснить, я буду пользоваться сценариями. В обоих сценариях мы предположим, что у меня есть приложение, которое начинает свой жизненный цикл в разработке, затем переезжает в QA, подготовку и, наконец, в релиз.

В моем первом сценарии у меня есть API, которое получает и обновляет информацию о пользователях моего сайта. В каждом продуктовом окружении (Dev, QA, Staging, Prod) тест-пользователи различаются. У них будут разные ID, имена и фамилии. Ссылки на окружения также будут различными. Однако мои тесты не изменятся: во всех окружениях я буду получать информацию о пользователе (GET) и обновлять ее (PUT).

Итак, я создаю четыре окружения Postman:

Users- Dev

Users- QA

Users- Staging

Users- Prod

В каждом из них у меня будут вот какие переменные:

environmentURL

userId

firstName

lastName

Моя тест-коллекция будет ссылаться на эти переменные. Скажем, у меня может быть такой запрос:

GET https://{{environmentURL}}/users/{{userId}}

URL окружения и userID будут зависеть от используемого окружения. Применяя эту стратегию, очень легко переключиться с Dev-окружения на QA или любое другое. Все, что мне нужно сделать – это изменить настройку окружения и снова прогнать мой тест.

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

В этом случае я создаю только одно окружение:

Email Test

В этом окружении будет переменная:

timestamp

Однако в моей коллекции тестов будет по одному тесту для каждого окружения:

Send Email- Dev

Send Email- QA

Send Email- Staging

Send Email- Production

Каждый запрос включает переменную timestamp. Разница в запросах в том, что отправляется в теле письма. В окружении Dev я использую запрос с "Dev" в теле письма, в QA – запрос с "QA", и так далее.

Решая, какую стратегию применить, думайте вот о чем:

• Что остается неизменным вне зависимости от окружения?
• Что меняется в зависимости от окружения?

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

Теперь давайте поговорим о том, как организовать наши тесты. Вначале подумаем о тест-коллекциях. Наиболее очевидный способ организовать коллекции – это по API. Если в вашем приложении несколько API, создайте по коллекции для каждого. Коллекции также можно создавать для тест-функций. К примеру, если у меня есть API пользователей, и я хочу прогнать полноценный регрессионный набор, ночной автоматизированный набор и smoke-тест деплоя, я могу создать три коллекции:

Users- Full Regression

Users- Nightly Tests

Users- Deployment Smoke

И, наконец, поговорим о папках. Postman очень гибок в этом отношении: в коллекции можно использовать сколь угодно много папок и подпапок. Вот несколько советов, как организовать ваши тесты по папкам:

• По типу запросов: все POST-запросы в одной папке, все GET-запросы в другой.
• По конечной точке: GET myapp/users в одной папке; GET myapp/user/userId в другой.
• По ожидаемому результату: положительные сценарии GET myapp/users в одной папке, негативные в другой.
• По фиче: GET myapp/users с сортировкой – в одной папке, and GET myapp/users с фильтрацией – в другой.

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

Предыдущие статьи на эту тему

Введение в REST-запросы и тестирование GET-запросов

Тестирование POST-запросов

Тестирование PUT-запросов

Создание коллекции в Postman

Добавление правил в Postman

Использование переменных в Postman

Обсудить в форуме