Тестирование сервис-ориентированной архитектуры (SOA - Service Oriented Architecture) — КиберПедия 

Автоматическое растормаживание колес: Тормозные устройства колес предназначены для уменьше­ния длины пробега и улучшения маневрирования ВС при...

Общие условия выбора системы дренажа: Система дренажа выбирается в зависимости от характера защищаемого...

Тестирование сервис-ориентированной архитектуры (SOA - Service Oriented Architecture)

2022-07-03 76
Тестирование сервис-ориентированной архитектуры (SOA - Service Oriented Architecture) 0.00 из 5.00 0 оценок
Заказать работу

https://www.softwaretestingmaterial.com/soa-testing/

Это тестирование архитектурного стиля SOA, в котором компоненты приложения предназначены для сообщения по протоколам связи, обычно через сеть. SOA - это метод интеграции бизнес-приложений и процессов для удовлетворения потребностей бизнеса. В разработке программного обеспечения SOA обеспечивает гибкость бизнес-процессов. Изменения в процессе или приложении могут быть направлены на конкретный компонент, не затрагивая всю систему. Разработчики программного обеспечения в SOA либо разрабатывают, либо покупают куски программ под названием SERVICES. Что такое Service?

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

● Service просты в сборке и легко переконфигурируют компоненты.

● Service можно сравнить со строительными блоками. Они могут построить любое необходимое приложение. Добавить и удалить их из приложения или бизнес-процесса очень просто.

● Service больше определяются бизнес-функциями, которые они выполняют, а не кусками кода.

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

Тестирование SOA должно быть сосредоточено на 3 уровнях:

● Уровень сервисов (Services Layer): Этот уровень состоит из сервисов, полученных из бизнес-функций. Например - Рассмотрим оздоровительный сайт, который состоит из: Трекер веса, Отслеживание уровня сахара в крови и трекера артериального давления. Трекеры отображают соответствующие данные и дату их ввода. Уровень сервисов состоит из сервисов, которые получают соответствующие данные из базы данных – Сервис трекера веса, сервис отслеживания уровня сахара в крови, сервис отслеживания артериального давления и Сервис логина.

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

● Потребительский уровень (Consumer Layer): Этот уровень в основном состоит из пользовательских интерфейсов. Тестирование приложения SOA распределяется на три уровня: Уровень обслуживания, Уровень интерфейса, Уровень end-to-end. Подход сверху вниз используется для проектирования тестов. Подход снизу-вверх используется для выполнения теста.

 

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

● Data based testing на основе бизнес-сценариев:

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

o Сценарии должны быть разработаны на основе интеграции

▪ Различные веб-сервисы приложения

▪ Веб-сервисы и приложения

o Настройка данных должна быть выполнена на основе вышеуказанных сценариев.

o Настройка данных должна быть выполнена так, чтобы охватить также сквозные сценарии

● Заглушки (Stubs):

o Будут созданы фиктивные интерфейсы для тестирования сервисов.

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

o Когда приложение использует интерфейс с внешней службой, которая не тестируется (сторонняя служба), во время тестирования интеграции можно создать заглушку.

● Regression testing:

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

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

o Этот набор тестов может быть повторно использован в нескольких релизах проекта.

● Тестирование уровня сервиса (Service Level testing):

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

● Functional testing:

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

o Правильные ошибки получены для запросов с неверными данными.

o Проверьте каждый запрос и ответ для каждой операции, которую служба должна выполнять во время выполнения.

o Проверяйте сообщения об ошибках при возникновении ошибки на уровне сервера, клиента или сети.

o Убедитесь, что полученные ответы имеют правильный формат.

o Подтвердите, что данные, полученные в ответе, соответствуют запрашиваемым данным.

● Security testing:

o Отраслевой стандарт, определенный тестированием WS-Security, должен соблюдаться веб-службой.

o Меры безопасности должны работать без нареканий.

o Шифрование данных и Цифровые подписи на документах

o Аутентификация и авторизация

