Овај водич објашњава шта је тестни сценарио заједно са значајем, имплементацијом, примерима и шаблонима тестног сценарија:

Свака софтверска функционалност/функција која се може тестирати се каже да је тестни сценарио. Перспектива крајњег корисника се узима у обзир приликом писања тестних сценарија.

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

Шта је тестни сценарио?

Размотрите хипотетичку ситуацију: Постоји огроман океан. Морате путовати преко океана од једне обале до друге. На пример, од Мумбаја, обале Индије до Коломба, обале Шриланке.

Начин путовања за који можете да изаберете је:

(и) Ваздушни путеви: Идите на лет за Коломбо

(ии) Водни путеви: Преферирајте брод за путовање у Коломбо

(иии) Железнице: Идите возом до Шриланке

Сада за тестне сценарије: Путовање од обале Мумбаја до обале мора у Коломбу је функционалност коју треба тестирати.

Сценарији за тестирање укључују:

  • Путовање ваздушним путем,
  • Путовање пловним путевима или
  • Путовање железницом.

Ови тестни сценарији ће имати тестне случајеве.

Тест случајеви који се могу написати за горенаведене тестне сценарије укључују:

Тестлокално и отпрема се по доступности интернет везе. 6 Промене које је извршило више корисника се не преписују. 7 Више корисника може радити на једном документу. 8 Рад се чува ако се интернет веза изгуби током отпремања датотеке. 9 Ограничења дељења се примењују исправно. 10 Корисници са ограничењем приказа не могу да уносе никакве измене у документе. 11 Документи се могу објавити на интернету за ширу јавност. 12 Измене урађене на документи се чувају са временском ознаком &амп; детаљи о аутору.

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

Ови критеријуми прихватања играју главну улогу у планирању итеративног процеса и никада их не треба занемарити. Њихово дефинисање унапред и унапред избегава изненађења или шокове на крају спринта или ослобађања

Дати предуслов.

Када да извршите акцију.

Онда се очекује резултат.

Формати Датог,Када и Тада су корисни за одређивање критеријума прихватања.

Пример шаблона тест сценарија

Користите ИД приче # ИД тестног сценарија # Верзија # Сценарији тестирања # Број тестних случајева Важност
УСИД12.1 ТСИД12.1.1 Кин12.4 Провери да ли се Киндле апликација исправно покреће. 4 Висока
УСИД12.1 ТСИД12.1.2 Кин12.4 Провери капацитет складиштења Киндле апликације. 3 Средњи

Закључак

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

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

Сценарио: Путовање ваздушним путем

Пробни случајеви могу укључивати сценарије као што су:

  1. Лет је према предвиђеном времену .
  2. Лет није по предвиђеном времену.
  3. Наступила је ванредна ситуација (јаке падавине и олуја).

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

Сада пређимо на сценарије технолошких тестова.

Све што се може тестирати је тестни сценарио. Стога можемо рећи да се свака софтверска функционалност која се тестира може поделити на више мањих функционалности и може се назвати 'тестним сценаријом'.

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

Сценарио тестера је процес у коме тестер тестира софтверску апликацију из перспективе крајњег корисника. Перформансе и квалитет софтверске апликације се темељно процењују пре имплементације у производно окружење.

Важност тестног сценарија

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

Сценарио теста: Направите омогућено плаћање за такси услуге.

Ово ће имати више тестних случајева као што је наведено у наставку:

(и) Метод плаћања који ће се користити: ПаиПал, Паитм, кредитна/дебитна картица.

(ии) Извршено плаћање је успешно.

(иии) Извршено плаћање је неуспешно.

(ив) Процес плаћања је прекинут између.

(в) Није могуће приступити начинима плаћања.

(ви) Апликација се  поквари између.

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

Разлика између тестног сценарија и тестног случаја

Тест сценарио Тест случајеви
Тест сценарио је концепт. Тест случајеви су решења за проверу тог концепта.
Сценарио за тестирање је функционалност високог нивоа. Тест случајеви су детаљна процедура за тестирање функционалности високог нивоа.
Сценарији за тестирање су изведени из захтева/корисничких прича. Тест случајеви су изведени из тестних сценарија .
Сценарио за тестирање је 'Која функционалност треба да се тестира' Тест случајеви су „Како тестирати функционалност“.
Сценарији за тестирање имају више тестних случајева. Тест случај може, али не мора бити повезан са више тестних сценарија.
Појединачни сценарији теста се никада не понављају. Појединачни тестни случај се може користити више пута у различитим сценаријима.
Потребна је кратка документација. Потребна је детаљна документација.
Неопходне су сесије размишљања да би се финализовао тест сценарио. Детаљно техничко познавање софтверске апликације је потребно
Уштеда времена јер ситни детаљи нису потребни. Одузети време јер треба водити рачуна о сваком детаљу од минуте.
Трошкови одржавања су ниски јер су потребни ресурсиниско. Трошкови одржавања су високи јер су потребни ресурси високи

Зашто су тестни сценарији неопходни?

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

  • Узмите пример тестног сценарија за резервацију такси.
  • Сценарији могу бити опције резервације таксија, начини плаћања, ГПС праћење, мапа пута приказана исправно или не, детаљи о таксију и возачу приказани су исправно или не, итд., сви су наведени у шаблону тест сценарија.
  • Сад претпоставимо да је тест сценарио да бисте проверили да ли су услуге локације укључене, ако нису укључене, прикажите поруку „Укључи услуге локације. Овај сценарио је пропуштен и није наведен у шаблону тест сценарија.
  • Сценарио 'Услуга локације' доводи до других тестних сценарија у вези са њим.

