“Бялата кутия” е категория тестване на софтуер, която се отнася до методите за тестване на функционирането на вътрешната структура и дизайна на софтуера. То контрастира с тестването на “черна кутия”, което представлява тестване, което не се занимава с вътрешните операции на софтуера, а тества само външните резултати на софтуера.
В тази статия ще разгледаме темата за тестването на бялата кутия: какво представлява, как работи и какви видове инструменти за тестване на софтуер могат да помогнат на тестерите и разработчиците да извършват тестване на бялата кутия при тестването на софтуер.
Какво представлява тестването на “бялата кутия”?
Тестването на “бялата кутия” е техника за тестване на софтуер, която включва тестване на вътрешната структура и дизайн на софтуера, за разлика от външните резултати или опита на крайния потребител, които се тестват при тестването на “черната кутия”.
Тестването в бяла кутия е общ термин, който включва много различни видове софтуерно тестване, включително тестване на блокове и интеграционно тестване. Тъй като тестването на “бялата кутия” включва тестване на код и програмиране, провеждането на тестването на “бялата кутия” обикновено изисква известни познания по компютърно програмиране.
Тестването на “бялата кутия” в софтуерното инженерство може да включва тестване на кода и вътрешния дизайн на софтуера, за да се провери входно-изходният поток и да се провери дизайнът, използваемостта и сигурността на софтуера.
Тестването на бялата кутия позволява на тестерите да проверяват вътрешната работа на системата, като същевременно проверяват дали въведените данни водят до определени, очаквани резултати.
Тестването на бялата кутия е съществена стъпка в тестването на софтуер, тъй като това е единственият вид тестване, при което се разглежда функционирането на самия код.
1. Кога и защо се нуждаете от бяла кутия
тестване в областта на софтуерното тестване и инженеринг?
Тестването на “бялата кутия” може да се извърши на различни етапи от цикъла на тестване, за да се провери функционирането на вътрешния код и структура.
Най-често тестването на “бялата кутия” се извършва, когато разработчиците и тестерите извършват тестване на единици, а понякога и по време на интеграционното тестване.
По дефиниция тестването на единици се счита за вид тестване на “бяла кутия”, докато интеграционното тестване може да има общи характеристики както на тестването на “бяла, така и на черна кутия “, но обикновено се счита за вид тестване на “черна кутия”.
В противен случай тестването на “бялата кутия” може да се използва и ad hoc за проверка на вътрешната работа на софтуерна компилация. Тестването в бяла кутия е най-икономичният начин за увеличаване на обхвата на тестовете, ако има нужда от това, и също така е лесен начин да се провери как работят определени части от кода или да се тестват области от софтуерната конструкция, за които тестващите подозират, че не са достатъчно тествани.
Официалните прегледи на кода, които се извършват с тестване на “бялата кутия”, също могат да се използват за идентифициране на пропуски в сигурността и други уязвимости. По същия начин, ако елементи от кода са повредени, тестването на бялата кутия може да помогне на софтуерните инженери да определят къде е грешката.
2. Когато не е необходимо да правите тестване на бялата кутия
В повечето случаи, когато софтуерните инженери и тестери преминават през цикъла на тестване на нова софтуерна разработка, е необходимо известно количество тестове на бялата кутия, за да се провери вътрешната работа на кода.
Тестването на единици е вид тестване на “бялата кутия”, което се извършва от разработчиците, за да се провери дали отделните единици работят според очакванията. Този ранен тип тестване позволява на разработчиците да идентифицират грешки и дефекти, преди да се извърши официално тестване в среда за осигуряване на качеството.
След тестването на модула се провеждат интеграционно тестване, системно тестване и тестване за приемане от потребителя. Те обикновено се считат за форми на тестване на черната кутия, които не включват много техники за тестване на бялата кутия.
В някои случаи обаче тестерите и разработчиците могат да използват тестване на бялата кутия по време на тези етапи, за да идентифицират конкретни дефекти в кода. На този етап, ако няма индикации, че нещо не е наред с кода, и всички тестове на черната кутия преминават успешно, много екипи за тестване могат да преценят, че няма нужда да провеждат допълнителни тестове на бялата кутия.
3. Кой участва в тестването на бялата кутия?
Тестването на бялата кутия почти винаги се извършва от разработчици на софтуер и софтуерни инженери. Това е така, защото тестването на “бялата кутия” изисква подробни познания за компютърния код и техниките за кодиране, а повечето QA тестери нямат техническите умения, необходими за провеждане на тестване на “бялата кутия”.
Тестването на единици, основният вид тестване на “бялата кутия”, винаги се извършва в средата за разработка от разработчиците. Разработчиците могат също така да извършват тестване на бялата кутия, когато е необходимо, за да проверят начина, по който работят различни елементи на кода, или да проверят дали грешките са отстранени правилно.
Предимства на тестването в бялата кутия
Тестването на “бялата кутия” позволява на разработчиците и софтуерните инженери да тестват повече аспекти на кода в сравнение с тестването на “черната кутия”.
Докато тестването в черна кутия може да ни покаже как дадена софтуерна конструкция функционира за крайните потребители, тестването в бяла кутия може да ни каже повече за това как работи софтуерният код. Чистият и ефективен код е от съществено значение при разработката на софтуер, особено ако разработчиците искат да използват кода повторно по-късно или да добавят поправки и актуализации в бъдеще.
1. Максимално покритие на тестовете
Тестването в бяла кутия може да помогне на тестерите да увеличат обхвата на тестовете. Тестването на възможно най-голяма част от софтуерния код обикновено увеличава шансовете за откриване на грешки в кода, а целта на тестването на бялата кутия обикновено е да се тества възможно най-голяма част от кода.
От друга страна, тестването “черна кутия” е просто изпълнение на тестови случаи, които могат да имат или да нямат широко покритие на кода.
2. Намиране на скрити грешки и бъгове
Едно от най-големите предимства на тестването на “бялата кутия” е, че тъй като тестването на “бялата кутия” проверява вътрешната функционалност, то улеснява разработчиците да откриват грешки и бъгове, които иначе биха могли да бъдат скрити дълбоко в кода.
Освен че се идентифицира наличието на грешки, обикновено е по-лесно да се определи къде точно в базата с код се намира грешката, когато се извършва тестване на бялата кутия, поради изключително специфичния характер на този вид техника за тестване.
3. Лесна автоматизация
Много е лесно да се автоматизира тестването в бялата кутия, особено при провеждане на тестване на единици. Тестовете на единици обикновено изискват от разработчиците да тестват поотделно малки части от кода, за да проверят дали те работят според очакванията. Това е много лесно за автоматизиране, което означава, че е бърза и ефективна форма на тестване на софтуер.
Това е една от причините, поради които тестването на единици се извършва преди други, по-трудоемки видове тестване.
4. Ефективно използване на времето
Тестването на “бялата кутия” е ефикасно от гледна точка на времето по редица причини.
Както беше споменато по-горе, автоматизирането на повечето видове тестване на “бялата кутия” е сравнително лесно, което означава, че тестването на “бялата кутия” често е по-бързо от тестването на “черната кутия”. Освен това тестването на бялата кутия улеснява разработчиците да откриват грешките, които идентифицират в кода, тъй като те ги откриват, докато тестват самия код.
5. Качество на кода
Тестването на бялата кутия позволява на разработчиците да погледнат отново на кода, който са написали, и да оценят неговото качество и чистота.
Прегледът на кода парче по парче дава възможност на разработчиците да премахнат ненужните части от кода и да го изчистят, което улеснява повторното използване и редактиране на части от кода в бъдеще.
Това може да накара разработчиците да обмислят начина на прилагане на кода и дали той ще бъде добре мащабиран в бъдеще.
Предизвикателствата на тестването на бялата кутия
Тестването на бялата кутия не е лишено от предизвикателства. Има няколко причини, поради които някои екипи за разработка могат да смятат, че тестването на “бялата кутия” е по-трудно за изпълнение от тестването на “черната кутия”, както и други причини, поради които някои хора могат да го смятат за по-малко важно от тестването на “черната кутия”.
1. Технически пречки
Тестването на “бялата кутия” е свързано с технически бариери, които не се срещат при тестването на “черната кутия”. За да извършат тестване на “бялата кутия”, тестерите трябва да познават вътрешната работа на системата, което при тестването на софтуер обикновено означава познания по програмиране.
Ето защо тестването на “бялата кутия” почти винаги се извършва от софтуерни инженери и разработчици, а не от QA тестери, които рядко имат необходимите технически умения за извършване на този вид тестване.
2. Разходи
Тестването на “бялата кутия” може да бъде по-скъпо в сравнение с тестването на “черната кутия”, тъй като този тип тестване е много задълбочено.
Разработчиците трябва да прекарват много време в писане на интензивни тестове на единици, а тестовете на “бялата кутия” често не могат да се използват повторно за други приложения, което означава, че извършването на тестовете на “бялата кутия” обикновено струва доста скъпо.
3. Точност
Тестването на “бялата кутия” не винаги е най-точният метод за тестване на софтуер и ако екипите за разработка разчитат единствено на тестването на “бялата кутия”, това би довело до много пропуснати грешки и случаи.
Тестването на “бялата кутия” валидира само вече съществуващи функции, докато тестването на “черната кутия” може да се използва за тестване на частично реализирани функции или за идентифициране на функции, които всъщност липсват в софтуера и трябва да бъдат включени в по-късни итерации.
4. Обхват
Тестването на “бялата кутия” обикновено не ни казва много за потребителското преживяване или за крайния резултат от функциите, вградени в софтуера.
Въпреки че разработчиците могат да използват тестване на “бялата кутия”, за да проверят дали кодът работи както трябва, те не могат да заключат, че работещият код предоставя правилните резултати на крайните потребители, без да комбинират тестване на “бялата кутия” с тестване на “черната кутия”.
Това означава, че има ограничения в обхвата на тестването на “бялата кутия” и в това колко много може да ни каже за софтуера.
Характеристики на тестовете на бялата кутия
Тестването на “бялата кутия” може да се определи с конкретни характеристики, които го отличават от други форми на тестване, като например тестване на “черната кутия” и “сивата кутия”.
Повечето от тези характеристики могат да бъдат разгледани от гледна точка на това как се различават от характеристиките на тестването в черна кутия и как това разграничава тестването в бяла кутия от тестването в черна кутия.
1. Възможност за поддържане
Тестването на “бялата кутия” води до по-високо ниво на поддържане на кода, като опростява работата, която екипът ви трябва да върши занапред.
Тъй като кодът и действията му с данните се наблюдават постоянно, поддръжката му е много по-лесна, тъй като се разбира къде и защо възникват проблеми. По този начин се опростява и кодът за бъдещи актуализации, тъй като не се разработват големи и сложни кръпки за неизвестни и прости проблеми.
2. Гъвкавост
Тестването на “бялата кутия” се извършва върху код, който е достатъчно гъвкав, за да приема промени сравнително бързо. Негъвкавият код, например този, който е част от модул или интеграция на трета страна, не позволява на тестера на бялата кутия да прави бързи промени.
Фокусирането върху наличието на код, който можете да променяте веднага щом откриете проблем, прави тестването на бялата кутия изключително адаптивно и означава, че проблемите в програмата се решават много по-бързо.
3. Модулност
Тестването на “бялата кутия” се развива добре в код, който има известна степен на модулност, което означава, че отделните елементи на софтуера са ясно разграничени един от друг.
Ако в дадена програма има “спагети код”, в който всеки аспект е свързан с друг, тестването на бялата кутия става безкрайно сложно, тъй като тестерът трябва да провери цялата програма, а не конкретна единица.
4. Интеграция
Тестването на бялата кутия е изключително полезно за интеграционно тестване. Тестващите могат да видят дали дадена функция работи до момента, в който напуска въпросния софтуер, и дали се връща от интегрираната система толкова функционална, колкото се очаква.
Това е изключително информативно и позволява на организацията да разбере дали проблемът е локален или е част от интегрираната платформа.
Какво тестваме в тестовете на бялата кутия?
Тестовете “бяла кутия” се използват за тестване на характеристики на кода, които не могат да бъдат проверени чрез методите за тестване “черна кутия”. Това може да означава тестване на работата на самия код, което позволява на разработчиците да разберат причините и последиците от различни аспекти на кода.
Разработчиците използват тестването на “бялата кутия”, за да тестват дупки в сигурността, оператори и функции, изходи и пътища в кода.
1. Вътрешни отвори за сигурност
Тестването на бялата кутия може да се използва за търсене на пропуски в сигурността и уязвимости в кода, от които хакерите и киберпрестъпниците биха могли да се възползват в бъдеще.
Тестването на “бялата кутия” може да се използва за проверка на спазването на най-добрите практики за сигурност по време на етапа на разработка и за търсене на уязвимости в сигурността, които могат да бъдат отстранени, преди кодът да премине към по-нататъшно тестване.
2. Пътища в процесите на кодиране
Тестването на “бялата кутия” позволява на разработчиците да тестват пътищата, които свързват различни елементи на кода. Разработчиците проверяват не само логиката на кода, но и структурата и хигиената на кода.
Добрият, чист код не съдържа излишни редове или счупени елементи, които не работят според очакванията, дори ако външните резултати от тестването на черната кутия са според очакванията.
3. Очаквани резултати
Тестването на “бялата кутия” може да тества и очакваните резултати от кода по същия начин, както и тестването на “черната кутия”, въпреки че тестерите правят това, като разглеждат кода, а не като използват приложението, както тестерите могат да направят при тестването на “черната кутия”.
Разработчиците тестват очакваните резултати, като проверяват входовете един по един и проверяват дали полученият резултат съответства на очакванията.
4. Изречения, обекти и функции
Чрез техниките за тестване на бялата кутия разработчиците на софтуер могат да гарантират, че операциите, обектите и функциите в кода се държат логично и водят до очакваните резултати.
5. Функционалност на условните цикли
Тестването на бялата кутия може да се използва и за проверка на функционалността на условни цикли, включително единични, сбити и вложени цикли. Разработчиците ще проверят дали тези цикли са ефективни, дали отговарят на изискванията за условна логика и дали правилно работят с локални и глобални променливи.
Изчистване на някои неясноти:
Тестване на бяла кутия срещу черна кутия срещу сива кутия
Тестване в бяла кутия, тестване в черна кутия и тестване в сива кутия са термини, които софтуерните тестери използват, за да обозначат различни категории тестване или различни методи за тестване.
Съвременното виждане за тези разграничения в тестването е, че границите между различните видове тестване на кутиите стават все по-неясни, тъй като различните видове тестване често съчетават елементи както от бялата, така и от черната кутия и извличат тестове от документи на различни нива на абстракция.
Въпреки това между тези форми на изпитване все още има важни различия.
1. Какво представлява тестването на черната кутия?
Тестването “черна кутия” е форма на тестване на софтуер, при която функционалността на софтуера се проверява от тестери, които нямат познания за вътрешната структура на кода или за това как да реализират кода на по-техническо ниво.
Тестването на “черната кутия” проверява само външните изходи на софтуера или, с други думи, проверява това, което крайният потребител ще изпита, когато работи със софтуера.
Тестването на черната кутия е известно още като поведенческо тестване, тъй като при него се проверява как софтуерът се държи при определени условия.
Тестерите могат да използват тестването на черната кутия, за да оценят как се държат различните функции на софтуера и да ги сравнят с очакванията, за да се уверят, че софтуерът отговаря на изискванията на потребителите. Тестването на “черната кутия” се използва при тестването на системата и тестването за приемане, за да се проверят различни функции и да се провери дали системата работи според очакванията, когато работи като цяло.
Когато се извършва тестване на черна кутия, потребителите пишат тестови случаи за индивидуална проверка на различни елементи. Тъй като тестването на “черна кутия” не изисква същите технически умения като тестването на “бяла кутия”, тестването на “черна кутия” обикновено се извършва от тестери в среда за осигуряване на качеството, а не от разработчици.
Автоматизирането на тестването на черната кутия обикновено е по-лесно за автоматизиране в сравнение с тестването на бялата кутия чрез използване на инструменти за автоматизиране от край до край като ZAPTEST.
Какви са разликите между тестването на “бялата кутия” и “черната кутия”?
Основната разлика между тестването в черна и бяла кутия е в това какво се тества.
Тестването на черната кутия е свързано с тестване на външните резултати от изграждането на софтуера, докато тестването на бялата кутия е свързано с тестване на това, което се случва под капака.
Някои от основните разлики между тестването в черна и бяла кутия са:
Цел
Целта на тестването на черната кутия е да се провери дали системата работи според очакванията на крайния потребител, докато целта на тестването на бялата кутия е да се провери качеството и целостта на кода на софтуера.
Например при тестването на черна кутия за видеоигра крайният потребител може да изпробва играта и да я прегледа за своя опит, а при тестването на бяла кутия за същия проект се гарантира, че въвеждането на определени входни данни води до извършване на правилното действие от героя.
Процес
Процесите, използвани при тестването на бялата и черната кутия, са много различни. Тестването на “бялата кутия” е много по-лесно за автоматизиране от тестването на “черната кутия” и обикновено тестването на “черната кутия” трябва да се автоматизира с помощта на инструменти за автоматизиране на софтуера.
Например при тестването на база данни тестът на бялата кутия включва автоматизиране на въвеждането на данни, за да се провери дали всички резултати са правилни, а тестът на черната кутия включва потребители, които възпроизвеждат ръчни процеси и ги отчитат без използване на система за автоматизация.
Тестери
Тестването на “черната кутия” почти винаги се извършва в среда за осигуряване на качеството от професионални тестери на софтуер, докато тестването на “бялата кутия” се извършва от разработчици на софтуер и инженери, които имат по-подробни технически познания за източника на кода.
Техники
При тестването на “черната кутия” се използват различни техники, като например разделяне на еквивалентност, анализ на граничните стойности и тестване с таблици с решения. При тестването на бялата кутия се използват техники като покриване на решения, покриване на условия и покриване на твърдения.
Операции
Методологиите за тестване “черна кутия” са подходящи за по-високи нива на тестване, като тестване на системата и тестване за приемане, докато тестването “бяла кутия” е по-подходящо за по-ниски нива на тестване, като тестване на единици и интеграционно тестване.
Поради тази причина тестването на “бялата кутия” обикновено се извършва преди повечето форми на тестване на “черната кутия”.
2. Какво представлява тестването в сивата кутия?
Тестването в сива кутия е техника за тестване на софтуер, която се използва за тестване на софтуерни продукти и приложения от тестери, които могат да имат частични познания за вътрешната структура на приложението, но не и пълни познания за нея.
Тестването на сивата кутия може да съчетава елементи от тестването на черната и бялата кутия, за да позволи на разработчиците и тестерите да идентифицират дефекти в кода и да откриват специфични за контекста грешки.
Тестването в сива кутия съчетава характеристиките на тестването в черна и бяла кутия. Тестерите трябва да имат известни познания за вътрешното функциониране на системата, както при тестването на “бяла кутия”, но те използват тези познания, за да създават тестови казуси и да изпълняват тези тестови казуси на ниво функционалност, както е при тестването на “черна кутия”.
Тестването в сива кутия предлага много от предимствата на тестването в черна и бяла кутия, като същевременно е сравнително ефикасно по отношение на времето и гъвкаво.
Какви са разликите между тестването в “бяла кутия” и “сива кутия”?
Тъй като тестването на сивата кутия предлага някои от същите функции като тестването на черната кутия, има някои големи разлики между тестването на сивата кутия и тестването на бялата кутия, макар и може би не толкова много, колкото при тестването на черната кутия.
Някои от най-големите разлики между тестването на сивата и бялата кутия са:
Структурни познания
При тестването на “бялата кутия” вътрешният дизайн и структурата на кода трябва да са напълно известни на лицето, което извършва тестването. При тестването в сивата кутия вътрешната структура на кода обикновено е известна само частично.
Участващи лица
Тестването на “бялата кутия” се извършва почти изключително от разработчици на софтуер и софтуерни инженери, докато тестването на “сивата кутия” може да се извършва от крайни потребители, тестери и разработчици.
Ефективност
Тестването на “бялата кутия” се счита за най-времеемкия вид тестване на софтуер, докато при тестването на “сивата кутия” се използват някои от предимствата на тестването на “черната кутия”, за да се намали времето, необходимо за извършване на тестовете.
Операция
При тестването на “бялата кутия” разработчиците просто пишат код за изпълнение на тестовете на “бялата кутия” и го изпълняват. При тестването на сивата кутия, както и при тестването на черната кутия, тестерите извършват функционални тестове, за да оценят как системата работи външно.
Покритие
Тестването в бяла кутия е най-изчерпателният тип тестване, докато обхватът на тестването в сива кутия може да варира в зависимост от това дали типът на изпълнените тестови случаи се основава на код или графичен потребителски интерфейс.
Заключение:
Бяла кутия срещу черна кутия срещу изпитване на сивата кутия
Тестване в бяла кутия, тестване в черна кутия и тестване в сива кутия са термини, използвани за обозначаване на различни техники за тестване на софтуер. Най-общо всеки тип тестване може да бъде дефиниран въз основа на степента, в която тестващите трябва да имат познания за базата от кодове и за реализацията на кода:
1. Тестване на черната кутия:
Вътрешната структура на кода е неизвестна.
2. Тестване на бялата кутия:
Вътрешната структура на кода е известна.
3. Тестване на сивата кутия:
Вътрешната структура на кода е частично известна.
По време на тестването на софтуера и трите вида тестване са важни за проверката на функционирането и целостта на софтуера. Докато тестването на “бялата кутия” ни казва повече за структурата на кода, тестването на “сивата кутия” и “черната кутия” може да провери как работи системата и дали тя отговаря на изискванията на крайния потребител.
Може би най-големите разлики между тези три вида тестване са свързани с това кой извършва всеки вид тестване, изискванията към самото тестване и какво включва тестването.
Тестването на “бялата кутия” е с най-висока бариера за навлизане, тъй като се извършва от разработчици с подробни познания за самата кодова база и защото е най-времеемкият и често скъп вид тестване.
За разлика от тях, тестването на черната кутия е най-лесно за изпълнение и може да се извършва от тестери без познания за основния код.
Видове тестове на бялата кутия
Съществуват много различни видове тестове на бялата кутия, като всеки от тях може да се използва за тестване на малко по-различни аспекти от вътрешната структура на кода.
По-долу са изброени някои от най-често използваните днес видове тестване на бялата кутия.
1. Тестване на пътя
Тестването на пътя е вид тестване на “бялата кутия”, основано на структурата на управление на програмата. Разработчиците използват структурата на контрола, за да създадат графика на потока на контрола и да тестват различни пътища в графиката.
Тестването по пътека е вид тестване, което зависи от структурата на управление на програмата, което означава, че изисква от тестващите да познават добре тази структура.
Например, ако дадена система трябва да се свързва с клиентите с определени съобщения в определени точки от фунията на продажбите, тестването на пътя включва гарантиране, че тя следва правилните стъпки в зависимост от условията, които данните задават.
2. Тестване на контура
Тестването на цикли е един от най-важните видове тестване на “бялата кутия”, при който се тестват цикли в кода на програмата. Циклите са реализирани в алгоритми в кода, а тестването на циклите проверява дали тези цикли са валидни.
Тестването на цикъла може да оцени дали има уязвимости в конкретни цикли и да посочи области, в които разработчиците може да се нуждаят от корекция на кода, за да гарантират, че цикълът функционира както трябва.
Пример за тест на цикъла е проследяване на цикъла с определен набор от точки с данни, които подтикват цикъла да продължи, като например отказ да се приемат някои условия, преди да се въведе цифра, която конкретно прекъсва цикъла. Ако цикълът се държи както се очаква, тестът е успешен.
3. Условно изпитване
Условното тестване е вид тестване в бялата кутия, при което се проверява дали логическите условия за стойностите в кода са верни или грешни.
Условното тестване е основна форма на тестване на “бялата кутия”, която показва на разработчиците дали кодът е логичен и отговаря на изискванията на програмната логика.
Пример за условно тестване е в счетоводна платформа. Въвеждането на поредица от разходи и приходи трябва да доведе до правилните текущи суми, като софтуерът осигурява точни резултати по време на успешен тест.
4. Единично тестване
Тестването на единици е важен етап от тестването на софтуера, при който разработчиците тестват отделни компоненти и модули и проверяват дали те работят според очакванията, преди да интегрират различните единици заедно.
Софтуерните инженери използват методите за тестване на “бялата кутия” при тестването на единици, за да тестват малки части от кода в даден момент. Това улеснява идентифицирането на грешки и пропуски, когато те се появят по време на тестването.
Пример за тестване на единици е в началото на разработката, когато компания създава прост бутон на уебсайт, който препраща потребителя към друга страница. Ако модулът работи според очакванията, той е успешен, като разработчиците правят промени, докато това стане.
5. Тестване на мутации
Изследването на мутации е вид изследване, при което се проверяват измененията и мутациите. При тестването с мутации разработчиците правят малки промени в изходния код, за да проверят дали това може да разкрие грешки в кода.
Ако тестовият случай премине успешно, това означава, че има някакъв проблем с кода, тъй като той не би трябвало да премине успешно след направените промени. В идеалния случай при мутационното тестване всички тестови случаи са неуспешни.
Пример за тестване на мутации е машинното обучение. Програмите за машинно обучение автоматично “мутират” в зависимост от новата информация, така че последователното тестване на тези програми за стандарта “мутация” информира разработчиците дали софтуерът работи според очакванията.
6. Интеграционно тестване
Интеграционното тестване е основен етап от тестването на софтуера, по време на който тестерите установяват дали различните модули работят правилно, когато са интегрирани с други модули.
По време на интеграционното тестване се използват техники за тестване на “бялата кутия”, за да се провери дали кодът функционира дори когато няколко модула, които често са кодирани от различни разработчици, работят заедно.
Когато например дадена база данни черпи информация от онлайн източник, интеграционното тестване гарантира, че данните, които тя черпи, са точни и се актуализират с достатъчно постоянна скорост.
7. Тестване за проникване
Тестването за проникване е вид тестване на “бялата кутия”, което може да се използва за симулиране на конкретни кибератаки върху системата.
При тестовете за проникване на тестерите се дава достъп до пълни данни за мрежата и системата, като например пароли и мрежови карти. След това те се опитват да получат достъп до данните в системата или да ги унищожат, като използват възможно най-много различни начини за атака.
Тестването за проникване е важен аспект от тестването на сигурността, който трябва да се извършва при всички софтуерни разработки.
Например платформата за човешки ресурси ще извърши тестове за проникване и ще потърси уязвимости в кода, за да се увери, че платформата е достатъчно сигурна, за да съхранява данните на служителите.
Техники за тестване на бялата кутия
Съществуват много различни техники за тестване на “бялата кутия”, които могат да се използват за провеждане на изброените по-горе тестове на “бялата кутия”. Както винаги, различните техники са най-подходящи за тестване на различни аспекти на кода, но всички изброени по-долу техники на бялата кутия са важни.
1. Обхват на декларацията
Една от характерните черти на тестването на “бялата кутия” е, че при извършването на тестовете на “бялата кутия” тестерите трябва да се опитат да обхванат възможно най-голяма част от изходния код.
Покритието на кода е сериозен показател за това, а покритието на твърденията е една от тези техники, които тестерите на “бялата кутия” могат да използват, за да увеличат покритието на твърденията в кода.
Покритието на изявленията е показател, който измерва броя на изпълнените изявления, разделен на общия брой изявления и умножен по 100. Тестерите на бялата кутия трябва да се стремят към високо покритие на изявлението.
2. Покритие на клоновете
Покритието на разклоненията, подобно на покритието на декларациите, отразява колко широко е покритието на определени елементи на кода при тестване в бяла кутия. Разклоненията са еквивалентни на операциите “IF” в логиката, където кодът се разделя на варианти true и false, които влияят на резултата от операцията.
Когато се използват техники за покриване на клонове, тестерите от “бялата кутия” проверяват дали всеки клон е обработен поне веднъж и потвърждават, че и двата клона работят правилно.
3. Покритие на пътя
Техниките за покриване на пътя оценяват пътищата в рамките на софтуерно приложение. Максималното покритие на тестовите пътища означава да се гарантира, че всички пътища в програмата са изследвани поне веднъж. Това е техника за тестване, подобна на покритието на клонове, но се счита за по-задълбочена и ефективна.
Тестването на покритието на пътя обикновено се счита за най-подходящо за тестване на цялостни приложения, а не на частични компилации.
4. Обхват на решенията
Покритието на решенията е една от най-важните техники на “бялата кутия”, тъй като предоставя данни за верните и грешните резултати от булевите изрази в изходния код.
Тестването на покритието на решенията валидира изходния код, като гарантира, че всяка марка на всяко потенциално решение е преминала поне веднъж по време на тестването.
Точките за вземане на решение включват всички случаи, в които има възможност за два или повече различни резултата.
5. Покритие на състоянието
Покритието на състоянието е известно също като покритие на изразяването. Тази техника на “бялата кутия” оценява подпроменливите в условните твърдения в кода, за да провери резултата от всяко логическо условие.
Този тип тестване разглежда само изрази с логически операнди, докато тестването на покритието на решенията и тестването на покритието на разклоненията се използват за осигуряване на други логически операции.
6. Покритие на множество състояния
При тестовете за покриване на множество условия тестерите проверяват различни комбинации от условия и оценяват решението, което кодът взема за всяка комбинация.
За тестовете за покриване на множество условия може да има много различни тестови случаи поради огромния брой комбинации от условия, които съществуват, така че този тип тестване често отнема много време.
7. Покритие на машината с крайни състояния
Покритието на машини с крайни състояния е важен вид тестване, но също така и един от най-трудните начини за постигане на високо покритие на кода при тестване в бяла кутия. Той работи върху функционалността на проекта и изисква от разработчиците да преброят броя на посещенията или преходите през дадено състояние по време на процеса на тестване, както и колко последователности съдържа всяка система от крайни състояния.
8. Изпитване на потока за управление
Тестването на потока на управление е техника за тестване на “бялата кутия”, която има за цел да установи реда на изпълнение на програмата с помощта на проста структура на управлението.
Разработчиците конструират тестови случаи за тестване на потока на управление, като избират конкретен раздел от програмата и изграждат път за тестване. Тестването на потока на управление обикновено се използва при тестването на единици.
Жизненият цикъл на тестването на бялата кутия
в разработването на софтуер
Тестването на “бялата кутия” е важна стъпка в жизнения цикъл на разработката на софтуер, въпреки че няма строго определено място в цикъла.
Разработчиците могат да извършват тестване на “бялата кутия”, когато им се налага да проверят функцията на кода, а някои разработчици може да са по-внимателни от други при проверката на новонаписан код, за да се уверят, че той е чист и не съдържа излишни редове.
Въпреки това тестването на бялата кутия най-често се извършва по време на тестването на блокове и интеграционното тестване. По време на фазата на разработка разработчиците извършват както тестване на модулите, така и интеграционно тестване.
Те се провеждат преди функционалното тестване, като например тестване на системата и приемателно тестване, и дават възможност на разработчиците да идентифицират, открият и отстранят основните грешки в началото на фазата на тестване, преди да предадат продукта на екипа по осигуряване на качеството.
Ръчни или автоматизирани тестове на бялата кутия?
Подобно на други видове тестване на софтуер е възможно да се автоматизира тестването на “бялата кутия”. То може да бъде ръчно или автоматизирано, въпреки че в повечето случаи е по-лесно да се автоматизира тестването на “бялата кутия”, отколкото на “черната кутия”.
Тъй като тестването на “бялата кутия” е много трудоемък вид тестване, автоматизацията става все по-популярна сред софтуерните екипи.
Ръчно тестване на бялата кутия: ползи, предизвикателства и процеси
Ръчното тестване на “бялата кутия” означава ръчно извършване на тестове на “бялата кутия” и изисква от разработчиците да имат уменията и времето да пишат индивидуални тестови случаи, за да тестват всеки ред код в дадена софтуерна компилация. Това може да отнеме много време, но също така води до най-задълбочените резултати от тестовете и изводите.
Някои от предимствата на ръчното провеждане на тестове на бялата кутия включват:
1. Дълбочина
Ръчното тестване позволява на тестващите да изследват софтуерния код в по-голяма дълбочина, отколкото автоматизираното тестване, ако решат да го направят, например като прочетат целия изходен код на дадено приложение, а не просто да автоматизират задачи, които засягат повърхностната функционалност.
2. Местоположение на грешката
Ръчното тестване улеснява откриването на грешки и дефекти, тъй като разработчиците трябва да могат да определят точно в кой ред от кода се намира грешката.
Например, ако видите, че дадено изображение не се зарежда, след което прегледате кода за редове, които включват зареждане на изображения, значително стеснявате причината.
3. Скорост
Ръчното тестване обикновено отнема повече време, отколкото автоматизираното, но ако разработчиците искат да проведат само един или два бързи теста, вероятно е по-бързо да ги извършат ръчно, отколкото да настроят автоматизация.
Например тестването на единици включва разглеждане на дадена функция и проверка дали тя работи, а не събиране на огромни количества данни чрез автоматизиране на процеса. Ръчното тестване на бялата кутия обаче има и недостатъци.
Някои от предизвикателствата пред ръчното тестване на бялата кутия включват:
1. Точност
Ръчното тестване може да позволи на разработчиците да обхванат широк спектър от кодове, но човешките тестери винаги са по-склонни към грешки и заблуди от компютърните програми, което означава, че ръчното тестване често се счита за по-малко точно от автоматизираното.
2. Време
Ръчното тестване отнема повече време, отколкото автоматизираното, а ръчното тестване на “бялата кутия” е едно от най-трудоемките тествания. Това увеличава времето за изпълнение и може да затрудни спазването на кратките срокове за разработка.
3. Разходи
Поради количеството работна ръка и ресурси, свързани с ръчното тестване на “бялата кутия”, то често е по-скъпо за екипите за разработка, отколкото автоматизираното тестване, което обикновено изисква по-малко разработчици и по-малко време.
4. Мащабируемост
Ръчното тестване е наистина подходящо само за тестване на малки приложения или на отделни компоненти на по-големи приложения. За по-големи приложения, като например бази данни, хоствани в облака, с хиляди входни данни в минута, автоматизираното тестване е много по-предпочитано като метод за симулиране на стандартни натоварвания.
Автоматизирано тестване на бялата кутия: ползи,
предизвикателства и процеси
Технологиите за автоматизация улесняват автоматизирането на аспектите на софтуерното тестване всеки ден. Преминаването на индустрията към хиперавтоматизация отчасти се дължи на ефективността и икономиите на разходи, които автоматизацията предлага на екипите за разработка, които винаги се чувстват силно притиснати.
“Бялата кутия” е един от най-подходящите и подходящи типове тестове за автоматизация, тъй като е сравнително лесно да се автоматизират, а спестеното време и разходи от автоматизацията на тестовете “бяла кутия” могат да бъдат значителни.
Автоматизираното тестване на “бялата кутия” може да включва разработчици, които сами пишат тестови скриптове, или процесът може да бъде ускорен с използването на цялостни инструменти като ZAPTEST, които предоставят най-съвременна технология за цялостно тестване на софтуер.
Някои от предимствата на автоматизирането на тестването на бялата кутия включват:
1. Точност
Компютърното тестване елиминира риска от грешки, тъй като компютрите не се уморяват и не правят грешки.
2. Време
Автоматизираното тестване на “бялата кутия” е значително по-бързо от ръчното тестване на “бялата кутия” и освобождава време, което разработчиците могат да отделят за други задачи, като например отстраняване на грешки или писане на пачове за обновяване.
3. Мащаб
Автоматизираното тестване се разширява много по-добре от ръчното тестване, така че ако софтуерното ви приложение се разраства или ако искате да извършите широкомащабно тестване наведнъж, автоматизацията е по-добрият вариант.
Например увеличаването на въвеждането на данни включва искане на повече входни данни при автоматизация в сравнение с наемането на повече служители при ръчни тестове.
4. Разходи
Разходите за автоматизирано тестване обикновено са по-ниски от разходите за ръчно тестване поради броя на работните часове, спестени от автоматизацията. 10-кратната възвръщаемост на инвестицията в ZAPTEST показва как автоматизацията може да спести пари на разработчиците и да доведе до по-висока възвръщаемост. Автоматизацията обаче не е лишена от недостатъци.
Някои от предизвикателствата при автоматизирането на тестването на бялата кутия включват:
1. Проследяване на грешки
Автоматизацията невинаги улеснява откриването на грешки в кода в зависимост от това как разработчиците автоматизират тестовете или какви инструменти за тестване се използват, особено в сравнение с ръчното тестване на бяла кутия, при което тестерите могат да видят кода, който се изпълнява, когато се появи грешка.
2. Умения
Не всички разработчици знаят как да автоматизират тестове или как да използват инструменти за автоматизирано тестване, така че преминаването към автоматизация може да изисква известни инвестиции в обучение на основни умения, като например кодиране на езика на конкретната платформа за тестване и използване на умения за анализ на данни, за да се разбере причината за проблемите при тест на бялата кутия.
Заключение: Ръчно тестване на бялата кутия
или автоматизация на тестовете в бялата кутия?
Като цяло тестването на “бялата кутия” в софтуерното инженерство е един от най-подходящите видове тестване за адаптиране към автоматизирано тестване, главно поради времеемкия и сложен характер на ръчното тестване на “бялата кутия”.
Автоматизираното тестване на “бялата кутия” е по-бързо, по-евтино, по-ефективно и по-точно от ръчното тестване, особено при работа с по-големи приложения.
Където е възможно, разработчиците на софтуер трябва да автоматизират тестването на бялата кутия при тестването на софтуер, за да повишат надеждността на тестовете и да обхванат по-голяма област от по-големи приложения чрез тестване, отколкото е практически възможно при ръчно извършване на тестовете. Това се дължи на значителните разходи и експертни познания, които се изискват при провеждането на тестове на “бялата кутия” изключително с ръчни методи.
Какво ви е необходимо, за да започнете
тестване на бялата кутия?
Преди да започнете тестването на “бялата кутия”, се уверете, че разполагате с всичко необходимо, за да започнете работа. В зависимост от това дали извършвате ръчно или автоматизирано тестване на “бялата кутия”, не се нуждаете от много ресурси, освен от време и пари.
Въпреки това трябва да се уверите, че екипът ви разполага с подходящите знания и инструменти за правилно провеждане на тестването на бялата кутия.
1. Разбиране на изходния код
Тестването на “бялата кутия” е тестване, което се извършва от разработчици на софтуер и инженери с пълни работни познания за изходния код и вътрешната структура на софтуера.
Ако сте QA тестер без тези познания, ще трябва да предадете софтуера на някой друг, преди да започне тестването на бялата кутия.
2. Тестови случаи
Необходимо е да се напишат тестови случаи, преди да се извърши тестване на бялата кутия. Случаите за тестване са индивидуални набори от инструкции, които описват действията, които тестващите или разработчиците могат да извършат, за да тестват функциите и работата на дадена система.
При тестването на “бялата кутия” тестовите случаи се разработват от хора с пълни познания за вътрешната структура на системата и се създават, за да се провери дали тя работи както трябва.
3. Инструменти за тестване на бялата кутия
Съществуват множество инструменти за тестване на “бялата кутия”, които поддържат достъп до изходния код и документите за проектиране, както и автоматизация на тестовете. Те също така се предлагат на различни цени за потребителите, като например версиите ZAPTEST FREE и ZAPTEST ENTERPRISE, които осигуряват по-голяма гъвкавост.
Изберете инструментите, които искате да използвате, преди да започнете тестването, като наблегнете на това да се уверите, че те имат правилната функционалност, например работа с различни платформи и технология за компютърно зрение, така че да виждате това, което виждат автоматичните тестове.
Уверете се, че всички разработчици и инженери, участващи в тестването, знаят как и кога да ги използват.
Процесът на тестване на бялата кутия
Тестването на “бялата кутия” включва много повече познания за работата на системата, отколкото тестването на “черната кутия”, и някои от стъпките при тестването на “бялата кутия” са малко по-различни.
Тестерите на “бялата кутия” трябва първо да идентифицират функциите или компонентите на системата, които искат да проверят, преди да начертаят възможните пътища за тестване и да напишат тестови случаи за изпълнение.
Процесът на тестване на “бялата кутия” може да се различава и в зависимост от техниката за тестване на “бялата кутия”, която използвате. Следвайте стъпките по-долу, за да разберете как да извършвате тестване на “бялата кутия”, като същевременно увеличавате максимално покритието на пътя.
Стъпка 1: Идентифициране на функциите, които трябва да бъдат тествани
Преди да извършите тестване на бялата кутия, помислете какво точно искате да тествате и как ще го направите. Обикновено това включва фокусиране върху малък набор от функции или характеристики и създаване на набор от тестови случаи само за тяхното тестване.
Ще извършвате тази стъпка отново и отново за различни области на системата, за да увеличите обхвата на тестовете, но е важно да разделите различните области на отделни тестове.
Колкото по-тесен е фокусът ви, толкова по-надеждни и точни могат да бъдат тестовете ви.
Стъпка 2: Начертайте всички възможни пътища в диаграма на потоците
Значителна част от подготвителната работа за тестването на “бялата кутия” е нанасянето на всички възможни пътища, които трябва да тествате, в блок-схема.
Тази стъпка може да ви помогне да увеличите покритието на пътя и да гарантирате, че проверявате всички възможни пътища във всеки създаден от вас тестови случай. Начертайте диаграма на потока, която обхваща всички възможни пътища за всяка функция или компонент, които тествате, например като очертаете различни пътища, които възникват при въвеждане на различни стойности.
Стъпка 3: Определяне на всички възможни пътища
Разгледайте блок-схемата си и определете всички възможни пътища, които потребителите могат да изминат, като започнете от първата стъпка на блок-схемата и завършите с последната стъпка.
Колкото повече разклонения и решения има в блок-схемата, толкова повече уникални пътища ще съществуват. Разбирането на броя на възможните уникални пътища може да ви помогне да се уверите, че тестовите ви случаи обхващат всяка възможност.
Стъпка 4: Създаване на тестови случаи
Следващият етап от тестването на “бялата кутия” е написването на тестови случаи, които проверяват всички пътища, идентифицирани по-горе.
Важно е да се уверите, че тестовите случаи обхващат всички възможни пътища и ясно очертават действията, които тестерите или разработчиците трябва да предприемат, за да изпълнят всеки тестов случай.
За всеки случай на изпитване включете идентификационен номер и име на случая на изпитване, кратко описание, както и очакваните резултати от всяко изпитване.
Стъпка 5: Изпълнение на тестови случаи
Сега е време за изпълнение на тестовите случаи, което повечето хора считат за извършване на самото тестване на бялата кутия.
Тестерите изпълняват тестовите случаи, като следват краткия набор от инструкции, описани във всеки тестов случай, и докладват резултата от всеки тестов случай. Това може да се сравни с очакваните резултати, описани в тестовия случай, за да се установи дали всеки тест на бялата кутия е преминал успешно или не.
Стъпка 6: Повторете цикъла, ако е необходимо
Подобно на други форми на тестване на софтуер, тестването на “бялата кутия” се състои в сравняване на действителното функциониране на системата с очакванията на тестващите за това как трябва да функционира системата.
Ако тестващите открият, че системата не се държи по начина, по който те очакват, това може да означава, че тестването на бялата кутия се е провалило и разработчиците трябва да коригират редовете код, преди да проведат по-нататъшно тестване.
Повторете горния процес, за да извършите по-нататъшно тестване на “бялата кутия”, докато системата не бъде изчерпателно тествана и всички грешки не бъдат отстранени.
Най-добри практики за тестване на бялата кутия
Най-добрите практики за тестване на “бялата кутия” зависят от вида на тестовете, които извършвате, и от етапа на процеса на тестване, в който се намирате.
Тъй като по-голямата част от тестването на “бялата кутия” се извършва по време на тестването на модула и интеграционното тестване, повечето най-добри практики за тестване на “бялата кутия” се прилагат за тези фази.
1. Максимално покритие на тестовете
По дефиниция е важно да се увеличи покритието на тестовете, когато се извършва тестване на “бялата кутия”, за да се гарантира, че голям процент от софтуера е тестван по време на тази фаза.
Можете да направите това, като увеличите максимално покритието на пътя и разклонението и напишете тестови случаи, които изследват всички възможни пътища и резултати по време на подготвителния етап.
2. Проверка на поведението и работата
Когато пишете тестови случаи при тестване на “бяла кутия”, искате да създадете тестови случаи, които проверяват дали системата функционира според очакванията ви, както и тестови случаи, които проверяват производителността на системата.
Например, освен че проверявате дали определени действия водят до определени резултати, можете да проверите и колко бързо системата може да изпълнява определени задачи или как различните променливи влияят на производителността.
3. Пишете тестови случаи независимо един от друг
Ако искате да проверите две различни функции, например ако даден клас код зависи от определена база данни, създайте абстрактен интерфейс, който отразява връзката с тази база данни, и имплементирайте интерфейса с подигравателен обект, за да тествате тази връзка.
Това гарантира, че тестовите случаи проверяват връзките, които искате да проверяват, а не нещо друго.
4. Покрийте всички пътища и примки
Максималното покритие на тестовете означава да се обхванат всички възможни пътища, като се вземат предвид условните цикли и други видове цикли в кода.
Уверете се, че сте разработили тестови случаи, които напълно изследват възможните пътища и проверяват дали циклите се държат така, както очаквате, независимо от входните данни.
7 грешки и капани при
Изпълнение на тестове на бялата кутия
Когато започвате да тествате “бялата кутия”, е важно да сте наясно с някои от най-често срещаните капани, в които разработчиците често попадат при провеждането на тестване на “бялата кутия”. Често срещаните грешки при тестването на “бялата кутия” могат да доведат до забавяния и неточности, които могат да навредят на качеството и графика на пускането на софтуера.
1. Мислене, че тестването на бялата кутия не е необходимо
Някои тестери смятат, че тестването на “бялата кутия” не е необходимо, тъй като при тестването на “черната кутия” се тестват всички външни изходи на софтуера и ако те работят правилно, се предполага, че и вътрешната работа на системата работи.
Въпреки това тестването на “бялата кутия” може да помогне на разработчиците да открият проблеми и грешки, които невинаги се появяват при тестването на “черната кутия”, и е от съществено значение за проверката на сигурността на софтуерните системи.
Например, ако в дадена програма има изтичане на памет, което води до влошаване на производителността за продължителни периоди от време и което не може да бъде изследвано чрез тестване на черната кутия, тестването на бялата кутия е единствената възможност за претърсване на кода и откриване на проблема преди широкото публично пускане.
2. Извършване на всички тестове на бялата кутия ръчно
Някои разработчици може да си мислят, че е също толкова лесно да се извърши тестване на “бялата кутия”, колкото и на “черната кутия”.
Въпреки това тестването на бялата кутия отнема значително повече време и разработчиците, които се опитват да провеждат тестването на бялата кутия изцяло ръчно, могат да установят, че е невъзможно да извършат ръчните проверки по желаните стандарти или при максимално покритие на тестовете.
3. Разпределяне на тестери за изпълнение на тестови случаи
Тестването на “бялата кутия” трябва да се извършва изцяло от разработчици, софтуерни инженери и хора, които напълно разбират вътрешната работа на софтуерната система.
Някои разработчици смятат, че могат да прехвърлят тестването на бялата кутия на тестерите на ОК, след като сами са написали тестовите случаи, но това само ще доведе до лошо изпълнение и ще намали качеството на документацията.
4. Бързане с тестването
Тестването на софтуера е дълъг и отнемащ време процес и някои разработчици може да се изкушат да приключат набързо с тестването на “бялата кутия”, за да преминат към следващата фаза на разработката. Важно е да се отделят достатъчно време и ресурси за тестване на бялата кутия, за да се гарантира, че разработчиците не се чувстват прибързани и че имат достатъчно време да увеличат покритието на тестовете.
5. Лоша документация
Поддържането на подходяща документация преди, по време и след тестването гарантира, че всички участници в разработването и тестването на софтуера имат достъп до правилната информация в точното време.
Уверете се, че всеки член на екипа по разработката знае как да пише ясна документация и как да докладва резултатите от тестването на бялата кутия.
6. Неправилно използване на инструменти за автоматизация
Инструментите за автоматизация могат да улеснят провеждането на тестове в бялата кутия, но е важно да се уверите, че целият ви екип разбира кои инструменти за автоматизация използвате и как да ги използва.
Различните инструменти са подходящи за различни видове тестване, затова е важно да изберете инструменти за автоматизация, които са подходящи за тестване на бялата кутия, и да се научите да използвате правилно техните функции.
Например някои инструменти не интегрират автоматизация и вместо това се фокусират върху събирането на информация и организирането на билети, което далеч не е идеално за автоматизирано тестване. Напротив, пълноценните инструменти, като например ZAPTEST, обхващат целия процес на тестване чрез функции като Автоматизация на всяка задача, което ги прави подходящи за по-ефективна работа по тестване на бяла кутия.
7. Не работи с екипа по осигуряване на качеството
Само защото тестването на “бялата кутия” се планира и извършва от разработчиците, това не означава, че екипът по осигуряване на качеството не трябва да участва по никакъв начин.
Важно е да предадете резултатите от тестването на бялата кутия на екипа по осигуряване на качеството, за да разберат какво е било тествано досега и как резултатите от тестването на бялата кутия могат да повлияят на начина, по който екипът по осигуряване на качеството подхожда към тестването на черната кутия.
Ако не включите екипа за осигуряване на качеството, това може да доведе до прекъсване на връзката между различните отдели, което ще доведе до лоша комуникация и по-лоша обратна връзка по време на тестването. Крайният резултат от това е значително по-ниско ниво на качество на крайния продукт.
Видове резултати от тестовете на бялата кутия
Когато извършвате тестване на софтуер в бяла кутия, ще получите различни резултати в зависимост от резултатите от проведените тестове. Разбирането на тези резултати от тестовете в бялата кутия може да ви помогне да разберете какви стъпки да предприемете по-нататък.
1. Резултати от тестовете
Резултатите от тестовете на “бялата кутия” ще ви покажат дали трябва да продължите с по-нататъшно тестване, дали има дефекти, които трябва да бъдат отстранени, и дали всеки отделен тестови случай е преминал успешно или не. Необходима е подробна документация, защото тя помага на разработчиците и тестерите да разберат резултатите от тестването на бялата кутия.
2. Дефекти
Дефектите могат да бъдат идентифицирани при тестване на “бялата кутия”, а понякога резултатът от тестовете на “бялата кутия” ще бъдат дефекти и грешки.
Ако софтуерната система не се държи така, както очаквате по време на тестването на “бялата кутия”, това може да означава, че в програмата има сериозни дефекти, които трябва да бъдат отстранени, преди да продължат разработването и тестването.
3. Доклади от изпитвания
Докладите от тестването са доклади, съставени от разработчици и тестери по време на и след тестването на софтуера.
Те съдържат подробна информация за резултатите от теста, включително кои тестови случаи са преминали успешно и кои не, каквито и да било дефекти, открити по време на тестването, и препоръки за следващите стъпки.
Разработчиците използват докладите от тестовете, за да комуникират с други разработчици, чиято задача може да бъде да поправят грешки, открити по време на тестовете.
Примери за тестове на бялата кутия
Тестването на бялата кутия позволява на разработчиците да проверят дали вътрешната структура на софтуерната система работи както трябва, независимо от външните резултати и изходи на системата.
Примерите по-долу илюстрират как тестването на бялата кутия може да помогне на разработчиците да проверят вътрешните функции на софтуера.
1. Пример за регистрационна страница за електронна търговия
Един от примерите за тестване на “бялата кутия” разглежда начина, по който разработчиците тестват функциите на уебсайтове. Ако се опитвате да тествате страницата за регистрация на уебсайт за електронна търговия, тестването в бяла кутия може да позволи на разработчиците да разберат дали функциите и класовете, свързани с регистрацията, работят по начина, по който трябва, когато се извършва функцията за регистрация.
Това включва цялата информация, която потребителят въвежда, и оценява параметрите на формуляра, включително датите, които са и не са валидни, и това, което формулярът счита за легитимен имейл адрес.
След това екипът влиза в серия от низове, които тестват формуляра, като някои от тях са предназначени за неуспех, а други – за успех, преди да се оценят резултатите спрямо прогнозираните.
От друга страна, при тестването “черна кутия” се проверява само дали самата страница работи, без да се прави допълнителен анализ на причините и начините.
2. Пример за калкулатор
Калкулаторите за приложения са друг пример за тестване на “бялата кутия”.
Ако създавате калкулатор, който се използва като част от приложение, тестерите на “черната кутия” просто ще проверят дали изходните данни на калкулатора са правилни при използването му по предназначение.
Тестерите на “бялата кутия” ще проверят вътрешните изчисления на калкулатора, за да проверят как е изчислен изходът и дали той е правилен. Това е по-полезно за по-сложни изчисления с няколко етапа, като например данъци. Тестерите разглеждат кода, за да видят стъпките, които калкулаторът извършва, и реда, в който се извършват стъпките, преди да видят резултата след всеки етап.
Ако входът на калкулатора е (7*4) – 6, а изходът е 22, това е правилно и тестът на черната кутия ще премине успешно. Но това е така, защото 7*4 = 28, а 28 – 6 е 22. Тестването на “бялата кутия” може да покаже, че софтуерът е намерил този резултат, като е извършил 7*4 = 32 и 32 – 6 = 22, като нито едно от двете не е правилно.
Тази по-добра проницателност показва, че изчислението е точно след всеки конкретен етап, открива етапа, на който може да не е точно, и го решава по-бързо, тъй като тестерът може ясно да види къде се появява проблемът.
Видове грешки и бъгове при тестването на бялата кутия
По време на тестването на бялата кутия е възможно да се идентифицират и открият грешки, които могат да повлияят на начина, по който системите работят под капака. Тези грешки могат да засягат външни функции или да влияят на производителността или надеждността.
По-долу са изброени някои от най-често срещаните видове грешки и пропуски, които възникват при тестване на “бялата кутия”.
1. Логически грешки
Логическите грешки възникват при тестването на “бялата кутия”, тъй като тестовете на “бялата кутия” показват области, в които програмата не функционира логически или в които функциите и условията се използват неправилно в кода на софтуера.
Логическите грешки могат да се проявят като сривове в системата или просто да доведат до неочаквано поведение и резултати.
2. Грешки при проектирането
Тестването на бялата кутия може да помогне на разработчиците да идентифицират грешки в дизайна на кода. Грешки в проектирането възникват, когато има разлика между логическия поток на софтуера и действителната реализация на софтуера. Те могат да доведат до неочаквано поведение и грешки в работата.
3. Типографски грешки
Типографските грешки и недостатъците в синтаксиса са грешки, които се дължат на човешка грешка – например защото разработчикът е изписал погрешно определена фраза или е добавил грешни препинателни знаци в даден ред код. Подобни малки грешки могат да доведат до нарушени функции и изявления, които софтуерът не може да прочете, което може да доведе до сериозни грешки в системата.
Общи показатели за тестване на бялата кутия
Когато извършвате тестване на “бялата кутия”, общите показатели за тестване могат да ви помогнат да измерите колко успешни и изчерпателни са тестовете на “бялата кутия”, както и да разберете качеството на работата на разработчиците.
Показателите за тестване дават информация за процеса на разработване, тъй като могат да идентифицират области за подобрение или да направляват процеса на тестване в бъдеще.
1. Обхват на кода
Една от основните характеристики на тестването в “бяла кутия” е, че то трябва да покрива възможно най-голяма част от кода, като можете да измерите колко код сте покрили с помощта на метрики за покритие на кода.
Метриките за покритие на кода показват каква част от общия код на приложението сте проверили с помощта на тестване в бялата кутия. Обикновено разработчиците се стремят да обхванат възможно най-близо до 100% от софтуерния код чрез тестване на “бялата кутия”.
Покритието на кода може да бъде разделено на различни показатели, включително покритие на пътя, сегмента, изявлението и клона.
Покритието на съставните условия е друг вид метрика за покритие на кода, която проверява дали всяко условие в рамките на набора е проверено по множество пътища и комбинации от пътища.
2. Показатели за дефекти
Показателите за дефекти отразяват колко дефекти са открити, колко добре тестовете на бялата кутия идентифицират дефектите и какъв процент от кода преминава или не преминава тестовете на бялата кутия.
Показателите за дефекти могат да бъдат представени като брой дефекти на хиляда реда код или като брой на общите дефекти в програмата. Макар че малкият брой дефекти може да изглежда положителен, разработчиците трябва да се уверят, че това не е така, защото дефектите са пропуснати при тестването.
3. Изпълнение на теста
Показателите за изпълнение на тестовете могат да помогнат на разработчиците бързо да разберат каква част от всички тестове са изпълнени до момента и колко неизпълнени теста остават. Метриките за изпълнение на текста помагат на софтуерните екипи да разберат докъде е стигнал напредъкът в тестването на бялата кутия и дали автоматизираните софтуерни тестове работят според очакванията.
Възможно е обаче да има както фалшиво положителни, така и фалшиво отрицателни резултати, което може да повлияе на точността на този показател.
4. Продължителност на теста
Показателите за продължителността на тестовете ни показват колко време отнема изпълнението на автоматизираните тестове, което е особено важно при тестването на “бялата кутия”, тъй като автоматизацията е от съществено значение за постигане на максимална ефективност на тестовете и покритие на тестовете.
Продължителността на тестовете често е пречка при гъвкавата разработка на софтуер, така че разбирането на това колко време отнема изпълнението на софтуерните тестове може да помогне на екипите за разработка да ускорят процеса на разработка.
Важно е обаче да запомните, че показателите за продължителността на тестовете не ви казват нищо за качеството на провежданите тестове.
Инструменти за тестване на бялата кутия
Инструментите и технологиите могат да направят тестването на “бялата кутия” значително по-точно, ефективно и изчерпателно. Инструментите за тестване на бяла кутия могат да помогнат на софтуерните инженери да автоматизират тестването на бяла кутия, да записват и документират процеса на тестване на бяла кутия и да управляват тестването на бяла кутия от началото до края.
5 най-добри безплатни инструмента за тестване на бяла кутия
Ако все още не искате да инвестирате в скъпи инструменти за тестване на “бялата кутия”, можете да изпробвате цял набор от безплатни инструменти за тестване на “бялата кутия” онлайн, без да плащате нищо.
Безплатните инструменти за тестване невинаги предлагат същата функционалност като корпоративните инструменти, но те са добра отправна точка за начинаещите в тестването на “бялата кутия” и могат да помогнат на екипите за разработка да придобият по-добра представа за това какви инструменти и технологии са им необходими.
1. Безплатно издание на ZAPTEST
ZAPTEST е инструмент за тестване на софтуер и софтуер за автоматизация на роботизирани процеси, който позволява на разработчиците и QA тестерите да автоматизират както тестването на “бялата кутия”, така и тестването на “черната кутия”.
Безплатната версия на ZAPTEST позволява множество виртуални потребители, множество итерации и поддръжка на потребителски форум. Приложението работи както с локални, така и с външни източници на данни и се интегрира с HP ALM, Rally и JIRA. Потребителите, които харесват безплатната оферта на ZAPTEST и искат да видят повече от това, което компанията предлага, могат да се информират за надграждане до корпоративното издание, когато то бъде готово.
2. Bugzilla
Bugzilla е много популярен инструмент за тестване на софтуер с отворен код, който позволява на разработчиците да проследяват грешки и дефекти в софтуера и да управляват жизнения цикъл на грешките.
Bugzilla улеснява възлагането на грешки на разработчиците, приоритизирането и проверката на грешките и затварянето им след отстраняването им. Bugzilla е чудесен инструмент за екипи, които все още се опитват да стандартизират подхода си към докладването на грешки, и е напълно безплатен за използване.
3. OpenGrok
OpenGrok е браузър за код с отворен код и търсачка за база данни. Той е съвместим с код, написан на Java C++, JavaScript и Python, както и с други езици за програмиране.
Ако искате да можете бързо да се ориентирате в голяма база от кодове по време на тестването на бялата кутия, OpenGrok е напълно безплатен и лесен за използване.
4. SQLmap
SQLmap е друг инструмент с отворен код, който се счита за почти необходим при тестването на “бялата кутия”. SQLmap регулира потока на експлоатиране и откриване на грешки при инжектиране на SQL.
SQLmap е самоопределящ се като “инструмент за тестване за проникване”, който може да помогне на тестващите “бялата кутия” да идентифицират и открият грешки в сигурността в изходния код и да ги отстранят, преди да продължат.
5. Ема
Emma е набор от инструменти с отворен код, който може да измерва покритието на кода ви, ако работите на Java. Това е изключително бърз начин за бързо установяване на покритието на кода и за проследяване на това колко код е покрил всеки член на екипа за разработка поотделно.
Emma поддържа покритие на класове, методи, редове и основни блокове и е изцяло базирана на Java.
5 най-добри инструменти за тестване на бялата кутия на предприятието
Ако търсите инструменти, които предлагат по-голяма функционалност или по-добра поддръжка, корпоративните инструменти за тестване на бели кутии може да са по-подходящи за вашия екип за разработка.
1. Издание ZAPTEST ENTERPRISE
Корпоративното издание на ZAPTEST е усъвършенствана версия на безплатния ZAPTEST. В тази версия потребителите могат да се възползват от неограничен брой шаблони за OCR, неограничен брой итерации и неограничен брой VBScript и JavaScript скриптове.
Корпоративното издание на ZAPTEST предлага по-пълен набор от инструменти за екипи от разработчици, които искат да преминат към автоматизация, а корпоративната версия се предлага и с експертна поддръжка, за да сте сигурни, че екипът ви ще извлече максимума от автоматизацията на софтуерното тестване и технологията RPA на ZAPTEST.
2. Fiddler
Fiddler е набор от инструменти на Telerik, който е създаден за тестване на уеб приложения в бялата кутия. Fiddler може да регистрира целия HTTP трафик между вашата система и интернет и да оценява зададените точки на прекъсване, както и да коригира изходящите и входящите данни. Той се предлага в различни формати в зависимост от бюджета и изискванията ви, така че има издание на Fiddler за почти всеки екип.
3. Укрепване на HP
HP Fortify, известен преди като Fortify, е друг инструмент за тестване на сигурността, който предлага цялостни решения за сигурност за тестване на “бяла кутия”. Пакетът от инструменти Fortify включва инструмента Fortify Source Code Analysis, който автоматично сканира изходния ви код за уязвимости, които могат да направят приложението ви отворено за кибератаки.
4. ABAP модул
Корпоративната версия на ABAP Unit позволява на разработчиците на софтуер да извършват бързо и лесно както ръчно, така и автоматизирано тестване на блокове. Разработчиците пишат тестове на единици в рамките на ABAP приложението и използват тези тестове за проверка на функциите на кода и идентифициране на грешки в рамките на тестването на единици.
Софтуерните екипи, които искат да изпробват този инструмент, могат да започнат с безплатната версия на ABAP Unit, преди да преминат към корпоративното издание.
5. LDRA
LDRA е патентован набор от инструменти, които могат да се използват за покриване на твърдения, клонове и решения при провеждане на тестване на “бяла кутия”. Това е отличен инструмент, ако искате да проверите дали изходният ви код отговаря на стандартните изисквания за съответствие, проследяване и хигиена на кода.
Кога трябва да използвате Enterprise
срещу безплатни инструменти за тестване на бели кутии?
Както корпоративните, така и безплатните инструменти за тестване на софтуер имат своето място във всеки съвременен екип за разработка на софтуер. Когато екипът ви се разраства и автоматизираното тестване става все по-важно за вашия подход за тестване на “бялата кутия”, вероятно ще искате да преминете от работа предимно с безплатни инструменти за тестване към работа с корпоративни инструменти, които предлагат повече функционалност и неограничени възможности за използване.
Въпреки това има специфични сценарии, при които безплатните инструменти могат да бъдат по-подходящи от корпоративните инструменти.
Много разработчици избират да започнат с безплатни инструменти, когато експериментират с нови функции и технологии, най-вече за да преценят дали тези технологии са подходящи за техния екип, преди да инвестират в корпоративни технологии.
Можете също така да изпробвате безплатни версии на корпоративни инструменти като ZAPTEST, за да ги изпробвате, преди да ги купите, и да разберете повече за това, което предлагат корпоративните инструменти.
И накрая, някои безплатни инструменти като Emma и Bugzilla са специализирани в нишови, но важни функции, които предлагат постоянни предимства дори на софтуерни екипи, готови да плащат за корпоративни технологии.
Тестване на бялата кутия: контролен списък, съвети и трикове
Когато сте готови да извършите тестване на “бялата кутия”, преди да започнете, се уверете, че имате всичко необходимо. По-долу е представен списък с неща, които трябва да запомните, преди да започнете тестването на бялата кутия, за да увеличите максимално обхвата на тестовете и да подобрите точността на резултатите от тестовете на бялата кутия.
1. Използване на инструменти за автоматизация
Инструментите за автоматизация могат значително да ускорят процеса на провеждане на тестване на “бялата кутия”, както и да намалят процента на грешките и да повишат общата точност.
Почти всички софтуерни екипи днес използват някакво ниво на автоматизация за провеждане на тестване на “бялата кутия”, така че експериментирането с различни инструменти и технологии за автоматизация, преди да започнете тестването на “бялата кутия”, може да ви помогне да изберете инструментите, които искате да използвате, преди да започне тестването.
2. Стремеж към 100% покритие на тестовете
Вероятно няма да постигнете целта си за 100% покритие на тестовете, но стремежът да се доближите максимално до тази стойност е най-добър при провеждане на тестване на бялата кутия.
Използвайте инструменти за измерване на покритието на тестовете, за да проследявате и измервате отделни показатели, като например покритие на пътища и клонове, и да се уверите, че всички най-важни пътища и клонове в софтуера ви са били покрити по време на тестването на “бялата кутия”.
3. Изготвяне на ясни доклади от тестове
Както и при други форми на тестване на софтуер, уверете се, че екипът ви знае как да съставя точни и ясни доклади за тестване след всеки етап от тестването.
Докладът за теста трябва да бъде написан в лесен за разбиране формат и да включва подробности за подхода за тестване, както и обобщение на изходите и резултатите от всеки изпълнен тестови случай. Окончателният доклад трябва да обоснове предприетите стъпки и да даде препоръки за следващите стъпки.
4. Измерване на успеха с метрики за тестване
Метриките за тестване помагат на софтуерните екипи да проследяват и записват напредъка на тестването на “бялата кутия” и предлагат ценна информация, която може да бъде използвана в бъдещите процеси на разработка.
Важно е разработчиците да използват метрики, за да разберат колко ефективно е тестването, което извършват, и колко чист е бил първоначалният им код, за да могат да подобрят работата си в бъдеще.
Тестване на бялата кутия:
Заключение
Тестването на “бялата кутия” в софтуерното инженерство е основен вид софтуерно тестване, което проверява вътрешната структура и логика на изходния код на софтуерното приложение.
В комбинация с тестването на черната кутия, тестването на бялата кутия установява не само дали софтуерът работи според очакванията, но и дали вътрешният код е логичен, чист и завършен.
Тестването на бялата кутия се извършва най-често при тестването на блокове и интеграционното тестване и винаги се извършва от разработчици и софтуерни инженери с пълно познаване на вътрешния код на софтуера.
Макар че някои тестове на бялата кутия могат да се извършват ръчно, днес голяма част от тестовете на бялата кутия се автоматизират поради подобренията в скоростта, ефективността и обхвата, които автоматизацията на тестовете на бялата кутия предлага.
Често задавани въпроси и ресурси
Ако искате да научите повече за тестването на бялата кутия, има много безплатни онлайн ресурси, които можете да използвате. Можете да използвате видеоклипове, книги и други ресурси, за да се научите да извършвате тестване на бялата кутия и да гарантирате, че стандартите за тестване на бялата кутия следват най-добрите практики.
1. Най-добрите курсове за автоматизация на тестовете в бяла кутия
Ако искате да научите повече за автоматизацията на тестовете на “бяла кутия”, можете да изкарате курс по тестване на софтуер и тестване на “бяла кутия”. Някои от тези курсове са акредитирани и предлагат официална квалификация, докато други са неофициални онлайн курсове, предназначени да помогнат на разработчици и софтуерни тестери, които искат да подобрят знанията си по дадена тема.
Някои от най-добрите курсове за тестване на бялата кутия, достъпни онлайн днес, включват:
2. Кои са петте най-важни въпроса за интервю за автоматизация на тестовете в бяла кутия?
Ако се подготвяте за интервю, на което може да обсъждате тестването на “бялата кутия”, техниките на “бялата кутия” и инструментите за автоматизация, е важно да знаете.
- Каква е разликата между тестването на “бялата кутия” и тестването на “черната кутия”?
- Защо е важно тестването на бялата кутия?
- Какви са някои от различните подходи, които можете да използвате при тестването на “бялата кутия”?
- Какви процеси са свързани с тестването на бялата кутия и как можем да ги подобрим?
- Кои са някои от инструментите и технологиите, които можете да използвате, за да направите тестването на бялата кутия по-бързо или по-точно?
3. Най-добрите уроци в YouTube за тестване на бялата кутия
Ако искате да научите повече за тестването на “бялата кутия”, гледането на уроци в YouTube може да ви помогне да разберете как работи тестването на “бялата кутия” и да видите визуални обяснения на процесите и подходите, свързани с тестването на “бялата кутия”.
Някои от най-информативните онлайн уроци в YouTube включват:
- Udacity: Пример за тестване на бялата кутия
- Guru99: Какво е тестване на бялата кутия?
- Тестване на “бялата кутия” срещу “черната кутия
- Техники за тестване на бялата кутия
- Наставник по тестване на софтуер: Какво представлява тестването в бялата кутия?
4. Как да поддържаме тестовете на бялата кутия
Поддръжката на тестовете на софтуера гарантира, че всеки път провежданите от вас тестове са задълбочени и подходящи за целта. Важно е да се поддържат всички видове софтуерни тестове както в черната кутия, така и в бялата кутия, тъй като кодът, върху който извършвате тестове, се променя постоянно с всяка поправка на грешки и итерация. Това означава, че вашите тестови скриптове трябва да се променят заедно с него.
Поддържането на тестове “бяла кутия” включва актуализиране на рамката за автоматизация на тестването и прилагане на процеси, предназначени да гарантират, че тестовете и тестовите случаи се актуализират редовно.
Можете да направите това, като:
Вграждане на поддръжката в дизайна на теста:
Обмислянето на бъдещето на тестването на “бялата кутия” още при създаването и проектирането на тестовете на “бялата кутия” ще улесни поддръжката на тестовете в бъдеще.
Осигуряване на ясна комуникация между екипите:
Уверете се, че всички членове на екипа ви за разработка разполагат с множество канали за комуникация, така че веднага щом бъдат направени промени в кода, те да бъдат отразени бързо в тестовете.
Бъдете адаптивни:
Понякога може да направите промени в кода, които не сте планирали. Уверете се, че екипът ви знае как да се адаптира бързо към тези промени и има уменията да проследява тези промени при тестване.
Постоянно преоценявайте протоколите за изпитване:
Протоколите за тестване, които сте приложили в началото на тестването, може да не са подходящи, когато софтуерът ви претърпи различни промени и подобрения. Преоценявайте протоколите си за тестване на редовни етапи, за да проверите дали те все още са подходящи.
5. Най-добрите книги за тестване на бялата кутия
Тестването на бялата кутия е задълбочена тема, чието овладяване може да отнеме години. Ако искате да станете експерт по съвременното тестване на бяла кутия в областта на тестването на софтуер, можете да прочетете книги за тестване на бяла кутия, написани от разработчици, учени и инженери.
Някои от най-добрите съвременни книги за тестване на “бялата кутия” и автоматизация на тестовете включват:
- Изкуството на софтуерното тестване, трето издание от Glenford J. Myers, Corey Sandler, Tom Badgett, Todd M. Thomas
- Тестване на софтуер: Йоргенсен, четвърто издание.
- Как да разбиваме софтуер: Практическо ръководство за тестване от Джеймс Уитакър
- Автоматизацията на софтуерните тестове Just Enough от Дан Мосли и Брус Поузи
Би трябвало да можете да намерите тези книги в някои книжарници и библиотеки, както и онлайн. Можете да намерите и други материали за четене и учебни ресурси в списъците с литература на добри курсове и програми за тестване на софтуер.
