Меню

Тестване на бяла кутия: Пълно ръководство с техники, примери и инструменти

white box testing complete guide with techniques

Опитайте Нашия Инструмент За Премахване На Проблемите

Какво е тестване на бяла кутия?

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

Тестването на бялата кутия включва разглеждане на структурата на кода. Когато знаете вътрешната структура на даден продукт, могат да се проведат тестове, за да се гарантира, че вътрешните операции се извършват съгласно спецификацията. И всички вътрешни компоненти са били адекватно упражнени.

Тестване на бяла кутия с пример

Какво ще научите:

Моят опит

Вече е почти десетилетие, откакто съм в областта на тестването на софтуер и досега забелязах, че тестерите са най-ентусиазирани в цялата софтуерна индустрия.

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

Но както се казва „Винаги има по-тъмна страна“ .

Тестерите също така наистина избягват тип тестване, който според тях е много сложен и парче от разработчика. Да, „Тестване на бяла кутия“.

Покритие

White Box Testing е покритие на спецификацията в кода:

1. Покритие на кода

2. Покритие на сегмента: Уверете се, че всеки кодов оператор се изпълнява веднъж.

3. Покритие на клон или тестване на възел: Покритието на всеки кодов клон от всички възможни беше.

4. Покритие на състоянието на съединението: За множество условия тествайте всяко условие с множество пътища и комбинация от различния път, за да достигнете до това състояние.

5. Основно тестване на пътя: Всеки независим път в кода е взет за тестване.

6. Тестване на потока от данни (DFT): При този подход проследявате конкретните променливи чрез всяко възможно изчисление, като по този начин дефинирате набора от междинни пътища през кода. DFT има тенденция да отразява зависимости, но това е главно чрез последователности от манипулация на данни. Накратко, всяка променлива на данни се проследява и нейното използване се проверява. Този подход има тенденция да разкрива грешки като използвани променливи, но не инициализирани или декларирани, но не използвани и т.н.

7. Тестване на пътя: Тестването на пътя е мястото, където са дефинирани и обхванати всички възможни пътища през кода. Това отнема много време.

8. Тестване на цикъл: Тези стратегии се отнасят до тестване на единични цикли, конкатенирани цикли и вложени цикли. Независими и зависими кодови вериги и стойности се тестват по този подход.

Защо изпълняваме WBT?

Уверявам:

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

За да откриете следните видове грешки:

  • Логическите грешки обикновено се прокрадват в нашата работа, когато проектираме и внедряваме функции, условия или контроли, които са извън програмата
  • Грешките в дизайна поради разликата между логическия поток на програмата и реалното изпълнение
  • Типографски грешки и проверка на синтаксиса

Това тестване изисква ли подробни умения за програмиране?

Трябва да пишем тестови случаи които осигуряват пълното покритие на програмната логика.

За това трябва да познаваме добре програмата, т.е. трябва да знаем спецификацията и кода, който ще бъде тестван. За този тип тестване са необходими познания по езици за програмиране и логика.

Ограничения

Не е възможно за тестване на всеки път на циклите в програмата. Това означава, че изчерпателното тестване е невъзможно за големи системи.

Това не означава, че WBT не е ефективен. Чрез избор на важни логически пътеки и структура на данните за тестване е практически възможно и ефективно.

Разлика между тестване на White-Box и Black-Box

Казано с прости думи:

При тестване на Black box тестваме софтуера от гледна точка на потребителя, но в White box виждаме и тестваме действителния код.

При тестване на черната кутия ние извършваме тестване, без да виждаме вътрешния системен код, но в WBT виждаме и тестваме вътрешния код.

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

Препоръчително четене => Пълно ръководство за тестване на Black Box

Стъпки за изпълнение на WBT

Етап 1 - Разберете функционалността на дадено приложение чрез неговия изходен код. Което означава, че тестерът трябва да е добре запознат с езика за програмиране и другите инструменти, както и техники, използвани за разработване на софтуера.

Стъпка 2 - Създайте тестовете и ги изпълнете.

Когато обсъждаме концепцията за тестване, „ покритие ”Се счита за най-важният фактор. Тук ще ви обясня как да имате максимално покритие от контекста на тестването на бяла кутия.

Прочетете също=> Графика за причините и последиците - Техника за писане на динамични тестове за максимално покритие

Видове и техники за тестване на бяла кутия

Има няколко типа и различни методи за всеки тип тестване на бяла кутия.

