testomat.io управление авто тестамиSoapUI - наше всё в данной задаче.
Писать код вручную имеет смысл, только если есть другие тесты, например, на селениуме и есть задача запускать все тесты вместе.
При любом другом раскладе тесты на SoapUI писать и поддерживать гораздо легче.
что Ви несете ?.. ))
4 лайка
Какой-то бездумный ответ. Чукча не читатель, чукча писатель?
Если есть аргументированные замечания по существу ответа - в студию. А на Ваш вопрос ответ может быть только 1: а Ви?
При чем тут селениум тести вообше к АРІ тестам ? Все зависит от знания библиотек и фреймворком, понятное дело если Ви мануальщик то Вам SOAP UI будет легче, так как там IDE интерфейс… но он крайне неудобен для многих потребностей, плюс более менее нормальна его версия платная. Писать код вручную всегда имеет смисл, особенно если деви уже много написали - можно работать с ними в pair
1 лайк
Аа, вот, что Вы не поняли! 
Оки, ща объясню.
Рассмотрим 3 расклада:
1). У нас планируются только автоматизированные API тесты. Все остальные тесты нам либо не нужны (ну, например, проект связан только сервисами и UI у него нет), либо проходятся исключительно мануально и автоматизации этих тестов не предвидится.
2). У нас планируются автоматизированные API тесты и автоматизированные UI тесты, но запускать мы их планируем по отдельности (например, этим занимаются разные команды и / или частота запуска этих тестов будет различна).
3). У нас планируются автоматизированные API тесты и автоматизированные UI тесты и мы планируем запускать их как единый набор тестов, иными словами, логика группировки данных тестов будет реализована не по типу теста, а по тестируемой сущности.
Я сознательно опускаю тут юнит тесты, поскольку слабо представляю себе вариант, чтобы мне потребовалась интеграция юнит тестов с каким бы то ни было другим типом тестов.
Рассмотрим pros & cons SoapUI тестов vs Java (к примеру) тестов.
В SoapUI скорость создания тестов гораздо выше, чем с помощью кода, уж поверьте человеку, который юзал данную тулзу овер 2-х лет Очень много вещей там можно сделать в 3 клика мышкой, особенно в Pro версии. Темп немного падает, когда появляется необходимость в сложных сценариях и скриптовых ассершенах, но таких случаев не более 5% от общей массы.
К примеру, сценарий типа “создаём объект POST запросом, затем проверяем через GET запрос с параметром id объекта, что данный объект появился в базе и его атрибуты соответствуют заданным, затем проверяем через GET запрос, что при запросе всех объектов данного типа данный объект попал в список” пишется в течение 20 мин, из которых 10 уйдёт на конструирование xml для объекта на 1-м шаге.
Единственный значительный недостаток тулзы - необходимость иметь хоть как-то работающий код, поскольку ассершены по существующей xml ставятся в 3 клика, если же xml нету - их приходится писать руками, что значительно замедляет работу. Как альтернативу, можно использовать моки, но их возвращаемые объекты придётся тогда создавать руками, на что тоже будет уходить немало времени, особенно если в объекте много атрибутов.
Теперь вернёмся к нашим сценариям.
1). Тут всё очевидно. Создавать тесты в SoapUI намного проще и быстрее, чем делать это в коде. Реализация CI будет выполнена 1 джобой, запускающей SoapUI тесты через командную строку. При наличии нескольких наборов тестов - возможно создание нескольких джоб или добавление параметра в джобу.
2). Поскольку необходимости в интеграции нет - смысла писать код я не вижу. Реализация CI (при необходимости) в данном случае будет выполнена 2-мя разными джобами, 1 из которых будет запускать SoapUI тесты, а 2-я - UI тесты (к примеру, базирующиеся на вышеупомянутом селениуме).
3). Вот тут как раз появляется необходимость интеграции. Для CI в данном случае я бы использовал связку Maven + TestNG, разбил тесты по категориям (матрицей тип теста (API, UI) - компонент или тип теста (smoke, functional, regression) - компонент), сделал общий логгер на базе того же log4j, добавил в джобу параметры, позволяющие запускать её с определённым набором тестов на базе выбранных значений матрицы или сделал бы несколько джоб с зафиксированными значениями параметров - в зависимости от задач. В этом случае потребность в интеграции и, как следствие, в унификации результатов, перекрывает дополнительные затраты времени, требующиеся на создание API тестов в коде. Разумеется, при достаточном количестве UI тестов. При малом количестве последних проще отказаться от интеграции и использовать вариант 2.
Очень похоже на голословные утверждения. Если у вас тесты это просто POST и GET запросы, то может так и есть, но это вовсе не означает, что так всегда. Более того при нормально написанном тестовом фрейморке на Java скорость разработки тестов либо примерно такая же, а иногда даже выше.
У меня на одном проекте как раз было все наоборот, причем это не с потолка взятые цифры, а реальное сравнение “было” → “стало”.
Вопрос по лицензированию и работе с SoapUI PRO
То что у вас проверка POST завязана на GET - это уже связность тестов, но вполне допускаю, что это приемлемая ситуация, т.к. и самому приходилось связывать вызовы одних сервисов при тестировании других, но в общем случае это не очень хороший принцип и может приводить к “эффекту домино”, а также к тому, что при несинхронной разработке, если POST был сделан раньше нужных GET’ов, то вы не сможете проверить автотестами результат его работы. Более того GET не всё возвращает обычно и соответственно вы по факту не проверяете то как запись легла в базу. Например, туда положили “” или пробел вместо null, но GET вам вернул одинако что так, что так. А потом окажется, что на это была какая-нибудь хитрая логика накручена.
1 лайк
Ну, веб-сервисы - это-таки POST, GET, PUT в основном
Обычно проверяются следующие вещи: response code, headers, логика (последняя проверяется обычно на основании того, что возвращает GET). Если есть требования, можно ещё нагрузку проверить.
Да, согласен. Но 1 WS обычно небольшой, поэтому связность 2-х тестов приводит к невозможности параллельного запуска тестов (но оставляет возможность параллельного запуска тест сьютов, что в случае запуска с 1 машины не представляет никаких недостатков в плане быстродействия). Эффекта домино не будет, поскольку 1 тест максимум завязан на 2 следующих (Property Transfer и GET), а остальные тесты от них не зависят.
Не совсем так. GET вернёт xml, в которой есть 3 варианта для ноды:
“”
Разница, очевидно, есть. Более того, мне было неинтересно, как запись легла в базу. Мне было интересно, что вернёт GET, потому что именно этим образом будет запрошена данная запись, прямое обращение к базе у нас на проекте было невозможным (специфика проекта). Таким образом, запрашивая базу напрямую, я максимум мог локализовать проблему (база или запрос), но усилий для этого мне надо было бы приложить в 3 раза больше, что не отвечало приоритетам задач.
А объясните и мне пожалуйста, как в вашем варианте можно хендлить следующие кейсы при вашей схеме :
- Refresh button -> зашли -> проверили -> API -> рефрешнули -> проверили что рефреш работает - you can not do without api call from ui tests.
- Turn on|off feature on server side (you can not do this from client side) - зашли -> проверили -> API -> перезашли -> проверили что something works right - you can not do without api call from ui tests
3.10-ти тестам нужно 10 сущностей (намек на datap_rovider) aka<user><prop1=p1/><prop2=p2/>...<prop10=p10/></user>, причем проперти вариативные и могут отсутствовать - copy&paste в SOAP?
4.Как сапортить два отдельных проекта (API+UI), когда у вас 500 UI тестов и 500 API тестов - и прямой видимости между test data и тестами у вас нету?
Я могу продолжать этот список и дальше - их есть у меня (thnx to indian guys).
IMHO вы еще не “проварились”.
1 Soap UI больше подходит для ручного тестирования, или если у вас проект не long-term то можно и на нём написать автотесты
2 Если проект long-term то лучше выбрать любой open-source фреймворк для веб-сервисов. Я рекомендую rest-assured. Потому-что в любом случае огребете проблемы с каким-то кейсом использования, а open-source можно самому поправить.
3 Работа напрямую в Java позволяет иметь гибкость 80-уровня. Что не позволяет любой готовый инструмент по типу Soap UI.
4 Как уже написали выше корректность самих данных, чаще всего проверяется через Entity Классы, т.е выполнили post запрос, потом вытянули сущность через EntityDto и проверяем конкретные поля. Тут надо отметить что сам класс DTO нужно тестировать отдельно.
2 лайка
Хорошее сравнение “за” и против". IMHO, даже не скорость разработки, а поддержка и рефакториг soapui и java тестов дают однозначный ответ в пользу java подхода.
1 лайк
@Defender вы же понимаете, что вашим способом вы не можете протестировать правильность работы тех же самых GET запросов? Если у вас есть проблемы с доступом в БД, то тут конечно ничего не попишешь, но вы должны понимать очень сильную ограниченность такого тестирования и его качества. Также вы не рассматриваете проблем при работе с несколькими сервисными слоями. У вас возможно с БД работает один сервисный слой и пишет одна и та же команда разработчиков, но во множестве случаев это не так. И там уже проверка того как значения легли в базу - это основополагающее. Потому что с данными работают не только ваши сервисы и не только ваш продукт или разрабочики. И там могут быть всякие чудеса и расхождения спецификаций и т.д. Поэтому тот способ, который вы описали - он применим, но очень и очень ограничен даже с точки зрения тестирования чисто API. А вот когда вы начнете писать что-то более сложное, то тут-то и начнуться чудеса в SoapUI и там уже начнутся приседания с портянками groovy-кода на 100-200 строк с постоянным копи-пастингом.
Также вам выше привели пример с динамическими XML структурами. Где-то будет такая структура, а в таком же самом запросе, но с другими данными уже немножко другая (новые теги, блоки и т.д.). И в этом случае у вас будет копи-пастинг XML-ек между тест-кейсами. А если через полгода разработчики внесут коррективу в запрос и добавят еще одно поле в XML-ку, то вам придется пробежаться по всем сценариям и точно также их все починить. И это будет происходить из раза в раз. Еще смешнее будет, если “поломают” вам структуру не в POST, а в GET запросе и вместо запуска тестов вы будете заниматься починкой. Причем будете еще вылавливать подобные сценарии из общего набора несвязанных POST-запросов. Опять-таки не раскрыт механизм наполнения данными в вашем примере. Потому что непонятно как вы получаете данные для своих запросов. А что если “захардкоженный” вами пользователь был удален? Или такой уже был создан в предыдущий раз и система не позволяет создавать второго такого же? И т.д. И когда все эти вещи на SoapUI начинаете решать, то со временем упираетесь в то, что больше тратите времени на саппорт старых тестов и не можете двигаться вперед. С Java это тоже происходит, тут не стоит лукавить, но по моим личным наблюдениям на проекте, который мигрировал с SoapUI разработки на Java - выйгрышь в производительности и удобстве работы катастрофический для SoapUI. И после этого нет никакого желания использовать данный инструмент на что-то более сложное, чем “пульнул ручками запрос, посмотрел ответ, поизучал в разных вариациях”, а потом взял эти тесты и заавтоматизировал по нормальному с использованием полноценной IDE.
1 лайк
Чтобы не гадать что вернет сервис, вам нужно готовить тестовые данные вручную и заливать их перед тестом. В таком случае, вы точно будете знать что нужно проверить на выходе. Если по каким-то причинам вы не можете сами подготовить данные, то тогда да, выборка из БД, но это при условии, что у вас могут меняться тестовые данные и вы не можете быть уверены в их содержании.
1 лайк
Никак. SoapUI позволяет автоматизировать API тесты, которые по своей сути есть интеграционные. Вы хотите микшированный сценарий API и UI тестов. Этот сценарий относится к случаю 3. Я же описал применимость выше.
Опять-таки микшированный сценарий.
Ну, можно, конечно, и копипастить, но SoapUI поддерживает Data Driven tests. Самый простой вариант навскидку - использовать DataSource. Работает только в Pro версии. Если надо сделать что-нить совсем нетривиальное - DS + Script step, который будет делать конструктор xml на базе тех данных, которые придут из DS шага.
UI тестов должно быть в 3…10 раз меньше, чем API тестов. Если у Вас не так - смотрите, почему неэффективны Ваши API тесты. Прямой видимости и не должно быть, в случае 2-х отдельных групп тестов. Т.е., test data для UI тестов могут быть отнюдь не теми же самыми, что и для API тестов. Если у Вас это не так - значит, Ваши тесты зачастую тупо дублируют друг друга.
Ещё раз: плз, обратите внимание на область применимости той стратегии, которую я расписал. Это не панацея для всех возможных вариантов 
И 99% пользователей SoapUI будут это делать.
Фи, ведь:
Я думаю, это зависит от 3-х вещей: знания пользователем инструмента, умения мыслить дальше, чем на 1 ход и выполняемых задач. Очевидно, что в случае 2-х похожих кейсов без перспективы появления 3-го, можно и скопипастить - затраты на модификацию 2-х степов вместо одного вряд ли превысят затраты на создание DS + SS, особенно вспоминая особенности отладки SS в SoapUI методом alert’ов В случае реализации стратегии Data Driven Testing, затраты на поддержку копипаста превысят все разумные пределы и в этом случае разумно сразу написать с заделом на будущее.
Но эта же проблема стоИт в полный рост перед Вами в коде: вряд ли Вы будете городить 4…5 abstration layers, если их будут использовать только 2 тест кейса.
Какие абстракции, какие лейерсы? Самый примитивный template engine + три строки кода, минимальные затраты, удобная отладка, никакого копи-паста, не надо заглядывать “за горизонты”.
SoapUI давно надо было похоронить в конце нулевых.
Мужики, хорош спорить. Кажется девушка спрашивала немного про другое 
А поговорить? 
Ну вообще-то девушка хотела узнать про подходы к проверке респонса от веб-сервиса и как хранить тестовые данные для этого…А вы сразу про что лучше iOS или Android 
Никто даже не уточнил какой веб-сервис, а вдруг там бородатое SOAP вместо REST?)
Бородатый - это CORBA services… или еще что похуже.