Испробување на програмска опрема

Испробување на програмска опрема — доста значајна фаза во разработката на еден систем. Околу 40 – 50 проценти од буџетот планиран за развој на еден систем е планиран за испробувањето.^[1] Испробувањето всушност претставува еден вид на истражување со цел да се обезбедат информации за квалитетот на производот и да се пронајдат грешките. Исто така со испробувањето на програмската опрема се обезбедува и објективни и независен пристап и на тој начин се овозможува клиентите да го ценат и разберат ризикот на имплементацијата на софтверот. Техниките за испробување вклучуваат процеси за испробување на програмата или апликацијата, во време на извршување, со цел да најдат програмски грешки или други дефекти.^[2]

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

1. Ги исполнува барањата, наведени во документацијата
2. Работи како што се очекува и
3. Може да биде имплементиран со истите одлики.

Испробувањето на програмската опрема, во зависност од методот со кој е избран за испробување, може да биде имплементиран во било која фаза од развојниот процес.^[3]

Различните модели за развој на програмската опремаразлично се фокусираат на тоа кога ќе биде направано испробувањето во развојниот период. Кај новите развојни модели, како што е приспособливиот модел, често се прават испробувања па дури и во процесот на кодирање, пред формално да дојде фазата на испробување. Сепак испробувањето обично се прави откако се дефинирани барањата и кодирањето е завршено.

Секој програмски производ има определена целна група на корисници. На пример, групата на корисници кои играат компјутерски игри се комплетно различни од оние корисници на банкарскиот софтвер. Па според тоа кога една организација развива или инвестира во некој програмски производ, таа може да процени дали производот би бил прифатлив за крајните корисници, која ќе биде неговата целна група на корисници, кои би биле неговите купувачи. Овде испробувањето на програмската опрема е оној кој ќе се обиде да ја изврши оваа проценка. Едно истражување од страна на NIST во 2002 година покажува дека програмските грешки ја чинеле Американската економија околу 59.5 билиони долари. Доколку било спроведено подобро испробување, оваа сума би била намалена за една третина.^[4]

Во 1979 година од страна на Глендфорд Маерс (англиски: Glenford J. Myers) било направена разграничување помеѓу дебагирање од испробување.^[5] Иако неговото внимание било насочено кон успешно испробување за кое морало да има грешка, односно ,, Успешен тест е секој тест кој ќе најде грешка‘‘,^[5][6] покажува дека желбата на програмската инженерска заедница била да се одвојат основните активности за развој, како што е дебагирањето од верификацијата. Дејв Гелперин и Вилијам Хатцел во 1988 година ја направиле следната класификација на фазите и целите кај испробувањето на програмската опрема:^[7]

