Семинарски Труд по предметот Софтверски Дизајн На тема :

White box & Black box Тестирање

Софтверски Дизајн Изработил Влатко Алексовски

Професор Индекс бр. Тони Стојановски 0085 фи

1.Вовед

Во оваа семинарска работа ке биде даден подетален приказ на два

од методите на софтверско тестирање, при што ќе биде изнесено кратко

претставување генерално на софтверските тестирања денес и низ

историјата. Исто така ке бидат презентирани начинот на кој тие се

спроведуваат , како се разгрануваат понатаму , што вклучуваат во своето

функционирање како и нивното влијание во бизнисот, од економска и

функционална гледна точка. Претставувајки ги двата метода следствено ќе

се направи споредба за економската исплатливост засебно на секој метод,

притоа компаративно предложувајки го евентуалниот победник на

модерното софтверско тестирање.

2

1.1 Претставувања и карактеристики на

софтверските тестирања

Софтверското тестирање претставува истражување спроведено да

обезбеди информации за квалитетот на производот или поправка на

грешката при тестирање,со известување кон одредени заинтересирани

чинители.Тоа исто така обезбедува објективен , независен поглед на

софтверот за да овозможи бизнис групацијата да го цени и разбира ризикот

кај имплементација на софтверот. Техниките на тестирање вклучуваат, но не

се ограничени да разликуваат процеси на извршување на програмата или

апликацијата од со намерата на наоѓање на софтверски бубачки.

Софтверското тестирање исто така може да претставува процес на

валидација и верификација дека софтверот на еден програм , апликација

или продукт ќе функционира со :

3

1. Претходно запознавање со бизнисот на клиентот и неговите потреби

со цел дознавање на техничките побарувања, потребни за дизајн и

развој на софтверот.

2. Софтверот работи како што треба

3. Самиот софтвер да биде имплементиран со истите карактеристики

Софтверското тестирање, во зависност од користените методи на

тестирање, може да биде имплементирано во секое време во процесот на

развој. Меѓутоа повеќето од тестирањата се спроведуваат откако е завршен

процесот на потребности за реализација и откако е завршено кодирањето.

Различните модели за развој на софтвер ке се сосредочат во

различни точки во процесот на развој. Поновите модели на развој , како

Agile, често зафаќаат развој воден од додатни тестирања и со тоа задаваат

зголемена доза на тестирања во рацете на развивачот. Во

потрадиционалниот модел повеќето тестирања настануваат откако се

дефинирани барањата и процесот на кодирање е завршен.

Тестирањето никогаш не може комплетно да ги воочи сите дефекти

на софтверот. Наместо тоа обезбедува еден вид на критицизам или

споредба која ја одредува состојбата или однесувањето на продуктот, во

однос на принципите или механизмите, според кои некој би можел да

препознае проблем. Овие принципи вклучуваат (но не се ограничени)

Спецификации, договори споредени продукти, претходни верзии на истите

продукти, наведувања на очекувани или наменети цели, корисничките

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

4

Секој софтверски продукт има однапред определена целна група на

потрошувачи . На пример групата на клиенти за сафтвер за видео игри е

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

организација развива или инвестира во софтверски продукт, таа ги

согледува сите подробности како тој би се имплементирал и помогнал на

своите крајни корисници, неговите првични потрошувачи, луѓето кои го

активирале и секако учесниците во целиот процес. Софтверското

тестирање, всушност претставува процесот кога софтверот се обидува да

ја изврши оваа имплементација, односно оваа задача.

1.2 Софтверското тестирање низ историјата

5

Низ историјата употребата на терминот “bug” – бубачка се користи за

да се опише дефект , а во инжинерството е жаргон веќе декади , можеби

уште од времето на Томас Едисон. Во софтверското тестирање ова тесно

се поврзува со 9 Септември 1945 , кога всушност првата бубачка,

предизвикала грешка во електромеханичкиот компјутер Харвард Марк II .

