Добрый день, находил похожие вопросы, но не нашел в них ответа для себя.
Имеется проект средних размеров проект, который является набором веб-сервисов общающихся между собой при помощи soap и json запросов. Сейчас происходит ручное тестирование при помощи soapUI, но хочется внедрить автотесты. Основной причиной, почему не хочется использовать соапюи в качестве автоматизированного тестировщика, это то что в полном цикле запросов будет 4-6 последовательных запросов по разным WSDL с использованием большого количества параметров, в т.м. числе параметры взятые из ответов на предыдущие запросы, возможно я не достаточно знаю SoapUI, что бы считать что там можно удобно реализовать подобную систему. Поэтому решено использовать язык программирования - питон.
Но у меня больше теоретические вопросы, т.к. опыта использования и темболее написания автотестов нет. В моем представлении автотест для вебсервиса должен совершать серию запросов с различными параметрами и парсить ответ на предмет наличия ошибок, логировать результаты. Верно ли мое представление? Пробовал смотреть лекции яндекса, оч интересно но мне видимо чего то не хватает для полного осознания. Возможно можете сами что то посоветовать? Книги? Лекции?
Все просто. У тебя есть сервис, есть методы сервиса дергай методы с параметрами и проверяй чего приходит. Сначала покрой простой флоу, потом переходи на сложные сценарии.
Посмотрите в сторону RobotFramework, он написан на python, и позволяет достаточно быстро писать тесты. Бибилотеки для него писать проще некуда
По поводу тестирования Soap веб-сервисов:
Проверки зависят очень сильно от реализации, требований и типа проверки, но для примера: отправляете запрос, если ответ пришел - проверяете его содержимое (по сути парсинг xml), если ответ не пришел или пришла ошибка - тест фейлится (только если вы не ожидаете что вернется ошибка или не будет ответа ), если запрос инициирует еще какие то действия на стороне сервера то проверяете и это, это может быть сохранение информации в БД, логирование и т.п.
Да, приблизительно так все и выглядит, как Вы представляете.
Логи обычно состоят из частей: краткий репорт по шагам и проверкам Pass/Fail/Error + детальный лог для анализа (состояние системы, развернутые отчеты об ошибках) + артефакты (например, дампы или иные массивы данных, полученные с веб-сервиса).
По поводу почитать - прогуглите ODT, DDT, KDT, BDD + типовые организации тест фреймворков. Это поможет привнести системность. Но не слишком впадайте в теоретизирование на начальном этапе, Вам ведь нужно первые результаты выдавать поскорее ))
Добрый вечер!
Спасибо за ответ, вопрос уже некоторое время лежит на сайте и за это время я поднакачался теорией, узнал примерную структуру своего теста (классы - тестовые алгоритмы, берут файлы в которых данные для тест кейса, потом проверка ответа), но я в небольшом тупике, ведь мне нужно будет собирать тест суиты(сценарии), но как тогда выбирать данные для серии запросов? Моя текущая структура предпологает независимость тестовых алгоритмов друг от друга, но в проекте(платежный шлюз) нужно проводить серию запросов…
В общем можно какой то комментари по поводу как связать воедино группу запросов и использование request data в таких сценариях.
Не уверен, что понял Ваш вопрос полностью. Попробую предположить.
Вам нужен data-driven, и при этом вы хотите привязать таблицы не к тесту, а сразу ко всей сьюите?
Если да, то скажите, каким образом они(сьюиты) у Вас организованы? Все-таки, предполагаю, что Вы имеете в виду что-то другое, так как выглядит непонятным, как будете использовать те же данные для разных тестов…
P.S. кто знает, как на этом сайте свои профили слить воедино?
Не могу ответить на вопрос, т.к. у самого нет четкого понимания… Ранее автотестами никогда не занимался и даже не видел их в глаза. У самого схожу пока чет не получаются, постоянно завожу себя в тупик(приходится часто переделывать). Можете посоветовать что-нибудь, если у меня цель покрыть тестами вебсервис json/xml? Есть 4-5 последовательных запросов, т.е. запрос зависит от ответа на предыдущий запрос.
В какую сторону копать?
по разработке полно информации а по автоматизации нет(
Я же для себя выбрал передачу параметров через Groovy Script.
Количество WSDL никак не мешает SoapUI передавать параметры между Step’ами
У нас на предыдущем проекте было 6-7 WSDL в некоторых по несколько десятков методов. Сценарии были многоступенчатыми с передачей UUID’ов и др. параметров между шагами.
Доходило до 20 шагов в сценарии для одной операции
И проблем с автоматизацией этого процесса не возникло.
Ответ прост. Я работаю младшим разработчиком и языки программирования мне ближе чем соапюи, я честно пытался в нем разобраться, но все время были фейлы, особенно с передачей параметров между степами, до сих пор не понимаю почему мой xpath не выбирал нужные поля, точнее в респонсе выделяет а в реквесте следующего степа не может.
Да и развиваться хочется как КУА ТА инженер, сейчас просматриваю фрейморвки готовые (самому пока не получается) на наличие возможности тестить бекенд, т.е. апи.
В SoapUI есть возможность писать на Java либо Groovy. Это полноценные языки программирования.
Проблем взять значения из Request’а или из Response не наблюдал. Точнее были кое-какие проблемы, но они оказались вполне решаемыми. Тем более они могут быть легко решаемы спициалистом, который позиционирует себя как “младший разработчик” и QA-специалист.
За SoapUI, если ему нормально научиться у вашей команды уже есть один несомненный плюс - он уже применяется на проекте. И он не будет “чудо-юдо” для других людей, особенно для ручных тестировщиков и их при должной сноровке можно подключать к разработке авто-тестов и к тому же будет легко из ручного теста делать автоматический. Нужно-то всего добавить несколько проверок будет и переносов параметров.
Странно, что вы пользуетесь этим инструментом для ручного тестирования и не смогли рассмотреть в нем потенциала для автоматизации. Есть сомнение, что вам подойдут и другие решения из готовых, в том числе и RobotFramework или JMeter (некоторые его используют вместо нагрузки для автоматизации).
У самопальных решений есть один минус - они “человекозависимы” и часто не известно насколько они будут “масштабируемы” и беспроблемны в будущем.
У SoapUI тоже есть минусы, в частности он много памяти выедает и на моей рабочей станции иногда требуется их запускать два экземпляра (снова-таки из-за другой проблемы в работе с двумя кодировками на одном проекте в двух разных “версиях”, когда требуется и старое поддержать и новое уметь). Есть и другие проблемы, но по удобству я для работы с сервисами пока ничего лучше не встречал. Может можно изучить еще что-то, но на текущем проекте мне это точно не потребуется потому что текущие потребности полностью покрываются текущим функционалом. Хотя пришлось и посидеть на “ненашинских” форумах и много гуглить вначале, чтобы решать те или иные заковыристые проблемы и искать более оптимальные решения. В том числе и как прикрутить его в Jazz и отбивать для отчетов перед руководством прохождение тестов и как работать с БД, и как работать не только с синхронными, но и с асинхронными сервисами через MQ, и как кодировать в Base64 и обратно и т.д. и т.п. Все эти проблемы решались! Нужно просто усердие, немного умения в программировании на Java/Groovy и умение находить ответы в Гугле.
testomat.io управление авто тестами