Какво е SOA тестване? Урок с пример

Какво е SOA тестване?

SOA (ориентиран към услуги ArchiТестване на текстура е тестване на архитектурния стил SOA, при който компонентите на приложението са проектирани да комуникират чрез комуникационни протоколи, обикновено по мрежа.

Какво е SOA?

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

In Софтуерно инженерствоSOA осигурява гъвкавост и адаптивност на бизнес процесите. Промяна в процес или приложение може да бъде насочена към конкретен компонент, без да засяга цялата система.

Разработчиците на софтуер, работещи в SOA, или разработват, или купуват части от програми, наречени услуги.

Какво е услуга?

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

• Услугата може да бъде функционална единица на приложение или бизнес процес, която може да бъде използвана повторно или повторена от всяко друго приложение или процес. (Например, на изображението по-горе, Payment Gateway е услуга, която може да бъде използвана повторно от всеки сайт за електронна търговия. Винаги, когато трябва да се извърши плащане, сайтът за електронна търговия извиква или заявява услугата Payment Gateway. След като плащането е завършено на шлюза, отговор се изпраща обратно до уебсайта за електронна търговия.)
• Услугите са лесни за сглобяване и лесни за преконфигуриране компоненти.
• Услугите могат да бъдат сравнени със градивни елементи. Те могат да изградят всяко необходимо приложение, а добавянето или премахването им от приложението или бизнес процеса е лесно.
• Услугите се определят повече от бизнес функцията, която изпълняват, отколкото като парчета код.

Уеб услуги

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

Уеб услуги са независими компоненти на приложението, които са достъпни през интернет.

Те могат да бъдат публикувани, намирани и използвани в мрежата и комуникират чрез интернет. Последователността по-долу показва как взаимодействат доставчик, регистър и потребител.

• Доставчикът на услуги публикува услугата в интернет.
• Клиентът търси конкретна уеб услуга в регистъра на уеб услугите.
• A URL и wsdl за необходимата уеб услуга се връщат. Използвайки WSDL и URL, комуникацията между доставчика на услуги и заявителя се осъществява чрез SOAP съобщения.
• Когато потребител извика уеб услуга, се установява HTTP връзка с доставчика.
• Създава се SOAP съобщение, което инструктира доставчика да извика необходимата логика на уеб услугата.
• Полученият от доставчика отговор е SOAP съобщение, което е вградено в HTTP отговора. Този HTTP отговор е форматът на данните, разбираем от потребителското приложение.

Пример

Екранната снимка по-долу показва метеорологична прогноза, предоставена от външна услуга и вградена в началната страница на търсачка.

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

SOA тестови слоеве

SOA се състои от различни технологии, а приложенията, изградени с помощта на SOA, имат различни услуги, които са слабо свързани. Диаграмата по-долу показва трите слоя, които трябва да покрие един тестов план.

SOA тестването трябва да се фокусира върху 3 системни слоя.

Слой услуги

Този слой се състои от услугите, предоставяни от системата, произлизащи от бизнес функции.

Например, помислете за уебсайт за уелнес, който се състои от:

• Тегло TracКер
• Кръвна захар TracКер
• Кръвно налягане TracКер

TracСлоят за услуги показва съответните данни и датата на въвеждането им. Слоят за услуги се състои от услугите, които получават съответните данни от базата данни:

• Тегло Tracкер услуга
• Кръвна захар Tracкер услуга
• Кръвно налягане Tracкер услуга
• Услуга за вход

Процесен слой

Процесният слой се състои от процесите, съвкупността от услуги, които са част от една функционалност.

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

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

Следните функции се вземат предвид:

• Добавяне на нови данни
• Редактиране на съществуващи данни
• Създаване на нов tracКер
• Изтриване на данни

Потребителски слой

Този слой се състои главно от потребителски интерфейси, както е показано на екрана по-долу.

Въз основа на тези слоеве, тестването на SOA приложение е разпределено на три нива:

• Ниво на обслужване
• Ниво на интерфейса
• Ниво от край до край

Двете посоки на движение се различават: за проектиране на тестове се използва подход „отгоре надолу“, докато за изпълнение на тестове се използва подход „отдолу нагоре“.

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

Подход за планиране на тестовете

• Пълната архитектура на приложението трябва да бъде разбрана от SOA тестерите.
• Приложението трябва да бъде разделено на независими услуги (услуга, която има собствена структура за заявки и отговори и не зависи от друга услуга за формиране на отговор).
• Структурата на приложението трябва да бъде реорганизирана в три компонента - данни, услуги и front-end приложения.
• Всички компоненти трябва да бъдат внимателно анализирани и да бъдат очертани бизнес сценарии.
• Бизнес сценариите трябва да бъдат класифицирани като общи сценарии и сценарии, специфични за приложението.
• A TracМатрица на възможностите трябва да бъдат подготвени и всички тестови случаи трябва да бъдат tracсъобразени с бизнес сценарии.

Подход за изпълнение на теста

• Всеки компонент на услугата трябва да бъде тестван.
• Тестване на интеграцията на компонентите на услугата трябва да се извърши за валидиране на потока от данни през услугите и целостта на данните.
• Тестване на системата на целия модел трябва да се направи, за да се валидира потокът от данни между front-end приложението и базата данни.
• Тестване на производителността трябва да се направи за фина настройка и оптимална производителност.

SOA методи за тестване

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

• Трябва да бъдат анализирани различни бизнес аспекти, свързани със системата.
• Сценариите трябва да бъдат разработени въз основа на интеграцията на различните уеб услуги на приложението и на уеб услугите с приложението.
• Настройката на данните трябва да се извърши въз основа на горните сценарии.
• Настройката на данните трябва да обхваща и сценарии от край до край.

2) Пънчета

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

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

