Комплетан водич за употребу и испитивање случајева употребе

use case use case testing complete tutorial

За почетак, хајде да разумемо „Шта је случај употребе?“ а касније ћемо разговарати „Шта је тестирање корисних случајева?“ .

Случај употребе је алат за дефинисање потребне интеракције са корисником. Ако покушавате да креирате нову апликацију или измените постојећу, води се неколико дискусија. Једна од критичних расправа коју морате водити је како ћете представљати захтев за софтверским решењем.

Пословни стручњаци и програмери морају се међусобно разумети у вези са захтевом, јер је то врло тешко постићи. Било који стандардни метод за структурирање комуникације између њих заиста ће бити благодат. То ће, заузврат, смањити погрешне комуникације и ево места на коме се користи случај употребе.

Овај водич ће вам дати јасну слику о концепту случаја употребе и тестирања, покривајући тиме различите аспекте који су у њега укључени, практичним примерима за лако разумевање било кога ко је потпуно нов у концепту.

Шта ћете научити:

• Случај употребе
• Ко користи документе „Усе Цасе“?
• Врсте случајева употребе
  • # 1) Сунчани дан Користите случајеве
  • # 2) Случајеви кишног дана
• Елементи у употреби
• Заступање
• Како написати случај употребе?
• Користите дијаграм случаја
• Корисничке радње
• Шта је испитивање случаја употребе?
  • Неке чињенице
  • Како створити образац за тест случај?
• Закључак
• Препоручено читање

Случај употребе

Случај коришћења игра значајну улогу у различитим фазама животног циклуса развоја софтвера. Случај употребе зависи од „Корисничких радњи“ и „Одзива система“ на Корисничке радње.

То је документација о „Радњама“ које изводи Глумац / Корисник и одговарајуће „Понашање“ Система према Корисничком „Радњу“. Користите случајеве може или не мора довести до постизања циља „Глумца / корисника“ у интеракцији са системом.

У Случају употребе ћемо описати ‘Како ће систем одговорити на дати сценарио?’ . „Кориснички је оријентисан“, а не „системски оријентисан“.

Оријентисан је на корисника: Навешћемо „које радње чини корисник?“ И „Шта глумци виде у систему?“.

Није „системски оријентисан“: Нећемо прецизирати „Који су улазни подаци дати систему?“ И „Који су излазни подаци које систем даје?“.

Развојни тим треба да напише „Случајеве употребе“, јер фаза развоја у великој мери зависи од њих.

Писац случајева, чланови тима и купци допринеће стварању ових случајева. Да бисмо их створили, треба да имамо окупљени развојни тим и да тим буде свестан концепата пројекта.

Након примене случаја, документ се тестира и понашање система се проверава у складу с тим. У случају да велико слово „А“ означава „глумца“, слово „С“ означава „систем“.

Ко користи документе „Усе Цасе“?

Ова документација даје потпун преглед различитих начина на које корисник комуницира са системом ради постизања циља. Боља документација може на много лакши начин да идентификује захтеве за софтверским системом.

Ову документацију могу користити програмери софтвера, тестери софтвера као и заинтересоване стране.

Употреба докумената:

• Програмери користе документе за примену кода и његово дизајнирање.
• Тестери их користе за креирање тест случајева .
• Учесници у послу користе документ за разумевање софтверских захтева.

Врсте случајева употребе

Постоје 2 типа.

Су:

• Сунчан дан
• Кишни дан

# 1) Сунчани дан Користите случајеве

Они су примарни случајеви који ће се највероватније догодити када све буде добро. Њима се даје приоритет у односу на остале случајеве. Када завршимо случајеве, дајемо га пројектном тиму на увид и осигуравамо да смо покрили све потребне случајеве.

јава прослеђивање низа методи

# 2) Случајеви кишног дана

Они се могу дефинисати као списак ивичних случајева. Приоритет таквих случајева доћи ће након „Случајева сунчане употребе“. Можемо потражити помоћ заинтересованих страна и менаџера производа да бисмо одредили случајеве као приоритет.

Елементи у употреби

Доље су дати различити елементи:

1) Укратко Опис : Кратки опис који објашњава случај.

2) глумац : Корисници који су укључени у радње случајева употребе.

