Как да класифицираме положителните и отрицателните сценарии на теста - измамник на тестера

how classify positive

Можете да направите нещо по лесния или по трудния начин - важното е да го направите. Има няколко прости ежедневни неща, но без увереност, нещо в тях не съвсем се вписва в съзнанието ни и степента на успех е хит или пропуск.

Нека вземем един прост пример днес и да намерим преки пътища, които не само ще изяснят концепциите, но и ще се уверят, че винаги ще го правите правилно.

Положителна или отрицателна класификация на тестови сценарии / случаи

Процесът на проектиране на теста е 3 пъти:

• Определете изискванията
• Напишете тестови сценарии (едноредови указатели какво да тествате)
• Проектирайте подробни инструкции за тестване (тестови случаи)

Когато пишем тестови сценарии, ние ги класифицираме в положителни и отрицателни условия. (Когато се замислите, наистина ли е важно да направите тази класификация? Ако да, за каква цел служи? Все пак трябва да ги тестваме, нали?) В по-голямата си част и мен ме бие. Но мисля, че това е опит за установяване на адекватно покритие и помага да се установи, че тестваме както щастливите, така и алтернативните пътища, които системата трябва да обработва. Моля, коментирайте по-долу, ако знаете други причини, поради които това се прави.

Сега, нека да разгледаме няколко изисквания, да напишем тестови сценарии и да извършим класификацията.

# 1) Вход :Потребител, който въведе правилни идентификационни данни, влиза в системата. Ако идентификационните данни са неправилни, достъпът се отказва и се показва съобщение за грешка.

# 2) Преглед на продуктите: Да предположим, че има онлайн каталог на всички продукти, налични в системата, и той ги показва в списък, когато се кликне върху връзката „Преглед на продуктите“.

# 3) Изход: При кликване върху тази връзка потребителят излиза от системата.

Ще напиша няколко тестови сценария за тези изисквания.

Таблица А:Правилният начин

Понякога обаче виждам тестовия сценарий, написан по този начин.

Таблица Б: Маркирани записиНетоса невалидни тестови сценарии.

За успешния случай на влизане има еднакъв и противоположен случай, когато няма да бъде успешен. Не се изискват всички изисквания по този начин и за тях наистина няма принуда да напишат отрицателен сценарий.

Долен ред: Не всяко изискване трябва да има отрицателни случаи.

В този момент, ако мислите „Откъде ще знам“ или „Все още не съм сигурен“, ето един прост лист за мами, който ще ви помогне.

компютърни инструменти за сканиране и ремонт на Windows 10

Ако има едно обобщение, което можем да направим относно приложенията, е, че те са динамични. Въведените от нас данни (данни, кликвания и т.н.) ще доведат до приложението по определен начин и ще генерират определен резултат.

Една проста корелация между входните и изходните променливи ще направи това лесно за разбиране.

Нека опитаме следното за влизане:

И така, виждате от горната таблица, можем да кажем, че категоризираме първичния поток като положителен и алтернативният поток (също правилното поведение на приложението) е маркиран като отрицателен.

Последните два случая в червено всъщност са грешки. Тестването е свързано с валидиране на изискванията и когато те не работят по предназначение, откриваме грешки. Тъй като не правим проверка за дефекти, последните два случая са невалидни.

Следвайки същия ред на мисли и прилагайки го за излизане и преглед на продукти, ето какво ще получите.

Както можете да видите, за тези изисквания няма възможност да се предостави неправилен вход. Следователно, не е необходимо да се пишат негативни тестови сценарии / случаи.

Заключителни мисли:

Системата може да бъде подложена на положителен или отрицателен вход. Така или иначе системата трябва да генерира правилни резултати. Случаите, които са склонни да се справят с правилното въвеждане, са положителни. Тези, които са за правилен, но отрицателен вход, са отрицателни.

Няколко указания:

# 1) Когато един крайни до крайни тестови случаи са написани за UAT или дори системно тестване, винаги положителните тестови случаи са тези, които влизат в потока.

# две) Понякога класификацията е субективна.Например, ако изтривам нещо в даден сайт и получа съобщение за потвърждение, което ме пита „Наистина ли искате да изтриете този запис?“ с опции ОК и Отказ - според мен щракването върху отмяна е положителен случай. Но някои смятат, че това е отрицателно, тъй като основното намерение на опцията „Изтриване“ е да изтрие и да не отмени операцията. Така че преценката на тестера също играе роля в класификацията.

# 3) За всеки положителен случай не винаги има равен и противоположен отрицателен случай.

Горният метод винаги гарантира правилна класификация. Опитайте сами и ми кажете, ако не стане. :) „Прекият път често е грешен разрез.“ - Но в този случай може и да не е!

За по-официално обяснение на отрицателното тестване, моля, проверете => Какво е отрицателно тестване и как да се пишат отрицателни тестови случаи?

За автора: Тази статия е написана от член на екипа на STH Swati S. Присъединете се към нейния курс за QA обучение на живо тук: „ Най-доброто обучение за тестване на софтуер, което някога ще получите! '

Моля, уведомете ни, ако сте харесали тази статия и искате да видите такива основни понятия, обяснени лесно в следващите статии.

Вашите коментари, въпроси, обратна връзка и читателска аудитория са високо оценени и оценени тук, в STH. Приятно тестване!

Препоръчително четене

• Положително тестване: Значение и достойнства, обяснени с реални тестови сценарии
• Как да напиша тестови случаи за страница за вход (примерни сценарии)
• Какво е отрицателно тестване и как да се пишат отрицателни тестови случаи?
• Как да напиша тестови случаи за банкомат (примерни сценарии)
• Ефективни сценарии за скриптове и отстраняване на неизправности в селен - Урок № 27 за селен
• Видове тестове за миграция: С тестови сценарии за всеки тип
• QTP урок # 24 - Използване на виртуални обекти и сценарии за възстановяване в QTP тестове
• Тестване на приложения за здравеопазване - съвети и важни сценарии за тестване (част 2)