Home

Автор: Кристин Джеквони (Kristin Jackvony)
Оригинал статьи: http://thethinkingtester.blogspot.com/2018/05/what-api-tests-to-automate-and-when-to.html
Перевод: Ольга Алифанова.

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

Предположим, что у нас есть API с такими запросами:

POST user

GET user/{userId}

PUT user/{userId}

DELETE user/{userId}

Первая категория тестов, которая нам понадобится – это позитивные запросы. К примеру:

POST-запрос нового пользователя: нужно убедиться, что мы получаем ответ 200.

GET – получение пользователя, нужно убедиться, что мы получаем ответ 200, и возвращается правильный пользователь.

PUT – обновление данных пользователя, убедиться в ответе 200.

DELETE – удаление пользователя, убедиться в ответе 200.

Следующая категория тестов – это простые негативные запросы, к примеру, такие:

POST-запрос нового пользователя с незаполненным обязательным полем: нужно убедиться, что мы получаем ответ 400.

GET – получение пользователя с несуществующим ID, нужно убедиться, что мы получаем ответ 404.

PUT – обновление данных пользователя с невалидным полем, убедиться в ответе 400.

DELETE – удаление пользователя с несуществующим ID, убедиться в ответе 404.

Ответы 400 и 404 стоит протестировать для каждого запроса, у которого они есть. Необязательно тестировать абсолютно все триггеры ответа 400: к примеру, не надо автоматизировать каждое пропущенное обязательное поле – но хотя бы один тест на пропуск одного обязательного поля должен присутствовать.

Третья категория тестов – это позитивные тесты с вариациями, например, такие:

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

GET – получение пользователя с параметрами запроса, к примеру, user/{userId}?fields=firstName,lastName. Нужно убедиться, что мы получаем ответ 200, и возвращается пользователь с нужными данными.

PUT – обновление данных пользователя, где одно из необязательных полей пустое, а одно пустое поле заменено на значение, убедиться в ответе 200.

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

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

POST-запрос нового пользователя без токена, убедиться в ошибке 401.

GET-запрос с неверным токеном, убедиться в ошибке 403.

PUT-запрос с неверным токеном, убедиться в ошибке 403.

DELETE-запрос без токена, убедиться в ошибке 401.

Для каждого запроса имеет смысл проверить и ошибку 401 (запрос неавторизованного пользователя), и ошибку 403 (запрос авторизованного пользователя).

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

Теперь давайте посмотрим, как использовать эти четыре типа тестов в автоматизации. Вначале нам понадобится несколько Smoke-тестов для быстрого прогона после деплоя кода из окружения в окружение, вплоть до прода. Эти тесты должны просто убеждаться, что все работает, поэтому нам достаточно прогнать тесты первой категории, простые позитивные. В нашем гипотетическом API у нас всего четыре типа запросов – это четыре теста. Это займет всего несколько секунд.

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

И, наконец, было бы круто создать регрессионный набор тестов, запускающийся еженощно. Прогон этого набора займет больше времени, потому что никто не сидит в ожидании его запуска. Я включаю все четыре типа тестов в этот набор, а иногда создаю два разных набора: первый содержит три типа тестов, а второй – только тесты безопасности. Даже если тестов у вас больше сотни, прогон, возможно, займет всего несколько минут, потому что API-тесты прогоняются быстро.

Когда ваши наборы тестов созданы и настроены для автозапуска, вы можете успокоиться: если с API что-то пойдет не так, вы об этом узнаете. Это освободит вам время для исследовательского тестирования!

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