Вижте изображението по-долу за справка.

Типове тестване на бяла кутия

Днес ще се съсредоточим главно върху типове тестове за изпълнение на „Техника за бяла кутия с единично тестване“.

3 основни техники за тестване на бяла кутия:

  1. Покритие на декларацията
  2. Браншово покритие
  3. Покритие на пътя

Обърнете внимание, че изявлението, разклонението или покритието на пътя не идентифицира грешка или дефект, който трябва да бъде отстранен. Той идентифицира само онези редове код, които или никога не се изпълняват, или остават недокоснати. Въз основа на това може да се фокусира по-нататъшното тестване.

Нека разберем тези техники една по една с прост пример.

# 1) Покритие на изявлението:

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

Следователно „Покритие на изявлението“ , както подсказва самото име, това е методът за проверка дали всеки ред от кода се изпълнява поне веднъж.

# 2) Покритие на клона:

„Branch“ в програмен език е като „IF инструкциите“. Изявлението IF има два клона: T рута и Фалш .

Така че в Покритие на клонове (наричано още покритие на решения) ние проверяваме дали всеки клон се изпълнява поне веднъж.

В случай на „декларация IF“, ще има две условия за изпитване:

  • Един за валидиране на истинския клон и,
  • Други за проверка на фалшивия клон.

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

# 3) Покритие на пътя

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

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

кой е най-добрият софтуер за управление на задачи

Също така проверете=> Различни видове тестване

Пример за тестване на бяла кутия

Помислете за простия псевдокод по-долу:

INPUT A & B C = A + B IF C>100 PRINT “ITS DONE”

За Покритие на декларацията - ще ни е необходим само един тест, за да проверим всички редове на кода.

Това означава:

Ако обмисля TestCase_01 да бъде (A = 40 и B = 70), тогава всички редове на кода ще бъдат изпълнени.

Сега възниква въпросът:

  1. Това достатъчно ли е?
  2. Ами ако разгледам тестовия си случай като A = 33 и B = 45?

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

Следователно за максимално покритие трябва да помислим ' Браншово покритие ' , който ще оцени условията “FALSE”.

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

Така че сега псевдокодът става:

INPUT A & B C = A + B IF C>100 PRINT “ITS DONE” ELSE PRINT “ITS PENDING”

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

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

TestCase_01 : A = 33, B = 45

TestCase_02 : A = 25, B = 30

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

Ето заключенията, които са получени досега:

  • Покритието на клона осигурява по-голямо покритие, отколкото покритие на изявление.
  • Покритието на клонове е по-мощно от покритието на изявление.
  • 100% покритие на клона само по себе си означава 100% покритие на извлеченията.
  • Но 100% покритие на извлеченията не гарантира 100% покритие на клонове.

Сега да преминем към Покритие на пътя:

Както беше казано по-рано, Path покритието се използва за тестване на сложни кодови фрагменти, които основно включват оператори на цикъл или комбинация от цикли и инструкции за решение.

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

INPUT A & B C = A + B IF C>100 PRINT “ITS DONE” END IF IF A>50 PRINT “ITS PENDING” END IF

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

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

За да ги опростим, нека разгледаме по-долу блок-схема на псевдо кода, който имаме:

Покритие на пътя 1

За да имаме пълно покритие, ще са ни необходими следните тестови случаи:

TestCase_01: A = 50, B = 60

TestCase_02 : A = 55, B = 40

TestCase_03: A = 40, B = 65

TestCase_04: A = 30, B = 30

Така покритият път ще бъде:

Покритие на пътя 2

Червена линия - TestCase_01 = (A = 50, B = 60)

Синя линия = TestCase_02 = (A = 55, B = 40)

Оранжева линия = TestCase_03 = (A = 40, B = 65)

Зелена линия = TestCase_04 = (A = 30, B = 30)

******************
= >> Свържете се с нас за да предложите вашата обява тук
*****************

Бяла кутия Инструменти за тестване

По-долу е даден списък с най-добрите инструменти за тестване на бяла кутия.

# 1) Веракод

Веракод

Инструментите за тестване на бялата кутия на Veracode ще ви помогнат да идентифицирате и отстраните недостатъците на софтуера бързо и лесно на намалена цена. Той поддържа няколко езика на приложения като .NET, C ++, JAVA и др., А също така ви позволява да тествате сигурността на десктоп, уеб, както и мобилни приложения. Все пак има няколко други предимства на инструмента Veracode. За подробна информация относно тестовите инструменти на Veracode White box, моля, проверете връзката по-долу.