3) Предуслов : Услови које треба задовољити пре него што случај почне.

4) Основни Проток : „Основни ток“ или „Главни сценарио“ је уобичајени ток рада у систему. То је ток трансакција које су глумци извршили ради постизања својих циљева. Када глумци ступе у интеракцију са системом, јер је то нормалан ток посла, неће бити грешака и глумци ће добити очекивани резултат.

5) Алтернативни проток : Поред нормалног тока посла, систем може имати и „Алтернативни ток рада“. Ово је ређа интеракција коју корисник врши са системом.

6) Изузетак проток : Ток који спречава корисника да постигне циљ.

7) Пост Услови : Услови које треба проверити након окончања случаја.

Заступање

Случај је често представљен у обичном тексту или дијаграму. Због једноставности дијаграма примена, било која организација сматра га необвезним

Пример случаја употребе:

Овде ћу објаснити случај „пријављивања“ у „Систем управљања школом“.

Бодови које треба забележити

• Уобичајене грешке које учесници раде са Усе Цасе је то што садржи превише детаља о одређеном случају или нема довољно детаља.
• Ово су текстуални модели, ако је потребно, можемо им додати или не визуелни дијаграм.
• Одредити применљиви предуслов.
• Напишите кораке процеса у правилном редоследу.
• Наведите захтеве за квалитетом процеса.

Како написати случај употребе?

Тачке сажете у наставку помоћи ће вам да напишете следеће:

=> Када покушавамо да напишемо случај, прво питање које треба да се постави је „Шта је примарна употреба за купца?“ Ово питање ће вас натерати да своје случајеве напишете из перспективе корисника.

=> Морали смо добити образац за ове.

=> Она мора бити продуктивна, једноставна и јака. Снажан случај употребе може импресионирати публику чак и ако има мањих грешака.

=> Требали бисмо то нумерисати.

=> Корак процеса требали бисмо написати по његовом редоследу.

=> Дајте правилно име Сценариома, именовање се мора извршити према намени.

=> Ово је понављајући поступак, што значи да када их напишете први пут неће бити савршен.

=> Идентификујте актере у систему. У систему можете пронаћи гомилу глумаца.

Пример ,ако узмете у обзир веб локацију за е-трговину попут Амазона, тамо можемо пронаћи глумце попут купаца, продаваца, велетрговаца, ревизора, добављача, дистрибутера, бриге о купцима итд.

У почетку, размотримо прве глумце. Можемо имати више глумаца који се понашају исто.

На пример , оба купца / продавца могу да „отворе рачун“. Исто тако, и „Купац и продавац“ могу да „претражују ставке“. Дакле, ово су дупликати понашања и њих треба елиминисати. Осим кориштења дупликата случајева, морамо имати и опћенитије случајеве. Због тога морамо да уопштимо случајеве како бисмо избегли дуплицирање.

=> Морамо одредити примењиви предуслов.

Користите дијаграм случаја

Дијаграм случаја употребе је сликовни приказ радњи корисника у систему. Пружа одличан алат у овом контексту, ако дијаграм садржи пуно актера, онда је то врло лако разумети. Ако је то дијаграм на високом нивоу, неће делити пуно детаља. Приказује сложене идеје на прилично основни начин.

Слика број: УЦ 01

Као што је приказано у Слика број: УЦ 01 представља дијаграм где Рецтангле представља „Систем“, овални представља „Усе Усе“, Стрелица представља „Однос“, а Ман представља „Корисника / Глумца“. Приказује систем / апликацију, затим приказује организацију / људе који са њом ступају у интеракцију и приказује основни ток „Шта систем ради?“

Слика број: УЦ 02

Фиг. Но: УЦ 03 - Употреби дијаграм случаја за пријаву

Ово је дијаграм случаја употребе случаја „Пријава“. Овде имамо више од једног глумца, сви су смештени ван система. Ученици, наставници и родитељи сматрају се примарним актерима. Због тога су сви постављени на левој страни правоугаоника.

Администратор и особље сматрају се секундарним глумцима, па их постављамо на десну страну правоугаоника. Глумци се могу пријавити у систем, па глумце и случај пријаве повезујемо конектором.

Остале функције које се налазе у систему су Ресетовање лозинке и Заборављена лозинка. Сви су повезани са случајем пријаве, па их повезујемо са конектором.

