Удаленка для jenkins+selenide+selenoid+allure+docker спецов на 2-3 часа в день. 100% remote! Присоединиться к проекту

Архитектурный вопрос по api тестированию

design-patterns
robot-framework
api
Теги: #<Tag:0x00007fedb7c52860> #<Tag:0x00007fedb7c526a8> #<Tag:0x00007fedb7c52540>

(Dmtry) #1

Добрый день.
Достались в поддержку автотесты rest api.
До меня работа была построена следующим образом,- тестировщик сочиняет запрос к бд (по идее, делает точно такой же запрос что и на стороне бекенда, а точнее рожает этот запрос параллельно независимо от разработчика) запросы что сейчас в тестах не помещаются на страницу обычно, и на них по словам предшественника уходило от дня до недели. Потом в цикле сравнивает с тем что отдает его запрос с тем что вернуло api. В цикле, значит почти всю портянку ответа. Это супер, в плане того что нас учили что избыточное тестирование недостижимы, оказывается нет.
Минус в том что тесты сложно поддерживаемы и даже с отчетом от робота понять что там сломалось трудно самому тестировщику. База одна на всех, где то потерялась консистентность, тесты упали, разобраться из за чего проблема. С базы берутся случайные значения.

Я старался раньше абстрогироваться от внутренней структуры, те использовать black box, честно говоря раньше тестровал апи только в postman, и очень хочу получить ответ знающих как мне правильно построить работу ? как быть с тем что есть и как построить работу дальше?

сейчас вижу несколько решений:

  1. пробовать поддерживать то что есть
  2. оставить стабильное с того что есть, подготовить дамп с тестовыми данными которые будут загружаться перед тестом, избавится от кучи запросов которые так же нуждаются в поддержке сейчас, переходить более в сторону черного ящика. Использовать эквивалентные классы/граничные условия вместо непрерывного перебора и сравнения.

(vmaximv) #2

Вы тестируете интеграцию api и db? Или просто api?
Если второй вариант - зачем вам вообще знать о data base, который вполне может стать например DB2 и вы выкинете все ваши запросы “на мороз”.
Легаси - оно такОе - проще переписать.


(Dmitriy Zverev) #3

Здравствуйте.

Честно говоря, всегда не понимал фразу “тестирую rest api”. Что это значит? Может быть, вы тестируете какую-то логику (бизнес-), одним из интерфейсов доступа к результатам работы которой является rest api и sql?
Исходя из этого, могли бы Вы написать в чем именно заключается проблема: сложный интерфейс, его неоптимальное использование в тестах, неконсистентное тестовое окружение, неопытность тестировщиков или что-то иное. Отмечу, что решение каждой из этих проблем может быть различным.


(Dmtry) #4

да, а разве rest api делает что то другое? Это интерфейс доступа/изменения каких то данных

Это и надо решить, то ли я не опытен и процесс тестирования построен правильно, или надо что то менять.
Написано (не мной) около 2000 тестов, примерно 70% из них стабильны. Понять что в них происходит очень сложно, или это функционал сломался или тест, кроме очевидных случаев. Представьте цикл по всему отданному ответу в ~1000 строк, и сравнение ответов апи с ответом нашего sql где то в середине log нам сообщает что 4332 != 3321, что это, зачем? Разобраться реально, часа за 3.
Сейчас упор сделан на проверку правдивости данных. те ожидаемый результат берется из sql запроса и в цикле сравнивается с огромным количеством строк ответа.

Просто api.

Сейчас склоняюсь к использованию json shema и xml shema для проверки.


(Dmitriy Zverev) #5

да, а разве rest api делает что то другое?

Да, и на мой взгляд Выша фраза “Сейчас склоняюсь к использованию json shema и xml shema для проверки” это подтверждает. Дело в том, что используя этот подход, Вы проверяете не логику, а формат передачи данных между узлами системы. Точнее говоря, Вам необходимо проверить, что 2+2 равно именно 4, а не некоторая цифра с типом int.

Как мне кажется проблема кроется тут "Понять что в них происходит очень сложно, или это функционал сломался или тест, кроме очевидных случаев. ".
Возможно, необходимо разобраться в логике проверяемого процесса и, вероятно, часть тестов окажется ненужной, код других сильно уменьшится, а для третьих подойдет data driven подход. Без конкретного примера обсуждать ситуацию сложно, но я бы посоветовал вести рефакторинг именно в таком ключе. Это позволит не потерять уже накопленные проверки и сделать преобразования на основе опыта.


(Max Krymtsov) #6

Доброго дня,

  1. Зрозуміти, який рівень тестування автоматизуєте:
  • інтеграційне тестування, тоді ми звіряємо що після якоїсь операції через АПІ, очікувані данні відповідають данним з бази. Я б використав фреймворк для data-binding, напркилад Spring для Java, або схожі аналоги.
  • системне тестування, тоді нам не цікаво на значення, які зберігаються в базі, все що ми записали/змінили через АПІ, можна прочитати/перевірити через АПІ. Якщо щось неправильно записалося в базу, при читанні цієї інформації вспливе. Rest-assured або аналоги ідеально підійдуть для цієї задачі.
  1. Забезпечити данні для тестів:
  • описати всі данні необхідні для тестів
  • гарантувати данні для тестів:
    1. якщо не має можливості незалежного енва - тоді треба створити данні виключно для автоматизації. Можна підливати їх скриптами перед кожним стартом, можна створювати данні для конкретного тесту як прекондішен перед тестом.
    2. якщо є можливість паралельного енву виключно для автоматизації - тоді варіант дампу, як ви запропонували. Але прийдеться погратися. Але бувають задачі, коли треба автоматизацію запустити на іншому енві, тоді цей варіант не спрацює.

#7

я б ще додав, що говорячи про АПІ тестінг, інтеграційне і системне в даному випадку дуже близькі по значенню, так як в більшості випадків апішка є прокладкою між юайкою і базою або іншим сервісом, тому 2 цих задачі часто об’єднують в одну. Тому стосовно пункту 1.2 я б таки звертав увагу на те які дані записались в базу, так як у випадку коли на один ріквест виконується логіка (а не просто створити/вичитати), можуть бути трабли. Зазвичай виникає задача звідки взяти вхідні дані, і очікуваний результат. Перша в більшості випадків вирішується шляхом зберігання тестових даних в екселі, генеруванням рандомних (рідко хардкодяться), витягуванням з бази даних, очікуваний же результат по логіці мав би братись з бази (іншого сервісу) для порівняння того шо вернула апішка. Для звичного фреймворку запросто підійде RestAssured як вже було сказано, в зв’язці з Jackson’ом і звичайним драйвером для бд


(Dmitry Gr) #8

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