Что такое тестирование SOA? Учебник с примером

Что такое тестирование SOA?

Тестирование SOA (сервис-ориентированной архитектуры) - это тестирование архитектурного стиля SOA, в котором компоненты приложения предназначены для взаимодействия через протоколы связи, как правило, по сети.

В этом руководстве вы узнаете:

• Что такое SOA?
• Что такое Сервис?
• SOA тестирование
• Стратегия тестирования SOA
• Методы тестирования SOA
• Проблемы при тестировании SOA
• Инструменты тестирования SOA
• Примеры использования тестирования SOA

Что такое SOA?

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

В программной инженерии SOA обеспечивает гибкость и гибкость бизнес-процессов. Изменения в процессе или приложении могут быть направлены на конкретный компонент, не затрагивая всю систему.

Разработчики программного обеспечения в SOA либо разрабатывают, либо покупают фрагменты программ, называемых СЛУЖБАМИ.

Что такое Сервис?

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

  (Например, на изображении выше, Платежный шлюз - это услуга, которую можно повторно использовать на любом сайте электронной коммерции. Всякий раз, когда необходимо произвести платеж, сайт электронной коммерции вызывает / запрашивает сервис Платежного шлюза. После того, как оплата будет произведена на шлюз, ответ отправляется на сайт электронной коммерции)
• Сервисы легко собрать и легко перенастроить компоненты.
• Услуги можно сравнить со строительными блоками. Они могут создать любое необходимое приложение. Добавить и удалить их из приложения или бизнес-процесса очень просто.
• Сервисы определяются больше бизнес-функцией, которую они выполняют, а не фрагментами кода.

Веб-сервисы

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

Их можно опубликовать, найти и использовать в сети. Они могут общаться через Интернет.

1. Поставщик услуг публикует услугу в Интернете.
2. Клиент ищет конкретную веб-службу в Реестре веб-служб.
3. Возвращается URL-адрес и WSDL для требуемой веб-службы.

   >> Используя WSDL и URL-адрес, связь между поставщиком услуг и запрашивающей стороной происходит через сообщения SOAP. <<

4. Когда потребитель вызывает веб-службу, с поставщиком устанавливается HTTP-соединение.

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

5. Ответ, полученный от поставщика, представляет собой сообщение SOAP, которое будет встроено в ответ HTTP. Этот HTTP-ответ представляет собой формат данных, понятный для приложения-потребителя.

Пример

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

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

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

SOA-тестирование должно быть сосредоточено на трех системных уровнях.

Уровень услуг

Этот уровень состоит из сервисов, сервисов, предоставляемых системой, производных от бизнес-функций.

Например -

Рассмотрим оздоровительный веб-сайт, состоящий из

1. Трекер веса
2. Трекер сахара в крови
3. Трекер артериального давления

Трекеры отображают соответствующие данные и дату их ввода. Слой служб состоит из служб, которые получают соответствующие данные из базы данных.

• Сервис отслеживания веса
• Сервис отслеживания уровня сахара в крови
• Служба отслеживания артериального давления
• Служба входа в систему

Уровень процесса

Уровень процессов состоит из процессов, совокупности сервисов, которые являются частью единой функциональности.

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

Основное внимание на этом уровне будет уделяться пользовательским интерфейсам и процессам.

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

Ниже будут рассмотрены функции

1. Добавление новых данных
2. Редактирование существующих данных
3. Создание нового трекера
4. Удаление данных

Потребительский уровень

Этот уровень в основном состоит из пользовательских интерфейсов.

В зависимости от уровня тестирование приложения SOA распределяется на три уровня.

1. Уровень обслуживания
2. Уровень интерфейса
3. От конца до конца уровня

• При разработке тестов используется подход «сверху вниз».
• Для выполнения теста используется подход «снизу вверх».

Стратегия тестирования SOA

Подход к планированию тестирования,

• Тестировщики SOA должны понимать полную архитектуру приложения.
• Приложение необходимо разбить на независимые службы (служба, которая имеет свою собственную структуру запроса и ответа и не зависит от какой-либо другой службы для формирования ответа).
• Структуру приложения необходимо реорганизовать на три компонента - данные, службы и интерфейсные приложения.
• Все компоненты должны быть тщательно проанализированы, а бизнес-сценарии должны быть расписаны.
• Бизнес-сценарии следует классифицировать как общие сценарии и сценарии для конкретных приложений.
• Должна быть подготовлена ​​матрица прослеживаемости, и все тестовые примеры должны быть сопоставлены с бизнес-сценариями.

Подход к выполнению теста

