Loading AI tools
З Вікіпедії, вільної енциклопедії
Нала́годження програ́ми [1] [2] [3] [4] [5] [6] [7], в мережі рідше знева́дження[8] (англ. debugging) — методичний процес пошуку та зменшення числа помилок або дефектів у комп'ютерній програмі або електронному обладнанні з метою отримання очікуваної поведінки. Зневадження, як правило, ускладнюється, коли різні підсистеми міцно пов'язані між собою, оскільки зміни в одній частині можуть викликати помилки в іншій.
Існують різні варіанти тлумачення походження терміна англ. debugging. Серед програмістів популярна легенда, що терміни «bug» та «debugging» першою вжила Ґрейс Гоппер у 1940-х роках[9]. Коли вона працювала на комп'ютері Mark II в Гарвардському університеті, її співробітники виявили, що міль застрягла в реле і тим самим призвела до збою в роботі комп'ютера. Грейс підклеїла в щоденник міль і написала, що це перший випадок в історії, коли жучка (англ. bug — жучок, комаха) виявили насправді (actual case). Сам запис свідчить про те, що слово баг у значенні помилки в програмі було вже відоме їй. Термін «bug» в сенсі технічної помилки вживався, принаймні ще в 1878 Томасом Едісоном, і «debugging», судячи з усього, використовувався як термін в аеронавтиці перед появою комп'ютерів. В Оксфордському словнику слово «debugging» з'явилося ще за два роки, до випадку з комахою. Слова bug і debugging у вузькому значенні помилки в програмі та процесу її виправлення утвердилися впродовж 50-х років, і на початку 60-х його вживання в літературі не потребувало додаткового пояснення.
Більшість перекладних і тлумачних словників ще з радянських часів як відповідник до «debugging» вказують «налагоджування». Термін «зневадження» був запропонований О. Кочергою та Є. Мейнаровичем на початку 2000-х, імовірно, щоб уникнути неоднозначності [джерело?] з поняттям загального налагоджування програми.
Пошук і виправлення помилок, які програмісти називають багами, — трудомісткий процес. Програмістський напівжарт визначає цикл життя програми, як 1:3:1 (написання:налагодження:використання). Вади трапляються переважно через неуважність або втому програміста, але інколи через непродуманий до кінця алгоритм. Кількість багів зростає зі зростанням розміру програми, а з її ускладненням виникають нові помилки, пов'язані зі взаємодією та взаємовпливом різних модулів.
Частина багів виправляється уже на етапі написання програми. Інша частина — після незалежного тестування. Зазвичай тестування, яке проводить користувач, який не знає механізму роботи програми, дозволяє виловити нові помилки, які програмісти не помічають, бо мають схильність робити тільки «правильні дії». Ще одна частина багів проявляється уже в роботі програми і потребує пізнього латання, чому служать патчі і сервісні пакунки.
 | Цей розділ не містить посилань на джерела. (квітень 2013) |
