SOA-тестирование

Question

Чем SOA-тестирование отличается от традиционного тестирования приложения

Answer 1

Поскольку каждый «поставщик услуг» должен иметь стандартный бизнес-ориентированный интерфейс (обычно предоставляемый с технологией WSDL), следующие свойства могут отличаться:

• Предоставляемые услуги не должны переходить от пересмотра к пересмотру модулей, если вы не вносите значительные изменения в сам бизнес.

• Модуль не должен заботиться о том, кто его клиенты, что облегчает тестирование модуля.

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

Edit:

• И, как уже указывали другие, вам необходимо проверять соответствие спецификации, а не если существующие компоненты системы работают друг с другом. Например, веб-страница может нормально отображаться в Internet Explorer, но при этом не соответствовать спецификации и, следовательно, может быть непригодна для других браузеров. Когда вы переходите на SOA, вы ожидаете, что сможете смело заменить поставщиков услуг.

Answer 2

Обычно тесты службы SOA представляют собой черный ящик , где вы используете только рассмотренный опубликованный контракт WSDL, однако иногда бывает необходимо провести прямую проверку в базах данных, особенно когда нет возможности (операции), которая может быть использован для проверки.

Кроме того, поскольку современные платформы SOA обычно совместно используют ресурсы с реализацией других сервисов, важно моделировать нагрузку обработки, превышающую или равную объему производства, и оценивать влияние потребления памяти, обработки и ввода-вывода, избегая отрицательных значений. влияние на уже развернутые услуги.

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

• несовместимый синтаксис: версия нового контракта версия может иметь новый элемент, но не может иметь новые обязательные элементы , потому что это сломает старых клиентов, такого рода Обычно эту проблему можно избежать, запустив автоматизированные тесты , реализованные с как текущими, так и новыми контрактами .
• абстракция проверки: часто каноническая модель (XML-схемы) используется совместно с несколькими службами во избежание преобразования типов и обеспечения общего бизнес-языка, обычно они не имеют все проверки, необходимые для всех операций обслуживания. Затем необходимая логика проверки выполняется непосредственно в реализации службы . Если новая версия службы реализует новый набор проверок, которых нет в опубликованном контракте, клиенты должны быть уведомлены, а сценарии должны быть проверены.

Инструменты, которые я обычно использую: SOAP UI и JMeter , и создают пользовательские автоматизированные тесты с использованием собственной инфраструктуры.

Answer 3

Soa-тестирование просто гарантирует, что все независимые сервисы ведут себя ожидаемым образом, при этом соблюдая контракт на ввод и вывод, установленный этими сервисами. Я нашел интересный инструмент для тестирования SOA, и это БЕСПЛАТНО SOArite .

Answer 4

SOA-тестирование можно определить как расширение традиционного тестирования.

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

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

Answer 5

Несколько (ценных?) Советов:

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

Проверьте надежность ваших потребителей: что происходит, когда сообщения теряются, когда поставщик услуг недоступен.

Answer 6

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

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

С услугами вам также необходимо обратить внимание на проблемы с сетью. Проведите традиционные тесты, помещая большой трафик в сеть, и отключитесь, чтобы посмотреть, как он работает.

Кроме того, для получения услуг не требуется иной подход. Просто контролируйте все входы и выходы.