Добрый день.
Достались в поддержку автотесты rest api.
До меня работа была построена следующим образом,- тестировщик сочиняет запрос к бд (по идее, делает точно такой же запрос что и на стороне бекенда, а точнее рожает этот запрос параллельно независимо от разработчика) запросы что сейчас в тестах не помещаются на страницу обычно, и на них по словам предшественника уходило от дня до недели. Потом в цикле сравнивает с тем что отдает его запрос с тем что вернуло api. В цикле, значит почти всю портянку ответа. Это супер, в плане того что нас учили что избыточное тестирование недостижимы, оказывается нет.
Минус в том что тесты сложно поддерживаемы и даже с отчетом от робота понять что там сломалось трудно самому тестировщику. База одна на всех, где то потерялась консистентность, тесты упали, разобраться из за чего проблема. С базы берутся случайные значения.
Я старался раньше абстрогироваться от внутренней структуры, те использовать black box, честно говоря раньше тестровал апи только в postman, и очень хочу получить ответ знающих как мне правильно построить работу ? как быть с тем что есть и как построить работу дальше?
сейчас вижу несколько решений:
пробовать поддерживать то что есть
оставить стабильное с того что есть, подготовить дамп с тестовыми данными которые будут загружаться перед тестом, избавится от кучи запросов которые так же нуждаются в поддержке сейчас, переходить более в сторону черного ящика. Использовать эквивалентные классы/граничные условия вместо непрерывного перебора и сравнения.
Вы тестируете интеграцию api и db? Или просто api?
Если второй вариант - зачем вам вообще знать о data base, который вполне может стать например DB2 и вы выкинете все ваши запросы “на мороз”.
Легаси - оно такОе - проще переписать.
Честно говоря, всегда не понимал фразу “тестирую rest api”. Что это значит? Может быть, вы тестируете какую-то логику (бизнес-), одним из интерфейсов доступа к результатам работы которой является rest api и sql?
Исходя из этого, могли бы Вы написать в чем именно заключается проблема: сложный интерфейс, его неоптимальное использование в тестах, неконсистентное тестовое окружение, неопытность тестировщиков или что-то иное. Отмечу, что решение каждой из этих проблем может быть различным.
да, а разве rest api делает что то другое? Это интерфейс доступа/изменения каких то данных
Это и надо решить, то ли я не опытен и процесс тестирования построен правильно, или надо что то менять.
Написано (не мной) около 2000 тестов, примерно 70% из них стабильны. Понять что в них происходит очень сложно, или это функционал сломался или тест, кроме очевидных случаев. Представьте цикл по всему отданному ответу в ~1000 строк, и сравнение ответов апи с ответом нашего sql где то в середине log нам сообщает что 4332 != 3321, что это, зачем? Разобраться реально, часа за 3.
Сейчас упор сделан на проверку правдивости данных. те ожидаемый результат берется из sql запроса и в цикле сравнивается с огромным количеством строк ответа.
Просто api.
Сейчас склоняюсь к использованию json shema и xml shema для проверки.
Да, и на мой взгляд Выша фраза “Сейчас склоняюсь к использованию json shema и xml shema для проверки” это подтверждает. Дело в том, что используя этот подход, Вы проверяете не логику, а формат передачи данных между узлами системы. Точнее говоря, Вам необходимо проверить, что 2+2 равно именно 4, а не некоторая цифра с типом int.
Как мне кажется проблема кроется тут "Понять что в них происходит очень сложно, или это функционал сломался или тест, кроме очевидных случаев. ".
Возможно, необходимо разобраться в логике проверяемого процесса и, вероятно, часть тестов окажется ненужной, код других сильно уменьшится, а для третьих подойдет data driven подход. Без конкретного примера обсуждать ситуацию сложно, но я бы посоветовал вести рефакторинг именно в таком ключе. Это позволит не потерять уже накопленные проверки и сделать преобразования на основе опыта.
інтеграційне тестування, тоді ми звіряємо що після якоїсь операції через АПІ, очікувані данні відповідають данним з бази. Я б використав фреймворк для data-binding, напркилад Spring для Java, або схожі аналоги.
системне тестування, тоді нам не цікаво на значення, які зберігаються в базі, все що ми записали/змінили через АПІ, можна прочитати/перевірити через АПІ. Якщо щось неправильно записалося в базу, при читанні цієї інформації вспливе. Rest-assured або аналоги ідеально підійдуть для цієї задачі.
Забезпечити данні для тестів:
описати всі данні необхідні для тестів
гарантувати данні для тестів:
якщо не має можливості незалежного енва - тоді треба створити данні виключно для автоматизації. Можна підливати їх скриптами перед кожним стартом, можна створювати данні для конкретного тесту як прекондішен перед тестом.
якщо є можливість паралельного енву виключно для автоматизації - тоді варіант дампу, як ви запропонували. Але прийдеться погратися. Але бувають задачі, коли треба автоматизацію запустити на іншому енві, тоді цей варіант не спрацює.
я б ще додав, що говорячи про АПІ тестінг, інтеграційне і системне в даному випадку дуже близькі по значенню, так як в більшості випадків апішка є прокладкою між юайкою і базою або іншим сервісом, тому 2 цих задачі часто об’єднують в одну. Тому стосовно пункту 1.2 я б таки звертав увагу на те які дані записались в базу, так як у випадку коли на один ріквест виконується логіка (а не просто створити/вичитати), можуть бути трабли. Зазвичай виникає задача звідки взяти вхідні дані, і очікуваний результат. Перша в більшості випадків вирішується шляхом зберігання тестових даних в екселі, генеруванням рандомних (рідко хардкодяться), витягуванням з бази даних, очікуваний же результат по логіці мав би братись з бази (іншого сервісу) для порівняння того шо вернула апішка. Для звичного фреймворку запросто підійде RestAssured як вже було сказано, в зв’язці з Jackson’ом і звичайним драйвером для бд
5 копеек по тому что уже вырисовывается:
писать в API тестах запросы к базе данных - плохая идея в принципе, выше описали почему.
как альтернатива - использовать в тестах реквесты парами GET-POST.
Например если мы хотим убедиться что данные про конкретный автомобиль правильно сохранились в базе, эти данные вытягиваются последующим GETом. не нужно проверять в каком виде они записываются в базу.
testomat.io управление авто тестами