• Каждый сервисный компонент должен быть протестирован.
• Интеграция Необходимо провести тестирование компонентов службы для проверки потока данных через службы и целостности данных.
• Системное тестирование всей модели должно быть выполнено для проверки потока данных между клиентским приложением и базой данных.
• Тестирование производительности должно быть выполнено для точной настройки и оптимальной производительности.

Методы тестирования SOA

1) Тестирование на основе данных на основе бизнес-сценариев,

• Следует проанализировать различные бизнес-аспекты, связанные с системой.
• Сценарии следует разрабатывать на основе интеграции
  • Различные веб-сервисы приложения
  • Веб-сервисы и приложения.
• Настройка данных должна производиться на основе описанных выше сценариев.
• Данные должны быть настроены таким образом, чтобы охватить сквозные сценарии.

2) Заглушки

• Для тестирования сервисов будут созданы фиктивные интерфейсы.
• Через эти интерфейсы могут быть предоставлены различные входные данные, а выходы могут быть подтверждены.
• Когда приложение использует интерфейс с внешней службой, которая не тестируется (сторонняя служба), во время тестирования интеграции может быть создана заглушка.

3) Регрессионное тестирование

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

4) Тестирование уровня обслуживания

Тестирование уровня обслуживания включает в себя тестирование компонента на функциональность, безопасность, производительность и совместимость.

Каждую услугу необходимо сначала протестировать независимо.

5) Функциональное тестирование

Функциональное тестирование должно проводиться для каждой службы, чтобы

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

6) Тестирование безопасности

Тестирование безопасности веб-службы - важный аспект во время тестирования уровня обслуживания приложения SOA; это обеспечивает безопасность приложения.

Во время тестирования необходимо учитывать следующие факторы:

• Отраслевой стандарт, определенный при тестировании WS-Security, должен соблюдаться веб-службой.
• Меры безопасности должны работать безупречно.
• Шифрование данных и электронные подписи на документах
• Аутентификация и авторизация
• SQL Injection, Malware, XSS, CSRF, другие уязвимости должны быть протестированы на XML.
• Атаки отказа в обслуживании

7) Тестирование производительности

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

При тестировании учитываются следующие факторы:

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

9) Тестирование уровня интеграции

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

10) Сквозное тестирование

Этот этап гарантирует, что приложение соответствует бизнес-требованиям как функционально, так и нефункционально.

Приведенные ниже элементы должны быть проверены во время сквозного тестирования.

• После интеграции все сервисы работают должным образом
• Обработка исключений
• Пользовательский интерфейс приложения
• Правильный поток данных через все компоненты
• Бизнес-процесс

Проблемы при тестировании SOA

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

Инструменты тестирования SOA

На рынке доступно множество инструментов тестирования SOA, которые помогают тестировщикам в тестировании приложений SOA. Вот некоторые из популярных инструментов тестирования SOA :

1) пользовательский интерфейс SOAP

«SOAP UI» - это инструмент функционального тестирования с открытым исходным кодом для тестирования служб и API.

• Настольное приложение
• Поддерживает несколько протоколов - SOAP, REST, HTTP, JMS, AMF, JDBC
• Веб-сервисы можно разрабатывать, проверять и вызывать.
• Также можно использовать для нагрузочного тестирования, автоматического тестирования и тестирования безопасности.
• Заглушки могут быть созданы MockServices
• Запросы и тесты веб-службы могут быть созданы автоматически через клиент веб-службы.
• Встроенные инструменты отчетности
• Разработано SmartBear

2) iTKO LISA

«LISA» - это набор продуктов, который предоставляет решение для функционального тестирования распределенных систем, таких как SOA.

• Также можно использовать для регрессии, интеграции, нагрузочного тестирования и тестирования производительности.
• Разработано iTKO (CA Technologies)
• Может использоваться для разработки и выполнения тестов.

3) Сервисный тест HP

«Service Test» - это инструмент функционального тестирования, который поддерживает тестирование как пользовательского интерфейса, так и общих сервисов.

• Функциональный тест и тест производительности сервисов можно выполнить с помощью одного скрипта.
• Интегрирован с HP QC.
• Можно управлять огромным объемом услуг и данных.
• Поддерживает тестирование совместимости путем моделирования клиентских сред JEE, AXIS и DotNet.
• Разработано HP.

4) Тест Parasoft SOA

SOA Test - это набор инструментов для тестирования и анализа, разработанный для тестирования API и приложений API.

• Поддерживает веб-службы, REST, JSON, MQ, JMS, TIBCO, HTTP, XML.
• Возможны функциональные тесты, тесты модулей, интеграции, регрессии, безопасности, взаимодействия, соответствия и производительности.
• Заглушки можно создавать с помощью Parasoft Virtualize, которые интеллектуальнее, чем пользовательский интерфейс SOAP.
• Разработано ParaSoft

