Испробување во бела кутија

White-box испробување (исто така познато како clear box испробување, glass box испробување, transparent box испробување, и структурирано испробување) е метод за испробување на софтвер кој ги испробува внатрешни структури или работата на апликацијата, а не нејзината функционалност (пр. black-boxиспробување). При white-box испробување, внатрешна перспектива на системот, како и програмски вештини, се користат за дизајнирање на тест примери/случаи. Тестерот избира влезови за вежбање на патеките низ кодот и ги одредува очекуваните излези. Ова е аналогно на испробување на јазли во коло, на пр. in-circuit testing (ICT). White-box испробувањето може да се примени за единица/unit, интеграција и нивото на системот на процесот на испробување на програмска опремаот. Иако традиционалните тестери имаат тенденција да размислуваат за white-box испробувањето како да е направено на ниво на единица//unit, денес се користи за интеграција и системско испробување. Може да испробува патеки во рамките на единицата, патеки помеѓу единиците за време на интеграцијата и помеѓу подсистемите за време на тест на ниво на систем. Иако овој метод на тест дизајн може да открие многу грешки или проблеми, тој има потенцијал да пропушти неимплементирани делови од спецификацијата или барањата што недостасуваат. Каде што white-box испробувањето е управувано од дизајнот,^[1] тоа е, управувано исклучиво од договорени спецификации за тоа како се бара секоја компонента на софтверот да се однесува (како во процесите DO-178C и ISO 26262), тогаш техниките за испробување на белата кутија можат да постигнат проценка за неимплементирани или исчезнати барања.

Дизајнот за White-box испробувањето ги вклучува следниве критериуми за покриеност на кодот:

Испробување на контрола на проток
Испробување на проток на податоци
Испробување на гранки
Опфат на изјавата
Покриеност на одлуката
Изменета покриеност на состојбата/одлуката
Испробување на главната патека
Испробување на патеката

Преглед

White-box испробувањето е метод за испробување на апликацијата на ниво на изворниот код. Овие тест случаи се добиени преку употреба на техниките за дизајн споменати погоре: испробување на контрола на проток, испробување на проток на податоци, испробување на гранки, испробување на патеки, покривање на изјава и покривање на одлука, како и изменето покривање на состојба/одлука. White-box испробување е употреба на овие техники како упатства за создавање средина без грешки со испитување на целиот код. Овие техники за white-box испробување се градежни блокови на white-box испробување, чија суштина е внимателно испробување на апликацијата на ниво на изворен код за да се намалат скриените грешки подоцна. Овие различни техники ја вежбаат секоја видлива патека на изворниот код за да ги минимизираат грешките и да создадат средина без грешки. Целата поента на white-box испробувањето е можноста да се знае која линија на кодот се извршува и да може да се идентификува кој треба да биде точниот излез.

Нивоа

Unit испробување. White-box испробувањето се врши за време на unit тестови за да се осигура дека кодот работи според предвиденото, пред да се случи интеграцијата со претходно испробуваниот код. White-box испробувањето се врши за време на unit тестови потенцијално фаќа многу дефекти рано и помага во решавање на дефекти што се случуваат подоцна откако кодот е интегриран со останатата апликација и затоа ги намалува влијанијата на грешките подоцна во развојот.
Интеграциско испробување. White-box испробувањето на ова ниво е напишано за да се испробуваат интеракциите на интерфејсите едни со други. Unit испробувањето се погрижи секој код да биде испробуван и соодветно да работи во изолирана средина и интеграцијата ја испитува исправноста на однесувањето во отворено опкружување преку употреба на white-box испробување за какви било интеракции на интерфејси што му се познати на програмерот.
Регресивно испробување. White-box испробувањето при регресивно испробување е употреба на рециклирани случаи за white-box испробување со unit и интеграциски тестови.

Основна постапка

Основните постапки за white-box испробување бараат тестерот да има длабоко познавање на изворниот код што се испробува. Програмерот мора да има длабоко разбирање за апликацијата за да знае какви видови тест случаи треба да создаде, така што секоја видлива патека се вежба за испробување. Откако ќе се разбере изворниот код, тогаш изворниот код може да се анализира за тест случаи што треба да се создадат. Следното се трите основни чекори што треба да се преземат кај white-box испробувањето за да се создадат тест-случаи:

Влезот вклучува различни видови на побарувања, функционални спецификации, детално дизајнирање на документи, правилен изворен код и безбедносни спецификации. Ова е фаза на подготовка на white-box испробување за да се изложат сите основни информации.
Обработката вклучува извршување анализа на ризик за водење на целиот процес на испробување, правилен план за испробување, извршување на тест случаи и комуникација на резултатите. Ова е фаза на градење тест случаи за да се осигураме дека тие темелно ја испробуваат апликацијата, дадените резултати соодветно се запишуваат.
Излезот вклучува подготовка на финален извештај кој ги опфаќа сите горенаведени подготовки и резултати. ^{[ потребно е цитирање ]}

Предности

White-box испробувањето е еден од двата најголеми методи на испробување што се користат денес. Има неколку главни предности:

