Ошибки в программном обеспечении (баги) можно классифицировать по разным критериям: по этапу обнаружения, по характеру проявления, по степени влияния на работу системы и т. д.
По этапу обнаружения и характеру
- Синтаксические ошибки. Возникают из‑за нарушения правил языка программирования: забытая скобка, опечатка в ключевом слове, неверный формат инструкции. Их обычно выявляет компилятор или интерпретатор ещё до запуска программы.
Пример:print "Hello"в Python 3 (нужноprint("Hello")). - Ошибки времени компиляции. Более широкий класс, включающий синтаксические и другие проблемы, которые не позволяют собрать исполняемый файл (например, отсутствие подключённых библиотек, несовместимость типов).
- Логические ошибки. Код синтаксически верен и выполняется, но даёт неверный результат из‑за ошибки в алгоритме. Это одни из самых коварных ошибок: программа не «падает», но работает неправильно.
Пример: в формуле среднего арифметического забыли разделить сумму на количество элементов. - Ошибки времени выполнения (runtime errors). Возникают при работе программы: деление на ноль, обращение к несуществующему элементу массива, исчерпание памяти, ошибка ввода‑вывода. Часто приводят к аварийному завершению.
Пример: попытка открыть файл, которого нет, без обработки исключения.
По степени влияния (severity) и приоритету (priority)
В тестировании и баг‑трекинге (Jira, YouTrack и др.) ошибки ранжируют:
- Blocker / Критические (Critical). Программа полностью неработоспособна или блокируется ключевой сценарий.
Пример: приложение не запускается, платёжная форма не отправляет данные. - Major / Серьёзные (Major). Значительно ухудшают функциональность, но не делают продукт полностью непригодным.
Пример: поиск работает только по части данных, отчёт формируется с пропусками. - Minor / Незначительные (Minor). Не мешают основной работе, но заметны пользователю.
Пример: кнопка немного смещена, текст обрезается в длинном названии. - Trivial / Косметические (Trivial). Почти не влияют на UX.
Пример: опечатка в подсказке, лишний пробел.
Приоритет (priority) определяет, насколько срочно ошибку нужно исправить, и зависит от бизнеса, дедлайнов и количества затронутых пользователей.
По типу проявления и среде
- Детерминированные баги. Проявляются стабильно при одних и тех же условиях. Их проще воспроизвести и исправить.
- «Плавающие» баги (Heisenbugs). Проявляются нерегулярно, исчезают или меняют поведение при попытке их отладить (например, из‑за многопоточности, таймингов, кэша).
- Баги, зависящие от окружения. Возникают только на конкретных ОС, браузерах, устройствах, версиях библиотек.
Пример: интерфейс «разъезжается» в старом браузере, утечка памяти проявляется только на слабых машинах. - Баги граничных условий. Проявляются на крайних значениях: пустая строка, ноль, максимально допустимое число, очень большой файл.
Пример: система падает при попытке загрузить файл размером ровно на 1 байт больше лимита.
По области влияния
- Функциональные ошибки. Не работает заявленная функция.
Пример: корзина не очищается после заказа. - Ошибки пользовательского интерфейса (UI). Проблемы отображения: наложение элементов, некорректные цвета, неработающие анимации.
- Проблемы UX (usability). Интерфейс неудобен, хотя технически всё работает.
Пример: слишком много шагов для простой операции, неочевидные названия кнопок. - Ошибки производительности. Медленная работа, высокие требования к ресурсам, утечки памяти.
Пример: отчёт формируется 5 минут вместо 10 секунд, потребление памяти растёт со временем. - Ошибки безопасности. Уязвимости, позволяющие получить несанкционированный доступ, выполнить произвольный код, раскрыть данные.
Пример: SQL‑инъекция, XSS, слабая аутентификация. - Ошибки интеграции. Проблемы взаимодействия модулей, микросервисов, сторонних API.
Пример: сервис не получает данные из очереди сообщений, ответ API интерпретируется неверно.
Специфические категории
- Race conditions (состояние гонки). Ошибка в многопоточных системах: результат зависит от порядка выполнения потоков.
Пример: два запроса одновременно пытаются обновить баланс счёта, одно из изменений теряется. - Deadlock (взаимная блокировка). Два или более потока бесконечно ждут друг друга, программа «зависает».
- Ошибки проектирования (design bugs). Фундаментальная проблема архитектуры: неверная модель данных, неудачный выбор протокола, плохая масштабируемость. Такие ошибки дорого исправлять на поздних этапах.
- Ошибки требований. Программа реализована верно, но требования изначально были ошибочными или неполными.
Пример: забыли учесть часовые пояса, не предусмотрели офлайн‑режим.
По времени обнаружения
- Ошибки этапа разработки. Находят сами разработчики при написании кода, код‑ревью, юнит‑тестах.
- Ошибки этапа тестирования. Выявляют тестировщики: ручное тестирование, автотесты, нагрузочные тесты, пентест.
- Продакшн‑баги. Обнаруживаются уже у пользователей: по логам, мониторингу, обращениям в поддержку, отчётам об ошибках.
Практическое значение классификации
- Для разработчиков классификация помогает быстрее локализовать проблему: если программа не компилируется — ищем синтаксис; если работает, но неверно — проверяем логику и граничные случаи.
- Для тестировщиков — выбирать подходящие виды тестов: юнит‑тесты для логики, интеграционные для взаимодействия, нагрузочные для производительности, пентесты для безопасности.
- Для менеджеров и владельцев продукта — оценивать риски и планировать исправления: критические баги закрывают в первую очередь, косметические — в рамках плановых обновлений.