Корисничке радње

То су радње које корисник извршава у систему.

На пример: Претраживање на лицу места, додавање предмета у фаворите, покушај контактирања итд.

Белешка:

• Систем је „шта год развијате“. То може бити веб локација, апликација или било која друга софтверска компонента. Генерално је представљен правоугаоником. Садржи случајеве употребе. Корисници су смештени изван „правоугаоника“.
• Користите случајеве су углавном представљени овалним облицима који специфицирају акције у њему.
• Глумци / корисници су људи који користе систем. Али понекад то могу бити други системи, особа или било која друга организација.

Шта је испитивање случаја употребе?

Долази под техником испитивања функционалне црне кутије. Како се ради о тестирању црне кутије, неће бити било какве инспекције кодова. У овом одељку је изнето неколико занимљивих чињеница о овоме.

Осигурава да ли путања коју користи корисник ради како је предвиђено или не. Осигурава да корисник може успешно извршити задатак.

Неке чињенице

• Не врши се тестирање да би се одлучило о квалитету софтвера.
• Чак и ако је то врста крајњег тестирања, то неће обезбедити целокупну покривеност корисничке апликације.
• На основу резултата теста познатог из тестирања случаја употребе, не можемо да одлучимо о примени производног окружења.
• Откриће недостатке у интеграционом тестирању.

Пример испитивања случаја употребе:

Размотрите сценарио у којем корисник купује артикал са веб локације за куповину на мрежи. Корисник ће се прво пријавити у систем и започети претрагу. Корисник ће одабрати један или више предмета приказаних у резултатима претраге и он ће их додати у корпу.

После свега овога, одјавиће се. Дакле, ово је Пример логички повезаних низа корака које ће корисник извршити у систему да би извршио задатак.

Ток трансакција у читавом систему од краја до краја тестиран је у овом тестирању. Случајеви коришћења су обично пут који ће корисници највероватније користити да би постигли одређени задатак.

Дакле, ово олакшава проналажење недостатака у Случајевима коришћења, јер укључује пут на који је већа вероватноћа да ће корисници наићи када корисник први пут користи апликацију.

Корак 1: Први корак је преглед докумената Усе Цасе.

Морамо да прегледамо и осигурамо да су функционални захтеви потпуни и тачни.

Корак 2: Морамо бити сигурни да су случајеви употребе атомски.

На пример: Размотрите „Систем управљања школом који има много функционалности као што су„ Пријава “,„ Прикажи детаље о ученику “,„ Прикажи оцене “,„ Прикажи присуство “,„ Контактирајте особље “,„ Накнаде за пријављивање “итд. У овом случају покушавамо да припремите случајеве коришћења за функцију „Пријава“.

Морамо бити сигурни да се ниједна од уобичајених токова посла не мора мешати са било којом другом функционалношћу. Мора бити у потпуности везан само за функцију „Пријави се“.

Корак 3: Морамо да прегледамо нормалан ток рада у систему.

Након прегледа тока посла, морамо се побринути да је потпун. На основу знања о систему или чак домену, можемо открити кораке који недостају у току рада.

Корак 4: Уверите се да ли је алтернативни ток посла у систему завршен.

Корак 5: Требали бисмо бити сигурни да је сваки корак у случају употребе проверен.

Сваки корак објашњен у тестирању случаја употребе може се тестирати.

На пример, неке трансакције кредитним картицама у систему се не могу тестирати из безбедносних разлога.

Корак 6: Једном када оживимо ове случајеве, тада можемо да напишемо тест случајеве.

Морамо написати тест случајеве за сваки нормалан проток и алтернативни проток.

На пример , Размотрите случај ‘Покажи оцене ученика’ у систему школског управљања.

Назив случаја употребе: Покажи студентске оцене

Глумци: Студенти, наставници, родитељи

Предуслов:

1) Систем мора бити повезан на мрежу.

2) Глумци морају да имају ‘студентску књижицу’.

Случај употребе за „Показивање студентских оцена“:

Одговарајући тест случај за случај „Покажи студентске оцене“:

Имајте на уму да овде приказана табела тест случајева садржи само основне информације. У наставку је детаљно објашњено „Како направити образац за тест случај“.

