Тестирање на софтвер

Од Википедија — слободната енциклопедија
Прејди на: содржини, барај
Тестирањето на софтверот е доста значајна фаза во развивањето на еден систем. Околу 40 – 50 проценти од буџетот планиран за развој на еден систем е планиран за тестирањето.[1]

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

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

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

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

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

Преглед[уреди]

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

Историја[уреди]

Во 1979 година од страна на Глендфорд Маерс (англиски: Glenford J. Myers) било направена разграничување помеѓу дебагирање од тестирање. [5] Иако неговото внимание било насочено кон успешно тестирање за кое морало да има грешка, односно ,, Успешен тест е секој тест кој ќе најде грешка‘‘,[5][6] покажува дека желбата на софтверската инженерска заедница била да се одвојат основните активности за развој, како што е дебагирањето од верификацијата. Дејв Гелперин и Вилијам Хатцел во 1988 година ја направиле следната класификација на фазите и целите кај тестирањето на софтверот:[7]
  • До 1956 – Период ориентиран кон дебагирање (не постоела јасна разлика помеѓу дебагирањето и тестирањето.[8]
  • 19571978 Период на демонстрирање (покажување). Период во кој се разликувало дебагирањето од тестирањето и се покажувало дека софтверот ги задоволува барањата.[9]
  • 19791982 Познат како период на деструкција, каде што целта била да се најдат грешки.[10]
  • 19831987 Период ориентиран кон евалуацијата. Целта била да во текот на животниот циклус на софтверот да биде овозможена евалуација и мерење на квалитетот. [11]
  • 1988 – 2000 Период на превенција, каде што тестирањето се прави за да се покаже дека софтверот ги задоволува барањата, ги открива грешките и ги намалува испадите.[12]

Теми на тестирањето на софтвер[уреди]

Опсег[уреди]

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

Функционално наспроти нефункционално тестирање[уреди]

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

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

Недостатоци и испади[уреди]

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

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

Брзо откривање на недостатоците[уреди]

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

Цена за поправка Време на откривање
Барања Архитектура Конструкција Тестирање на системот Завршување на продуктот
Време на појавување Барања 5–10× 10× 10–100×
Архитектура - 10× 15× 25–100×
Конструкција - - 10× 10–25×

Тестирање на компатибилноста[уреди]

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

Влезни комбинации и предуслови[уреди]

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


Статичко наспроти динамичко тестирање[уреди]

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

Верификација и валидација на софтверот[уреди]

Тестирањето на софтверот се користи за негова верификација и валидација.[20]

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

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

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

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

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

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

Тим за тестирање на софтвер[уреди]

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

Методи за тестирање[уреди]

Box пристап[уреди]

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

White box тестирање (бела кутија, отворена кутија)[уреди]

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

Типови на тестирање со отворена кутија[уреди]

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

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

Black box тестирање (црна кутија, затворена кутија)[уреди]

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

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


Наводи[уреди]

  1. Estimation of Software Testing Effort: An Intelligent Approach проверено на 01.04.2012
  2. Exploratory Testing, Cem Kaner, Florida Institute of Technology, Quality Assurance Institute Worldwide Annual Software Testing Conference, Orlando, FL, November 2006
  3. Software Testing проверено на 01.04.2012
  4. Software Errors Cost U.S. Economy $59.5 Billion Annually проверена на 01.04.2012
  5. 5,0 5,1 Myers, Glenford J. (1979). „The Art of Software Testing“. John Wiley and Sons. ISBN 0-471-04328-1. 
  6. 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. http://books.google.com/?id=7RoIAAAAIAAJ. 
  7. Gelperin, D.; B. Hetzel (1988). „The Growth of Software Testing“. „CACM“ 31 (6). ISSN 0001-0782. 
  8. Gelperin, D.; B. Hetzel (1988). „The Growth of Software Testing“. „CACM“ 31 (6). ISSN 0001-0782. 
  9. 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. 
  10. 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. 
  11. 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. 
  12. 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. 
  13. 13,0 13,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. 
  14. Kolawa, Adam; Huizinga, Dorota (2007). „Automated Defect Prevention: Best Practices in Software Management“. Wiley-IEEE Computer Society Press. стр. 41–43. ISBN 0470042125. http://www.wiley.com/WileyCDA/WileyTitle/productCd-0470042125.html. 
  15. Non-functional testing проверена на 01.04.2012
  16. Kolawa, Adam; Huizinga, Dorota (2007). „Automated Defect Prevention: Best Practices in Software Management“. Wiley-IEEE Computer Society Press. стр. 426. ISBN 0470042125. http://www.wiley.com/WileyCDA/WileyTitle/productCd-0470042125.html. 
  17. 17,0 17,1 Section 1.1.2, Certified Tester Foundation Level Syllabus, International Software Testing Qualifications Board
  18. McConnell, Steve (2004). „Code Complete“ (2nd издание). Microsoft Press. стр. 29. ISBN 0-7356-1967-0. 
  19. Principle 2, Section 1.3, Certified Tester Foundation Level Syllabus, International Software Testing Qualifications Board
  20. Tran, Eushiuan (1999). „Verification/Validation/Certification“. Koopman, P.. „Topics in Dependable Embedded Systems“. USA: Carnegie Mellon University. 
  21. Savenkov, Roman (2008). „How to Become a Software Tester“. Roman Savenkov Consulting. стр. 159. ISBN 978-0-615-23372-7.