Шта је СОА тестирање?
Тестирање СОА (Сервице Ориентед Арцхитецтуре) тестирање је тестирање СОА архитектонског стила у којем су компоненте апликације дизајниране за комуникацију путем комуникационих протокола, обично преко мреже.
У овом упутству ћете научити-
- Шта је СОА?
- Шта је услуга?
- СОА тестирање
- Стратегија за СОА тестирање
- СОА методе испитивања
- Изазови у СОА тестирању
- СОА Алати за тестирање
- Случајеви употребе СОА тестирања
Шта је СОА?
СОА је метода интегрисања пословних апликација и процеса заједно како би се задовољиле пословне потребе.
У софтверском инжењерству, СОА пружа окретност и флексибилност пословним процесима. Промене процеса или апликације могу се усмерити на одређену компоненту без утицаја на цео систем.
Програмери софтвера у СОА-и или развијају или купују делове програма који се називају УСЛУГЕ.
Шта је услуга?
- Услуге могу бити функционална јединица апликације или пословног процеса, коју било која друга апликација или процес може поново употребити или поновити.
(На пример, на горњој слици, Паимент Гатеваи је услуга коју било која веб локација за е-трговину може поново користити. Кад год то треба извршити уплата, веб локација за е-трговину позива / захтева услугу Паимент Гатеваи. Након што се плаћање изврши приступник, одговор се шаље веб локацији е-трговине)
- Услуге се лако састављају и лако конфигуришу компоненте.
- Услуге се могу упоредити са грађевинским блоковима. Они могу да конструишу било коју потребну апликацију. Једноставно их је додати и уклонити из апликације или пословног процеса.
- Услуге су више дефинисане пословном функцијом коју обављају, а не као делови кода.
Веб сервиси
Веб услуге су независне компоненте апликација, које су доступне преко Веба.
Могу се објавити, пронаћи и користити на Интернету. Они могу комуницирати путем Интернета.
- Добављач услуга објављује услугу на Интернету.
- Клијент тражи одређену веб услугу из Регистра веб услуга
- Враћају се УРЛ и ВСДЛ за потребну веб услугу.
>> Коришћењем ВСДЛ-а и УРЛ-а, комуникација између добављача услуга и подносиоца захтева одвија се путем СОАП порука. <<
- Када потрошач позове веб услугу, провајдеру ће бити успостављена ХТТП веза.
СОАП порука је креирана да упути добављача да позове потребну логику веб услуге.
- Одговор примљен од добављача је СОАП порука која ће бити уграђена у ХТТП одговор. Овај ХТТП одговор је формат података који је потрошачкој апликацији разумљив.
Пример
Почетна страница веб странице и претраживача приказују свакодневни временски извештај. Уместо целокупног кодирања одељка о временским приликама, Услуга извештавања о времену може се купити од продавца и интегрисати у странице.
СОА тестирање
СОА се састоји од различитих технологија. Апликације изграђене помоћу СОА имају разне услуге које су међусобно повезане.
СОА тестирање треба да се усредсреди на 3 системска слоја
Услужни ниво
Овај слој чине услуге, услуге које излаже систем изведен из пословних функција.
На пример -
Размислите о веб локацији Веллнесс која се састоји од
- Веигхт Трацкер
- Трагач за шећером у крви
- Трацкер за крвни притисак
Трацкери приказују одговарајуће податке и датум уноса. Слој услуга састоји се од услуга које одговарајуће податке добијају из базе података-
- Услуга праћења тежине
- Услуга праћења шећера у крви
- Услуга праћења крвног притиска
- Услуга пријаве
Слој процеса
Слој процеса састоји се од процеса, прикупљања услуга које су део једне функционалности.
Процеси могу бити део корисничког интерфејса (за бивши претраживач), део ЕТЛ алата (за добијање података из базе података).
Главни фокус овог слоја биће на корисничком интерфејсу и процесу.
Кориснички интерфејс трагача за тежину и његова интеграција са базом података је примарни фокус.
Испод ће бити узете у обзир функције
- Додавање нових података
- Уређивање постојећих података
- Израда новог трацкер-а
- Брисање података
Потрошачки слој
Овај слој се углавном састоји од корисничког интерфејса.
На основу слоја, тестирање СОА апликације распоређено је у три нивоа.
- Ниво услуге
- Ниво интерфејса
- Крај до краја ниво
- Приступ одозго надоле се користи за дизајнирање тестова.
- Приступ одоздо према горе користи се за извршавање теста.
Стратегија за СОА тестирање
Приступ планирању испитивања,
- Комплетну архитектуру апликације СОА тестери треба да разумеју.
- Апликацију треба поделити на независне услуге (Услуга која има сопствену структуру захтева и одговора и не зависи од било које друге услуге која формира одговор).
- Структуру апликације треба реорганизовати у три компоненте - Дата, Сервицес и фронт-енд апликације.
- Све компоненте треба пажљиво анализирати, а пословне сценарије треба оцртати.
- Пословни сценарији би требали бити класификовани као уобичајени сценарији и сценарији специфични за апликацију.
- Треба припремити матрицу сљедивости, а све случајеве испитивања треба пратити у пословним сценаријима.
Приступ извршењу теста
- Треба тестирати сваку услужну компоненту.
- Интеграција Тестирање компонената услуге требало би извршити да би се потврдио проток података кроз услуге и интегритет података.
- Системско тестирање комплетног модела треба извршити да би се потврдио проток података између фронт-енд апликације и базе података.
- Треба извршити тестирање перформанси ради финог подешавања и оптималних перформанси.
СОА методе испитивања
1) Тестирање засновано на пословном сценарију,
- Треба анализирати разне пословне аспекте повезане са системом.
- Сценарије треба развити на основу интеграције
- Разне веб услуге апликације
- Веб услуге и апликације.
- Постављање података треба извршити на основу горе наведених сценарија.
- Подесавање података треба обавити тако да покрива и крај до краја сценарије.
2) Стубс
- Лажни интерфејси ће бити створени за тестирање услуга.
- Преко ових интерфејса могу се обезбедити различити улази, а излази могу бити потврђени.
- Када апликација користи интерфејс за спољну услугу, која није на тесту (услуга независне компаније), за време тестирања интеграције може се створити квар.
3) Испитивање регресије
- Испитивање регресије на апликацији треба обавити када постоји више издања како би се осигурала стабилност и доступност система.
- Биће створен свеобухватан пакет за регресијски тест који покрива услуге које чине важан део апликације.
- Овај тестни пакет се може поново користити у више издања пројекта.
4) тестирање нивоа услуге
Тестирање нивоа услуге укључује тестирање компоненте на функционалност, сигурност, перформансе и интероперабилност.
Сваку услугу треба прво тестирати независно.
5) функционално испитивање
Функционално тестирање треба обавити на свакој услузи до
- Уверите се да услуга пружа тачан одговор на сваки захтев.
- Исправне грешке се добијају за захтеве са неважећим подацима, лошим подацима итд.
- Проверите сваки захтев и одговор за сваку операцију коју услуга мора да изврши у току рада.
- Потврдите поруке грешке када се грешка догоди на нивоу сервера, клијента или мреже.
- Потврдите да су примљени одговори у правом формату.
- Потврдите да подаци примљени у одговору одговарају траженим подацима.
6) Испитивање сигурности
Тестирање безбедности веб услуге је важан аспект током тестирања нивоа СОА апликације; ово осигурава сигурност примене.
Током тестирања треба покрити следеће факторе:
- Веб услуга треба да се придржава индустријског стандарда дефинисаног тестирањем ВС-Сецурити.
- Мере безбедности треба да раде беспрекорно.
- Шифровање података и дигитални потписи на документима
- Аутентификација и ауторизација
- СКЛ Ињецтион, Малваре, КССС, ЦСРФ, остале рањивости треба тестирати на КСМЛ-у.
- Напади ускраћивања услуге
7) Испитивање перформанси
Потребно је извршити тестирање перформанси услуге, јер се услуге могу поново користити, а више апликација можда користи исту услугу.
Током испитивања узимају се у обзир следећи фактори:
- 8) Перформансе и функционалност услуге треба тестирати под великим оптерећењем.
- Учинак услуге треба упоредити док радите појединачно и у оквиру апликације је упарен.
- Треба извршити испитивање оптерећења услуге
- да би се верификовало време одзива
- да провери да ли има уских грла
- ради провере искоришћења процесора и меморије
- да предвиди скалабилност
9) Тестирање нивоа интеграције
- Тестирање нивоа услуге осигурава исправан рад само услуга појединачно, а не гарантује рад спојених компонената.
- Тестирање интеграције врши се фокусирајући се углавном на интерфејсе.
- Ова фаза покрива све могуће пословне сценарије.
- Нефункционално тестирање апликације требало би обавити још једном у овој фази. Сигурност, усаглашеност и испитивање перформанси осигуравају доступност и стабилност система у свим аспектима.
- Комуникациони и мрежни протокол треба тестирати како би се потврдила конзистентност комуникације података између услуга.
10) Енд то Енд тестирање
Ова фаза осигурава да апликација потврђује пословне захтеве и функционално и нефункционално.
Ставке у наставку осигуравају да се тестирају током тестирања од краја до краја
- Све службе раде како се очекује након интеграције
- Изузетак руковање
- Кориснички интерфејс апликације
- Одговарајући проток података кроз све компоненте
- Пословних процеса
Изазови у СОА тестирању
- Недостатак интерфејса за услуге
- Процес тестирања обухвата више система, што ствара сложене потребе за подацима
- Апликација је колекција различитих компонената која се мења. Потреба за регресионим тестирањем је чешћа.
- Због вишеслојне архитектуре тешко је изоловати недостатке.
- Будући да ће се услуга користити у различитим интерфејсима, тешко је предвидети оптерећење, па је стога планирање теста перформанси отежано.
- СОА је колекција хетерогених технологија. Тестирање СОА апликације захтева људе са различитим скуповима вештина што заузврат повећава трошкове планирања и извршења.
- Будући да је апликација интеграција више услуга, безбедносно тестирање има свој удео. Потврда аутентичности и ауторизације је прилично тешка.
СОА Алати за тестирање
На тржишту су доступни многи СОА алати за тестирање који помажу тестерима у тестирању СОА апликација. Ево неколико популарних алата за тестирање СОА :
1) СОАП УИ
„СОАП УИ“ је алат за функционално тестирање отвореног кода за тестирање услуга и АПИ-ја.
- Десктоп апликација
- Подржава више протокола - СОАП, РЕСТ, ХТТП, ЈМС, АМФ, ЈДБЦ
- Веб услуге се могу развијати, прегледати и позвати на њих.
- Може се користити и за тестирање оптерећења, аутоматизацију и сигурносно тестирање
- МобСервицес може створити гребање
- Захтеви и тестови за веб услуге могу се аутоматски генерисати путем клијента веб услуге.
- Имати уграђене алате за извештавање
- Развио СмартБеар
2) иТКО ЛИСА
„ЛИСА“ је пакет производа који пружа решење за функционално тестирање дистрибуираних система попут СОА.
- Такође се може користити за регресију, интеграцију, оптерећење и тестирање перформанси.
- Развио иТКО (ЦА Тецхнологиес)
- Може се користити за дизајнирање и извршавање тестова.
3) ХП сервисни тест
„Сервисни тест“ је алат за функционално тестирање, који подржава тестирање корисничког интерфејса и заједничких услуга
- И функционално и тестирање перформанси услуга могу се извршити помоћу једне скрипте.
- Интегрисано са ХП КЦ.
- Огромном количином услуга и података може се управљати.
- Подржава тестирање интероперабилности симулацијом ЈЕЕ, АКСИС и ДотНет клијентских окружења.
- Развио ХП.
4) Парасофт СОА тест
СОА Тест је пакет алата за тестирање и анализу развијен за тестирање АПИ-ја и АПИ апликација.
- Подржава веб услуге, РЕСТ, ЈСОН, МК, ЈМС, ТИБЦО, ХТТП, КСМЛ технологије.
- Могуће је тестирање функционалности, јединице, интеграције, регресије, сигурности, интероперабилности, усаглашености и перформанси.
- Стубс се могу креирати помоћу Парасофт Виртуализе, који су интелигентни од СОАП УИ.
- Развио ПараСофт
Случајеви употребе СОА тестирања
Размислите о веб локацији е-трговине која садржи следеће функције и подфункције:
Наређеље се извршава
ФАЗА 1
У првој фази СОА тестирања, тј. Фази стратегије тестирања, апликација се дели на услуге и пословне функције.
Размотримо у наставку да ли су Услуге у апликацији.
- Цреате Ордер
- Проверите статус купца
- Промените статус налога
- Проверите статус поруџбине
- Проверите инвентар
Пословне функције су исте као и функције веб локације.
Напомена: Документ о стратегији тестирања би садржао листу услуге и функције које треба тестирати.
ФАЗА 2
Фаза планирања теста. Тест примери су написани за сваки ниво.
- Крај до краја ниво. Тест примери су написани за сваки случај и ток пословне употребе.
Испод су примери тест случајева
- Направите поруџбину са активним корисником.
- Направите поруџбину са неактивним корисником.
- Направите поруџбину са доступним производом са количином наруџбе <доступна количина.
- Направите поруџбину са доступним производом са количином наруџбе> доступном количином.
- Направите поруџбину са више ставки
- У потпуности откажите поруџбину.
- Откажи поруџбину делимично.
- Ниво интеграције. Тест примери су написани за интеграцију базе података и корисничког интерфејса.
Испод су примери тест случајева.
- Направите нову поруџбину са једном ставком. Проверите да ли је налог креиран у бази података.
- Направите нову поруџбину са једном ставком. Уверите се да је цена израчуната за поруџбину тачна.
- Направите нову поруџбину са једном ставком. Уверите се да је количина доступног производа мања за износ наруџбине.
- Проверите да ли је статус налога приказан на корисничком интерфејсу исти као и статус базе података.
- Откажите налог и проверите да ли је статус налога измењен у бази података.
- При првом плаћању проверите да ли су детаљи о уплати унети у кориснички интерфејс сачувани у бази података.
- За враћање уплата, проверите да ли су детаљи плаћања у бази података приказани на корисничком интерфејсу.
- Ниво услуге. Свака услуга је тестирана на све услове података.
Испод је неколико примера.
| Не. | Детаљи поруџбине | Стање поруџбине |
|---|---|---|
| 1 | Цреате Ордер. Број предмета = 1 | Количина по наруџби <Количина по бази података |
| 2 | Цреате Ордер. Број предмета> 1 | Количина по наруџби <Количина по бази података. |
| 3 | Направите број поруџбине = 1 | Количина по наруџби> Количина по бази података |
| 4 | Проверите статус поруџбине | Статус у бази података = активан |
| 5 | Проверите статус поруџбине | Статус у бази података = Отпремљено |
| 6 | Проверите статус поруџбине | Статус у бази података = Отказано |
| 7 | Проверите статус поруџбине | ИД поруџбине = Неважећи |
| 8 | Проверите доступност производа | Количина производа> 0 |
| 9 | Проверите доступност производа | Количина производа = 0 |
| 10 | Проверите доступност производа | ИД производа = неважећи |
ФАЗА 3 - Извршење теста
Извршење теста користи приступ одоздо према горе, тј. Прво се врши тестирање нивоа услуге, затим ниво интеграције и на крају тестирање од краја до краја.
1) Ниво услуге
Узмимо у обзир да се алат Соапуи разматра за тестирање апликације.
ВСДЛ и УРЛ се прегледавају у тестном прозору СОАП-а.
Захтев за сваку услугу биће приказан у прозору захтева.
Изменом података према тестним случајевима на нивоу услуге, креирају се захтеви за сваки тестни случај.
|
Тест Цасе |
Захтев |
Очекивани одговор |
|---|---|---|
|
Цреате Ордер. Број предмета = 1Количина по наруџби <Количина на дб |
<продуцтид>к2 <куантити> 2 |
<ордерид>о3251 <мессаге> Успешно |
|
Направи налог. Бр. предмета> 1Количина по наруџби <Количина на дб |
<продуцтид>и1<куантити>1<продуцтид>и2 <куантити> 3 |
<ордерид>о3251 <мессаге> Успешно |
|
Цреате ОрдерНо. предмета = 1Количина по наруџби> Количина по дб |
<продуцтид>к23 <куантити> 200 |
<ордерид>нулл <мессаге> Неуспешно |
|
Провери статус статуса налога у бази података = Активно |
<ордерид> о9876 |
<статус>Ацтиве <мессаге> Успешно |
|
Провери статус статуса налога у бази података = Испоручено |
<ордерид> о9656 |
<статус> Отпремљено <мессаге> Успешно |
|
Провери ид статуса наруџбине = Неважеће |
<ордерид> и5686 |
<статус>нулл <мессаге> Неуспешно |
|
Проверите доступност производаКоличина производа> 0 |
<продуцтид> д34 |
<куантити>34<аваилабле> да <мессаге> Успешно |
|
Проверите доступност производаКоличина производа = 0 |
<продуцтид> и34 |
<куантити>0<аваилабле>но <мессаге> Успешно |
|
Проверите доступност производа ИД производа = неважећи |
<продуцтид> сдер |
<мессаге> Неуспешно |
2) Ниво интеграције
Тест случајеви нивоа интеграције извршавају се на корисничком интерфејсу и бази података.
- Направите поруџбину са једном ставком -
- Корисник отвара веб локацију.
- Иде да наручи.
- Бира важећи производ и количину и чува поруџбину.
- Треба да се прикаже порука у којој се каже да је поруџбина успешно послата.
- Корисник отвара базу података и проверава да ли су детаљи поруџбине исти као они унети на веб локацији.
3) Ниво од краја до краја
Токови пословања и случајеви коришћења извршавају се на корисничком интерфејсу.
- Направите поруџбину са више ставки -
- Корисник отвара веб локацију.
- Иде да наручи.
- Распитује се о важећем производу и количини их додаје у корпу.
- Остали важећи производи се додају са важећим количинама и наруџба се чува. Плаћање се врши путем новог начина плаћања и врши се наруџба.
- Требало би да се прикаже порука са поруком „Поруџбина је успешно постављена“.
- Тестер треба да потврди да се цео ток одвија без искривљавања података.
Закључак:
Скицирањем праве стратегије за тестирање, ресурсе, алате и усаглашеност за пружање добре услуге, СОА тестирање може пружити потпуно и савршено тестирану апликацију.