Несаканите ефекти од познавањето на изворниот код се корисни за темелно испробување.
Оптимизацијата на кодот станува лесна кога се изложени незабележителни тесни грла.
Дава интроспекција на програмерот затоа што програмерите внимателно ја опишуваат секоја нова имплементација.^{[се бара извор]}^{[ потребно е цитирање ]}
Обезбедува можност за следење на тестовите од изворот, а со тоа дозволува идните промени во изворот лесно да бидат зафатени во ново додадените или изменетите тестови.^[2]
Лесно се автоматизира.^[3]
Овозможува јасни, инженерски засновани правила за тоа кога да престанете да испробувате.^[4]

Недостатоци

Иако white-box испробувањето има големи предности, тоа не е совршено и содржи некои недостатоци:

White-box испробувањето носи комплексност на испробувањето затоа што тестерот мора да има познавање на програмата или, пак, тест тимот треба да има барем еден многу добар програмер кој може да ја разбере програмата на ниво на код. White-box испробувањето бара програмер со високо ниво на знаење поради комплексноста на нивото на испробување што треба да се направи.^{[се бара извор]}
Во не^{[ потребно е цитирање ]}кои прилики, не е реално да може да се испробува секоја постоечка состојба на апликацијата и некои услови ќе бидат непроверени.^{[се бара извор]}^{[ потребно е цитирање ]}
Тестовите се фокусираат на софтверот каков што постои, а функционалноста што недостасува не може да се открие.
Резултирачкиот тест може да биде кревок, бидејќи тие се цврсто споени со специфичното спроведување на предметот што се испробува. Кодот што се испробува може да се препише за да се спроведе истата функционалност на поинаков начин што ги поништува претпоставките испечени во тестот. Ова може да резултира со тестови кои непотребно паѓаат или, во најлош случај, тестови кои сега даваат лажни позитиви и маскираат грешки во кодот.

Модерен поглед

Посовремен став е дека дихотомијата помеѓу white-box испробување и black-box испробување е замаглена и станува сè порелевантна. Додека „white-box“ првично значеше користење на изворниот код, а black-box значеше употреба на барања, тестовите сега се добиени од многу документи на различни нивоа на апстракција. Вистинската поента е дека тестовите обично се дизајнираат од апстрактна структура како што е влезниот простор, графикон или логички предикати, а прашањето е од кое ниво на апстракција ја извлекуваме таа апстрактна структура.^[3] Тоа можат да бидат изворен код, барања, описи на влезниот простор или еден од десетиците типови модели на дизајн. Затоа, разликата „white-box/black-box“ е помалку важна и поимите се помалку релевантни.

Хакирање

При испробување на пенетрација, white-box испробувањето се однесува на метод каде хакер со бела капа има целосно познавање на системот што е нападнат. Целта на тестот за пенетрација во white-box е да се симулира злонамерен инсајдер кој има познавање и евентуално основни квалификации за целниот систем.

Поврзано

Наводи

↑ Stacy Nelson (June 2003), NASA/CR–2003-212806 Certification Processes for Safety-Critical and Mission-Critical Aerospace Software (PDF), Ames Research Center, стр. 25, [Glossary] White Box Testing: Design-driven testing where engineers examine internal workings of code
↑ Binder, Bob (2000). Testing Object-oriented Systems. Addison-Wesley Publishing Company Inc.
↑ ^3,0 ^3,1 Ammann, Paul; Offutt, Jeff (2008). Introduction to Software Testing. Cambridge University Press. ISBN 9780521880381.
↑ Myers, Glenford (1979). The Art of Software Testing. John Wiley and Sons.

Надворешни врски

BCS SIGIST (Специјалистичка интересна група за компјутерско општество во испробување на програмска опрема): http://www.testingstandards.co.uk/Component%20Testing.pdf Архивирано на 26 февруари 2021 г. Стандард за испробување на компонентите на софтверот ], Работен нацрт 3.4, 27. Април 2001 година.
http://agile.csc.ncsu.edu/SEMaterials/WhiteBox.pdf Архивирано на 5 септември 2008 г. има повеќе информации за испробување на проток на контрола и испробување на проток на податоци.
http://research.microsoft.com/en-us/projects/pex/ Pex - Автоматско испробување на белата кутија за. НЕТ

[1] Stacy Nelson (June 2003), NASA/CR–2003-212806 Certification Processes for Safety-Critical and Mission-Critical Aerospace Software (PDF), Ames Research Center, стр. 25, [Glossary] White Box Testing: Design-driven testing where engineers examine internal workings of code

[binder-2] Binder, Bob (2000). Testing Object-oriented Systems. Addison-Wesley Publishing Company Inc.

[introtest-3] 3,0 ^3,1 Ammann, Paul; Offutt, Jeff (2008). Introduction to Software Testing. Cambridge University Press. ISBN 9780521880381.

[myers-4] Myers, Glenford (1979). The Art of Software Testing. John Wiley and Sons.

[1]

[2]

[3]

[4]