how classify positive
Можете нешто учинити на лакши или тежи начин - важно је да то учините. Постоји неколико једноставних свакодневних ствари, али без самопоуздања нешто у вези с њима не уклапа се у наше мисли и обим успеха је погодак или промашај.
Узмимо један једноставан пример данас и пронађимо пречице које ће не само разјаснити концепте већ и осигурати да ћете их увек правилно исправити.
Позитивна или негативна класификација тест сценарија / случајева
Процес дизајнирања теста је троструки:
- Идентификујте захтеве
- Напишите сценарије теста (показивачи у једном реду шта треба тестирати)
- Дизајнирајте детаљна упутства о начину тестирања (тест примери)
При писању сценарија теста класификујемо их на позитивне и негативне услове. (Кад боље размислите, да ли је заиста важно направити ову класификацију? Ако да, којој сврси она служи? Све их ионако морамо тестирати, зар не?) И мене то углавном погађа. Али мислим да је то покушај успостављања адекватне покривености и помаже да се утврди да тестирамо и срећне и алтернативне путеве којима би систем требало да иде. Молимо вас да коментаришете испод ако знате неке друге разлоге због којих је то учињено.
Погледајмо сада неколико захтева, напишите сценарије тестирања и извршите класификацију.
# 1) Пријава :Корисник који унесе исправне акредитиве улази у систем. Ако су акредитиви нетачни, приступ се одбија и приказује се порука о грешци.
# 2) Погледајте производе: Претпоставимо да постоји мрежни каталог свих производа доступних у систему и он их све приказује на листи када се кликне на везу „Прикажи производе“.
# 3) Одјава: Када се кликне на овај линк, корисник се одјављује.
Написаћу неколико сценарија тестирања за ове захтеве.
Табела А:Прави начин
| ИД сценарија теста | Опис сценарија теста | Позитивно Негативно |
|---|---|---|
| ТС_логин_01 | Потврдите ако се корисник успешно пријави ако су унесени акредитиви тачни | Позитивно |
| ТС_логин_02 | Потврдите ако кориснику није дозвољен приступ када су унесени акредитиви нетачни | Негативно |
| ТС_ВиевПродуцт_01 | Потврдите да ли су све ставке наведене када се кликне на везу Прикажи производе | Позитивно |
| ТС_логоут_01 | Потврдите да ли је већ пријављени корисник одјављен из система када се кликне на одјаву | Позитивно |
Међутим, понекад видим тест сценарио написан овако.
Табела Б: Уноси обележениНетосу неважећи сценарији теста.
| ИД сценарија теста | Опис сценарија теста | Позитивно Негативно |
|---|---|---|
| ТС_логин_01 | Потврдите ако се корисник успешно пријави ако су унесени акредитиви тачни | Позитивно |
| ТС_логин_02 | Потврдите ако кориснику није дозвољен приступ када су унесени акредитиви нетачни | Негативно |
| ТС_ВиевПродуцт_01 | Потврдите да ли су све ставке наведене када се кликне на везу Прикажи производе | Позитивно |
| ТС_ВиевПродуцт_02 | Потврдите ако сви артикли нису наведени када се кликне на везу за преглед производа | Негативно |
| ТС_логоут_01 | Потврдите да ли је већ пријављени корисник одјављен из система када се кликне на одјаву | Позитивно |
| ТС_логоут_02 | Потврдите ако се корисник не одјави када се кликне на везу за одјаву | Негативно |
За успешан случај пријаве постоји једнак и супротан случај када неће бити успешан. Не би требало да сви захтеви буду такви и за њих заиста не постоји принуда да напишу негативан сценарио.
Закључак: Не би сваки захтев требао имати негативне случајеве.
У овом тренутку, ако размишљате „Како ћу знати“ или „Још увек нисам сигуран“, ево једноставног варалица које ће вам помоћи.
Ц ++ питања за интервју и одговори за искусне
Ако постоји једна генерализација коју можемо да учинимо у вези са апликацијама, јесте да су оне динамичне. Унос (подаци, кликови итд.) Који пружамо довешће до тога да апликација буде на одређени начин и генерише одређени излаз.
Једноставна корелација између улазних и излазних променљивих олакшаће ово разумевање.
Покушајмо следеће за пријаву:
| Улазни | Оутпут | Позитивно Негативно |
|---|---|---|
| Тачно (тачне информације за пријаву) | Тачно (Корисник пријављен) | Позитивно |
| Нетачно (нетачне информације о пријави) | Тачно (порука о грешци) | Негативно |
| Тачно (тачне информације за пријаву) | Нетачно - пријава не успева | Буг / Дефецт |
| Нетачно (нетачне информације о пријави) | Нетачно (систем их пријављује) - „Ох, ужас!“ :) | Грешка / квар |
Дакле, видите из горње табеле, можемо рећи да примарни проток категоризујемо као позитиван, а алтернативни проток (такође исправно понашање апликације) означавамо као негативан.
Последња два случаја у црвеној боји су у ствари грешке. Тестирање се односи на валидацију захтева и када они не раде како је предвиђено, проналазимо грешке. С обзиром да не вршимо валидацију за недостатке, последња два случаја су неважећа.
Пратећи исти ред размишљања и примењујући га на одјаву и преглед производа, ево шта ћете добити.
| Улазни | Оутпут | Позитивно Негативно |
|---|---|---|
| Одјава (клик) | Тачно - Одјава се | Позитивно |
| Одјава (клик) | Нетачно - остаје пријављен | Грешка / квар |
| Погледајте производе (кликните) | Тачно - приказује производе | Позитивно |
| Погледајте производе (кликните) | Нетачно (није листа или нетачан приказ листе) | Грешка / квар |
Као што видите, за ове захтеве не постоји могућност давања нетачног уноса. Због тога не морају бити написани негативни сценарији / случајеви тестирања.
Закључне мисли:
Систем може бити изложен позитивном или негативном инпуту. У сваком случају, систем би требао генерирати исправан излаз. Случајеви који се баве тачним уносом су позитивни. Они који се тичу тачног, али негативног уноса су негативни.
Неколико упута:
# 1) Када је тестови од краја до краја су написани за УАТ или чак за системско тестирање, увек позитивни тест случајеви чине то.
#два) Понекад је класификација субјективна.На пример, ако бришем нешто на некој веб локацији и примим поруку потврде која ме пита „Да ли сте сигурни да желите да избришете овај унос?“ са ОК и Цанцел опцијама - по мени је клик на Цанцел позитиван случај. Али неки мисле да је негативан јер је примарна намера опције „Избриши“ брисање, а не отказивање операције. Дакле, пресуда тестера такође игра улогу у класификацији.
# 3) За сваки позитиван случај не постоји увек једнак и супротан негативан случај.
Горња метода увек гарантује тачну класификацију. Пробајте сами и реците ми ако не. :) „Пречица је често погрешан рез.“ - Али у овом случају то можда није случај!
За формалније објашњење негативног тестирања, погледајте => Шта је негативно тестирање и како писати негативне тест случајеве?
О аутору: Овај чланак је написала чланица СТХ тима Свати С. Придружите се њеном курсу КА обуке уживо овде: „ Најбоља обука за тестирање софтвера коју ћете икада добити! '
Обавестите нас да ли вам се свидео овај чланак и желите ли да у основним чланцима будете лако објаснили такве основне концепте.
Ваши коментари, питања, повратне информације и читалачка публика су овде високо цењени и цењени. Срећно тестирање!
Препоручено читање
- Позитивно тестирање: значење и заслуге објашњени стварним сценаријима теста
- Како написати тест случајеве за страницу за пријаву (примери сценарија)
- Шта је негативно тестирање и како писати негативне тест случајеве?
- Како написати тест случајеве за банкомат (примери сценарија)
- Ефикасни сценарији за скриптирање и решавање проблема са селенијем - Водич за селениј # 27
- Врсте тестирања миграције: Са сценаријима испитивања за сваки тип
- КТП водич # 24 - Коришћење виртуелних објеката и сценарија опоравка у КТП тестовима
- Тестирање здравствених апликација - савети и важни сценарији испитивања (2. део)