• Тестване на регресия върху приложението трябва да се прави, когато има няколко издания, за да се гарантира стабилността и наличността на системите.
• Ще бъде създаден цялостен набор от регресионни тестове, обхващащ услугите, които формират важна част от приложението.
• Този тестов набор може да се използва повторно в множество издания на проекта.

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

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

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

Функционално тестване трябва да се направи за всяка услуга, за да:

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

6) Тестване на сигурността

Тестването на сигурността на уеб услугата е важен аспект по време на тестването на нивото на обслужване на SOA приложението, защото гарантира безопасността на приложението.

Следните фактори трябва да бъдат обхванати по време на тестването:

• Уеб услугата трябва да спазва индустриалния стандарт, дефиниран от WS-Security.
• Мерките за сигурност трябва да работят безупречно.
• Криптиране на данни и цифрови подписи върху документите.
• Удостоверяване и оторизация.
• SQL инжекция, зловреден софтуер, XSS, CSRF и други уязвимости ще бъдат тествани на XML.
• Атаки с отказ на услуга.

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

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

По време на тестването се вземат предвид следните фактори:

• Ефективността и функционалността на услугата трябва да бъдат тествани при голямо натоварване.
• Производителността на услугата трябва да се сравнява, когато тя работи самостоятелно и когато е свързана в рамките на приложението.
• Тестване на натоварването на услугата трябва да се извърши, за да се провери времето за реакция, да се проверят за пречки, да се провери използването на процесора и паметта и да се предвиди мащабируемостта.

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

• Тестването на нивото на обслужване гарантира правилното функциониране на услугите поотделно; то не гарантира работата на свързаните компоненти.
• Интеграционното тестване се извършва, като се фокусира главно върху интерфейси.
• Тази фаза обхваща всички възможни бизнес сценарии.
• Нефункционалното тестване на приложението трябва да се извърши още веднъж на тази фаза. Тестването за сигурност, съответствие и производителност гарантира наличността и стабилността на системата във всички аспекти.
• Комуникационните и мрежовите протоколи трябва да бъдат тествани, за да се потвърди съгласуваността на комуникацията на данни между услугите.

9) Тестване от край до край

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

Гарантирано е, че елементите по-долу ще бъдат тествани по време на тестване от край до край:

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

Предизвикателства при SOA тестването

Прилагането на тези методи рядко е лесно и трудностите, описани по-долу, се повтарят в почти всяка SOA програма.

• Липса на интерфейси за услуги.
• Процесът на тестване обхваща множество системи, което създава сложни нужди от данни.
• Приложението е съвкупност от различни компоненти, които са склонни да се променят, така че необходимостта от регресионно тестване е по-честа.
• Поради многослойната архитектура е трудно да се изолират дефекти.
• Тъй като една услуга се използва от различни интерфейси, натоварването е трудно за предвиждане, което прави планирането на тестовете за производителност тромаво.
• SOA е съвкупност от хетерогенни технологии. Тестването на SOA приложение изисква хора с различни умения, което от своя страна увеличава разходите за планиране и изпълнение.
• Тъй като приложението интегрира множество услуги, тестването за сигурност има своите проблеми. Валидирането на удостоверяване и оторизация е трудно.