Примеры использования тестирования SOA

Рассмотрим веб-сайт электронной коммерции, который содержит следующие функции и подфункции:

Обработка заказов

ФАЗА 1

На первом этапе тестирования SOA, т. Е. На этапе стратегии тестирования, приложение разбивается на службы и бизнес-функции.

Давайте рассмотрим ниже представлены Сервисы в приложении.

• Создать заказ
• Проверить статус клиента
• Изменить статус заказа
• Проверить статус заказа
• Посмотри инвентарь

Деловые функции идентичны функциям Веб-сайта.

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

ФАЗА 2

Фаза планирования тестирования. Тестовые случаи написаны для каждого уровня.

1. От конца до конца уровня. Тестовые примеры написаны для каждого бизнес-сценария и потока.

   Ниже приведены примеры тестовых случаев.

   • Создайте заказ с активным пользователем.
   • Создайте заказ с неактивным пользователем.
   • Создайте заказ с доступным продуктом с количеством заказа <доступное количество.
   • Создайте заказ с доступным продуктом с количеством заказа> доступное количество.
   • Создайте заказ с несколькими товарами
   • Отменить заказ полностью.
   • Частично отменить заказ.
2. Уровень интеграции. Тестовые примеры написаны для интеграции базы данных и пользовательского интерфейса.

   Ниже приведены примеры тестовых случаев.

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

Ниже приведены несколько примеров.

Нет.	Информация для заказа	Условие заказа
1	Создать заказ. Кол-во пунктов = 1	Количество в заказе <Количество в базе данных
2	Создать заказ. Кол-во пунктов> 1	Количество в заказе <Количество в базе данных.
3	Создать заказ № позиций = 1	Количество по заказу> Количество в базе данных
4	Проверить статус заказа	Статус в базе данных = Активен
5	Проверить статус заказа	Статус в базе данных = Отправлено
6	Проверить статус заказа	Статус в базе данных = Отменено
7	Проверить статус заказа	Идентификатор заказа = Недействительный
8	Проверить наличие товара	Количество товара> 0
9	Проверить наличие товара	Количество товара = 0
10	Проверить наличие товара	Идентификатор продукта = недопустимый

ФАЗА 3 - Выполнение теста

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

1) Уровень обслуживания

Будем считать, что инструмент Soapui предназначен для тестирования приложения.

WSDL и URL просматриваются в тестовом окне SOAP.

Запрос для каждой услуги будет отображаться в окне запроса.

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

Прецедент	Запрос	Ожидаемый ответ
Создать заказ. Количество позиций = 1 Количество в заказе <Количество в дБ	x2 2	o3251 Успешно
Создать заказ. Товаров> 1Количество в заказе <Количество в дБ	y11 y2 3	o3251 Успешно
Создать OrderNo. Товаров = 1 Количество в заказе> Количество в дБ	x23 200	null Неудачно
Проверить статус заказа в базе данных = активен	o9876	Active Успешно
Проверить статус заказа в базе данных = отправлено	o9656	Shipped Успешно
Проверить статус заказа ID заказа = Недействительный	y5686	null Неудачно
Проверить наличие товараКоличество товара> 0	d34	34да Успешно
Проверить наличие товараКоличество товара = 0	y34	0no Успешно
Проверить наличие продукта Идентификатор продукта = недопустимый	sder	Неудачный

2) Уровень интеграции

Тестовые примеры уровня интеграции выполняются в пользовательском интерфейсе и базе данных.

• Создайте заказ с одним товаром -
• Пользователь открывает сайт.
• Едет оформить заказ.
• Выбирает действительный продукт и количество и сохраняет заказ.
• Должно появиться сообщение о том, что заказ размещен успешно.
• Пользователь открывает базу данных и проверяет, совпадают ли детали заказа с данными, введенными на сайте.

3) От конца до конца уровня

Бизнес-потоки и варианты использования выполняются в пользовательском интерфейсе.

• Создайте заказ с несколькими товарами -
• Пользователь открывает сайт.
• Едет оформить заказ.
• Запрашивает о действующем товаре и количестве, добавляет его в корзину.
• Другие действительные продукты добавляются в действительных количествах, и заказ сохраняется. Оплата производится новым способом оплаты и размещается заказ.
• Должно появиться сообщение «Заказ успешно размещен».
• Тестировщик должен убедиться, что весь поток выполняется без искажения данных.

Вывод:

Набросав правильную стратегию тестирования, ресурсов, инструментов и соответствия для обеспечения хорошего обслуживания, тестирование SOA может предоставить полностью и идеально протестированное приложение.