Что такое SOA-тестирование? Учебное пособие с примером
Томас Гамильтон
⚡ Умное резюме
Тестирование SOA подтверждает работоспособность сервисно-ориентированной архитектуры. ArchiАрхитектура, в которой слабо связанные сервисы обмениваются сообщениями по сети, проверяя каждый сервис в отдельности, интеграцию между ними и весь бизнес-процесс от начала до конца.
Что такое SOA-тестирование?
SOA (сервисно-ориентированный Archi(Текстура) Тестирование Это тестирование архитектурного стиля SOA, в котором компоненты приложения спроектированы для взаимодействия посредством коммуникационных протоколов, как правило, по сети.
Что такое СОА?
SOA — это метод интеграции бизнес-приложений и процессов для удовлетворения потребностей бизнеса.
In Программная инженерияSOA обеспечивает гибкость и адаптивность бизнес-процессов. Изменение процесса или приложения может быть направлено на конкретный компонент, не затрагивая всю систему.
Разработчики программного обеспечения, работающие в архитектуре SOA, либо разрабатывают, либо приобретают готовые блоки программ, называемые Услуги.
Что такое сервис?
На приведенной ниже схеме показан платежный шлюз, опубликованный как сервис, к которому могут обращаться несколько сайтов электронной коммерции.
- Сервис может представлять собой функциональную единицу приложения или бизнес-процесса, которую можно повторно использовать или воспроизводить в любом другом приложении или процессе. (Например, на изображении выше платежный шлюз — это сервис, который может быть повторно использован любым сайтом электронной коммерции. Всякий раз, когда необходимо совершить платеж, сайт электронной коммерции вызывает или запрашивает сервис платежного шлюза. После завершения платежа на шлюзе ответ отправляется обратно на сайт электронной коммерции.)
- Сервисы легко собирать и легко переконфигурировать компоненты.
- Сервисы можно сравнить со строительными блоками. Они позволяют создать любое необходимое приложение, и добавлять или удалять их из приложения или бизнес-процесса очень легко.
- Сервисы определяются скорее выполняемой ими бизнес-функцией, чем фрагментами кода.
Web-сервисы
Большинство SOA-сервисов предоставляются в виде веб-сервисов, поэтому механику вызова веб-сервиса стоит продумать до создания тестовых слоев.
Веб-службы являются независимыми компонентами приложения, доступными через Интернет.
Они могут быть опубликованы, найдены и использованы в интернете, и они взаимодействуют через интернет. Приведенная ниже последовательность показывает, как взаимодействуют поставщик услуг, реестр и потребитель.
- Поставщик услуг публикует услугу в Интернете.
- Клиент осуществляет поиск конкретного веб-сервиса в реестре веб-сервисов.
- A URL и WSDL Для требуемого веб-сервиса возвращаются данные. Используя WSDL и URLОбмен данными между поставщиком услуг и запрашивающей стороной происходит посредством SOAP-сообщений.
- Когда потребитель обращается к веб-сервису, устанавливается HTTP-соединение с провайдером.
- Создается SOAP-сообщение, которое дает указание поставщику вызвать необходимую логику веб-сервиса.
- Ответ, полученный от поставщика, представляет собой SOAP-сообщение, встроенное в HTTP-ответ. Этот HTTP-ответ имеет формат данных, понятный приложению-потребителю.
Пример
На скриншоте ниже показан прогноз погоды, предоставленный сторонним сервисом и встроенный на главную страницу поисковой системы.
На главной странице веб-сайта и в поисковой системе отображается ежедневный прогноз погоды. Вместо того чтобы писать код для раздела с прогнозом погоды с нуля, можно приобрести готовый сервис прогноза погоды у поставщика и интегрировать его в страницы.
Слои тестирования SOA
SOA состоит из различных технологий, и приложения, построенные с использованием SOA, имеют множество слабо связанных между собой сервисов. На диаграмме ниже показаны три уровня, которые должен охватывать план тестирования.
Тестирование SOA должно быть сосредоточено на трех уровнях системы.
Уровень услуг
Этот слой состоит из сервисов, предоставляемых системой и вытекающих из бизнес-функций.
Например, рассмотрим веб-сайт о здоровье и благополучии, который включает в себя:
- Вес Tracкег
- Кровавый Сахар Tracкег
- Кровяное давление Tracкег
TracКомпоненты отображают соответствующие данные и дату их ввода. Уровень сервисов состоит из сервисов, которые получают соответствующие данные из базы данных:
- Вес Tracсервис кер
- Кровавый Сахар Tracсервис кер
- Кровяное давление Tracсервис кер
- Служба входа в систему
Уровень процесса
Слой процессов состоит из процессов, представляющих собой совокупность сервисов, являющихся частью единой функциональности.
Эти процессы могут быть частью пользовательского интерфейса (например, поисковой системы) или частью инструмента ETL, который извлекает данные из базы данных.
Основное внимание на этом уровне уделяется пользовательским интерфейсам и процессам. Пользовательский интерфейс веса tracОсновное внимание уделяется Ker и его интеграции с базой данных.
Следует учитывать следующие функции:
- Добавление новых данных
- Редактирование существующих данных
- Создание нового tracкег
- Удаление данных
Потребительский уровень
Этот слой в основном состоит из пользовательских интерфейсов, как показано на скриншоте ниже.
Исходя из этих уровней, тестирование SOA-приложения распределяется на три этапа:
- Уровень обслуживания
- Уровень интерфейса
- Конечный уровень
Два направления движения различаются: подход «сверху вниз» используется для проектирования тестов, а подход «снизу вверх» — для их выполнения.
Стратегия тестирования SOA
Подход к планированию тестирования
- Тестировщики SOA должны понимать полную архитектуру приложения.
- Приложение необходимо разбить на независимые сервисы (сервис, имеющий собственную структуру запросов и ответов и не зависящий от каких-либо других сервисов для формирования ответа).
- Структуру приложения необходимо реорганизовать, разделив её на три компонента: данные, сервисы и интерфейсные приложения.
- Необходимо тщательно проанализировать все компоненты и разработать бизнес-сценарии.
- Бизнес-сценарии следует разделить на общие и специфические для конкретного приложения.
- A TracМатрица возможностей должны быть подготовлены, и все тестовые примеры должны быть tracотнесено к бизнес-сценариям.
Подход к выполнению теста
- Каждый компонент службы должен быть протестирован.
- Интеграционное тестирование компонентов службы необходимо выполнить для проверки потока данных через службы и целостности данных.
- Тестирование системы Для проверки потока данных между фронтенд-приложением и базой данных необходимо провести полную проверку модели.
- Тестирование производительности необходимо выполнить для точной настройки и оптимальной производительности.
Методы тестирования SOA
1) Тестирование на основе данных, ориентированное на бизнес-сценарии.
- Необходимо проанализировать различные аспекты ведения бизнеса, связанные с данной системой.
- Сценарии следует разрабатывать на основе интеграции различных веб-сервисов приложения, а также веб-сервисов с приложением.
- Настройка данных должна производиться с учетом вышеописанных сценариев.
- Настройка данных также должна охватывать все сквозные сценарии.
2) Заглушки
- Для тестирования сервисов создаются фиктивные интерфейсы.
- Через эти интерфейсы можно предоставлять различные входные данные, а выходные данные можно проверять.
- Если приложение использует интерфейс к внешнему сервису, который не тестируется (сторонний сервис), то в процессе интеграционного тестирования можно создать заглушку.
3) Регрессионное тестирование
- Регрессионное тестирование Обновление приложения следует проводить при наличии нескольких релизов, чтобы обеспечить стабильность и доступность системы.
- Будет создан комплексный набор регрессионных тестов, охватывающий службы, которые составляют важную часть приложения.
- Этот набор тестов можно использовать повторно в нескольких релизах проекта.
4) Тестирование уровня обслуживания
Тестирование на уровне сервиса включает проверку компонента на функциональность, безопасность, производительность и совместимость. Каждый сервис должен быть сначала протестирован независимо.
5) Функциональное тестирование
Функциональное тестирование Это следует делать для каждой службы, чтобы:
- Убедитесь, что сервис выдает правильный ответ на каждый запрос.
- Убедитесь, что для запросов с недопустимыми или некорректными данными выдаются правильные сообщения об ошибках.
- Проверяйте каждый запрос и ответ для каждой операции, которую сервис должен выполнить во время выполнения.
- Проверьте сообщения об ошибках, возникающих на уровне сервера, клиента или сети.
- Убедитесь, что полученные ответы имеют правильный формат.
- Убедитесь, что данные, полученные в ответе, соответствуют запрошенным данным.
6) Тестирование безопасности
Тестирование безопасности веб-сервиса является важным аспектом тестирования на уровне сервиса в SOA-приложении, поскольку оно обеспечивает безопасность приложения.
При тестировании необходимо учитывать следующие факторы:
- Веб-сервис должен соблюдать отраслевой стандарт, определенный WS-Security.
- Меры безопасности должны работать безупречно.
- Шифрование данных и цифровые подписи на документах.
- Аутентификация и авторизация.
- На платформе будут проведены тесты на уязвимости, связанные с SQL-инъекциями, вредоносным ПО, XSS, CSRF и другими угрозами. XML.
- Атаки отказа в обслуживании.
7) Тестирование производительности
Необходимо проводить тестирование производительности сервиса, поскольку сервисы являются многократно используемыми, и несколько приложений могут использовать один и тот же сервис.
При тестировании учитываются следующие факторы:
- Работоспособность и функциональность сервиса необходимо тестировать под большой нагрузкой.
- Необходимо сравнить производительность сервиса при его работе в автономном режиме и в составе приложения.
- Тестирование нагрузки Для проверки времени отклика, выявления узких мест, оценки использования ЦП и памяти, а также для прогнозирования масштабируемости необходимо провести соответствующие проверки сервиса.
8) Тестирование уровня интеграции
- Тестирование на уровне сервисов обеспечивает корректную работу отдельных сервисов; оно не гарантирует работу связанных между собой компонентов.
- Интеграционное тестирование проводится с упором в основном на интерфейсы.
- Этот этап охватывает все возможные бизнес-сценарии.
- На этом этапе следует еще раз провести нефункциональное тестирование приложения. Тестирование безопасности, соответствия стандартам и производительности обеспечивает доступность и стабильность системы во всех аспектах.
- Протоколы связи и сетевые протоколы должны быть протестированы для проверки согласованности передачи данных между службами.
9) Сквозное тестирование
На этом этапе обеспечивается соответствие приложения бизнес-требованиям как с функциональной, так и с нефункциональной точки зрения.
Все перечисленные ниже предметы будут проверены в ходе сквозное тестирование:
- Все сервисы работают как положено после интеграции
- Обработка исключений
- Пользовательский интерфейс приложения
- Правильный поток данных через все компоненты
- Бизнес-процесс
Проблемы тестирования SOA
Применение этих методов редко бывает простым, и описанные ниже трудности повторяются практически в каждой программе SOA.
- Отсутствие интерфейсов для сервисов.
- Процесс тестирования охватывает множество систем, что создает сложные потребности в данных.
- Приложение представляет собой набор различных компонентов, которые имеют тенденцию к изменению, поэтому необходимость в регрессионном тестировании возникает чаще.
- Из-за многослойной архитектуры сложно изолировать дефекты.
- Поскольку сервис используется различными интерфейсами, предсказать нагрузку сложно, что затрудняет планирование тестирования производительности.
- SOA — это набор разнородных технологий. Тестирование SOA-приложения требует участия специалистов с различными навыками, что, в свою очередь, увеличивает затраты на планирование и выполнение.
- Поскольку приложение объединяет множество сервисов, тестирование безопасности сопряжено со своими трудностями. Проверка аутентификации и авторизации представляет собой сложную задачу.
Инструменты тестирования SOA
На рынке представлено множество инструментов для тестирования SOA-приложений, помогающих тестировщикам в этом процессе. Вот некоторые из популярных инструментов тестирования SOA.
1) SoapUI
SoapUI — это инструмент функционального тестирования сервисов с открытым исходным кодом. API тестирование.
- Настольное приложение
- Поддерживает множество протоколов — SOAP, REST, HTTP, JMS, AMF, JDBC.
- Веб-сервисы можно разрабатывать, проверять и вызывать.
- Также может использоваться для испытаний под нагрузкой. Автоматизация тестированияи тестирование безопасности
- Заглушки могут создаваться с помощью MockServices.
- Запросы и тесты веб-сервиса могут генерироваться автоматически через его клиент веб-сервиса.
- Имеет встроенные инструменты для создания отчетов.
- Разработан компанией SmartBear, которая занимается поставкой как... открытые источники SoapUI дистрибуция и коммерция ReadyAPI edition
2) Виртуализация сервисов Broadcom (ранее iTKO LISA)
LISA — это набор продуктов, предоставляющий решение для функционального тестирования распределенных систем, таких как SOA. Продукт перешел от iTKO к CA Technologies и сегодня продается под названием Broadcom Service Virtualization.
- Также может использоваться для регрессионного, интеграционного, нагрузочного и производительного тестирования.
- Может использоваться для разработки и выполнения тестов.
3) UFT One (ранее HP Service Test)
Service Test — это инструмент функционального тестирования, поддерживающий как тестирование пользовательского интерфейса, так и тестирование общих сервисов. Его возможности тестирования API были интегрированы в Unified Functional Testing, который теперь продается компанией [название компании]. OpenText as UFT Один.
- Функциональное тестирование и тестирование производительности сервисов можно выполнить с помощью одного скрипта.
- Интегрирован с Quality Center, теперь продается как OpenText ALM / Центр качества.
- Можно управлять огромным объемом сервисов и данных.
- Поддерживает тестирование совместимости путем моделирования клиентских сред JEE, AXIS и DotNet.
4) Parasoft SOAtest
Parasoft SOAtest — это набор инструментов для тестирования и анализа, разработанный для тестирования API и приложений, управляемых API.
- Поддерживает веб-сервисы, REST, JSON, MQ, JMS, TIBCO, HTTP и технологии XML.
- Возможно функциональное, модульное, интеграционное, регрессионное тестирование, тестирование безопасности, совместимости, соответствия стандартам и производительности.
- Заготовки можно создавать с помощью Parasoft Virtualizeкоторые более способны, чем SoapUI MockServices.
Варианты использования SOA-тестирования
Приведенный ниже пример поэтапно применяет описанную выше стратегию, методы и инструменты к одному сайту электронной коммерции.
Рассмотрим веб-сайт электронной коммерции, содержащий перечисленные ниже функции и подфункции.
Обработка заказов
Приведенная ниже диаграмма разбивает процесс обработки заказов на подфункции, которые затем становятся услугами.
ФАЗА 1
На первом этапе тестирования SOA, этапе разработки стратегии тестирования, приложение разбивается на сервисы и бизнес-функции.
Рассмотрим нижеперечисленные услуги в приложении.
- Создать заказ
- Проверьте статус клиента
- Изменить статус заказа
- Проверить статус заказа
- Посмотри инвентарь
Функции, лежащие в основе бизнеса, совпадают с функциями веб-сайта.
Примечание: Документ со стратегией тестирования должен содержать список сервисов и функций, которые необходимо протестировать.
ФАЗА 2
Это этап планирования тестирования. Испытательные случаи Для каждого уровня написаны соответствующие инструкции.
Комплексный уровень. Для каждого бизнес-сценария и сценария использования написаны тестовые примеры. Ниже приведены примеры тестовых примеров.
- Создайте заказ с участием активного пользователя.
- Создайте заказ с неактивным пользователем.
- Создайте заказ с имеющимся в наличии товаром, при этом количество заказанных товаров должно быть меньше имеющегося в наличии количества.
- Создайте заказ с имеющимся в наличии товаром, при этом количество товара в заказе должно превышать количество товара в наличии.
- Создайте заказ, включающий несколько товаров.
- Полностью отменить заказ.
- Частично отменить заказ.
Уровень интеграции. Тестовые примеры пишутся для интеграции базы данных и пользовательского интерфейса. Ниже приведены примеры тестовых примеров.
- Создайте новый заказ с одним товаром. Убедитесь, что заказ создан в базе данных.
- Создайте новый заказ с одним товаром. Убедитесь, что цена, рассчитанная для заказа, верна.
- Создайте новый заказ с одним товаром. Убедитесь, что количество доступного товара уменьшено на сумму заказа.
- Убедитесь, что статус заказа, отображаемый в пользовательском интерфейсе, совпадает со статусом в базе данных.
- Отмените заказ и убедитесь, что статус заказа изменен в базе данных.
- При первой оплате убедитесь, что введенные в пользовательский интерфейс платежные данные сохранены в базе данных.
- Для возврата платежей убедитесь, что сведения о платеже в базе данных отображаются в пользовательском интерфейсе.
Уровень обслуживания. Каждый сервис тестируется на соответствие всем условиям обработки данных. Ниже приведены несколько примеров.
| № | Детали Заказа | Условия заказа |
|---|---|---|
| 1 | Создать заказ. Кол-во предметов = 1 | Количество в заказе < Количество в базе данных |
| 2 | Создать заказ. Количество предметов > 1 | Количество в заказе < Количество в базе данных |
| 3 | Создать заказ. Кол-во предметов = 1 | Количество в заказе > Количество в базе данных |
| 4 | Проверить статус заказа | Статус в базе данных = Активный |
| 5 | Проверить статус заказа | Статус в базе данных = Отправлено. |
| 6 | Проверить статус заказа | Статус в базе данных = Отменено |
| 7 | Проверить статус заказа | Идентификатор заказа = Недействительный |
| 8 | Проверить наличие товара | Количество товара >0 |
| 9 | Проверить наличие товара | Количество товара =0 |
| 10 | Проверить наличие товара | Идентификатор продукта = недействителен |
Этап 3 — Выполнение тестов
При выполнении тестирования используется подход «снизу вверх»: сначала проводится тестирование на уровне сервисов, затем на уровне интеграции, и, наконец, сквозное тестирование.
1) Уровень обслуживания
Рассмотрим тот факт, что SoapUI Этот инструмент используется для тестирования приложения. WSDL и URL просматриваются в тестовом окне SoapUIЗапрос для каждой услуги отображается в окне запросов. Путем изменения данных в соответствии с тестовыми сценариями уровня сервиса создаются запросы для каждого тестового сценария.
| Тестовый кейс | Запрос | Ожидаемый ответ |
|---|---|---|
| Создать заказ. Количество товаров = 1, Количество в заказе < Количество в базе данных. | х2 2 | о3251 Успешный |
| Создать заказ. Количество товаров > 1, количество в заказе < количество в базе данных. | у1 1 у2 3 | о3251 Успешный |
| Создать заказ. Количество товаров = 1, Количество в заказе > Количество в базе данных. | х23 200 | нулевой Неудачный |
| Проверьте статус заказа. Статус в базе данных = Активный | о9876 | Активный Успешный |
| Проверьте статус заказа. Статус в базе данных = Отправлено | о9656 | Отправленный Успешный |
| Проверить статус заказа. Идентификатор заказа = Недействительный | y5686 | нулевой Неудачно |
| Проверьте наличие товара. Количество товара > 0 | д34 | 34 да Успешный |
| Проверьте наличие товара. Количество товара = 0 | y34 | 0 нет Успешный |
| Проверить наличие товара. Идентификатор товара = недействителен. | Сдер | Неудачный |
2) Уровень интеграции
Тестовые сценарии интеграционного уровня выполняются для пользовательского интерфейса и базы данных. Создайте заказ с одним товаром:
- Пользователь открывает сайт.
- Пользователь переходит к оформлению заказа.
- Пользователь выбирает подходящий товар и количество, а затем сохраняет заказ.
- Должно отобразиться сообщение об успешном оформлении заказа.
- Пользователь открывает базу данных и проверяет, совпадают ли данные заказа с данными, введенными на сайте.
3) Сквозной уровень
Бизнес-процессы и сценарии использования реализуются в пользовательском интерфейсе. Создайте заказ с несколькими товарами:
- Пользователь открывает сайт.
- Пользователь переходит к оформлению заказа.
- Пользователь запрашивает информацию о подходящем товаре и его количестве и добавляет его в корзину.
- Добавляются другие подходящие товары в подходящем количестве, и заказ сохраняется. Оплата производится новым способом, и заказ оформляется.
- Должно появиться сообщение «Заказ размещен успешно».
- Тестировщик должен убедиться, что весь процесс завершается без искажения данных.
