Какво е SOA тестване?
Тестването на SOA (Service Oriented Architecture) е тестване на архитектурен стил на SOA, при което компонентите на приложението са проектирани да комуникират чрез комуникационни протоколи, обикновено през мрежа.
В този урок ще научите -
- Какво е SOA?
- Какво е услуга?
- SOA тестване
- Стратегия за SOA тестване
- Методи за тестване на SOA
- Предизвикателства при тестването на SOA
- Инструменти за тестване на SOA
- Случаи за използване на SOA тестване
Какво е SOA?
SOA е метод за интегриране на бизнес приложения и процеси заедно, за да се отговори на бизнес нуждите.
В софтуерното инженерство SOA осигурява гъвкавост и гъвкавост на бизнес процесите. Промените в процеса или приложението могат да бъдат насочени към определен компонент, без да засягат цялата система.
Разработчиците на софтуер в SOA или разработват, или купуват парчета програми, наречени УСЛУГИ.
Какво е услуга?
- Услугите могат да бъдат функционална единица на приложение или бизнес процес, които могат да бъдат повторно използвани или повторени от всяко друго приложение или процес.
(Например в горното изображение Payment Gateway е услуга, която може да бъде използвана повторно от всеки сайт за електронна търговия. Винаги, когато трябва да се извърши плащане, сайтът за електронна търговия се обажда / заявява услугата Payment Gateway. След като плащането е извършено на шлюз, отговор се изпраща до уебсайта за електронна търговия)
- Услугите са лесни за сглобяване и лесни за преконфигуриране на компоненти.
- Услугите могат да се сравняват с градивни елементи. Те могат да конструират всяко необходимо приложение. Добавянето и премахването им от приложението или бизнес процеса е лесно.
- Услугите се определят повече от бизнес функцията, която изпълняват, а не като парчета код.
Уеб услуги
Уеб услугите са независими компоненти на приложението, които са достъпни в мрежата.
Те могат да бъдат публикувани, намерени и използвани в мрежата. Те могат да общуват чрез интернет.
- Доставчикът на услуги публикува услугата в интернет.
- Клиентът търси конкретна уеб услуга от Регистъра на уеб услугите
- Връща се URL и WSDL за необходимата уеб услуга.
>> Използвайки WSDL и URL адреса, комуникацията между доставчика на услуги и заявителя се осъществява чрез SOAP съобщения. <<
- Когато потребителят се обади на уеб услуга, ще се установи HTTP връзка с доставчика.
Създава се SOAP съобщение, за да инструктира доставчика да извика необходимата логика на уеб услугата.
- Отговорът, получен от доставчика, е SOAP съобщение, което ще бъде вградено в HTTP отговора. Този HTTP отговор е форматът на данните, който е разбираем за потребителското приложение.
Пример
Началната страница на уебсайт и търсачка показва ежедневен доклад за времето. Вместо да кодирате раздела за доклад за времето навсякъде, Услуга за доклад за времето може да бъде закупен от доставчик и интегриран в страниците.
SOA тестване
SOA се състои от различни технологии. Приложенията, създадени с помощта на SOA, имат различни услуги, които са свободно свързани.
SOA тестването трябва да се фокусира върху 3 системни слоя
Уровень на услугите
Този слой се състои от услуги, услуги, изложени от система, получена от бизнес функции.
Например -
Помислете за Уелнес уебсайт, който се състои от
- Проследяване на тегло
- Проследяващ кръвната захар
- Проследяващо кръвно налягане
Тракерите показват съответните данни и датата, на която са въведени. Услугата се състои от услугите, които получават съответните данни от базата данни-
- Услуга за проследяване на тегло
- Услуга за проследяване на кръвна захар
- Услуга за проследяване на кръвно налягане
- Услуга за вход
Процесен слой
Process Layer включва процесите, събирането на услуги, които са част от една функционалност.
Процесите могат да бъдат част от потребителския интерфейс (за бивша - търсачка), част от ETL инструмент (за получаване на данни от базата данни).
Основният фокус в този слой ще бъде върху потребителските интерфейси и процес.
Потребителският интерфейс на тракера за тежести и интегрирането му с базата данни е основният фокус.
По-долу ще бъдат разгледани функциите
- Добавяне на нови данни
- Редактиране на съществуващи данни
- Създаване на нов тракер
- Изтриване на данни
Потребителски слой
Този слой се състои основно от потребителски интерфейси.
Въз основа на слоя, тестването на SOA приложение се разпределя на три нива.
- Ниво на обслужване
- Ниво на интерфейса
- Ниво от край до край
- Подходът отгоре надолу се използва за тестово проектиране.
- Подходът отдолу нагоре се използва за тестово изпълнение.
Стратегия за 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
- Уеб услугите могат да се разработват, проверяват и извикват.
- Може да се използва и за тестване на натоварване, тестване за автоматизация и тестване на сигурността
- Stubs могат да бъдат създадени от MockServices
- Заявките и тестовете за уеб услуги могат да се генерират автоматично чрез клиента за уеб услуги.
- Имате вградени инструменти за отчитане
- Разработено от SmartBear
2) iTKO LISA
"LISA" е продуктов пакет, който предоставя функционално решение за тестване на разпределени системи като SOA.
- Може да се използва и за регресия, интегриране, натоварване и тестване на производителността.
- Разработено от iTKO (CA Technologies)
- Може да се използва за проектиране и изпълнение на тестове.
3) HP Service Test
"Service Test" е инструмент за функционално тестване, който поддържа тестване както на потребителски интерфейс, така и на споделени услуги
- Както функционален, така и тест за ефективност на услугите може да се направи с един скрипт.
- Интегриран с HP QC.
- Огромното количество услуги и данни могат да бъдат управлявани.
- Поддържа тестване на оперативна съвместимост чрез симулиране на клиентска среда JEE, AXIS и DotNet.
- Разработено от HP.
4) Parasoft SOA тест
SOA Test е набор от инструменти за тестване и анализ, разработен за тестване на API и API приложения.
- Поддържа уеб услуги, REST, JSON, MQ, JMS, TIBCO, HTTP, XML технологии.
- Възможни са функционални, модулни, интеграционни, регресионни, защитни, оперативно съвместими, съвместими и тествани.
- Stubs могат да бъдат създадени с помощта на Parasoft Virtualize, които са интелигентни от SOAP UI.
- Разработено от ParaSoft
Случаи за използване на SOA тестване
Помислете за уебсайт за електронна търговия, който съдържа следните функции и подфункции:
Обработка на поръчки
ЕТАП 1
В първата фаза на тестване на SOA, т.е. фаза на тестовата стратегия, приложението е разбито на услуги и бизнес функции.
Нека разгледаме по-долу услугите в приложението.
- Създаване на поръчка
- Проверете състоянието на клиента
- Промяна на състоянието на поръчката
- Проверете състоянието на поръчката
- Проверете инвентара
Бизнес функциите са същите като функциите на уебсайта.
Забележка: Документът за стратегията за тестване ще съдържа списъка на услугата и функциите, които трябва да бъдат тествани.
ФАЗА 2
Фаза на планиране на теста. Тестови случаи се пишат за всяко ниво.
- Ниво от край до край. Тестовите случаи са написани за всеки случай и поток на бизнес употреба.
По-долу са дадени примерите за тестови случаи
- Създайте поръчка с активния потребител.
- Създайте поръчка с неактивен потребител.
- Създайте поръчка с наличния продукт с количество за поръчка <налично количество.
- Създайте поръчка с наличния продукт с количество на поръчката> налично количество.
- Създайте поръчка с множество артикули
- Анулирайте поръчка напълно.
- Анулирайте частично поръчката.
- Ниво на интеграция. Тестовите случаи са написани за интегриране на база данни и потребителски интерфейс.
По-долу са дадени примерни тестови случаи.
- Създайте нова поръчка с един елемент. Проверете дали поръчката е създадена в базата данни.
- Създайте нова поръчка с един елемент. Уверете се, че изчислената цена за поръчката е вярна.
- Създайте нова поръчка с един елемент. Уверете се, че количеството на наличния продукт е по-малко от сумата на поръчката.
- Проверете дали състоянието на поръчката, показана в потребителския интерфейс, е същото като това в базата данни.
- Анулирайте поръчката и проверете дали състоянието на поръчката е променено в базата данни.
- За първото плащане проверете дали данните за плащане, въведени в потребителския интерфейс, са запазени в базата данни.
- За връщане на плащания проверете дали данните за плащанията в базата данни са показани на потребителския интерфейс.
- Ниво на обслужване. Всяка услуга е тествана за всички условия на данните.
По-долу са дадени няколко примера.
| Не. | подробности за поръчката | Състояние на поръчката |
|---|---|---|
| 1 | Създаване на поръчка. Брой елементи = 1 | Количество по поръчка <Количество в базата данни |
| 2 | Създаване на поръчка. Брой елементи> 1 | Количество при поръчка <Количество в базата данни. |
| 3 | Създайте номер на поръчка на артикули = 1 | Количество при поръчка> Количество в базата данни |
| 4 | Проверете състоянието на поръчката | Състояние на базата данни = Активно |
| 5 | Проверете състоянието на поръчката | Състояние на базата данни = Изпратено |
| 6 | Проверете състоянието на поръчката | Състояние на базата данни = Анулирано |
| 7 | Проверете състоянието на поръчката | Идентификационен номер на поръчката = невалиден |
| 8 | Проверете наличността на продукта | Количество продукт> 0 |
| 9 | Проверете наличността на продукта | Количество продукт = 0 |
| 10 | Проверете наличността на продукта | Идент. № на продукта = невалиден |
ЕТАП 3 - Изпълнение на теста
Изпълнението на теста използва подход отдолу-нагоре, т.е. първо се извършва тестване на ниво услуга, след това ниво на интеграция и накрая тестване от край до край.
1) Ниво на обслужване
Нека помислим, че инструментът Soapui се счита за тестване на приложението.
WSDL и URL се преглеждат в тестовия прозорец на SOAP.
Заявката за всяка услуга ще се покаже в прозореца на заявката.
Чрез модифициране на данните според тестовите случаи на ниво услуга се създават заявки за всеки тестов случай.
|
Тестов случай |
Заявка |
Очакван отговор |
|---|---|---|
|
Създаване на поръчка. Брой артикули = 1 Количество по поръчка <Количество по db |
|
|
|
Създаване на поръчка. на артикулите> 1 Количество на поръчка <Количество на db |
|
|
|
Създаване на поръчка №. на артикулите = 1 Количество при поръчка> Количество по db |
|
|
|
Проверете Status Status Status на базата данни = Active |
|
|
|
Проверете Status Status Status на базата данни = Изпратена |
|
|
|
Проверете статус на поръчка id = Невалиден |
|
|
|
Проверете наличността на продукта Количество на продукта> 0 |
|
<количество> 34 <на разположение> да <съобщение> Успешно |
|
Проверете наличността на продукта Количество на продукта = 0 |
|
|
|
Проверете наличността на продукта Идентификатор на продукта = невалиден |
|
|
2) Ниво на интеграция
Тестовите случаи на ниво интеграция се изпълняват в потребителския интерфейс и базата данни.
- Създайте поръчка с един елемент -
- Потребителят отваря уебсайта.
- Отива да направи поръчка.
- Избира валиден продукт и количество и запазва поръчката.
- Трябва да се покаже съобщение, в което се казва, че поръчката е направена успешно.
- Потребителят отваря база данни и проверява дали данните за поръчката са същите като тези, въведени на уебсайта.
3) Ниво от край до край
Бизнес потоците и случаите на използване се изпълняват в потребителския интерфейс.
- Създайте поръчка с множество артикули -
- Потребителят отваря уебсайт.
- Отива да направи поръчка.
- Запитва за валиден продукт и количество ги добавя в количката.
- Други валидни продукти се добавят с валидни количества и поръчката се запазва. Плащането се извършва чрез нов начин на плащане и се прави поръчка.
- Трябва да се покаже съобщение „Поръчката е направена успешно“.
- Тестерът трябва да потвърди, че целият поток се извършва без изкривяване на данни.
Заключение:
Чрез скициране на правилната стратегия за тестване, ресурси, инструменти и съответствие за осигуряване на добро обслужване, тестването на SOA може да осигури напълно и перфектно тествано приложение.