o SQL-инъекции, вредоносные программы, XSS, CSRF и другие уязвимости должны быть проверены на XML. Атаки отказа в обслуживании

● Performance testing:

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

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

o Нагрузочное тестирование сервиса: проверить время отклика, проверить наличие узких мест, проверить использование процессора и памяти, прогнозировать масштабируемость

● Тестирование уровня интеграции (Integration level testing):

o Интеграционное тестирование проводится с упором в основном на интерфейсы.

o Этот этап охватывает все возможные бизнес-сценарии.

o Нефункциональное тестирование приложения должно быть сделано еще раз на этом этапе. Security, compliance, and Performance testing обеспечивают доступность и стабильность системы во всех аспектах.

o Коммуникационные и сетевые протоколы должны быть протестированы для проверки согласованности обмена данными между сервисами.

● End to End testing:

o Все сервисы работают должным образом после интеграции

o Обработка исключений

o Пользовательский интерфейс приложения

o Правильный data flow через все компоненты

o Бизнес-процесс

Тестирование планирования ресурсов предприятия (ERP - Enterprise Resource Planning)

https://www.softwaretestingmaterial.com/approach-the-testing-of-erp-applications/

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

Приложения ERP стали критически важными для бесперебойной работы предприятий. Поскольку они включают в себя множество модулей, функций и процессов, необходимость их проверки становится критической. Предприятия осознают необходимость использования модели SMAC (Social, Mobile, Analytics и Cloud) для ускорения роста. Однако капитальный ремонт основных процессов, администрируемых устаревшими приложениями ERP, также важен. Приложения ERP помогают предприятиям управлять различными функциями, отделами и процессами, включая генерируемые в них данные. Эти приложения помогают предприятиям работать как единое целое и в процессе генерировать такие результаты, как повышение производительности, повышение эффективности, сокращение отходов, повышение качества обслуживания клиентов и повышение рентабельности инвестиций. Ввиду важности приложений ERP для организаций, они должны быть протестированы и утверждены. Тестирование приложений ERP может обеспечить бесперебойную работу множества задач в организациях. Они могут включать в себя отслеживание инвентаризации и операций с клиентами, управление финансами и человеческими ресурсами, среди многих других.

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

Поскольку система ERP содержит огромные объемы данных, тестирование ручных процедур может потребовать много времени и средств. Автоматизированное тестирование может помочь проверить все функции и возможности при минимальных затратах времени и средств. Кроме того, поскольку несколько бизнес-подразделений организации могут иметь разные процессы или процедуры, автоматическое тестирование может проверять точность их результатов по конкретным параметрам. Кроме того, ERP-систему необходимо периодически обновлять с появлением новых технологий, таких как Cloud, Big Data и Mobility. Такие обновления помогают организации проверять транзакции в режиме реального времени, что невозможно вручную.

Системы ERP доступны в нескольких версиях, предназначенных для нескольких доменов, подразделений и клиентов, лучшие доступные инструменты:

● Microsoft Dynamics NAV - для малых и средних предприятий

● SAP Insurance - Для страховых компаний

● Microsoft Dynamics AX - для крупных предприятий

● SAP Banking - Для банковского сектора

 

Доп. материал:

Тестування CRM-систем на прикладі Salesforce


Поделиться с друзьями:

Архитектура электронного правительства: Единая архитектура – это методологический подход при создании системы управления государства, который строится...

История развития хранилищ для нефти: Первые склады нефти появились в XVII веке. Они представляли собой землянные ямы-амбара глубиной 4…5 м...

Таксономические единицы (категории) растений: Каждая система классификации состоит из определённых соподчиненных друг другу...

Общие условия выбора системы дренажа: Система дренажа выбирается в зависимости от характера защищаемого...



© cyberpedia.su 2017-2024 - Не является автором материалов. Исключительное право сохранено за автором текста.
Если вы не хотите, чтобы данный материал был у нас на сайте, перейдите по ссылке: Нарушение авторских прав. Мы поможем в написании вашей работы!

0.023 с.