Пошук помилки в програмі, як правило, — тривале і клопітке завдання. Найважливішим чинником успішності та швидкості цього процесу є, мабуть, досвід програміста, але труднощі зі зневадженням програмного забезпечення також залежать значною мірою від мови програмування. Чимало середовищ розробки програмного забезпечення мають серед своїх інструментів спеціальну програму зневаджувач. Зневаджувач є програмним інструментом, який дозволяє програмісту контролювати виконання програми, зупиняти його, знову запускати, встановлювати точки зупинки, змінювати значення змінних у пам'яті й навіть, у деяких випадках, надає можливість повернутися в минуле. Термін зневаджувач може також стосуватися програміста.
Мови програмування високого рівня, наприклад, Java, спрощують зневадження, оскільки мають спеціальні програмні засоби, як, наприклад, обробка виняткових ситуацій, що дозволяють швидше локалізувати помилку. У мов програмування нижчого рівня, таких як C або Асемблер, помилка в програмі часто може створити проблеми, що проявляються не зразу, такі, як пошкодження цілісності пам'яті, і їх набагато важче виявити, оскільки зовнішньо проблема може проявитися набагато пізніше і в несподіваній формі. В таких випадках, надзвичайно корисними є спеціальні програми на кшталт зневаджувача пам'яті.
У деяких ситуаціях можуть бути дуже корисними програмні засоби загального призначення, що прив'язані до конкретної мови. Прикладом можуть бути інструменти статичного аналізу коду. Ці інструменти виконують пошук дуже конкретних відомих (поширених та рідкісних) проблем у тексті програми. Вони дозволяють знаходити помилки, які рідко фіксуються компілятором або транслятором, оскільки вони не синтаксичні, а семантичні. Наприклад, інструкція С
if (x = foo()) bar();
підозріла. Можливо, програміст помилково використав присвоювання замість порівняння. Однак, вона є цілком легальною в С, і компілятор її пропустить.
Деякі виробники таких інструментів стверджують, що їхні програми можуть виявити понад 300 різних потенційних проблем. Такі засоби можуть бути надзвичайно корисними при перевірці дуже великих обсягів сирцевого коду, коли дуже неефективно переглядати весь код чи відстежувати всі шляхи його виконання. Типовим прикладом виявленої проблеми може бути звернення до змінної до її ініціалізації. Іншим прикладом може бути суворіша перевірка типів, якщо мова такої не має. Таким чином, ці засоби є кращими для виявлення потенційних вад, на противагу фактичним вадам. Як наслідок, ці засоби мають високий рівень помилкового спрацьовування. Давня утиліта Unix lint є одним з найстаріших прикладів засобів такого типу.
Для налагодження електронних пристроїв (наприклад, комп'ютерного обладнання), а також програмного забезпечення низького рівня (BIOS, драйвери пристроїв тощо) і вбудованих програм, застосовують такі інструменти, як осцилограф, аналізатор логіки, ICE, POST-контролери, які часто використовується і в комбінації. Вони можуть виконувати багато типових дій звичайних зневаджувачів для програмного забезпечення мікропроцесорних систем.
Часто перший крок зневадження полягає в тому, щоб спробувати відтворити проблему, тобто точно визначити ситуацію, коли програма працює неправильно. Випадок, коли програма працює неправильно завжди є відносно простим, але часто проблеми проявляються тільки при експлуатації, уже після того, як програма пройшла тестування, яке не може перевірити всі можливі ситуації. Відтворення проблеми може бути особливо нетривіальним завданням, наприклад, у випадку паралельних процесів або незвичайних помилок. Крім того, специфічне вживання програми користувачем, або незвичайне оточення може значно ускладнити відтворення проблеми.
Після того, як помилку відтворено, потрібно виділити ту частину програми, де виникає збій, щоб працювати тільки з нею. Часто достатньо обмежитися тільки кількома рядами коду. Таке спрощення можна зробити вручну, за допомогою підходу «розділяй і володарюй». Програміст пробує вилучити деякі частини програми і перевіряє чи проблема все ще існує. При роботі з програмами, що використовують графічному інтерфейсі користувача, програміст спрощуватиме вікно програми, прибираючи контрольні елементи й перевіряючи, чи помилка все ще залишається. Для автоматизації цього процесу може використовуватися зневадження дельтою[10].
| Цей розділ не містить посилань на джерела. (квітень 2013) |
Після того, як випробування випадку спрощено достатньо, програміст може розпочати пошук та виправлення помилки. Це можна робити або вручну, або з використанням зневаджувача. Поширеним є вставляння в програму додаткових інструкції, що регулярно роздруковували б інформацію про хід виконання програми. Такий метод називається трасуванням. У простих випадках трасування — лише декілька інструкцій виводу, що показує значення змінних в певних точках виконання програми.
Наприклад,
#ifdef DEBUG
printf ("Перед викликом foo x= %d\n", x);
#endif
x = foo();
#ifdef DEBUG
printf ("Після виклику foo x= %d\n", x);
#endif
Можна використати зневаджувач, який дає доступ до стану програми (значення змінних, стек викликів) і відстежити походження помилки. Якщо мова програмування використовує компілятор, то зазвичай у бінарному коді програми вже втрачено відповідність між інструкціями процесору та рядками тексту програми. Тому для зневаджувача програму потрібно відкомпілювати в спеціальному режимі, де така відповідність збережена. При цьому розмір бінарного файлу програми зростає, а її виконання сповільнюється. Після того як помилку знайдено й виправлено, відповідний файл потрібно відкомпілювати в звичайному режимі. Зазвичай, при розробці програмного забезпечення в інтегрованому середовищі режим зневадження використовується за умовчанням, а перед поставкою програмного забезпечення замовнику його відключають.
| Цей розділ не містить посилань на джерела. (квітень 2013) |
Іноді помилку можна знайти, аналізуючи дамп процесу. Таке зневадження називають посмертним (post mortem). Деякі операційні системи створюють дамп (відбиток пам'яті процесу) при аварійному завершенні програми, програміст може утворити його вручну, за потреби, наприклад командою dump операційної системи Unix. Для зіставлення пам'яті зі змінними програми бажано мати таблицю символів. В роботі допомагають спеціальні програми — аналізатори дампу. Дебаґери на зразок gdb теж можуть зчитати і проаналізувати дамп.
Шукати помилку можна, спостерігаючи за процесом з іншого комп'ютера. Для запуску віддаленого зневадження зневаджувач підключається до віддаленої системи через мережу. Після того, як зв'язок встановлено, зневаджувач може контролювати виконання програми на віддаленій системі та отримувати інформацію про її стан.
Антизневадження є «застосування в комп'ютерному коді одного або декількох методів, що перешкоджають спробам зворотної розробки та зневадження цільового процесу».[11] Види підходів:
Зневадження може бути перешкодою при використанні одного або кількох з вищезазначених методів. Є достатньо багато методів антизневадження для захисту програмного забезпечення від більшості загроз.[12]
Seamless Wikipedia browsing. On steroids.
Every time you click a link to Wikipedia, Wiktionary or Wikiquote in your browser's search results, it will show the modern Wikiwand interface.
Wikiwand extension is a five stars, simple, with minimum permission required to keep your browsing private, safe and transparent.