Оваа бубачка била внимателно отстранета и снимена во архивата. Оваа

историја е најчесто поврзана со името на Грејс Мури Хопер кој го има

опишано ова случување во архива-записникот.

Самата историја на тестирање се смета дека се формирала сво

педесетите години кога бил дизајниран првиот модерен програмски јазик

FORTRAN-Формула преведувачот . Сепак низ историјата софтверското

тестирање било разграничено од дебагирањето од Гленфорд Џ. Маерс во

1979 . Иако неговото тестирање индицирало дека секој тест е успешен

само ако се пронајде бубачка-грешка. Сепак ова тестирање ја

претставувало желбата на софтверската инжинерска заедница да се одвои

од фундаменталните развојни активности , како што е дебагирањето во

однос на верификацијата. Дејв Гелперин и Вилијам Ц. Хецел ги

класифицирале фазите и целите на софтверското тестирање во следниве

нивоа :

До 1956 - ориентирано на дебагирање

1957 - 1978 - ориентирано на демонстрација

1979 - 1982 - ориентирано на уништување

1983 -1987 - ориентирано на проценување

1988 - 2000 - превентивно ориентирано

6

Примарната цел за тестирањето е детекцијата на софтверските

неуспеси, со цел дефектите да мозат да бидат откриени и корегирани. Така

да се знае дека тестирањето не може да воспостави дека продуктот

функционира соодветно под сите услови , но мозе само да воспостави дека

продуктот не функционира тестиран под одредени услови. Кругот на

делување на софтверското тестирање многу често вклучува и преглед на

кодот како и извршување на самиот код во различни средини и услови. Исто

така тестирањето се задрзува и на прегледување на аспектите на кодот како

на пр. Дали го извршува тоа што треба да го прави и неговата реакција

спрема потребата. Во моменталната култура на развој на софтвер,

организацијата која тестира може да биде одвоена од тимот кој го развива

софтверот. Има различни улоги за членовите на тимот за тестирање.

Информацијата која е добиена од софтверското тестирање може да биде

искористена да го поправи процесот според кој софтверот е развиен.

2. White box Тестирање

White box тестирањето е метод кој тестира безбедност и може да биде

искористен да провери дали имплементацијата на кодот го прати

наменетиот дизајн, да ја провери имплементираната безбедносна

функционалност и да ги открие неодредените ранливости на софтверот.

Намената на секој безбедносен метод за тестирање е да се биде сигурен за

цврстината на системот, кога ке се соочи со најзагадочните напади или пак,

нормалните софтверски потфрлувања. White box тестирањето е базирано

на знаењето како е имплементиран системот. Ова тестирање вклучува

проток на анализирани податоци, контрола и инфо на протокот,

исклучителност за справување со грешки во системот, како и намерното и

ненамерното однесување на софтверот. При овој метод на тестирање

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

7

во било кое време на животниот циклус откако кодот е развиен , сепак

добра пракса е тестирањето да се изврши за времетраењето на единечното

тестирање на фазите. White box тестирањето бара знаење, што може да

го прави софтверот безбеден или небезбеден, како да размислува како

напаѓач на софтверот, како и селекцијата за употреба на различни алатки и

техники на тестирање . Првиот чекор во ваквото тестирање е да се сватат и

анализираат достапните дизајн архиви, изворни кодови и други важни

развојни артефакти , затоа што познавањето на потребите е од

фундаментално значење за безбедноста на софтверот. Вториот чекор е да

се креира тест кој максимално ќе го експлоатира софтверот .така што тест-

креаторот мора да размислува како напаѓач. Трет чекор тестирањето да

биде извршено ефективно, тестерите мора да знаат и владеат со повеќе

алатки за тестирање и различните техники достапни за извршување на

White box методот. Трите потребни чекори потребни за успешно тестирање

не работат изолирани еден од друг туку функционираат заедно.

2.1 Процес на изведба на White box Тестирање

