Есть отличная удаленная работа для php+codeception+jenkins+allure+docker спецов. 100% remote! Присоединиться к проекту

Тестирование API, что выбрать для тестирования на CI сервере + локально с UI

soapui
rest
robot-framework
api
Теги: #<Tag:0x00007f7b64681eb0> #<Tag:0x00007f7b64681d48> #<Tag:0x00007f7b64681c08> #<Tag:0x00007f7b64681a50>

(Tatyana Durova) #1

Добрый день, есть много тестов на SoapUI, но думаю отказаться от использования этого продукта и переписать все на фрейймворке типа Robotframework или иных (варианты приветствую).

Есть несколько требований:

  1. UI интерфейс или возможность реализовать его, для удобного тестирования и отладки локально.
  2. Возможность запуска тестов без UI, на сервере интеграции
  3. готовые классы, методы для быстрого создания тестов на АПИ

#2

@Tatyana_Durova я бы рекомендовал Postman. он работает и на декстопе и сами тесты можно запускать через newman - это консольный интерфейс + он очень простой в использовании


(Tatyana Durova) #3

да вы что, как там ассерты нормальные делать и цепочки и тд? я его использовала, но это какой то несерьезный инструмент и вовсе не гибкий.


#4

@Tatyana_Durova

вот простейший тест
var jsonData = JSON.parse(responseBody)
tests[“Status code is 200”] = responseCode.code === 200
tests[“Body matches Result”] = jsonData.result === true
tests[“Body matches ErrorCode”] = jsonData.errorCode === 0
tests[“Body matches ErrorKey”] = jsonData.errorKey === “”

Но стоит добавить - что я сам перешел на просто python + requsts lib - мне проще с ним работать - но у нас много кто использует Postman - даже с девелоперов.


(Taras) #5

RestAssured хорошая вещица , для чего Вам UI интерфейс ?


(Goshko Nazar) #6

Меняем одно шило на другое. Зачем добавлять оверхед в виде фреймворков на такую простую вещь как REST тесты? python+requests+любой лаунчер тестов, вплось до unittest.
Другой вопрос - зачем Вам UI на тестах? Показывать другу?


(Tatyana Durova) #7

Мне незачем, сейчас вот тоже подумала, что если кому то надо будет - пусть открывают любой ui клиент и по моим данным воспроизводят… Это идея из команды исходила, насчет UI.


(Михаил Братухин) #8

Если не секрет, то почему решили отказываться от SoapUI?

Сам пробовал не проекте. Были у него как сильные, так и не очень стороны. Хотелось бы знать и мнение других пользователей.

P.S. под требованием “необходим UI” и умение “воспроизводить” что подразумевается? Я так понимаю, что при тестировании API главное чтоб было нормальное логирование: что куда и как шлём и что получаем/неполучаем в ответ + если нужно еще проверки в БД. А имея норм логирование и любой инструмент, который может также слать запросы, даже тот же SoapUI - воспроизвести проблему дел на 2 минуты.


(Tatyana Durova) #9

Бесплатная версия -убогая и особо не поддерживается, как я понимаю сейчас, могу ошибаться. Мы использовали платную, но и с ней проблем много, больше всего напрягает не всегда корректные результаты тестов - тест выглядит красным, открываешь шаги - они все зеленые. Еще пытаемся сейчас настроить запуск на CI сервере, приходим в выводу о необходимости доп лицензии или float лицензия, что уже гораздо дороже.

Кстати появилась идея на миллион долларов =) А как можно создавать какой то тестовый проект, совместимый с POstman? Чтобы не реализовывать свое UI, но дать возможность генерировать проекты, импортируемые в postman, чтобы каждый мог локально у себя запускать что надо. Плюс еще думаю как организовать хранение отправляемых данных (в том числе медиа файлы большого объема, их хорошо бы как то кэшировать). У кого какие идеи?


(Tatyana Durova) #10

это да, но вот разработчики в моей команде мечтают вообще о готовом запросе на блюдечке, я так их поняла.


(Михаил Братухин) #11

Добрый день! У себя на проекте использовал бесплатную версию SoapUI 5.0.0 в ней проблем с красными тестами у которых внутри все шаги и проверки зеленые не наблюдал. Возможно что это проблема более новых версий или даже платной. Я от 5.2.1 на проекте отказался: плюсов для себя не увидел, но при этом были всякие раздражающие ошибки. Единственно, что может тест упал при запуске набора, а затем упавший степ был успешно пройден отдельно или ассерт исправлен и все шаги стали зелеными, а в графическом интерфейсе окно с набором не перерисовалось и осталось красным. Других идей у меня нет. Действительно ни разу не сталкивался именно с таким вот поведением.


