Мени

Писање тест примера из СРС документа (ПРЕУЗИМАЊЕ примерака тест пројеката у реалном времену)

writing test cases from srs document

Испробајте Наш Инструмент За Елиминисање Проблема

Писање тест случајева из СРС документа (преузмите примере тест примера уживо) - Софтверско тестирање КА Траининг Даи 4

Само да поновимо оно што смо до сада радили - пробијамо се кроз Обука за тестирање софтвера мини-курс на живом пројекту ОрангеХРМ.

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

  1. Преглед СРС-а,
  2. Тест сценариј / идентификација опсега испитивања и
  3. Документирао план испитивања .

Писање тест случајева из СРС документа

Сад смо дошли до дела који је стварна ствар,тест случајеви.

Као што је назначено у чланку пре овога: Тест случајеве документује КА тим док траје СДЦ-ова фаза кода. Другим речима, док Дев тим гради софтверски систем, тим за тестирање се припрема са тест случајевима који би нам помогли да тестирамо систем када је спреман, тј. На крају фазе кода.

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

Идемо одмах до тога.

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

Основи писања тест случајева

# 1) Ако су се сценарији испитивања односили на „Шта ћемо тестирати“ на АУТ - тест случајеви су у питању „Како ћемо тестирати један захтев“.

На пример , ако је тест тест „Потврдите администраторску функционалност пријаве“ - То би донело 3 тест случаја (или услова) - Пријава (успешна), Пријављивање неуспешно када се унесе нетачно корисничко име, Неуспешно пријављивање када се унесе нетачна лозинка . Сваки тест случај би, заузврат, имао кораке за решавање како можемо да проверимо да ли је одређени услов теста задовољен или не.

#два) Улаз за креирање документа са тест примером је ФРД, сценарији тестирања створени у претходном кораку и сви други референтни документи ако су присутни.

# 3) Документација о тест примерима важан је резултат КА тима и дели се са БА, ПМ и другим тимовима када се то уради ради њихових повратних информација.

# 4) Посао је подељен међу члановима тима и сваки члан ће бити одговоран за стварање тест случајева за одређени модул или део одређеног модула.

# 5) Баш као и код сценарија за тестирање, пре него што започнемо са документацијом Тест примера, мора се договорити заједнички образац. Практично све се може користити за креирање тест случајева. 2 најчешће коришћена избора су МС Екцел и МС ворд.

# 6) Тхе МС ворд шаблон изгледа отприлике овако:

МС цасе образац за тест случајеве

# 7) Тхе Екцел образац може изгледати овако:

ка примери тестова за обуку клс

# 8) Из горња два шаблона може се уочити да су поља (или компоненте) које чине тестни случај једнака, једина разлика је начин на који су организована.

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

Поља у тест случајевима

Узмимо тренутак, да посматрамо поља која су део тест случаја.

Ид тест случаја и опис тест случаја су генерички.

Остала поља се могу објаснити на следећи начин:

  • Предуслов: Стање АУТ (стање у којем АУТ мора бити да бисмо могли започети).
  • Улазни: Кораци за унос података. За ове кораке важно је напоменути какве су улазне информације потребне - тест подаци.
  • Тачка валидације / окидач / акција : Шта је узрок валидације? (Кликните на дугме или пребаците или приступ линку. Уверите се да постоји најмање једна тачка провере тест случаја - у супротном ће све бити унос података без ичега што треба тражити. Такође да бисмо осигурали да имамо довољно модуларности, покушајте да не комбинујете превише тачака валидације у један тест случај. Оптимално је 1 по тест случају.)
  • Излаз: Очекивани резултат.
  • Постуслов: Ово су додатне информације које се пружају у корист тестера само да би тест случај био проницљивији и информативнији. То укључује објашњење шта се дешава или шта се може очекивати од АУТ-а након што се изврше сви кораци у тестном примеру.

Такође погледајте => Узорак предлошка за тест случај

Узорак тест примера пројеката уживо (преузимање)

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

На основу горе поменутог процеса креирали смо неколико примера тестова за модул ОрангеХРМ налога. Они би требало да вам дају тачан формат тест примера и идеју о томе како приступити писању тест случајева.

=> Преузмите узорак документа о тест случајевима за наш пројекат уживо овде .

Белешка: Постоји неколико слика упућених на узорке КСЛС докумената за тест примере. Ако ово гледате у старијој верзији МС Оффице, можда ћете се суочити са проблемима компатибилности.

У наставку смо навели те слике према њиховим именима у КСЛС датотекама:

Погледајте слику 1
Погледајте слику 2
Погледајте слику 3

Ето, све урађено и све добро.

Методи писања / оптимизације тест случајева

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

Испод су наведене везе које пружају додатне информације о овим методама.

како уклонити елемент из низа у јави

Користећи горње технике и пратећи општи поступак креирања тест примера, креирамо скуп тест случајева који би ефикасно тестирали постојећу апликацију.

Неколико важних тачака које треба забележити

  • Тест случајеви које креирамо нису само референтна тачка за КА фазу већ и за УАТ.
  • Случајеви интерних тестова су Рецензиран у тиму .
  • Када се тест случајем не реши одређена ситуација - правило је да се неће тестирати. Дакле, ово је добро место за проверу да ли тестни пакет који смо креирали постиже циљ од 100% покривености тестом или не. Да би се то урадило, може се створити матрица сљедивости. Погледајте све што можете знати о Овде је матрица следљивости .
  • Алати - Алати за управљање тестовима попут КЦ , кТест помозите нам у активности стварања тест случајева. Да бисте видели пример како се могу решити тест примери помоћу Центра за квалитет, погледајте ово Водич за Центар за квалитет .
  • Алати за аутоматизацију могу се користити за стварање тест случајева - у том случају се називају тест скриптама.
Про врх :Извршите проверу правописа и граматике на сваком документу који креирамо. Ми смо представници квалитета за ИТ пројекте - и то се не одражава позитивно на нас ако су сами наши производи лошијег квалитета.

То нас доводи до циља још једног занимљивог сегмента.

Закључак

Крај процеса израде теста / фазе дизајна теста (СТЛЦ) и крај фазе кода (СДЛЦ) обично ће означити крај фазе припреме теста и почетак фазе извођења теста.

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

=> КА тренинг дан 5: Извршење теста

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

Обавестите нас о својим питањима и коментарима у наставку. Срећно тестирање!

ПРЕВ Туториал |. | СЛЕДЕЋА Лекција

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

^