Направо към съдържанието

Дебъгване

от Уикипедия, свободната енциклопедия

Дебъгване (от английското debugging) е процесът на проследяване на изпълнението на дадена компютърна програма с цел намиране и отстраняване на грешки („бъгове“) в нея. Извършва се с помощта на специализирани програмни инструменти наречени дебъгери.

Многобройни книги са написани за дебъгването, тъй като то включва много аспекти, включително интерактивни отстраняване на грешки, контрол на потока, интеграционно тестване, лог файлове, наблюдение (приложения, система), профилиране, статистически контрол на процеса, и специални дизайн тактики за подобряване на откриването на бъговете.

Има някои противоречия относно произходът на термина „дебъгване“. Полулярността на термините „бъг“ и „дебъгване“ се дължи на адмирал Грейс Хопър (1940-те), докато тя работи по Mark II Computer в Харвардския университет, нейните сътрудници открили молец (bug – „бъг“) забит в реле и по този начин, възпрепятстващ операция, и след отстраняването му тя отбелязва, че те са „де-бъгнали“ (махнали грешката) от системата. Въпреки това терминът „бъг“ в смисъла на техническа грешка датира най-малко от 1878 г. и Томас Едисън, и „дебъгване“, е бил термин използван в аеронавтиката, преди да влезе в света на компютрите. Всъщност, в интервю Грейс Хопър отбелязва, че тя не е създателка на термина. „Бъг“ се оказва подходящ за вече съществуващата терминология, така че бива запазен. Писмо от Дж. Роберт Опенхеймер (директор на проекта на атомната бомбаМанхатън“ от Втората световна война в Лос Аламос, Ню Мексико) използва термина в писмо до д-р Ърнест Лорънс в Калифорнийския университет в Бъркли, с дата 27 октомври 1944 г., по отношение на наемане на допълнителен технически персонал.

С повишаването сложността на софтуерните и електронните систем, различните техники за дебъгване се разширяват с повече методи за откриване на аномалии, оценка на въздействието, и частично софтуерно коригиране или пълно обновление на системата. Думите „аномалия“ и „несъответствие“ могат да бъдат използвани, тъй като са по-неутрални термини, за да се избегнат думите error (грешка), defect (дефект) или bug (бъг), където трябва да се разбира, че всички т.нар. грешки, дефекти или бъгове трябва да бъдат поправени (на всяка цена). Вместо това може да се направи оценка на въздействието, за да определи дали промени за премахване на една аномалия (или несъответствие) биха били рентабилни за системата, или може би да се планира нова версия с нужните промени. Не всички проблеми са жизнено-критични или критични в една система. Също така е важно да се избегне ситуация, в която промяната може да се окаже по-притеснителна за потребителите в дългосрочен план, отколкото временното примиряване с известен проблем (където „излекуване ще бъде по-лошо от болестта“). Базирайки се на решения на приемливостта на някои аномалии може да се отрече съществуването на проблем и в резултатът периода да се отчете като мандат с нулев дефект. Имайки предвид въпроса с обезпечението, като например оценката на разходите спрямо ползите, следва с широките техники за дебъгване, да се определи честотата на аномалиите (колко често се срещат едни и същи бъгове), и оценка на тяхното въздействие на цялостната система.

Дебъгването е с обхват на сложност, от определяне на прости грешки до извършването на продължителни и отегчителни задачи за събиране на данни, анализи и насрочване на обновления. Уменията на програмиста за дебъгване могат да бъдат основен фактор в способността да се реши един проблем, но сложността на софтуерното дебъгване варира значително със сложността на системата, а също така зависи до известна степен и от използвания езика за програмиране и наличните инструменти като дебъгери. Дебъгерите са софтуерни инструменти които дават възможност на програмиста да следи изпълнението на дадена програма, да го спре, да го рестартира, да заложи точки на прекъсване на програмата (breakpoints), както и да променя стойностите в паметта. Терминът дебъгер може да се използва също и за лицето, което отстранява грешките.

Като цяло, езици за програмиране от високо ниво, като например Java, правят дебъгването по-лесно, защото те имат функции като обработка на изключенията, които улесняват спирането върху истинските източници на хаотично поведение. В езиците за програмиране като C или асемблер, бъговете могат да причинят безшумни проблеми като повреждане на паметта (memory corruption), и често е трудно да се видят първоначално. В тези случаи могат да бъдат необходими инструменти за дебъгване.

В определени случаи основните инструменти които са специфични за езика на които е написан софтуерът могат да бъдат много полезни. Те са представени като статични инструменти за анализ на код. Тези инструменти търсят в рамките на изходния код както много специфични и общи, така и много редки проблеми. Всички засечени проблеми ще бъдат поети от компилатора и интерпретатора които не проверяват синтактично а семантично кода. За някои инструменти се твърди че могат да откриват над 300 уникални по рода си проблема. Съществуват както безплатни така и платени инструменти. Тези инструменти могат да бъдат изключително полезни когато се проверяват огромни по размер проекти. Типичен пример за откриване на проблем би бил код сочещ към променлива която се извиква преди на променливата да е зададена стойност. Друг пример би било да се извършва строга проверка на типа, когато езика не го изисква. По този начин тези инструменти са по-добри в намирането на евентуалните грешки, в превес на действителните грешки.