(Tatyana Durova) #12

Сейчас вот все-таки думаю перейти на что-то типа такого:
Spring RestTemplate
Rest Assured
Groovy wslite


(Taras) #13

если знать Java или Groovy то в фришной версии можно всего что нужно добиться


(Tatyana Durova) #14

Можно, но в итоге это не дольше выходит, чем через код? И в бесплатной версии интерфейс к тому же не очень удобный, память течет и тд, мне кажется с обычным кодом таких проблем не будет, тесты будут гибче и изящнее?


(Михаил Братухин) #15

Будут, конечно.
Но я за более прагматичный подход просто. Как бы мне это не было больно осознавать, но заказчику по большому счету плевать на наше тестирование и даже на наши отчеты. Проверял. Не читают. Но вот что их волнует - это чтобы купленное ими ПО работало и не имело дефектов/проблем, выполняло свои функции и приносило компании прибыль (сокращало расходы).

Все остальные штуки, которые интересны нам, это уже для IT-шников: это и удобство сопровождения и разработки и тестируемости и т.д. Как и почему мы достигаем результата заказчику в 99% случаев все равно.

Поэтому я и удивился, что вы отказываетесь от уже сформированной модели на SoapUI с наверняка немалым числом готовых кейсов в пользу полностью нового подхода. Будет ли экономически оправдан данный переход - большой вопрос. Я вот на новом проекте через Java сервисы юзаю, но там и задача другая и сам проект с нуля стартовал. А вот до этого делал на SoapUI и там этот подход остался и дальше себе тихо и мирно развивается. Потому что снова писать тесты это время и деньги, которых может и не быть, а также возможные баги в самих тестах, которые нужно править, а эти уже есть и работают и ловят ошибки и проверены временем. Как-то так. Но SoapUI я когда-то выбирал просто потому, что особо и не из чего было выбирать и на первых парах с ним было удобно работать. Сразу из ручного сценария делать автоматизированный в одной и той же среде.

P.S. при запуске через консоль у меня память в SoapUI не утекала. А вот через GUI - да, бывали разные вещи. Особенно бесило, когда файл проекта с правками и новыми тестами не сохранялся и вся работа за день псу под хвост.


(Tatyana Durova) #16

Спасибо большое за ответ, пока наверное так торопиться не буду, попробую бороться с проблемами в SoapUI и в фоне для себя освою RestSharp/RestAssurance (про запас).


(Goshko Nazar) #17

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

PS. Намедни понадобилась тулза для писанины поблочной на носители, облазил пол интернета, ничего не нашел. Взгляд пал на Win32 Disk Imager, думай мелкий, и поддерживает CMD аргументы. Открыл исходник, и ужаснулся, насколько UI из программы 4-Х (!!!) функций, сделал ужасного монстра. Вот Вам повод задуматься.
Пруфы, что бы балаболом не казаться - https://sourceforge.net/p/win32diskimager/code/ci/master/tree/src/


(Евгений Бухгаммер) #18

Наш проект тестируется самописным фреймворком на php. Для тестирования апи вам нужна curl-like либа на любом языке.для сложных запросов, создания контекста для тестов - хорошей идеей будет завести дб хелперы , написанные на любом ОРМ. Они должны обеспечивать вас данными в дата провайдере и гарантировать случайность и исключительность. Сам по себе рест запрос бесполезен без выборок реальных данных, поэтому описать какой-никакой воркфлоу для каждого теста/тест сьюта будет хорошей идеей . если интересно, посмотрите отличное видео Паши Асанова с SQA Days про фреймворк 2fingers.


(brbrr) #19

Добавлю от себя. Тестирую АПИ для мобильных приложений. А там и oAuth и отправка изображений и пр. Изначально начал писать апи клиент для удобства ручных тестов (нужно имитировать дейсвтия разных пользвателей), в итоге все вылилось в клиент + тесты + отчеты.

Все это написано на ruby, тесты в rspec, репорты в CI - Allure.
Благодаря rspec - есть удобное разделение тестов на сьюты по контекстам (номер тикета), что дает возможнось легкость запуска нужных тестов в виде rspec -t feature:TICKET-999


Дайте пару советов по процессу автоматизации тестирования
(Евгений Бухгаммер) #20

Как в Вашем случае разруливаются ситуации, в которых нужно произвести действие над сущностью (UPDATE, POST, DELETE), которая находится в еще не готовом состоянии? Как вами подготавливается контекст? Насколько rspec позволяет готовить данные?