Връзка към уебсайт: Веракод

# 2) EclEmma

EclEmma

EclEmma първоначално е проектиран за тестови проби и анализи в работната среда на Eclipse. Смята се, че е безплатен инструмент за покритие на Java код и има няколко функции. За да инсталирате или научите повече за EclEmma, ​​моля, проверете връзката по-долу.

Връзка към уебсайт: EclEmma

# 3) RCUNIT

RCUnit

Рамка, която се използва за тестване на C програми, е известна като RCUNIT. RCUNIT може да се използва съответно въз основа на условията на MIT лиценза. Той е безплатен за използване и за да инсталирате или научите повече за него, моля, проверете връзката по-долу.

Връзка към уебсайт: RCUNIT

# 4) cfix

cfix е една от модулните рамки за тестване за C / C ++, която цели единствено да направи възможно най-опростено и лесно разработване на тестови пакети. Междувременно cfix обикновено е специализиран за режим NT Kernel и Win32. За да инсталирате и научите повече за cfix, моля, проверете връзката по-долу

Връзка към уебсайт: cfix

# 5) Тест на Google

Тест на Google

Googletest е тестовата рамка на C ++ на Google. Тестове за откриване, тестове за смърт, тестове с параметри на стойност, фатални и нефатални неуспехи, генериране на отчети за XML тестове и т.н. са няколко функции на GoogleTest, но има и няколко други функции. Linux, Windows, Symbian, Mac OS X са няколко платформи, където е използван GoogleTest. За даИзтеглете, моля, проверете връзката по-долу.

Линк за изтегляне: Тест на Google

# 6) EMMA

Ема

Emma е лесен за използване безплатен инструмент за покритие на JAVA код. Той включва няколко функции и предимства. За да изтеглите и научите повече за Ема, моля, проверете връзката по-долу.

Линк за изтегляне: EMMA

# 7) NUnit

NUnit

NUnit е лесна за използване рамка за тестване на модули с отворен код, която не изисква ръчна намеса за преценка на резултатите от теста. Той поддържа всички .NET езици. Той също така поддържа тестове, управлявани от данни, и тестове, изпълнявани паралелно под NUnit. По-ранните версии на NUnit използваха лиценз NUnit, но NUnit 3 се пуска под лиценза MIT. И двата лиценза позволяват безплатно използване без никакви ограничения. За да изтеглите и научите повече за NUnit, моля, проверете връзката по-долу.

Линк за изтегляне: NUnit

# 8) CppUnit

CppUnit

CppUnit е модулна рамка за тестване, написана на C ++ и се счита за порт на JUnit. Тестовият изход за CppUnit може да бъде в XML или текстов формат. Той създава модулни тестове със собствен клас и изпълнява тестове в тестовите пакети. Той е лицензиран под LGPL. За да изтеглите и научите повече за CppUnit, моля, проверете връзката по-долу.

Линк за изтегляне: CppUnit

# 9) JUnit

шпионско приложение за iphone и android

JUnit

JUnit е тиха проста рамка за модулно тестване, която поддържа автоматизация на тестове в Java Programming Language. Той поддържа главно в разработката, задвижвана от тестове и също така предоставя отчет за покритие на теста. Той е лицензиран под Eclipse Public License. За безплатно изтегляне и за да научите повече за JUnit, моля, проверете връзката по-долу.

Линк за изтегляне: JUnit

# 10) JsUnit

JsUnit

JsUnit се счита за пристанището на JUnit към javascript. И това е рамка за модулно тестване с отворен код, която да поддържа клиентски Javascript. Той е лицензиран под GNU Public License 2.0, GNU Lesser Public License 2.1 и Mozilla Public License 1.1. За да изтеглите и научите повече за JsUnit, моля, проверете връзката по-долу.

Линк за изтегляне: JsUnit

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

Чувствайте се свободни да предложите по-прости или усъвършенствани инструменти, които използвате за техниката на бяла кутия.

Заключение

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

Ако се направи правилно, тестването на бялата кутия със сигурност ще допринесе за качеството на софтуера. Също така е добре тестерите да участват в това тестване, тъй като може да предостави най-„безпристрастното“ мнение за кода. :)

Уведомете ни, ако имате въпроси относно методите, които обсъдихме в тази статия.

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

^