Испробување на програмска опрема
Испробување на програмска опрема — доста значајна фаза во разработката на еден систем. Околу 40 – 50 проценти од буџетот планиран за развој на еден систем е планиран за испробувањето.[1] Испробувањето всушност претставува еден вид на истражување со цел да се обезбедат информации за квалитетот на производот и да се пронајдат грешките. Исто така со испробувањето на програмската опрема се обезбедува и објективни и независен пристап и на тој начин се овозможува клиентите да го ценат и разберат ризикот на имплементацијата на софтверот. Техниките за испробување вклучуваат процеси за испробување на програмата или апликацијата, во време на извршување, со цел да најдат програмски грешки или други дефекти.[2]
Исто така може да се каже дека испробувањето на софтвер претставува процес за валидација и верификација на програмата, апликација или производ за тоа дека:
- Ги исполнува барањата, наведени во документацијата
- Работи како што се очекува и
- Може да биде имплементиран со истите одлики.
Испробувањето на програмската опрема, во зависност од методот со кој е избран за испробување, може да биде имплементиран во било која фаза од развојниот процес.[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 пати повеќе отколку тој проблем да се откриел кај прегледот на барањата. Модерните методи би можеле да коштаат помалку за прераспределба и одржување него во минатото.
| Цена за поправка | Време на откривање | |||||
|---|---|---|---|---|---|---|
| Барања | Архитектура | Конструкција | Испробување на системот | Завршување на производот | ||
| Време на појавување | Барања | 1× | 3× | 5–10× | 10× | 10–100× |
| Архитектура | - | 1× | 10× | 15× | 25–100× | |
| Конструкција | - | - | 1× | 10× | 10–25× | |
Испробување на компатибилноста
уредиЧеста причина за програмски недостаток претставува немањето на компатибилност со другите програмски апликации, оперативни системи (или различни верзии на оперативниот систем, стари или нови) или пак околината. На пример, немањето на компатибилност може да настане поради тоа што програмерите го развивале програмската опрема на најновите околини, а истовремено и таму го испробувале. Па поради ова може да се случи кај некои корисници програмската опрема да не функционира како што треба. Од ова се може да заклучиме дека најновите производи, може да не функционираат на претходни верзии на околината или на стар хардвер, на кој работеле претходните верзии. Понекогаш таквите проблеми може да се решат со превентивна апстракција на функционалноста на оперативниот систем во одвоени програми модули или библиотеки.
Влезни комбинации и предуслови
уредиОсновен проблем кај програмското испробување е тоа што испробувањето со сите можни комбинации како влезни параметри и предуслови не е возможно, па дури ни кај едноставните производи.[12][18] Ова значи дека е голем бројот на недостатоци кај програмскиот производ и тие недостатоци е потешко да се најдат доколку програмата ретко влегува во состојби каде што има недостатоци. Уште позначајно е дека нефункционалните димензии како употребливост, размерливост, перформансите, компатибилноста, доверливоста може да бидат многу субјективни, односно нешто што содржи задоволителна вредност за една личност може за друга личност да не биде.
Статичко наспроти динамичко испробување
уредиПостојат повеќе приоди кон испробувањето на програмската опрема. Прегледот, текот на развивање на програмата (англиски: walkthrough) или испитувањата се сметаат како дел од статичкото испробување, додека пак извршувањето на програмата со дадено множество на тест случаи е динамичко испробување. Статичкото испробување може да биде (а за жал во пракса уште почесто) прескокнато. Додека пак динамичкото испробување се прави веднаш откако програмата ќе биде користена за првпат (генерално се смета за почетна фаза на испробувањето). Исто така динамичкото испробување може да почне и пред програмата комплетно да биде завршена, со цел да се испробаат одредени делови од кодот(модули или функции). За оваа цел се користат таканаречени стабови (англиски: stub), драјвери или околина за дебагирање. На пример, програмите за табеларни пресметки се испробуваат на поголема проширена интерактивност, и како резултат на тоа веднаш се прикажуваат резултатите при некоја промена на бројки или текст.
Верификација и валидација на програмската опрема
уредиИспробувањето на програмската опрема се користи за негова верификација и валидација.[19]
- Верификација: Дали програмската опрема правилно сме го развивале? (дали е во согласност со спецификацијата)
- Валидација : Дали сме го развиле вистинскиот софтвер? (дали е тоа што клиентот го бара)
Термините за верификација и валидација обично се мешаат во индустријата, исто така тие и неправилно се дефинираат. Нивните дефиниции според IEEE речникот за терминологии од програмското инженерство се:
Верификација – процес на проценка на системот или компонентите за да се одреди дали производот во одредена фаза на развивање ги исполнува условите дадени на почетокот на секоја фаза.
Валидација – процес на проценка на системот или компонентите, во текот или на крајот од фазата за развивање, со цел да се одреди дали ги задоволува наведените барања.
Според ISO 9000 стандардот:
Верификација – потврдување со проверка и давање на објективни докази дека наведените барања се задоволени. Валидација – потврдување со проверка и давење на објективни докази дека барањата за специфична намена или апликација се исполнети.
Тим за испробување на софтвер
уредиИспробувањето на програмската опрема се прави од страна на програмските тестери. Сè до 1980-тите години терминот ,, програмски тест инженер‘‘ се користеше генерално. Подоцна поради различните цели во програмското инженерство се воведоа нови улоги во тимот за испробување како што се: менаџер, раководител на испробување, тест дизајнер, автоматизиран развивач и тест администратор.
Методи за испробување
уредиBox пристап
уредиМетодите за испробување на програмската опрема се поделени на таканаречени бели (white box) и црни (black box) испробувања. Овие два пристапи се користат за да го опишат гледиштето на инженерите за испробување кога ги дизајнираат тест случаите.
White box испробување (бела кутија, отворена кутија)
уредиWhite box е она испробување во кое тестерот има пристап до структурата на внатрешните податоци и алгоритми вклучувајќи го и кодот.
Типови на испробување со отворена кутија
уредиПостојат следниве типови на white box испробување:
- Испробување на АПИ – се исптобува апликацијата со користење на јавни и приватни апликациски програмски интефејси.
- Покривање на кодот – се создаваат тестови коишто задоволуваат критерија за покривање на кодот (на пример, тест дизајнерот може да создава тест случаи со кој ќе бидат извршени сите состојби на програмата барем еднаш).
- Методи за внесување на недостаток.
- Методи за мутациско испробување.
- Статичко испробување – Сите типови на статичко испробување.
Black box испробување (црна кутија, затворена кутија)
уредиBlack box испробувањето го третира софтверот како „затворена кутија“ без никакво знаење на неговата внатрешна имплементација. Методите за black box испробувањето вклучуваат: еднакво партиционирање, анализа на граничните вредности, испробување на сите парови, испробувањето засновано на моделот, истражувачкото испробување и испробувањето засновано на спецификација.
Предности и негативности – black box испробувањето нема никаква поврзаност со кодот, а перцепцијата на тест - инженерот е многу јасна: кодот мора да има грешка. Тест - инженерите наоѓаат грешка, онаму каде што програмерите не можат да најдат. Од друга страна тест – инженерите кога испробуваат со црна кутија, кога ја извршуваат својата работа, велат дека чувствувале како да се движат низ лавиринт во кој нема осветлување, поради тоа што тие не знаат како програмската опрема што го испробуваат е и конструиран.[20]
Наводи
уреди- ↑ Estimation of Software Testing Effort: An Intelligent Approach Архивирано на 5 септември 2012 г. проверено на 01.04.2012
- ↑ Exploratory Testing Архивирано на 26 јануари 2009 г., Cem Kaner, Florida Institute of Technology, Quality Assurance Institute Worldwide Annual Software Testing Conference, Orlando, FL, November 2006
- ↑ Software Testing проверено на 01.04.2012
- ↑ Software Errors Cost U.S. Economy $59.5 Billion Annually проверена на 01.04.2012
- ↑ 5,0 5,1 Myers, Glenford J. (1979). The Art of Software Testing. John Wiley and Sons. ISBN 0-471-04328-1.
- ↑ Company, People's Computer (1987). „Dr. Dobb's journal of software tools for the professional programmer“. Dr. Dobb's journal of software tools for the professional programmer. M&T Pub. 12 (1–6): 116.
- ↑ 7,0 7,1 Gelperin, D.; B. Hetzel (1988). „The Growth of Software Testing“. CACM. 31 (6). ISSN 0001-0782.
- ↑ From 1957–1978 there was the demonstration oriented period where debugging and testing was distinguished now - in this period it was shown, that software satisfies the requirements. Gelperin, D.; B. Hetzel (1988). „The Growth of Software Testing“. CACM. 31 (6). ISSN 0001-0782.
- ↑ The time between 1979–1982 is announced as the destruction oriented period, where the goal was to find errors. Gelperin, D.; B. Hetzel (1988). „The Growth of Software Testing“. CACM. 31 (6). ISSN 0001-0782.
- ↑ 1983–1987 is classified as the evaluation oriented period: intention here is that during the software lifecycle a product evaluation is provided and measuring quality. Gelperin, D.; B. Hetzel (1988). „The Growth of Software Testing“. CACM. 31 (6). ISSN 0001-0782.
- ↑ From 1988 on it was seen as prevention oriented period where tests were to demonstrate that software satisfies its specification, to detect faults and to prevent faults. Gelperin, D.; B. Hetzel (1988). „The Growth of Software Testing“. CACM. 31 (6). ISSN 0001-0782.
- ↑ 12,0 12,1 Kaner, Cem; Falk, Jack and Nguyen, Hung Quoc (1999). Testing Computer Software, 2nd Ed. New York, et al: John Wiley and Sons, Inc. стр. 480 pages. ISBN 0-471-35846-0.CS1-одржување: повеќе имиња: список на автори (link) Грешка во наводот: Неважечка ознака
<ref>; називот „Kaner1“ е зададен повеќепати со различна содржина. - ↑ Kolawa, Adam; Huizinga, Dorota (2007). Automated Defect Prevention: Best Practices in Software Management. Wiley-IEEE Computer Society Press. стр. 41–43. ISBN 0470042125.
- ↑ Non-functional testing проверена на 01.04.2012
- ↑ Kolawa, Adam; Huizinga, Dorota (2007). Automated Defect Prevention: Best Practices in Software Management. Wiley-IEEE Computer Society Press. стр. 426. ISBN 0470042125.
- ↑ 16,0 16,1 Section 1.1.2, Certified Tester Foundation Level Syllabus Архивирано на 17 декември 2008 г., International Software Testing Qualifications Board
- ↑ McConnell, Steve (2004). Code Complete (2. изд.). Microsoft Press. стр. 29. ISBN 0-7356-1967-0.
- ↑ Principle 2, Section 1.3, Certified Tester Foundation Level Syllabus Архивирано на 17 декември 2008 г., International Software Testing Qualifications Board
- ↑ Tran, Eushiuan (1999). „Verification/Validation/Certification“. Во Koopman, P. (уред.). Topics in Dependable Embedded Systems. USA: Carnegie Mellon University. Посетено на 2008-01-13.
- ↑ Savenkov, Roman (2008). How to Become a Software Tester. Roman Savenkov Consulting. стр. 159. ISBN 978-0-615-23372-7.