Програмна помилка, звичайно називана «багом», — це дефект у програмі або системі, через який вона поводиться неправильно: видає неправильні дані, зависає, аварійно закривається або проявляє інші небажані симптоми. Більшість таких помилок виникає через огріхи під час проектування або написання коду, але іноді винні інструменти розробки, наприклад компілятори, які генерують некоректний виконуваний файл.
Термін «програмна помилка» зазвичай застосовують до дефектів, які проявляються під час виконання коду; це відрізняє їх від концептуальних помилок на рівні архітектури або від синтаксичних помилок, що заважають компіляції. Звіт про знайдену проблему називають звітом про помилку; якщо помилка викликала аварійне завершення роботи, документ зазвичай називають креш‑репортом.
Етимологія терміна баг
Слово bug у значенні «уловиста технічна несправність» використали ще до комп’ютерів — працівники телеграфу та телефонних мереж так називали неполадки в електроніці. У 1878 році Томас Едісон писав про «міль», які з’являються після першої ідеї та заважають довести винахід до комерційного успіху.
Значення та класифікація помилок програмного забезпечення
Різні види помилок потребують різних підходів до пошуку та виправлення, тому їх зручніше класифікувати за кількома ознаками.
Класифікація за етапом виявлення
За тим етапом, на якому проявляється дефект, помилки ділять на три групи:
- синтаксичні помилки;
- попередження компілятора;
- помилки часу виконання або семантичні помилки.
Синтаксичні помилки порушують правила мови і блокують компіляцію. Попередження вказують на потенційні проблеми, які не перешкоджають збірці, але можуть призвести до багів. Семантичні помилки проявляються лише під час виконання — це логічні огріхи в алгоритмах або неправильна робота з пам’яттю.
Класифікація за ступенем важливості
За впливом на роботу системи помилки зазвичай ранжують так:
- блокуючі (Blockers);
- критичні (Critical / Showstoppers);
- серйозні (Major);
- незначні (Minor);
- косметичні (Cosmetic).
Блокуючі та критичні баги роблять продукт непридатним до використання; серйозні знижують зручність, а незначні й косметичні частіше стосуються дрібних незручностей та зовнішнього вигляду.
Класифікація за тривалістю появи
За частотою прояву помилки діляться на три типи:
- постійні;
- плавучі (Intermittent);
- залежні від середовища.
Постійні відтворюються стабільно, плавучі — лише іноді, а залежні від середовища проявляються лише в специфічних конфігураціях користувача або обладнання.
Класифікація за місцем і напрямом
За областю коду або сигналами, які вони зачіпають, помилки бувають такими:
- помилки користувацького інтерфейсу;
- помилки в системах обробки винятків;
- помилки, пов’язані з граничними умовами;
- помилки обчислень;
- помилки керування потоками виконання;
- помилки обробки або інтерпретації даних;
- помилки стану гонки (race conditions);
- помилки підвищення навантаження на систему;
- помилки контролю версій та ідентифікаторів;
- помилки тестування.
Деякі дефекти залишаються непоміченими роками і проявляються лише за рідких умов — прикладом служить «Проблема 2038 року», пов’язана з переповненням лічильника часу в UNIX‑подібних системах. Помилки також часто відкривають шлях для атак, включаючи несанкціонований доступ та DoS‑атаки.
Різновиди специфічних помилок
За характером нестабільності помилки традиційно називають так:
- гейзенбаг (Heisenbug);
- борбаг (Bohr bug);
- мандельбаг (Mandelbug);
- шрёдинбаг (Schroedinbug);
- гінденбаг (Hindenbug);
- багсон Хіггса (Higgs‑bugson).
Пошук та виправлення помилок
Процес знаходження та усунення багів називають налагодженням. Для цього застосовують налагоджувачі, які дозволяють крокувати по коду, спостерігати за значенням змінних та ставити точки зупину. Приклади популярних інструментів — WinDbg для Windows та GDB для UNIX‑подібних систем.
Налагодження вимагає системного підходу: ізоляція проблем (наприклад, бінарний пошук за ділянками коду) та логування поведінки програми допомагають швидше локалізувати джерело збою.
Звіти про помилки
Частина дефектів виправляють ще на стадії збирання та тестування, але деякі потрапляють до релізів і виявляються у користувачів. Для збору відомостей про такі випадки використовують автоматичні механізми звітів про помилки:
Ці системи збирають дані про стан застосунку в момент збою та відправляють їх розробникам. Приклад вбудованого рішення — утиліта Dr. Watson у системах Windows. Також існують сторонні бібліотеки — Breakpad та CrashRpt — які допомагають інтегрувати збір краш‑репортів у застосунки.
Наслідки помилок
Помилки в коді можуть призводити до найрізноманітніших наслідків — від дрібних незручностей до серйозних економічних та людських втрат. Конкретні приклади:
- аварія ракети-носія «Аріан‑5» 4 червня 1996 року;
- помилки в медичному прискорювачі Therac‑25 у 1980‑х роках;
- фінансові збитки великої організації у серпні 2012 року.
У випадку з Ariane‑5 переповнення під час перетворення 64‑бітного значення у 16‑бітне призвело до збої системи наведення та знищення ракети з чотирма супутниками на борту. У випадках з Therac‑25 програмні помилки спричинили передозування опромінення у пацієнтів та стали трагічним уроком щодо потреби верифікації критично важливих систем. У 2012 році через помилку в алгоритмі високочастотної торгівлі організація втратила 440 мільйонів доларів за 45 хвилин.
Попередження помилок та підвищення якості коду
Щоб зменшити кількість дефектів, використовують набір практик та інструментів, які охоплюють увесь цикл розробки:
- ретельне проектування та архітектура;
- стандарти кодування та рев’ю коду;
- автоматизоване тестування;
- статичний та динамічний аналіз коду;
- формальна верифікація для критично важливих систем;
- керування конфігурацією та версіями.
Чіткі вимоги та продумана архітектура зменшують ризик фундаментальних помилок. Рев’ю коду та єдині стандарти роблять код зрозумілішим та легшим у підтримці. Автоматизовані тести та аналізи допомагають ловити регресії та вразливості, а формальна верифікація застосовується там, де ціна помилки — людське життя або мільйони доларів. Системи контролю версій, наприклад Git, дозволяють відстежувати зміни та швидко повертатися до стабільних версій.
Пожиттєвий цикл помилки
Від моменту виявлення до остаточного закриття багу проходить кілька етапів:
- Нова.
- Призначено.
- Відкрита.
- Виправлена.
- На тестуванні.
- Перевірена.
- Повторно відкрита.
- Відхилена.
- Відкладена.
Цей цикл зазвичай відстежують за допомогою систем трекінгу багів, які допомагають командам координувати роботу, бачити поточний стан дефектів та керувати пріоритетами виправлень.
