black box testing an depth tutorial with examples
В този урок, използвайки моя индустриален опит в тестването на софтуер, нека се запознаем с видовете и техниките на тестване на черна кутия, заедно с неговия процес, предимства, недостатъци и някои инструменти за автоматизация, за да го тестваме, освен ръчно тестване.
Също така ще научим за разликите между тестване на бяла кутия и тестване на черна кутия.
Списък с уроци за „Техники за тестване на черна кутия“:
Урок # 1: Какво е тестване на черна кутия
Урок # 2: Какво е тестване на бяла кутия
Урок № 3: Опростено функционално тестване
Урок № 4: Какво е тестване на случаи на употреба
Урок №5 : Техника за тестване на ортогонален масив
Техники
Урок № 6: Анализ на гранична стойност и разделяне на еквивалентността
Урок # 7: Тестване на таблица за решения
Урок № 8: Тестване на държавния преход
Урок # 9 : Предполагане на грешка
Урок № 10: Графично базирани методи за тестване
Почти всички ние извършваме тестване на черна кутия всеки ден!
Независимо дали сме се научили или не, всички сме провеждали и провеждали тестване на черна кутия много пъти в ежедневния си живот !!
От самото име вероятно можете да разберете, че то включва взаимодействие със системата, което тествате като кутия с мистерии. Това означава, че не сте достатъчно осведомени за вътрешната работа на системата, но знаете как трябва да се държи.
Ако вземем пример за да тестваме нашата кола или мотор, винаги я караме, за да сме сигурни, че не се държи по необичаен начин. Виждате ли? Вече направихме тестване на Black Box.
Какво ще научите:
- Какво е тестване на черна кутия?
- Видове тестване на черна кутия
- Инструменти за тестване на черна кутия
- Техники за тестване на черна кутия
- Как да направя стъпка-мъдър?
- Предимства и недостатъци
- Разлика между тестване на бяла кутия и тестване на черна кутия
- Заключение
- Препоръчително четене
Какво е тестване на черна кутия?
Black Box Testing е известен също като поведенчески, непрозрачен, затворен, базиран на спецификации или очен тест.
Това е метод за тестване на софтуер, който анализира функционалността на софтуер / приложение, без да знае много за вътрешната структура / дизайн на тествания елемент и сравнява входната стойност с изходната стойност.
как да инициализирам общ масив в java
Основният фокус при тестването на Black Box е върху функционалността на системата като цяло. Срокът ‘Тестване на поведението’ се използва и за тестване на черна кутия. Дизайнът на тестовете за поведение е малко по-различен от дизайна на теста за черна кутия, тъй като използването на вътрешни знания не е строго забранено, но все пак се обезкуражава.
Всеки метод за тестване има свои предимства и недостатъци. Има някои грешки, които не могат да бъдат намерени с помощта на единствената техника на черна кутия или само бяла кутия.
По-голямата част от приложенията са тествани по метода на Black Box. Трябва да покрием по-голямата част от тестовите случаи, така че повечето грешки да бъдат открити от a Черна кутия метод.
Това тестване се извършва по време на разработката на софтуер и тестване на жизнения цикъл, т.е. в етапи на тестване на модул, интеграция, система, приемане и регресия.
Това може да бъде както функционално, така и нефункционално.
Видове тестване на черна кутия
На практика има няколко вида тестване на черната кутия, но ако разгледаме основния му вариант, тогава споменатите по-долу са двата основни.
# 1) Функционално тестване
Този тип се занимава с функционалните изисквания или спецификации на приложение. Тук се тестват различни действия или функции на системата чрез предоставяне на входа и сравняване на действителния изход с очаквания изход.
Например ,когато тестваме падащ списък, кликваме върху него и проверяваме дали той се разширява и всички очаквани стойности се показват в списъка.
Няколко основни типа функционални тестове са:
- Тестване на дим
- Изпитване на разумността
- Тестване на интеграцията
- Тестване на системата
- Тестване на регресия
- Тест за приемане от потребителя
=> Прочетете повече за Функционално тестване .
# 2) Нефункционално тестване
Освен функционалностите на изискванията, има и няколко нефункционални аспекта, които трябва да бъдат тествани, за да се подобри качеството и ефективността на приложението.
Няколко основни типа нефункционално тестване включват:
- Тестване на използваемостта
- Тестване на товара
- Тестване на производителността
- Тестване на съвместимост
- Стресиране
- Тестване на скалируемост
=> Прочетете повече за Нефункционално тестване .
Инструменти за тестване на черна кутия
Инструментите за тестване на Black Box са предимно инструменти за запис и възпроизвеждане. Тези инструменти се използват за тестване на регресия, за да се провери дали новата компилация е създала грешка в предишната функционалност на работещото приложение.
Тези инструменти за запис и възпроизвеждане записват тестови случаи под формата на някои скриптове като TSL, VB скрипт, Javascript, Perl и др.
Техники за тестване на черна кутия
За системно тестване на набор от функции е необходимо да се проектират тестови случаи. Тестерите могат да създават тестови случаи от документа за спецификация на изискванията, като използват следните техники за тестване на Black Box.
- Разделяне на еквивалентност
- Анализ на гранична стойност
- Тестване на таблица за решения
- Тестване на държавния преход
- Предполагане на грешка
- Графично базирани методи за тестване
- Сравнително тестване
Нека разберем всяка техника в детайли.
# 1) Разделяне на еквивалентност
Тази техника е известна също като разделяне на клас на еквивалентност (ECP). При тази техника входните стойности на системата или приложението се разделят на различни класове или групи въз основа на нейното сходство в резултата.
Следователно, вместо да използваме всяка входна стойност, сега можем да използваме всяка една стойност от групата / класа, за да тестваме резултата. По този начин можем да поддържаме покритието на теста, докато можем да намалим много преработки и най-важното време, прекарано.
Например:
Както присъства в горното изображение, текстовото поле „ВЪЗРАСТ” приема само числата от 18 до 60. Ще има три групи класове или групи.
Два невалидни класа ще бъдат:
а) По-малко или равно на 17.
б) По-голямо или равно на 61.
Един валиден клас ще бъде нещо между 18 и 60.
По този начин сме намалили тестовите случаи само до 3 тестови случая въз основа на формираните класове, като по този начин покриваме всички възможности. Така че тестването с някоя стойност от всеки набор от класа е достатъчно за тестване на горния сценарий.
=> Препоръчително четене - Какво е разделяне на еквивалентност?
# 2) Анализ на гранична стойност
От самото име можем да разберем, че в тази техника ние се фокусираме върху стойностите на границите, тъй като се установява, че много приложения имат голямо количество проблеми по границите.
c и c ++ въпроси за интервю
Граница означава стойностите близо до границата, при която се променя поведението на системата. При анализ на гранична стойност се проверяват както валидните, така и невалидните входове, за да се проверят проблемите.
Например:
Ако искаме да тестваме поле, където трябва да се приемат стойности от 1 до 100, тогава избираме граничните стойности: 1-1, 1, 1 + 1, 100-1, 100 и 100 + 1. Вместо да използваме всички стойности от 1 до 100, ние просто използваме 0, 1, 2, 99, 100 и 101.
# 3) Тестване на таблица за решения
Както самото име подсказва, че навсякъде, където има логически връзки като:
Ако
{
(Състояние = Вярно)
след това действие1;
}
else действие2; / * (условие = невярно) * /
Тогава тестерът ще идентифицира два изхода (action1 и action2) за две условия (True и False). Така че въз основа на вероятните сценарии се изрязва таблица за решения, за да се подготви набор от тестови случаи.
Например:
Вземете пример за банка XYZ, която предоставя лихвен процент за възрастния мъж от 10%, а за останалите 9%.
В този пример условие C1 има две стойности като true и false, условие C2 също има две стойности като true и false. Тогава броят на общите възможни комбинации ще бъде четири. По този начин можем да извлечем тестови случаи, използвайки таблица за решения.
видове метаданни в хранилището на данни
# 4) Тестване на държавния преход
Изпитването на държавен преход е техника, която се използва за тестване на различните състояния на тестваната система. Състоянието на системата се променя в зависимост от условията или събитията. Събитията задействат състояния, които се превръщат в сценарии и тестерът трябва да ги тества.
Диаграмата за систематичен преход на състоянието дава ясна представа за промените в състоянието, но е ефективна за по-прости приложения. По-сложните проекти могат да доведат до по-сложни диаграми на прехода, като по този начин го направят по-малко ефективен.
Например:
# 5) Предполагане на грешки
Това е класически пример за тестване на базата на опит.
При тази техника тестващият може да използва своя опит относно поведението и функционалностите на приложението, за да отгатне областите, склонни към грешки. Много дефекти могат да бъдат намерени чрез познаване на грешки, когато повечето разработчици обикновено правят грешки.
Малко често срещани грешки, с които разработчиците обикновено забравят да се справят:
- Разделете на нула.
- Обработка на нулеви стойности в текстови полета.
- Приемане на бутона Submit без никаква стойност.
- Качване на файл без прикачен файл.
- Качване на файл с по-малко или повече от ограничения размер.
# 6) Графично базирани методи за тестване
Всяко приложение е натрупване на някои обекти. Всички такива обекти се идентифицират и графиката се подготвя. От тази обектна графика се идентифицира всяка обектна връзка и съответните тестове се пишат, за да се открият грешките.
# 7) Сравнително тестване
За тестване по този метод се използват различни независими версии на един и същ софтуер.
Как да направя стъпка-мъдър?
Като цяло, когато се следва систематичен процес за тестване на проект / приложение, качеството се запазва и е полезно в дългосрочен план за следващи кръгове на тестване.
- Първата стъпка е да се разбере спецификацията на изискванията на приложението. Трябва да има подходящо документирано SRS (спецификация на софтуерните изисквания).
- Използвайки гореспоменатите техники за тестване на черна кутия, като анализ на гранична стойност, разделяне на еквивалентност и т.н. Наборите от валидни и невалидни входове се идентифицират с техните желани резултати и тестовите случаи се проектират въз основа на това.
- Проектираните тестови случаи се изпълняват, за да проверят дали преминават или не, като проверяват действителните резултати с очакваните резултати.
- Неуспешните тестови случаи се повдигат като дефекти / грешки и се адресират до екипа на разработчиците, за да го отстранят.
- Освен това въз основа на дефектите, които са отстранени, тестерът проверява повторно дефектите, за да провери дали те се повтарят или не.
Предимства и недостатъци
Предимства
- Не е необходимо тестерът да има техническа подготовка. Важно е да тествате, като сте на мястото на потребителя и мислите от гледна точка на потребителя.
- Тестването може да започне, след като се разработи проектът / приложението. И тестерите, и разработчиците работят независимо, без да се намесват в пространството на другия.
- Той е по-ефективен за големи и сложни приложения.
- Дефектите и несъответствията могат да бъдат идентифицирани на ранния етап на тестването.
Недостатъци
- Без никакви технически познания или познания по програмиране има шансове да се игнорират възможните условия на сценария, който ще бъде тестван.
- В определено време има възможности за по-малко тестване и пропускане на всички възможни входове и тяхното тестване на изхода.
- Пълно тестово покритие не е възможно за големи и сложни проекти.
Разлика между тестване на бяла кутия и тестване на черна кутия
По-долу са дадени няколко разлики между тях:
| Тестване на черна кутия | Тестване на бяла кутия |
|---|---|
| Това е метод за тестване, без да имате познания за действителния код или вътрешната структура на приложението | Това е метод за тестване, имащ знания за действителния код и вътрешната структура на приложението |
| Това е тестване от по-високо ниво като функционално тестване. | Този тип тестване се извършва при по-ниско ниво на тестване като Unit Testing, Integration Testing |
| Той се концентрира върху функционалността на тестваната система | Той се концентрира върху действителния код - програма и нейния синтаксис |
| Тестването на черната кутия изисква спецификация на изискванията за тестване | Тестването на White Box изисква проектни документи с диаграми на потока от данни, диаграми и др. |
| Тестването на черната кутия се извършва от тестерите | Тестването на бялата кутия се извършва от разработчици или тестери със знания по програмиране. |
Заключение
Това са някои от основните точки по отношение на тестването на черна кутия и общия преглед на техниките и методите.
Тъй като не е възможно да се тества всичко с човешко участие със 100 процента точност, ако гореспоменатите техники и методи се използват ефективно, това определено ще подобри качеството на системата.
В заключение, това е много полезен метод за проверка на функционалността на системата и идентифициране на повечето дефекти.
Надявам се, че бихте получили задълбочени познания за техниката за тестване на черна кутия.
Препоръчително четене
- Основни разлики между тестване на черна кутия и тестване на бяла кутия
- Най-добри инструменти за тестване на софтуер 2021 г. (Инструменти за автоматизация на QA теста)
- Функционално тестване срещу нефункционално тестване
- Учебник за тестване по двойки или за всички двойки с инструменти и примери
- Тестване на бяла кутия: Пълно ръководство с техники, примери и инструменти
- Урок за тестване на обем: Примери и инструменти за тестване на обем
- Урок за тестване на конфигурация с примери
- Изтегляне на eBook за тестване на Primer