Это отрывок из статьи Как тестировать методы REST API. Мне хочется, чтобы было возможность дать ссылку именно на тестирование ответа)
Когда мы получаем ответ в REST-методе, надо проверить тело ответа и его статус код. Давайте разберемся, как это делать.
Тело ответа
Чек-лист проверки:
- Какие поля вернулись в ответе?
- Значения в полях
- Текст ошибок
Поля в ответе нужно:
- сравнить с ТЗ
- сравнить между собой SOAP \ REST
Если у нас есть ТЗ — то всё понятно. Читаем, как должно быть, проверяем, как есть на самом деле. Смотрим на то, что все поля из требований вернулись, и что в них правильное значение. А то вдруг я сохраняю имя “Оля”, а там всегда сохраняется “Тестовый”... Очень удобно сразу автотесты писать в том же постмане, если отдельного фреймворка нет — идем по ТЗ и каждое поле выверяем.
Если ТЗ нет, то уже сложнее. Ищем «хранителя информации», расспрашиваем, проверяем, как работает на самом деле. Думаем, есть ли проблемы в текущем поведении. Нет? Ок, значит, так и надо.
Если в ответе сообщение об ошибке, то внимательно его изучаем. В API это ещё важнее, чем просто в графическом интерфейсе. Поймет ли пользователь, что именно он сделал не так, где именно ошибся? Помните, плохое сообщение об ошибке приведет к тому, что вас будут дергать по пустякам, вырывая из контекста.
См также:
Если у вас в системе два интерфейса — SOAP и REST, нужно проверить оба. Обычно они должны быть идентичны. Да и в коде это обеспечивается условно говоря двойной аннотацией “сделай и soap, и rest сгенери”, разработчик не дублирует всю функциональность дважды, а просто “включает” API.
В таком случае действительно всё будет работать идентично, кроме пустых полей в ответе. Что будет, если какое-то поле не заполнено? Может легко быть такая ситуация:
— SOAP возвращает пустые поля;
— REST нет.
Более того, это даже может быть нормально! Например, исходно писался только SOAP-интерфейс, и было правило возвращать все поля, даже пустые. Потом решили стать модными, молодежными, подключили REST. И решили там поля пустые не возвращать.
К тому же в SOAP всегда есть схема WSDL, где указаны обязательные поля. Значит, они будут возвращаться в ответе. В ресте же схема WADL необязательна, да и там любят придерживаться принципа минимальных чернил, лишнего не выводить.
В общем, проверьте обязательно, как методы срабатывают на:
- Отсутствие данных на входе (поле не пришло вообще / пришло пустое)
- Пустые поля на выходе
Если по разному, то это должно быть описано в доке!
Практика на примере Users
Сначала отправляем базовый запрос и там, и там, как в документации. Но уже по документации мы можем заметить, что набор поле в ответах разный. В SOAP перечислены все поля юзера, включая кличку кошечки, собачки итд… В REST же несколько базовых полей, и всё.
Как так вышло? Очень просто. Для реста набор полей согласовали, разработчик сделал. Потом я сказала, что хочу ещё и SOAP. А там нужна схема WSDL, разработчик с ней особо не парился. Есть сущность “user”? Ну её и вернем в ответе. А в сущности как раз много полей…
Мне не критично, так что менять не стали, да и вообще отличный пример «да, и так бывает» же! =))
Ок, давайте теперь посмотрим на особенности API, ведь всю бизнес-логику перетестировать в SOAP смысла нет, она должна совпадать… Ну разве что вы совсем не верите своим разработчикам… Или кейсы очень важные. А так — бизнес-логику смотрим один раз, а потом переходим в особенностям API.
Перестановка мест слагаемых
Поменяем местами name и email — ой ёй ёй!
Система пишет «Некоректный email Имечко 666». Это значит, что она ориентируется не названия полей, передаваемые в тегах, а на их порядковых номер. И это ОЧЕНЬ ПЛОХО, на такое стоит идти ставить баг.
Тем более обоснование у нас есть — неединообразно работает. REST вот от перестановки не зависит, и SOAP не должен.
А ещё слово «Некоректный» написано неправильно, там должно быть две буквы “р”. Проверяем в REST, посылая заведомо плохой емейл — да, и там ошибка. Надо бы исправить. Текстовку ошибок вычитываем внимательно!
Регистрозависимость
Каждый тег регистрозависим сам по себе — открывающий и закрывающий должны совпадать по написанию, в том числе по регистру. Если это сломать, будет точно плохой запрос, но мы начнем с условно хорошего — оба тега в капс-локе:
<EMAIL>ggg55555@mail.com</EMAIL>Работает!
А вот теперь попробуем разный регистр внутри тегов (в json такую проверку не сделать, это особенно XML, дублирование названия поля):
<EMAIL>ggg55555@mail.com</email>Не работает — Bad Request. Чтож, вполне логично.
Well formed XML
Что, если сломать XML? Скажем, оставить закрывающий тег «/email» без второй угловой скобки:
<wrap:doRegister>
<email>ggg5555@mail.com</email
<name>Имечко 666</name>
<password>1</password>
</wrap:doRegister>Возвращается ошибка
<faultcode>SOAP-ENV:Client</faultcode>
<faultstring>Bad Request</faultstring>Не супер информативно, но в целом ясно, что мы где-то с запросом накосячили. И если такой текст именно на well formed, то и ладно. Тогда по нему будет сразу понятно, в чем именно проблема. Посмотрим дальше.
Статус-коды
Разработчик может использовать стандартные коды ответов,
2хх — все хорошо
4хх — ошибка на клиенте (в запросе)
5хх — ошибка на сервере
А может придумать свои:
570 — пустой ответ на поиск;
571 — нашли одного ФЛ;
572 — нашли несколько ИП;
573 — нашли только ИП;
…
Разработчик может даже перекрыть стандартные:
400 — Bad Request
↓
400 — Internal Server Error
Но так лучше не делать =))) Просто знайте, что возможность такая имеется.
Если разработчик ленивый и не настроил коды, то вы будете огребать на любую ошибку стандартный код: 400 Bad Request. Неверный заголовок? Ошибка 400. Неверное тело? Ошибка 400. Проблемы в бизнес-логике? Ошибка 400… Ну и как тут разобраться, что именно надо исправлять?
Или ещё “лучше”, разработчик может сказать “всегда возвращай код 200”. И это очень нехорошо, ведь именно по коду мы ориентируемся в первую очередь: всё хорошо или что-то плохо?
Поэтому статус-код проверяем всегда, обращаем на него внимание. Ну а если в методе собственные статусы (как, например, в методе MagicSearch)
Практика на примере Users
На статус надо было обращать внимание всегда, чтобы не дублировать снова все тесты. Но сейчас просто дернем “хороший” и “плохой” запросы.
Хороший — статус 200, всё ок:
Плохой — ой, статус снова 200, хотя мы видим сообщение об ошибке:
Нехорошо! На это надо ставить баг.
См также:
Как тестировать методы REST API — полная статья, не только про заголовки
PS — статья написана в помощь студентам моих курсов «Инженер по тестированию ПО» и «Тестирование REST API». Хотите практики? Приходите к нам =)
Комментариев нет:
Отправить комментарий