Инструменти за тестване на SOA

На пазара се предлагат много инструменти за SOA тестване, които помагат на тестерите при тестването на SOA приложения. Ето някои от популярните инструменти за SOA тестване.

1) SoapUI

SoapUI е инструмент с отворен код за функционално тестване на услуги и API тестване.

• Десктоп приложение
• Поддържа множество протоколи — SOAP, REST, HTTP, JMS, AMF, JDBC
• Уеб услугите могат да бъдат разработвани, проверявани и извиквани.
• Може да се използва и за тестове за натоварване, Тестване на автоматизациятаи тестване на сигурността
• Заготовките могат да бъдат създадени от MockServices
• Заявките и тестовете за уеб услуги могат да се генерират автоматично чрез неговия клиент за уеб услуги.
• Има вградени инструменти за отчитане
• Разработено от SmartBear, която доставя и двете с отворен код SoapUI дистрибуцията и търговската ReadyAPI издание

2) Виртуализация на услугите на Broadcom (преди iTKO LISA)

LISA е продуктов пакет, който предоставя решение за функционално тестване на разпределени системи като SOA. Продуктът премина от iTKO към CA Technologies и днес се продава като Broadcom Service Virtualization.

• Може да се използва и за регресионно, интеграционно, натоварващо и производителностно тестване.
• Може да се използва за проектиране и изпълнение на тестове.

3) UFT Едно (преди това HP Service Test)

Service Test е инструмент за функционално тестване, който поддържа тестване както на потребителски интерфейс, така и на споделени услуги. Възможността му за API тестване беше включена в Unified Functional Testing, който сега се продава от OpenText as UFT One.

• Както функционалните, така и производителните тестове на услугите могат да се извършват от един скрипт.
• Интегриран с Център за качество, сега се продава като OpenText ALM / Център за качество.
• Може да се управлява огромно количество услуги и данни.
• Поддържа тестване за оперативна съвместимост чрез симулиране на JEE, AXIS и DotNet клиентски среди.

4) Parasoft SOAtest

Parasoft SOAtest е набор от инструменти за тестване и анализ, разработен за тестване на API и API-базирани приложения.

• Поддържа уеб услуги, REST, JSON, MQ, JMS, TIBCO, HTTP и XML технологии.
• Възможни са функционални, модулни, интеграционни, регресионни, тестове за сигурност, оперативна съвместимост, тестове за съответствие и тестове за производителност.
• Мъничките могат да бъдат създадени с помощта на Парасофт Виртуализация, които са по-способни от SoapUI MockServices.

Случаи на употреба при тестване на SOA

Разработеният пример по-долу прилага стратегията, методите и инструментите по-горе към един сайт за електронна търговия, стъпка по стъпка.

Помислете за уебсайт за електронна търговия, който съдържа функциите и подфункциите по-долу.

Обработка на поръчка

Таблицата по-долу разделя обработката на поръчките на подфункции, които се превръщат в услуги.

ФАЗА 1

В първата фаза на SOA тестване, фазата на тестова стратегия, приложението се разделя на услуги и бизнес функции.

Нека разгледаме услугите по-долу в заявлението.

• Създаване на поръчка
• Проверете състоянието на клиента
• Промяна на състоянието на поръчката
• Проверете състоянието на поръчката
• Проверете инвентара

Бизнес функциите са същите като функциите на уебсайта.

Забележка: Документът за стратегията за тестване ще съдържа списъка с услугите и функциите, които трябва да бъдат тествани.

ФАЗА 2

Това е фазата на планиране на теста. Тестови случаи са написани за всяко ниво.

Ниво от край до край. Тестовите случаи са написани за всеки бизнес случай на употреба и поток. По-долу са дадени примери за тестови случаи.

• Създайте поръчка с активен потребител.
• Създайте поръчка с неактивен потребител.
• Създайте поръчка с наличен продукт с количество за поръчка < наличното количество.
• Създайте поръчка с наличен продукт с количество за поръчка > налично количество.
• Създайте поръчка с няколко артикула.
• Отменете напълно поръчка.
• Частично анулиране на поръчка.

Ниво на интеграция. Тестовите случаи са написани за интеграция на базата данни и потребителския интерфейс. По-долу са дадени примерни тестови случаи.