2.1.1 Влезови во изведба на процесот на тестирање

Некои од артефактите релевантни за White Box тестирањето

вклучуваат изворен код, извештај од анализа на ризици, спецификација

за безбедност/потребна документација, документација за дизајн и

осигурување на квалитетот на дадените документи.

Изворниот код е најважниот артефакт потребен за да се изврши

White Box тестирањето. Без пристап кон кодот White Box

тестирањето не може да биде извршено, поради тоа што е

базирано на познавање на софтверското тестирање т.е како е

имплементиран системот. Во теорија White Box тестирањето може

да биде изведено со расклопување или декомпилација на кодот,

8

но процесот ќе биде отежнат со употреба на премногу труд и

премногу грешки.

Архитектонските и дизајн анализите на ризици би требало да

бидат водечка сила позади секоја активност на White Box

тестирањето, вклучувајќи тест планирање, креција на тест случаи,

селекција на податоци за тестирање, како и селекција на

техниката и критериумуот на тестирање. Ако анализата на ризикот

не комплетирана за системот ова треба да биде првата активност

изведена како дел од White Box тестирањето.

Дизајн документите се суштински за подобрување на

разбирливоста на програмата, ефективноста во развојот тест

случувањата. Ако дизајн документацијата е недостапна или

поинаку недоволна, барањето на тест тимот ќе биде минимален

директен пристап до дизајн тимот, со цел добивање на конкретни

прашања и одговори. Како и да е тест тимот ќе има потреба од

изградба на конкретно разгледена одлука како софтверот треба

да се однесува.

Безбедносните спецификации се неопходни, за да се разбере и

ратификацира функционалноста на обезбедувањето на

софтверот , тестирајки. Адекватно на информациите, ако

обезбедувањето на системот потфрли под наведените

спецификации и барања, тогаш тест тимот треба да ја опфати

целокупната платформа за тестирање вклучувајки го и дизајн

тимот и инфото од сопственикот.

Тестерите на безбедноста треба да имаат пристап до сигурносна

документација со цел да го разберат квалитетот на софтверот со

почит кон неговата цел на функционирање. Квалитетните

сигурносни документации треба да содржат тест стратегија, тест

планови и извештаи за дефекти. Перформансите на тестот се

битни за разбирање на ограничувањата наметнати на системот и

како системот се однесува под притисок.

9

Секој артефакт релевантен за разбирливоста на програмата

треба да биде достапен на White box тестерите.

2.1.2 Активности во процесот на White box тестирање

Воглавно процесот на White box тестирање е следниов :

1. Изведување на анализа на ризик за водење на целикупниот процес

на тестирање. Во Microsoft SDL процесот ова се однесува на

моделирањето на закани кон системот [Howard 06].

2. Да се развие стратегија на тестирање која дефинира какви тест

активности се потребни, за комплетирање на целите на

тестирањето.

3. Развој на детален тест план кој ќе ги организира подсеквентните

процеси на тестирање.

4. Подготви ја тест околината за извршување на тестирњето.

5. Изврши ги тест случувањата и достави ги резултатите.

6. Изготвување на извештај.

2.2 Резултати од White box тестирање

10

Секој безбедносен тест метод цели да се постигне сигурноста, дека

тестираниот софтвер ги извршува своите безбедносни цели, односно дека

софтверот е робустен и отпорен и под нај опасните напади. Сигурносното

тестирање вклучува два обратни процеса : првиот, тестирање на

сигурносните механизми да се осигураме дека соодветно функционирааат

како така имплементирани ; Второ, изведба на тестови базирани на ризикот

мотивирани да ја разберат целта на евентуалните напаѓачи на софтверот.

White box сигурносното тестирање ги следи двата пристапа и открива

грешки во програмирањето и имплеметирање. Видот на грешките откриени

за време White box тестирањето се неколку и имаат големо влијание на

контекстот на извршување на тестираниот софтвер. Некои од грешките

