testomat.io управление авто тестамиRestAssured хорошая вещица , для чего Вам UI интерфейс ?
1 лайк
Меняем одно шило на другое. Зачем добавлять оверхед в виде фреймворков на такую простую вещь как REST тесты? python+requests+любой лаунчер тестов, вплось до unittest.
Другой вопрос - зачем Вам UI на тестах? Показывать другу?
3 лайка
Мне незачем, сейчас вот тоже подумала, что если кому то надо будет - пусть открывают любой ui клиент и по моим данным воспроизводят… Это идея из команды исходила, насчет UI.
Если не секрет, то почему решили отказываться от SoapUI?
Сам пробовал не проекте. Были у него как сильные, так и не очень стороны. Хотелось бы знать и мнение других пользователей.
P.S. под требованием “необходим UI” и умение “воспроизводить” что подразумевается? Я так понимаю, что при тестировании API главное чтоб было нормальное логирование: что куда и как шлём и что получаем/неполучаем в ответ + если нужно еще проверки в БД. А имея норм логирование и любой инструмент, который может также слать запросы, даже тот же SoapUI - воспроизвести проблему дел на 2 минуты.
Бесплатная версия -убогая и особо не поддерживается, как я понимаю сейчас, могу ошибаться. Мы использовали платную, но и с ней проблем много, больше всего напрягает не всегда корректные результаты тестов - тест выглядит красным, открываешь шаги - они все зеленые. Еще пытаемся сейчас настроить запуск на CI сервере, приходим в выводу о необходимости доп лицензии или float лицензия, что уже гораздо дороже.
Кстати появилась идея на миллион долларов =) А как можно создавать какой то тестовый проект, совместимый с POstman? Чтобы не реализовывать свое UI, но дать возможность генерировать проекты, импортируемые в postman, чтобы каждый мог локально у себя запускать что надо. Плюс еще думаю как организовать хранение отправляемых данных (в том числе медиа файлы большого объема, их хорошо бы как то кэшировать). У кого какие идеи?
это да, но вот разработчики в моей команде мечтают вообще о готовом запросе на блюдечке, я так их поняла.
Добрый день! У себя на проекте использовал бесплатную версию SoapUI 5.0.0 в ней проблем с красными тестами у которых внутри все шаги и проверки зеленые не наблюдал. Возможно что это проблема более новых версий или даже платной. Я от 5.2.1 на проекте отказался: плюсов для себя не увидел, но при этом были всякие раздражающие ошибки. Единственно, что может тест упал при запуске набора, а затем упавший степ был успешно пройден отдельно или ассерт исправлен и все шаги стали зелеными, а в графическом интерфейсе окно с набором не перерисовалось и осталось красным. Других идей у меня нет. Действительно ни разу не сталкивался именно с таким вот поведением.
Сейчас вот все-таки думаю перейти на что-то типа такого:
Spring RestTemplate
Rest Assured
Groovy wslite
если знать Java или Groovy то в фришной версии можно всего что нужно добиться
1 лайк
Можно, но в итоге это не дольше выходит, чем через код? И в бесплатной версии интерфейс к тому же не очень удобный, память течет и тд, мне кажется с обычным кодом таких проблем не будет, тесты будут гибче и изящнее?
Будут, конечно.
Но я за более прагматичный подход просто. Как бы мне это не было больно осознавать, но заказчику по большому счету плевать на наше тестирование и даже на наши отчеты. Проверял. Не читают. Но вот что их волнует - это чтобы купленное ими ПО работало и не имело дефектов/проблем, выполняло свои функции и приносило компании прибыль (сокращало расходы).
Все остальные штуки, которые интересны нам, это уже для IT-шников: это и удобство сопровождения и разработки и тестируемости и т.д. Как и почему мы достигаем результата заказчику в 99% случаев все равно.
Поэтому я и удивился, что вы отказываетесь от уже сформированной модели на SoapUI с наверняка немалым числом готовых кейсов в пользу полностью нового подхода. Будет ли экономически оправдан данный переход - большой вопрос. Я вот на новом проекте через Java сервисы юзаю, но там и задача другая и сам проект с нуля стартовал. А вот до этого делал на SoapUI и там этот подход остался и дальше себе тихо и мирно развивается. Потому что снова писать тесты это время и деньги, которых может и не быть, а также возможные баги в самих тестах, которые нужно править, а эти уже есть и работают и ловят ошибки и проверены временем. Как-то так. Но SoapUI я когда-то выбирал просто потому, что особо и не из чего было выбирать и на первых парах с ним было удобно работать. Сразу из ручного сценария делать автоматизированный в одной и той же среде.
P.S. при запуске через консоль у меня память в SoapUI не утекала. А вот через GUI - да, бывали разные вещи. Особенно бесило, когда файл проекта с правками и новыми тестами не сохранялся и вся работа за день псу под хвост.
1 лайк
Спасибо большое за ответ, пока наверное так торопиться не буду, попробую бороться с проблемами в SoapUI и в фоне для себя освою RestSharp/RestAssurance (про запас).
Всем глубоко плевать как и на чем вы пишите тесты, интересует всех только их эффективность, по этому чем минимальнее и понятнее все будет организовано, тем проще Вам это будет поддерживать.
PS. Намедни понадобилась тулза для писанины поблочной на носители, облазил пол интернета, ничего не нашел. Взгляд пал на Win32 Disk Imager, думай мелкий, и поддерживает CMD аргументы. Открыл исходник, и ужаснулся, насколько UI из программы 4-Х (!!!) функций, сделал ужасного монстра. Вот Вам повод задуматься.
Пруфы, что бы балаболом не казаться - https://sourceforge.net/p/win32diskimager/code/ci/master/tree/src/
Наш проект тестируется самописным фреймворком на php. Для тестирования апи вам нужна curl-like либа на любом языке.для сложных запросов, создания контекста для тестов - хорошей идеей будет завести дб хелперы , написанные на любом ОРМ. Они должны обеспечивать вас данными в дата провайдере и гарантировать случайность и исключительность. Сам по себе рест запрос бесполезен без выборок реальных данных, поэтому описать какой-никакой воркфлоу для каждого теста/тест сьюта будет хорошей идеей . если интересно, посмотрите отличное видео Паши Асанова с SQA Days про фреймворк 2fingers.
Добавлю от себя. Тестирую АПИ для мобильных приложений. А там и oAuth и отправка изображений и пр. Изначально начал писать апи клиент для удобства ручных тестов (нужно имитировать дейсвтия разных пользвателей), в итоге все вылилось в клиент + тесты + отчеты.
Все это написано на ruby, тесты в rspec, репорты в CI - Allure.
Благодаря rspec - есть удобное разделение тестов на сьюты по контекстам (номер тикета), что дает возможнось легкость запуска нужных тестов в виде rspec -t feature:TICKET-999
Как в Вашем случае разруливаются ситуации, в которых нужно произвести действие над сущностью (UPDATE, POST, DELETE), которая находится в еще не готовом состоянии? Как вами подготавливается контекст? Насколько rspec позволяет готовить данные?
Чаще всего я пишу тесты уже по относительно готовому функционалу. Бывают ситуации конечно, когда пишу до реализации, по просьбе разработчика.
В клиенте реализовано несколько уровней абстракций:
Actions - верхний уровень, работает с бизнес сущностями и апи
API - разные апи (oauth, public, user)
Request - минимальная обертка над библиотекой отправки запросов. нужна, по факту, только для oauth подписей.
В самих тестах так же тестируються отдельно API и Actions.
Например для нового метода, подобный метод добавляется в соответсвующий API класс, и дальше он покрывается тестами.
def change_pin(old_pin, new_pin)
payload = {
oldPin: old_pin,
newPin: new_pin
}
headers = @json_headers
Request.post("#{@base_url}/user/pin-code",
payload.to_json, headers, before_execution_proc: before_proc) { |resp| resp }
end
Не понял про подготовку данных rspec-омю
А под клиентом вы что имеете в виду?
А где вы храните тестовые артефакты? Например файлы, которые надо отправить. И иногда их еще надо менять… в Soapui они кэшируются и в дальнейшем их можно открыть прямо из тесткейса, посмотреть что там за файл, заменить его другим, если надо и тд…
Как я писал:
Изначально начал писать апи клиент для удобства ручных тестов (нужно имитировать действия разных пользвателей)
Клиент - такой себе имитатор реального мобильного клиента. С внешним интерфейсом который используется в тестах (к слову - он используется еще и в UI тестах)
Так же, я его использую как консольный клиент при ручных тестах мобильного приложения.
Про файлы - на самом деле из файлов - это рандомные картинки, которые генерирует сам клиент. для меня это не важно. Но в принципе - что мешает хранить их рядом с тестами, и редактировать там же. А реализация этого всего зависит только от типа файлой, и задач.