Подтвердить что ты не робот

Автоматизация Тестирование веб-сервисов

Я работаю в команде Midtier, и я довольно много тестировал веб-сервисы. Ручное использование интерфейса SOAP. У меня возникла задача получить автоматическую проверку регрессионного теста. Сейчас у нас нет команды Automation, и поэтому мне предоставляется полная свобода использования любого инструмента, который я хочу, и пусть мой менеджер знает, какой инструмент подходит хорошо. Но мне еще предстоит изучить Automation Testing. Какие-либо предложения, которые будут хорошим инструментом для тестирования автоматизации Midtier? У нас есть много сервисов, где мы проверяем результаты с результатами в SAP. Например, если я тестирую цену на предмет в Midtier, я должен проверить, соответствует ли цена возвращенной цене в SAP. Я делал это вручную, когда я вхожу в SAP, переходя к предоставленному коду транзакции и проверяя цену для этого элемента, может кто-нибудь подумать о каком-либо хорошем инструменте автоматизации тестирования, где я могу справиться с такой ситуацией?

4b9b3361

Ответ 1

Я работаю по аналогичной просьбе. Поскольку клиент уже автоматизировал некоторые из сервисов с помощью soapUI (ОС), моя работа немного сложнее.

В версии ОС нет источника данных, шаги тестирования цикла данных для создания набора тестов с управлением данными, но всегда есть работа.

Вы можете использовать даже версию с открытым исходным кодом для реализации трех видов распространенных систем автоматизации.

  • Action Driven framework. Чтобы применить эту среду для soapUI, вам нужно определить некоторые общие этапы тестирования при настройке, выполнении и проверке службы. После того, как они идентифицированы, отделите их в тестовом наборе и/или тестовых примерах и просто вызовите соответствующий тестовый пакет/тестовый шаг.

    Например: У меня есть тестовый шаг, который подтвердил, что служба заказа была сделана в db службой, поэтому я создам тестовый набор + тестовый пример и добавлю тестовый шаг jdbc для поиска идентификатора заказа на основе данных, которые я поставляю, Запрос будет параметризован. В фактическом script я запустим службу и выберу все значения, необходимые для запуска db-запроса. Эти значения будут переданы в многоразовый тестовый пример с использованием тестового тестового теста.

    Несколько вещей, которые следует помнить, - это если у вас есть большое количество тестовых примеров/параметров, и подумайте, что нужно будет изменить сервис, а затем поместить параметры в файл excel и загрузить их с помощью groovy из набора тестов setup script.

    Вам понадобится scriptom api для работы с excel или Jxl (немного более сложная реализация)

  • Основанный на данных фреймворк, в этой структуре вы в основном определяете другой сценарий, который вы хотите запустить в службе, и заполняете excel соответствующими данными, затем используя groovy и scriptom или jexcel или jxl api через все строк в excel и выполнять сервис с различными элементами данных. Этот подход можно сделать настолько сложным, насколько вам нравится, и так просто, как вы хотите.

  • Основанная на ключевых словах структура - это, вероятно, самые сложные рамки для всех, поскольку она требует, чтобы вы много планировали, разрабатывали и тому подобное. В настоящее время я разрабатываю такую ​​структуру. Я бы поделился некоторыми деталями с вами, если бы не было соглашений о конфиденциальности.

Я также понимаю, что вы новичок в groovy, вы должны проверить soapUI и groovy сайт, у них есть много действительно хороших примеров и помните, что всегда есть stackoverflow, чтобы отвечать на ваши запросы.

Сообщите мне, как вы это делаете.

Ответ 2

То, что мы делали во время большого проекта, связано со многими связанными устаревшими системами (200+ услуг):

  • для каждой службы мы создали проекты SoapUI с соответствующими утверждениями, отражающими доброту службы (возможность подключения, функциональность и т.д.).
  • мы создали Hudson, чтобы запустить список этих проектов SoapUI для этих сервисов. Все выполненные службы регистрируются (запрос, ответ)
  • мы создали задания ant для анализа зарегистрированных ответов и создания ежедневного отчета (также выполняемого на Hudson)

Мы также коснулись асинхронных сервисов путем поиска шаблонов в журналах сервера. Здесь важно иметь соглашение о создании проекта SoupUI (имена, необходимые утверждения и т.д.).

Ответ 3

То, что я сделал в подобной ситуации (необходимо было протестировать очень сложное стороннее приложение, которое, как правило, имело повторяющиеся проблемы с качеством): я написал некоторые модульные тесты, используя обычную среду JUnit 4, но вместо тестирования локальных классов Java, Я выполнил вызовы веб-службы и проверил ответ. Если вам нужно проверить результаты по отношению к серверу SAP R/3, это возможно также с помощью Java Connector (JCo), доступного из http://service.sap.com/connectors, Недостаток - вам, очевидно, нужно знать, как тестировать код в Java.

Ответ 4

Вы можете использовать Soap-UI Pro, если хотите автоматизировать тестирование регрессии веб-сервисов. Автоматизация довольно проста в soapui, я работаю над одним и тем же. Я автоматизировал свой веб-сервис для интеграции всех рейсов с помощью мыла ui. Вы можете использовать groovy язык сценариев для сложных сценариев.

Спасибо, Hanumant

Ответ 5

Если ваши веб-сервисы являются REST, просто запишите сначала с экспортом REST Client (Chrome Plugin) с Maven. Создайте проект Maven и добавьте плагин exp:

<plugin>
    <groupId>com.restlet.client</groupId>
    <artifactId>maven-plugin</artifactId>    
    <version>2.3.0.1</version>
    <executions>
        <execution>
            <phase>test</phase>
            <goals>
                <goal>test</goal>
            </goals>   
            <configuration>
                <file>API_Testing.json</file>
                <selectedEnvironment>Staging</selectedEnvironment>
                <licenseKey/>
            </configuration>
        </execution>
    </executions>
</plugin>