откриени при тестирање вклучуваат :

Влезни податоци кои ја загрозуваат безбедноста. Изложеност на чуствителни информации кон неавторизирани

корисници. Несоодветен проток кој ја загрозува безбедноста. Неадекватна имплементација на функционалноста во

безбедноста. Несакано софтверско однесување кое има безбедносни

импликации. Привидни недостатоци на дизајнот од дизајн спецификацијата. Гранични обврзувања без недостатоци кај интерфејс нивото.

White box тестирањето значително ја подобрува ефективноста на

тестирањето како и неговата покриеност. Тоа може влијателно да ја

подобри продуктивноста во откривањето на грешки-бугови кои се тешки за

наоѓање со black box тестирањето или други самостојни методи за

тестирање.

3. Black Box Tестирање

11

Black Box Тестирање не е тип на тестирање. Тоа всушност е тест

стратегија, на која не и е потребно некое знаење за влезниот дизајн или

код. Самото име ‘ black box ’ – Црна кутија наложува дека не е потребно

познавање нана влезната логика или структурата на кодот за

функционирање. Видовите на тестирање под оваа стратегијасе комплетно

основани и фокусирани на тестирањето , односно функционалноста и

барањата на работата производот односно софтвер апликацијата. Black Box

Тестирање некогаш е исто така именувано и "Opaque Testing",

"Functional/Behavioral Testing" и "Closed Box Testing". Основата на оваа

стратегија лежи во селектирањето на соодветна информација за

функционалност. Така што тестирајки против функционалноста на системот

наметнувајки му абнормални услови и однесувања па се до нормалните се

врши самата проверка. Во денешницата стана заедничко целата тест

работа да се префрли на трето лице, кое не е толку запознаено со логиката

и кодот на апликацијата се со цел тоа да биде индиферентно на тест

методите кои ке ги употреби.

Со цел да се имплементира Black Box стратегијата, тестерот треба да

биде подготвен за имплементација. Потребно е тестерот да биде темелен

со бараната спецификација на системот и како корисник , кој би требало да

знае , као системот треба да се однесува како одговор на одредени акции

врз истиот. Одредени типови на тестирање кои потпаѓаат под Black Box

стратегијата се : тестирање на функционалноста, стрес тестирање,

тестирање на обновувањето, тестирање на обемот, прифатливост од страна

на корисникот, системско тестирање, тестирање за чистота и чад, тест за

употребливост, истражување, алфа тестирање, бета тестирање итн.

Овие типови на тестирање повторно се поделени во групи :

Тестирање во кое корисникот игра улога на тестер

12

Корисник не е потребен ( со бараната систем спецификација

самиот систем е корисник кој треба да знае како треба да се

однесува во однос на одредена акција ).

Black Box Тестирање е техника која не покажува интерес за внатрешниот

тек на процесот на тестирање на апликацијата од страна на тестерот.

Запознаеноста на тестерот е доведена на ниво, тој има само информација

за влезовите во системот и што да очекува на излезот, со што целосно

занемарува како се одвива процесот од влезот до излезот. Тестерот дури и

воопшто не го прегледува програмскиот код и не му се потребни

дополнителни знаења различни од тие на спецификацијата.

13

3.1 Разлики помеѓу WhiteBox и Black Box методот

Најлесен начин да се започне дебата за софтверско тестирање е да се

запрашаме за разликите помеѓу Black Box & White Box тестирањето. Овие

термини се воглавно користени заедно, сепак се чини дека секој има

различна идеја за тоа што тие значат. Black Box тестирањето започнува со

една метафора. Замислете дека тестирате некој електронски систем. Тој е

сместен во црна кутија со светла, прекинувачи и екран на надворешноста

на кутијата. Тестирањето мора да се изведе без отварање на кутијата .Исто

така и без отварање на кутијата, без да се гледа што има под површината .

Мора да се види дали работи само со вртење на прекинувачите(влезовите)

