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

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

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

Что такое СОА?

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

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

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

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

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

Web-сервисы

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

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

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 должны понимать полную архитектуру приложения.
• Приложение необходимо разбить на независимые сервисы (Сервис, который имеет собственную структуру запросов и ответов и не зависит от какого-либо другого сервиса для формирования ответа).
• Структуру приложения необходимо реорганизовать на три компонента: данные, службы и интерфейсные приложения.
• Необходимо тщательно проанализировать все компоненты и прорисовать бизнес-сценарии.
• Бизнес-сценарии следует классифицировать как общие сценарии и сценарии, специфичные для приложения.
• A Матрица прослеживаемости должны быть подготовлены, и все тестовые примеры должны быть прослежены до бизнес-сценариев.

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

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

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

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

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

2) Заглушки

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Следующие элементы подлежат проверке в ходе комплексного тестирования.

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

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

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

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

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

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

ФАЗА 1

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

Рассмотрим ниже услуги в приложении.

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

Бизнес-функции аналогичны функциям Сайта.

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

ФАЗА 2

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

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

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

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

ЭТАП 3 – Выполнение теста

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

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

Давайте рассмотрим, что Соапуи инструмент рассматривается для тестирования приложения.

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

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

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

Тестовый кейс	Запрос	Ожидаемый ответ
Создать заказ. Количество позиций = 1Количество в заказе <Количество в базе данных	х2 2	о3251 Успешный
Создать номер заказа. товаров > 1Количество в заказе <Количество в базе данных	у1 1 у2 3	о3251 Успешный
Создать номер заказа. товаров = 1Количество в заказе > Количество в базе данных	х23 200	нулевой Неудачный
Проверить статус заказа. Статус в базе данных = Активен.	о9876	Активный Успешный
Проверьте статус заказа. Статус в базе данных = Отправлено.	о9656	Отправленный Успешный
Проверить статус заказаИдентификатор заказа = Недействительный	y5686	нулевой Неудачный
Проверить наличие товараКоличество товара >0	д34	34 да Успешный
Проверить наличие товараКоличество товара =0	y34	0 нет Успешный
Проверить наличие продуктаИдентификатор продукта = недействителен	Сдер	Неудачный

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

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

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

3) Сквозной уровень

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

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

Заключение

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