• Създайте нова поръчка с един артикул. Проверете дали поръчката е създадена в базата данни.
• Създайте нова поръчка с един артикул. Проверете дали изчислената цена за поръчката е правилна.
• Създайте нова поръчка с един артикул. Проверете дали количеството на наличния продукт е намалено със сумата на поръчката.
• Проверете дали състоянието на поръчката, показано в потребителския интерфейс, е същото като това в базата данни.
• Отменете поръчката и проверете дали състоянието на поръчката е променено в базата данни.
• За първо плащане, проверете дали данните за плащане, въведени в потребителския интерфейс, са запазени в базата данни.
• За връщане на плащания проверете дали данните за плащането в базата данни се показват в потребителския интерфейс.

Ниво на обслужване. Всяка услуга се тества за всички условия на данните. По-долу са дадени няколко примера.

Не.	подробности за поръчката	Състояние на поръчката
1	Създаване на поръчка. Брой артикули = 1	Количество по поръчка < Количество по база данни
2	Създаване на поръчка. Брой артикули > 1	Количество в поръчката < Количество в базата данни
3	Създаване на поръчка. Брой артикули = 1	Количество в поръчка > Количество в база данни
4	Проверете състоянието на поръчката	Състояние в базата данни = Активно
5	Проверете състоянието на поръчката	Състояние в базата данни = Изпратено
6	Проверете състоянието на поръчката	Състояние в базата данни = Отменено
7	Проверете състоянието на поръчката	ID на поръчката = Невалиден
8	Проверете наличността на продукта	Количество продукт >0
9	Проверете наличността на продукта	Количество на продукта =0
10	Проверете наличността на продукта	ID на продукта = невалиден

ФАЗА 3 — Изпълнение на теста

Изпълнението на тестовете използва подход „отдолу нагоре“: първо се извършва тестване на ниво услуга, след това на ниво интеграция и накрая тестване от край до край.

1) Ниво на обслужване

Нека вземем предвид, че SoapUI Инструментът се използва за тестване на приложението. WSDL и URL се преглеждат в тестовия прозорец на SoapUI, а заявката за всяка услуга се показва в прозореца за заявки. Чрез промяна на данните съгласно тестовите случаи на ниво услуга, заявките се създават за всеки тестов случай.

Тестов случай	Поискайте	Очакван отговор
Създаване на поръчка. Брой артикули = 1, Количество в поръчката < Количество в базата данни	x2 2	o3251 Успешно
Създаване на поръчка. Брой артикули > 1, Количество в поръчката < Количество в базата данни	y1 1 y2 3	o3251 Успешно
Създаване на поръчка. Брой артикули = 1, Количество в поръчката > Количество в базата данни	x23 200	нула Неуспешно
Проверете състоянието на поръчката. Статус в базата данни = Активна	o9876	Активен Успешен
Проверете състоянието на поръчката. Статус в базата данни = Изпратена	o9656	Изпратено Успешен
Проверете състоянието на поръчката. Идентификационен номер на поръчката = Невалиден	y5686	нула Неуспешно
Проверете наличността на продукта. Количество продукт >0	d34	34 да Успешно
Проверете наличността на продукта. Количество продукт = 0	y34	0 не Успешно
Проверете наличността на продукта. Идентификационен номер на продукта = невалиден	sder	Неуспешно

2) Ниво на интеграция

Тестовите случаи на ниво интеграция се изпълняват на потребителския интерфейс и базата данни. Създайте поръчка с един артикул:

• Потребител отваря уебсайта.
• Потребителят отива, за да направи поръчка.
• Потребителят избира валиден продукт и количество и запазва поръчката.
• Трябва да се покаже съобщение, че поръчката е направена успешно.
• Потребителят отваря базата данни и проверява дали данните на поръчката съвпадат с тези, въведени на уебсайта.

3) Ниво от край до край

Бизнес потоците и случаите на употреба се изпълняват на потребителския интерфейс. Създайте поръчка с множество артикули:

• Потребител отваря уебсайта.
• Потребителят отива, за да направи поръчка.
• Потребителят запитва за валиден продукт и количество и ги добавя в количката.
• Добавят се други валидни продукти с валидни количества и поръчката се запазва. Плащането се извършва чрез нов метод на плащане и поръчката се нарежда.
• Трябва да се покаже съобщение „Поръчката е направена успешно“.
• Тестерът трябва да валидира, че целият поток завършва без изкривяване на данните.

Въпроси и Отговори