и да се види што ќе се случи со светлатаи екранот(излезите). Ова е Black

Box тестирање. Софтверот за ова тестирање ја извршува истата функција

само софтверски. Конкретното значење на метафората всушност зависи од

тоа, како ке ја дефинираме лимитираноста на кутијата и каков пристап Black

– црнината ќе блокира.

Спротивен пристап кон тестирањето, би било , електронскиот систем да

биде отворен, да се види како колата се врзани , да се вметнат сондите

внатрешно, можеби и да се исклучи и дел од нив, со што би се извршило

тестирањето. Овој метод на тестирање е White box тестирање, но веќе

метафората е неверодостојна. Во интерес на логиката, некои луѓе го

преферирааат терминот “ Clear Box” тестирање. Но дури и “ Clear Box” ве

држи настрана од мерење на сондите во внатрешноста. Всушност

најлогично би било да се употребува терминот “ no box” тестирање. Но

метафората кружи наоколу под законите на логиката така да, останува

општо познатиот термин во употреба White box.

Предностите на Black box тестирањето се следниве :

Тестирањето е непристрасно затоа што дизајнерот и тестерот се

независни еден од друг

14

Тестерот нема потреба од предходно познавање на некој програмски

јазик

Тестирањето е завршено од перспектива на корисникот не на

дизајнерот

Тест слуцаите можат да бидат дизајнирани веднаш кога

спецификациите се комплетирани

Неговите недостатоци вклучуваат :

Тестирањето може да биде непристрасно, ако софтверскиот

дизајнер веќе извршил случај на тестирање

Случаите за тестирање се тешки за дизајнирање

Тестирајки го секој можен влезен извор е нереално, затоа што ке

биде потребно недефинирана временска инстанца, со што се

доведува во прашање засебното работење на програмата ,кога ќе се

стартуваат останатите програми.

Заклучокот кој треба да го генерализираме е дека тестирањето е

суштинска форма на осигурување. Тестирањето е макотрпно, одзема многу

време, големи финансиски трошоци. Така да правењето на изборот помеѓу

Black box & White box или комбинирано тестирање треба да биде базиран

спрема ризиците кон системот. Анализите за ризик овозможуваат правилна

содржина и информација да калкулираат со времето и напорот кој треба да

се вложи за да се постигне ефективноста на тестирањето.

Сите методи на тестирање можат да откријат можни софтверски ризици и

потенцијални експлоатирања. White box тестирањето директно

идентификува повеке грешки во спфтверот. Меѓутоа неговите потреби

побаруваат располагање со време и финансиски средства и бара

специјални вештини на тестерите. Како и со секој друг метод на тестирање

White box тестирањето има предности, како заеднички трошоци и

алтернативи. Ефективен пристап кон тестирање е тој кој врши баланс

15

помеѓу ефикасноста и ефективноста, со цел да ги идентификува

најголемиот број на критични дефекти за најмала цена. Сепак од аспект на

економска исплатливост не можеме да направиме генерализација, од

причини што во глобала методите на тестирање се поврзани. Обидувајки се

да направиме економски поисплатлива одлука, ја намалуваме и влијаеме

на ефикасноста на тестирањето во друг сегмент, со што ги покренуваме

трошоци за тој сегмент и ја изобличуваме целта на тестирањето.

Генерализираме дека успешното софтверско тестирање, мора да ги

вклучува во пакет WhiteBox и Black Box тест методите.

Референци

16

http://en.wikipedia.org/wiki/Software_testing

https://buildsecurityin.us-cert.gov/bsi/articles/best-practices/ white-box/259-BSI.html

http://www.allinterview.com/showanswers/33254.html http://www.buzzle.com/editorials/4-10-2005-68349.asp

http://www.stickyminds.com/sitewide.asp? Function=edetail&ObjectType=COL&ObjectId=2968

http://www.webopedia.com/TERM/B/Black_Box_Testing.html

17