Въведение в тестване на черни кутии
Техники за тестване на черни кутии е метод, който включва вътрешната структура, дизайн или изпълнение на продукта, който трябва да бъде тестван. Тестовете, които се провеждат, могат да бъдат или функционални, или нефункционални. Това е известно като тестване в черни кутии, тъй като човекът, който тества системата, не е запознат с вътрешната структура на кода. Тестерът не знае нищо за подробности за внедряването и за вътрешните пътища. Тестването се извършва изцяло въз основа на софтуерните изисквания и спецификации, които се получават от тестера. Основният акцент в това тестване е входът и изходът, които се предоставят на системата.
Техники за тестване на черни кутии
Тестовите случаи, които са предназначени за тестване на система, играят важна роля в тестването. Начинът, по който са създадени, и сценариите, които покриват, трябва да бъдат взети под внимание. Тестерите могат да създадат документ за спецификация на изискванията, като използват следните техники:
- Разделяне на равностойността
- Анализ на граничната стойност
- Тестване на таблица с решения
- Тест за държавен преход
- Грешка познайте
- Графично базирани методи за тестване
- Сравнително тестване
- Използвайте Техника на случаите
Следват техниките, обяснени по-долу:
1. Тестване на еквивалентност
- Тази техника разделя входните стойности, които се предоставят на софтуера, на различни групи или класове. Това се прави въз основа на резултатите, които ще дойдат като резултат. Тази техника е известна още като разделение на класа на еквивалентност. По този начин спестяваме усилията да дадем различни входни данни. Вместо това ние даваме една стойност на групата или класа, за да тестваме резултата за тази група или клас. Това помага за подобряване на покритието на теста и от своя страна намалява преработката. Времето също се спестява, тъй като не трябва да се дават отделни входове. Входът за всеки клас е достатъчен.
- Нека вземем пример за оценки, които учениците оценяват. Ако ученикът е с над 75%, той е осигурил първи клас с отличие. По същия начин, ако резултатът е между 60% до 75%, тогава той / тя е осигурил първи клас. Ако резултатът е между 50% до 60%, тогава втори клас. Ако резултатът е между 40% до 50%, тогава преминете клас, в противен случай не успеете. Тук ще има четири паралелки. Тези тестови случаи са оформени и се гарантира, че следователно всички възможности са обхванати. Следователно тестването с всички стойности в този набор е достатъчно.
2. Анализ на граничната стойност
- Тук акцентът е върху стойностите, които присъстват на границите. Това е така, защото обикновено има много проблеми, открити при тестване със стойности, фокусирани върху границите. Границата се фокусира върху стойности близо до границата, при която поведението на системата се променя. При анализ на граничните стойности трябва да се тестват и двата входа, които са валидни и невалидни.
- Например, ако искаме да тестваме стойности, които варират от 1 до 100, тогава трябва да проверим дали програмата работи за стойности като 1-1, 1 + 1, 1, 100-1, 100 + 1 и т.н. Това помага в спестявайки време отново, тъй като можем да проверим само за стойности като 0, 1, 2, 99, 100 и 101.
3. Тестване на таблица с решения
Винаги, когато има логически условия или стъпки за вземане на решения, тогава тази техника трябва да се използва. Те могат да бъдат като ако дадено условие не е изпълнено, тогава трябва да се извърши действие А, иначе трябва да се извърши действие Б. Тестерът трябва да идентифицира входа и действията, които трябва да бъдат извършени въз основа на условията. Въз основа на тях се създава таблица за решения. Помислете за пример, при който нечетен брой превозни средства е разрешен само в понеделник, сряда, петък и неделя, докато четни превозни средства с численост са разрешени във вторник, четвъртък и събота. В този случай има две условия и две действия. Условие 1 е нечетни превозни средства, а условие 2 е равномерно превозно средство. Действията са дните, когато тези превозни средства могат да бъдат по пътищата. Общият брой на тестовите случаи в този случай може да бъде четири и следователно таблицата с решения може да бъде получена съответно.
4. Тест за държавен преход
При тази техника тестовият случай се опитва да тества системата при различни състояния. Това състояние може да се промени в зависимост от различни условия или събития. Когато се случи определено събитие, тези сценарии могат да бъдат тествани.
5. Познаване на грешка
Тази техника се основава главно на опита. След като изпитателят има опит в работата по всяко приложение, неговото поведение и функционалности са му известни. Това е начин, чрез който могат да бъдат открити много проблеми. Използвайки този опит, за тестерите е лесно да отгатнат къде повечето разработчици са склонни да правят грешки. Те могат да обработват нулеви стойности, да приемат бутона за изпращане без никаква стойност, да качват файл без прикачен файл, да качват файл с по-малък или по-голям от определения ограничен размер и т.н.
6. Графично тестване
Всяко приложение се изгражда с помощта на някои обекти. Всички обекти, които се използват, се отбелязват и се подготвя графика. От тази графика се идентифицира връзката на всеки обект и тестовите случаи се записват съответно.
7. Тест за сравнение
При тази техника се използват различни версии на един и същ софтуер и след това се сравняват, за да се тества цялата система. Поведението се отбелязва и сравнява за всички версии и се отбелязват всякакви отклонения.
8. Използвайте Техника на случаите
Тази техника се използва за идентифициране на всички тестови случаи в употреба според системата. Всички сценарии са отбелязани, които помагат за разбирането на пълната функционалност на всяка функция в краен случай. В тестовите случаи трябва да има случаи, които обхващат всички сценарии от началото до края според използването на системата.
заключение
Тестването на Black Box не влиза в детайлите на кодирането. Основно се фокусира върху тестване и валидиране на поведението и функционалността на софтуера. Няма нужда от техническа подготовка и тестването може да започне, веднага щом бъде направено разработването на проекта. И тестерите, и разработчиците могат да работят в силози. Той е по-ефективен за големи приложения, когато функционалността има значение повече от този код. Той също така помага за идентифициране на дефекти и проблеми в ранния етап на тестване. След като бъде направен повторен тест, той може да бъде проверен, ако проблемите продължават да продължават и системата се проверява отново.
Препоръчителни статии
Това е ръководство за техниките за тестване на черни кутии. Тук обсъждаме Въведение в тестването на черната кутия, техниките и най-добрите 8 техники в черната кутия. Можете да разгледате и другите ни предложени статии, за да научите повече -
- Тестване на Fuzz
- Отрицателно тестване
- Тестване на таблица с решения
- Тестване на сива кутия