Табела приказује „Тест Цасе“ који одговара случају „Схов Студент Марк“ као што је приказано горе.

Најбољи начин да напишете тест случајеве је да прво напишете тестове за „Главни сценарио“, а затим да их напишете за „Алтернате Степс“. „ Кораци ’ у тест случајевима се добијају из докумената Усе Цасе. Прво „ Корак' у случају „Прикажи студентску оцену“, „Ентер Студент Наме“ постаће прва Корак у „Тест Цасе-у“.

Корисник / глумац мора бити у могућности да уђе у њега. Ово постаје Очекивани резултат .

Можемо потражити помоћ технике дизајнирања тестова попут „ анализа граничне вредности ’ , „Подела еквиваленције“ док припремамо тест случајеве. Техника дизајна теста помоћи ће да се смањи број тест случајева и тиме смањи време потребно за тестирање.

Како створити образац за тест случај?

Када припремамо тест случајеве, морамо размишљати и понашати се попут крајњег корисника, тј. Ставити се на крај крајњег корисника.

На тржишту је доступно неколико алата који помажу у овом контексту. ' ТестЛодге ’је један од њих, али није бесплатан алат. Морамо је купити.

Потребан нам је образац за документовање тест случаја. Размотримо уобичајени сценарио „пријављивање на ФЛИПКАРТ“ који нам је свима познат. Гоогле табела се може користити за израду табеле тест примера и дељење са члановима тима. За сада користим Екцел документ.

Ево примера

=> ПРЕУЗМИТЕ овај образац табеле тест примера овде

Прво, назовите листу са одговарајућим именом. Пишемо тест случајеве за одређени модул у пројекту. Дакле, морамо додати 'Назив пројекта' и ‘Пројектни модул ’Колоне у табели тест случајева. Документ мора садржати име творца тест случајева.

Стога додајте „Направио“ и 'Датум креирања' колоне. Неко мора да прегледа документ (вођа тима, менаџер пројекта итд.), Па додајте ‘Прегледао’ колона и „Прегледан датум“ .

Следећа колона је „Тестни сценарио“ , овде смо пружили Пример сценарија теста ‘Верификујте Фацебоок пријаву’ . Додајте колоне „ИД тестног сценарија“ и „Опис тест случаја“ .

За сваки тест сценарио ћемо написати 'Тест случајева ’. Дакле, додајте колоне „ИД тест случаја“ и ‘Опис тест случаја ’. За сваки тестни сценарио биће „Услов постовања“ и „Предуслов“ . Додајте колоне „Пост-Цондитион“ и „Пре-Цондитион“.

Друга важна колона је 'Тест подаци' . Садржи податке које користимо за тестирање. Тест сценарио мора претпоставити очекивани резултат и стварни резултат. Додајте колону 'Очекивани резултат' и „Стварни резултат“. „Статус“ показује резултат извршења тест сценарија. Може бити или проћи / проћи.

Тестери ће извршити тест случајеве. Морамо то укључити као ‘Извршио’ и „Датум извршења“ . Додаћемо „Команде“ ако их има.

Закључак

Надам се да бисте имали јасну представу о случајевима примене и испитивању случајева употребе.

Писање ових случајева је итеративни процес. За писање ових случајева треба вам само мало праксе и добро познавање система.

Укратко, можемо да користимо „Користи испитивање случаја“ у апликацији да бисмо пронашли везе које недостају, непотпуне захтеве итд. Ако их пронађемо и изменимо систем, систем ће постићи ефикасност и тачност.

Да ли имате претходно искуство са случајевима коришћења и тестирањем? Слободно делите са нама у одељку за коментаре испод.

Препоручено читање

• Функционално тестирање вс нефункционално тестирање
• Дубински водичи за помрачење за почетнике
• Алфа тестирање и бета тестирање (потпун водич)
• Водич за тестирање ДевОпс-а: Како ће ДевОпс утицати на КА тестирање?
• Најбољи алати за тестирање софтвера 2021. године (КА Тест Аутоматион Тоолс)
• Водич за испитивање употребљивости: Комплетан водич за почетак
• Водич за ГУИ тестирање: Комплетан водич за тестирање корисничког интерфејса (УИ)
• Водич за испитивање разарања и испитивања без разарања