Ови могу бити :

    • Услуга локације је засивљена.
    • Услуга локације је укључена, али нема интернета.
    • Ограничења услуге локације .
    • Приказује се погрешна локација.
  • Недостатак једног сценарија може значити пропуштање многих других кључних сценарија или тест случајева . Ово може имати велики негативан утицај током имплементације софтверске апликације. Ово резултира великим губитком средстава (рокова).
  • Сценарији теста у великој мери помажу у избегавању исцрпног тестирања . Осигурава да су сви кључни иОчекивани пословни токови се тестирају, што додатно помаже у енд-то-енд тестирању апликације.
  • Ово штеде време. Такође, није потребан много детаљнији опис према тестним случајевима. Једнолинијски опис је прецизиран о томе шта треба тестирати.
  • Сценарији теста се пишу након браинсторминг сесија чланова тима. Отуда је вероватноћа пропуштања било ког сценарија (кључног или мањег) минимална. Ово се ради имајући у виду техничке детаље и пословни ток софтверске апликације.
  • Штавише, сценарије тестирања може одобрити или клијент пословног аналитичара или обоје који имају експлицитно знање о апликацији која се тестира.

Сценарији теста су стога неизоставни део СДЛЦ-а.

Имплементација тестних сценарија

Да видимо имплементацију тестних сценарија или како да напишемо тест сценарије:

  • Епик/пословни захтеви су формирани.
    • Пример Епиц : Направите Гмаил налог. Епиц може бити главна карактеристика апликације или пословног захтева.
  • Епицс је подељен на мање корисничке приче у спринтовима.
  • Корисничке приче су изведене из Епицс-а. Ове корисничке приче морају бити базиране и одобрене од стране заинтересованих страна.

  • Сценарији теста су изведени из корисничких прича или БРС (Документ пословних захтева), СРС (Системски захтевСпецифицатион Доцумент), или ФРС (Фунцтионал Рекуиремент Доцумент) који су финализовани и базирани.
  • Тестери пишу сценарије теста.
  • Ове тест сценарије одобрава вођа тима, пословни аналитичар или менаџер пројекта у зависности од организације.
  • Сваки сценарио тестирања мора бити везан за најмање једну корисничку причу.
  • Позитивни као и негативни сценарији теста морају бити идентификовани.
  • Корисничке приче обухватају Критеријуми прихватања као што је :
    • Критеријуми прихватања су листа услова или стања намере за захтеве корисника. Очекивања корисника, а такође и неспоразуми се узимају у обзир приликом писања критеријума прихватања.
    • Они су јединствени за једну корисничку причу и свака корисничка прича мора имати најмање један критеријум прихватања који би требало да се независно тестира.
    • Критеријуми прихватања помажу у одређивању које карактеристике су у обиму, а које су ван опсега пројекта. Ови критеријуми треба да обухватају функционалне и нефункционалне карактеристике.
    • Пословни аналитичари пишу критеријуме прихватања и власник производа их одобрава.
    • Или у неким случајевима, власник производа може сам да напише критеријуми.
    • Сценарији теста се могу добити из критеријума прихватања.

Примери тестних сценарија

#1) Тест сценарији за Киндле апликацију

Киндле је апликација која омогућава е-читачима да тражее-књиге на мрежи, преузмите их и купите. Амазон Киндле пружа читаоцу е-књига стварно искуство држања књиге у руци и читања. Чак је и окретање страница лепо симулирано у апликацији.

Сада да забележимо тест сценарије. ( Напомена: Ограничени сценарији су наведени у наставку да бисте добили општу идеју за писање тестног сценарија. Из њега може бити изведено више тестних случајева).

Сценарији за тестирање # Сценарио за тестирање
1 Провери да ли се Киндле апликација исправно покреће.
2 Проверите прилагођавање резолуције екрана према различитим уређајима, након покретања апликације.
3 Провери да ли је приказани текст читљив.
4 Провери да ли опције увећања и умањивања раде.
5 Провери да ли су компатибилне датотеке увезене у Киндле апликацију читљиве.
6 Провери капацитет складиштења Киндле Апп.
7 Провери да ли функција преузимања ради исправно.
8 Провери да симулација окретања странице ради исправно
9 Провери компатибилност формата е-књига са апликацијом Киндле.
10 Провери фонтове које подржава Киндле апликација.
11 Провери трајање батерије коју користи Киндле апликација.
12 Провери перформансеКиндлеа у зависности од мрежне повезаности (Ви-Фи, 3Г или 4Г).

Из сваког горе наведеног сценарија теста може се извести више случајева тестирања.

#2) Критеријуми прихватања за Гоогле документе

'Гоогле документи' је апликација заснована на вебу за креирање, уређивање и дељење Ворд докумената, табела, слајдова и образаца. Свим датотекама се може приступити на мрежи помоћу веб претраживача који има интернет везу.

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

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

Критеријуми прихватања # Критеријуми прихватања
1 Ворд, Схеетс или Формс се могу успешно отворити без грешке.
2 Шаблони су доступни за документе, листове и слајдове.
3 Доступни шаблони су доступни корисницима.
4 Коришћени шаблон се може уређивати (нпр. фонтови, величина фонта, додавање текста, брисање текста, уметање слајда).
5 Ако интернет веза привремено није доступна, датотека се може сачувати
Скролај на врх