• До 1956 – Период ориентиран кон дебагирање (не постоела јасна разлика помеѓу дебагирањето и испробувањето.^[7]
• 1957 – 1978 Период на демонстрирање (покажување). Период во кој се разликувало дебагирањето од испробувањето и се покажувало дека програмската опрема ги задоволува барањата.^[8]
• 1979 – 1982 Познат како период на уништување, каде што целта била да се најдат грешки.^[9]
• 1983 – 1987 Период ориентиран кон евалуацијата. Целта била да во текот на животниот циклус на програмската опрема да биде овозможена евалуација и мерење на квалитетот.^[10]
• 1988 – 2000 Период на превенција, каде што испробувањето се прави за да се покаже дека програмската опрема ги задоволува барањата, ги открива грешките и ги намалува испадите.^[11]

Основната намена на испробувањето е да се најдат програмските испади, па тие да бидат сместени и коригирани. Со испробувањето не може да се констатира дека производот ќе работи под сите услови, но може да се констатира дека нема да функционира правилно под одредени услови.^[12] Опсегот на испробувањето на програмската опрема често вклучува преглед на кодот како и извршување на самиот код во различни средини и услови, како и преглед на аспектите на кодот: дали го работи како што е предвидено да работи? Нивото кое што денеска го има развојот на софтвер дозволува, тимот којшто е задолжен за испробување да биде одвоен од тимот задолжен за развој. Секој член од тимот за испробување има своја посебна задача и улога. Информациите добиени од испробувањето се користат да се коригира процесот кој се користи да се развија софтверот.^[13]

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

За разлика од функциналното испробување, нефункционалното испробување се однесува на тоа дали системот ги исполнува нефункционалните барања. Тоа ги покрива следните испробувања:^[14]

• Испробување на стандардите (англиски: Baseline testing)
• Испробување на компатибилноста
• Испробување на издржливоста
• Испробување на сигурноста
• Испробување при вчитување
• Испробување на размерливоста
• Испробување на употребливоста
• Испробување на зафатнината

Некои од недостатоците не мора да се предизвикани како резултат на грешките во кодирањето. Најголем број на грешки доаѓаат од ,,празнините‘‘ во барањата, на пример неразбирливите барања , коишто доведуваат до погрешно дизајнирање на програмата од стана на дизајнерот.^[15] Најголем број такви празнини во барањата се во нефункционалните барања како што се барањата за проверливост, размерливост, одржливост, употребливост, барањата за перформансите и сигурноста.

Програмските недостатоци се појавуваат како резултат на грешките од програмерот што ги прави програмерот при пишување на изворниот код. Доколку тој изворен код се изврши, во одредени ситуации ќе продуцира грешен резултат и предизвикува испад.^[16] Не мора да значи дека сите недостатоци би резултирале со испади. На пример, некој недостаток на мртов код (код што никогаш нема да се изврши) никогаш не би довел до испад. Недостатокот може да се претвори во испад кога ќе настане промена на околината. Примери за промена на околината се промена на хардверската платформа, промена на податоци или интеракција со друг софтвер. Еден недостаток може резултира со широк спектар испади.^[16]

Факт е дека колку побрзо се откријат недостатоците, толку помали ќе бидат трошоците тие да се поправат. Следната табела ги прикажува трошоците на поправање во зависност од фазата во која тие недостатоци ќе бидат откриени.^[17] На пример, ако се најде проблем во барањата откако производот е завршен, тоа неговото поправање би чинело 10 – 100 пати повеќе отколку тој проблем да се откриел кај прегледот на барањата. Модерните методи би можеле да коштаат помалку за прераспределба и одржување него во минатото.

Честа причина за програмски недостаток претставува немањето на компатибилност со другите програмски апликации, оперативни системи (или различни верзии на оперативниот систем, стари или нови) или пак околината. На пример, немањето на компатибилност може да настане поради тоа што програмерите го развивале програмската опрема на најновите околини, а истовремено и таму го испробувале. Па поради ова може да се случи кај некои корисници програмската опрема да не функционира како што треба. Од ова се може да заклучиме дека најновите производи, може да не функционираат на претходни верзии на околината или на стар хардвер, на кој работеле претходните верзии. Понекогаш таквите проблеми може да се решат со превентивна апстракција на функционалноста на оперативниот систем во одвоени програми модули или библиотеки.

Основен проблем кај програмското испробување е тоа што испробувањето со сите можни комбинации како влезни параметри и предуслови не е возможно, па дури ни кај едноставните производи.^[12][18] Ова значи дека е голем бројот на недостатоци кај програмскиот производ и тие недостатоци е потешко да се најдат доколку програмата ретко влегува во состојби каде што има недостатоци. Уште позначајно е дека нефункционалните димензии како употребливост, размерливост, перформансите, компатибилноста, доверливоста може да бидат многу субјективни, односно нешто што содржи задоволителна вредност за една личност може за друга личност да не биде.

Постојат повеќе приоди кон испробувањето на програмската опрема. Прегледот, текот на развивање на програмата (англиски: walkthrough) или испитувањата се сметаат како дел од статичкото испробување, додека пак извршувањето на програмата со дадено множество на тест случаи е динамичко испробување. Статичкото испробување може да биде (а за жал во пракса уште почесто) прескокнато. Додека пак динамичкото испробување се прави веднаш откако програмата ќе биде користена за првпат (генерално се смета за почетна фаза на испробувањето). Исто така динамичкото испробување може да почне и пред програмата комплетно да биде завршена, со цел да се испробаат одредени делови од кодот(модули или функции). За оваа цел се користат таканаречени стабови (англиски: stub), драјвери или околина за дебагирање. На пример, програмите за табеларни пресметки се испробуваат на поголема проширена интерактивност, и како резултат на тоа веднаш се прикажуваат резултатите при некоја промена на бројки или текст.

Испробувањето на програмската опрема се користи за негова верификација и валидација.^[19]

• Верификација: Дали програмската опрема правилно сме го развивале? (дали е во согласност со спецификацијата)
• Валидација : Дали сме го развиле вистинскиот софтвер? (дали е тоа што клиентот го бара)

Термините за верификација и валидација обично се мешаат во индустријата, исто така тие и неправилно се дефинираат. Нивните дефиниции според IEEE речникот за терминологии од програмското инженерство се:

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

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

Според ISO 9000 стандардот:

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

Испробувањето на програмската опрема се прави од страна на програмските тестери. Сè до 1980-тите години терминот ,, програмски тест инженер‘‘ се користеше генерално. Подоцна поради различните цели во програмското инженерство се воведоа нови улоги во тимот за испробување како што се: менаџер, раководител на испробување, тест дизајнер, автоматизиран развивач и тест администратор.

Методите за испробување на програмската опрема се поделени на таканаречени бели (white box) и црни (black box) испробувања. Овие два пристапи се користат за да го опишат гледиштето на инженерите за испробување кога ги дизајнираат тест случаите.

White box е она испробување во кое тестерот има пристап до структурата на внатрешните податоци и алгоритми вклучувајќи го и кодот.

Постојат следниве типови на white box испробување:

• Испробување на АПИ – се исптобува апликацијата со користење на јавни и приватни апликациски програмски интефејси.
• Покривање на кодот – се создаваат тестови коишто задоволуваат критерија за покривање на кодот (на пример, тест дизајнерот може да создава тест случаи со кој ќе бидат извршени сите состојби на програмата барем еднаш).
• Методи за внесување на недостаток.
• Методи за мутациско испробување.
• Статичко испробување – Сите типови на статичко испробување.

Black box испробувањето го третира софтверот како „затворена кутија“ без никакво знаење на неговата внатрешна имплементација. Методите за black box испробувањето вклучуваат: еднакво партиционирање, анализа на граничните вредности, испробување на сите парови, испробувањето засновано на моделот, истражувачкото испробување и испробувањето засновано на спецификација.

Предности и негативности – black box испробувањето нема никаква поврзаност со кодот, а перцепцијата на тест - инженерот е многу јасна: кодот мора да има грешка. Тест - инженерите наоѓаат грешка, онаму каде што програмерите не можат да најдат. Од друга страна тест – инженерите кога испробуваат со црна кутија, кога ја извршуваат својата работа, велат дека чувствувале како да се движат низ лавиринт во кој нема осветлување, поради тоа што тие не знаат како програмската опрема што го испробуваат е и конструиран.^[20]