Области знаний
Партнёрские проектыМатериалы БРЭСпецпроектыСтать автором
Настроить видСменить языкИнформация
О РУВИКИ
Найти статью
ТехнологииРазработка ПОТестирование, отладка и качествоОтладка

Отладка

Pause

Экспертиза РАН

Logo-ran.pngLogo-ran-black.png
Проводится экспертиза
Российской академией наук
Подробнее
Times2.svg

Экспертиза РАН

Arrow-Right.png
Logo-ran.png
Проводится экспертиза
Российской академией наук
Подробнее

Отла́дка програ́ммы (англ. debugging) — деятельность по поиску, локализации и устранению причин некорректного поведения программы. Отладка включает воспроизведение выявленной проблемы, исследование выполнения программы и её состояния, формирование и проверку гипотез о причине неисправности, внесение исправлений и последующую проверку их результата[1][2].

Отладка тесно связана с тестированием, но не тождественна ему. Тестирование предназначено для выявления несоответствий между фактическим и требуемым поведением программы, тогда как отладка исследует причины обнаруженных несоответствий и направлена на их устранение[2][3].

Отладка проводится на различных этапах жизненного цикла программного обеспечения, прежде всего при разработке и сопровождении. При эксплуатации она применяется при расследовании сбоев и других отклонений поведения программных систем[4][5].

По характеру действий отладка сходна с технической диагностикой: сначала фиксируется проявление неисправности, затем устанавливаются условия её возникновения, локализуется причина и проверяется результат исправления. В программном обеспечении причина и проявление дефекта могут быть разделены во времени либо относиться к разным взаимодействующим компонентам[2].

Терминология

В русскоязычной литературе употребление терминов, описывающих программные неисправности, не полностью единообразно. Для обозначения проблем используются понятия «ошибка», «дефект», «неисправность», «отказ» и другие термины; в англоязычной литературе им соответствуют, в частности, англ. error, англ. defect, англ. fault и англ. failure[3][6].

Термин англ. fault обычно используется для обозначения причины неправильного поведения, а англ. failure — для наблюдаемого отказа программы или системы. англ. Defect может обозначать выявленное несовершенство программного продукта без обязательного проведения такого различия. В конкретных публикациях границы между терминами могут отличаться[7].

В англоязычной практике слово англ. bug широко используется для обозначения программной ошибки или дефекта. От него образовано слово debugging — отладка[8].

История

Происхождение термина

Слово англ. bug в значении технической неисправности появилось до возникновения электронных вычислительных машин. В документах, связанных с деятельностью Томаса Эдисона, оно используется применительно к неполадкам технических устройств уже в 1870-х годах[9].

9 сентября 1947 года при поиске причины неисправности электромеханического компьютера Harvard Mark II была найдена моль, застрявшая между контактами реле. Насекомое прикрепили к журналу испытаний с записью о первом фактическом случае обнаружения «bug». Этот эпизод впоследствии стал одним из наиболее известных сюжетов истории компьютерной техники, однако он не является возникновением самого термина[10].

Грейс Хоппер входила в группу специалистов, работавших с Mark II, и позднее способствовала распространению связанных с этим терминов. Однако считать её автором самого понятия или слова bug оснований нет: техническое употребление этого слова существовало задолго до 1947 года[10][11].

Уже в начале 1950-х годов развивались специальные методы диагностики программ. В 1951 году С. Гилл опубликовал работу о диагностике ошибок программ для EDSAC, описав процедуры, облегчавшие поиск ошибок в программах ранней вычислительной машины[12].

Развитие средств отладки

По мере роста сложности программ ручное исследование результатов дополнялось отладчиками, средствами трассировки, анализа памяти и потоков. Позднее появились программные срезы, статистическая локализация неисправностей, динамическое инструментирование, запись и воспроизведение выполнения и автоматическое исправление программ[8][13][14].

В отечественной научной литературе развитие автоматизированной диагностики связано, в частности, с исследованиями статического анализа в Институте системного программирования РАН. Создание анализатора Svace сопровождалось разработкой методов поиска дефектов, анализа потока данных и специализированных детекторов ошибок для различных языков программирования[15].

Процесс отладки

Универсального алгоритма отладки не существует. Обычно работа начинается с обнаружения проблемы, после чего устанавливаются условия её воспроизведения, формируются гипотезы о причине, выполняется локализация, вносится исправление и проводится повторная проверка. При неудаче любой из этапов может быть повторён[2][16].

Обнаружение проблемы

Началом отладки может служить сообщение об ошибке, аварийное завершение, неверный результат вычислений, нарушение производительности или сообщение пользователя. Существенно различать наблюдаемый симптом и предполагаемую причину. Например, исключение может возникнуть в одном модуле, хотя ошибочное состояние было создано значительно раньше в другом[8][2].

Источниками диагностической информации служат результаты тестов, журналы, трассировки, дампы памяти и сведения о конфигурации. Чем полнее зафиксированы условия происшествия, тем меньше пространство возможных причин, которое приходится исследовать[16].

Воспроизведение

Воспроизведение заключается в установлении входных данных, последовательности действий и состояния среды, при которых ошибка возникает. Воспроизводимый пример позволяет сравнивать результаты разных запусков и систематически изменять условия эксперимента[2].

Если исходный сценарий сложен, его стараются уменьшить до минимального примера. Для автоматизированного уменьшения тестового случая используется, в частности, метод delta debugging, который позволяет сохранять отказ при последовательном сокращении входных данных[17].

Некоторые ошибки трудно воспроизвести из-за зависимости от порядка событий, времени выполнения, случайных величин или состояния внешних компонентов. Для них применяются повторные эксперименты, расширенное журналирование, фиксация конфигурации и запись выполнения программы[18].

Формирование гипотез

После получения воспроизводимого случая исследователь формулирует предположение о причине проблемы. Возможными причинами являются ошибка в алгоритме, некорректные данные, нарушение условий работы с ресурсами, ошибка синхронизации, несовместимость интерфейсов или особенности окружения[2].

Гипотезы проверяются контролируемыми изменениями. Изменяется одно из условий, после чего сравниваются результаты. Такой подход позволяет отделять причины, связанные друг с другом, и постепенно сокращать область поиска[8].

Локализация и исправление

Локализация заключается в определении программного элемента, связанного с возникновением неисправности. Им может быть строка программы, функция, модуль, структура данных, конфигурационный параметр или взаимодействие нескольких компонентов[4].

После локализации в программу вносится изменение. Оно должно устранять причину, а не только скрывать её проявление. Затем повторно проверяется исходный сценарий и связанные с ним случаи[2].

Регрессионное тестирование позволяет проверить, не привело ли исправление к появлению новых ошибок или изменению ранее работавшего поведения. Поэтому отладка и тестирование на практике образуют взаимосвязанный итерационный процесс[3].

Характерные классы дефектов

Методы отладки зависят от природы неисправности. Логические дефекты приводят к неверным результатам при формально успешном выполнении. Ошибки управления ресурсами связаны с неправильным использованием памяти, файлов, соединений и других ресурсов. Ошибки интерфейсов возникают из-за несовпадения предположений компонентов о данных, порядке операций или допустимых состояниях[19].

Для многопоточных программ характерны ошибки синхронизации, включая гонки данных и взаимные блокировки. Ошибки окружения связаны с версиями библиотек, конфигурацией, операционной системой, оборудованием или внешними службами[20].

Методы отладки

Интерактивная отладка

Основным средством интерактивной отладки является отладчик. Он позволяет приостанавливать выполнение программы в заданных точках, выполнять код пошагово, исследовать значения переменных, регистров и памяти, а также просматривать стек вызовов. Точки останова могут быть условными и зависеть от значений или событий[2][21].

Интерактивный анализ особенно эффективен, когда ошибка воспроизводится непосредственно во время отладки. Однако сам отладчик изменяет характеристики выполнения программы. Это особенно существенно для многопоточных приложений, где изменение времени выполнения может повлиять на порядок событий[22].

Журналирование

Журналирование состоит в записи событий выполнения программы и связанных с ними параметров. В журнал могут помещаться сведения об ошибках, времени выполнения операций, идентификаторах запросов и других значимых событиях[16].

Журналирование особенно важно для эксплуатируемого программного обеспечения, когда подключение интерактивного отладчика невозможно. Анализ журналов может использоваться и для поиска закономерностей, предшествующих отказу. Исследования программных систем показывают возможность использования данных о событиях для анализа поведения приложений и выявления проблем[23].

Трассировка

Трассировка фиксирует последовательность событий выполнения. В распределённых системах она позволяет связать операции, выполняемые разными процессами и сервисами, в одну цепочку обработки запроса[24].

Современная наблюдаемость объединяет трассы с журналами и метриками. Такое объединение облегчает сопоставление отказа с состоянием нескольких компонентов системы[25].

Статический и динамический анализ

Статический анализ выполняется без запуска исследуемой программы. Он применяется для поиска потенциальных ошибок, подозрительных конструкций и нарушений заданных правил. В строгом смысле статический анализ не является отладкой конкретного выполнения, но используется в общем процессе обнаружения и устранения дефектов[4].

В России одним из наиболее известных направлений таких исследований являются работы ИСП РАН по анализатору Svace. В нём используются анализ абстрактных синтаксических деревьев, анализ потока данных и другие методы, позволяющие искать ошибки в исходном коде[15][26].

Методы статического анализа могут быть специализированы для отдельных видов дефектов. В работах ИСП РАН описаны, в частности, поиск недостижимого кода, ошибки обращения к буферам и анализ программ на языке Java[27][28][29].

Одним из ограничений статического анализа является возможность ложноположительных предупреждений. Поэтому практически важны не только полнота поиска, но и точность результатов[26].

Динамический анализ исследует свойства программы непосредственно во время выполнения. К нему относятся средства обнаружения ошибок работы с памятью, анализа многопоточности, трассировки и измерения поведения отдельных частей программы[3].

Valgrind представляет собой инфраструктуру динамического двоичного инструментирования. В её состав входят инструменты для анализа управления памятью и синхронизации многопоточных программ[30].

Для безопасности приложений используется динамическое тестирование безопасности приложений (DAST, англ. Dynamic Application Security Testing), при котором работающая программа исследуется с внешней стороны. DAST относится прежде всего к тестированию безопасности, но обнаруженные им проблемы могут стать предметом последующей отладки[31].

Программные срезы

Программный срез представляет собой часть программы, связанная с заданным элементом программы и соответствующими зависимостями по данным или управлению. Обратный срез помогает исследовать происхождение значения, а прямой — влияние определённого элемента на дальнейшее выполнение.[13]

Срезы позволяют уменьшить объём кода, который необходимо исследовать при отладке сложной программы. Метод применяется также при анализе влияния изменений и локализации неисправностей[13][4].

Локализация неисправностей

Локализация неисправностей предназначена для определения тех участков программы, которые наиболее вероятно связаны с наблюдаемым отказом. Для этого используются результаты тестов, данные покрытия, трассы и другие сведения о выполнении[32].

Распространены методы, основанные на сопоставлении успешных и неуспешных тестов. Результатом является ранжированный список участков программы, требующих исследования. Одним из известных ранних методов такого типа является Tarantula[33].

Российские исследования развивают автоматическую локализацию с использованием методов машинного обучения. В работе А. М. Достоваловой и А. А. Шерминской предложен метод локализации ошибок времени выполнения по данным трассировки функций с использованием нейронной сети[34].

Уменьшение входных данных

При сложных ошибках исходный набор данных или последовательность действий могут быть слишком велики для ручного анализа. Delta debugging автоматически уменьшает такой набор, сохраняя свойство, при котором ошибка продолжает воспроизводиться. Это облегчает установление минимального набора условий, связанных с отказом.[17]

Посмертная отладка

Посмертная отладка проводится после завершения процесса или возникновения сбоя. Основными источниками информации являются дампы памяти, стеки вызовов, сведения об исключениях и журналы[2].

Метод особенно важен для программ, работающих в эксплуатации, когда повторное выполнение с теми же условиями невозможно. Посмертный анализ позволяет исследовать состояние системы в момент уже завершившегося сбоя[16].

Реверсивная отладка

Реверсивная отладка позволяет исследовать предшествующие состояния программы. Для этого используется запись выполнения и последующее воспроизведение с возможностью перемещения к более ранним точкам исполнения[35].

Подобные средства особенно полезны при редких ошибках, причина которых обнаруживается только после выполнения большой последовательности операций. Для распределённых систем исследовались методы детерминированного воспроизведения, сохраняющие информацию, необходимую для повторного анализа взаимодействия компонентов[18].

Отладка параллельных и распределённых программ

В параллельных программах часть ошибок возникает вследствие взаимодействия потоков и процессов. К ним относятся гонки данных, взаимные блокировки и ошибки координации доступа к общим ресурсам[22].

Гонка данных (англ. data race) связана с конфликтующими обращениями нескольких потоков к общей памяти при отсутствии необходимой синхронизации. Более широкое состояние гонки относится к ситуациям, в которых результат зависит от порядка конкурентных событий[20].

Особенность отладки параллельных программ состоит в том, что диагностические средства сами могут изменять время выполнения. Установка точки останова или добавление подробного журналирования иногда изменяет порядок событий и скрывает ошибку. Поэтому применяются специализированные параллельные отладчики, профилирование и средства воспроизведения[22].

Для распределённых систем дополнительную сложность создаёт разделение состояния между несколькими процессами и узлами. Один запрос может последовательно или параллельно обрабатываться несколькими сервисами, а причина отказа может находиться в компоненте, не являющемся местом непосредственного проявления ошибки[24].

Поэтому для таких систем используются коррелированные журналы, метрики и распределённые трассы. Сведения связываются идентификаторами запросов и операций, что позволяет восстанавливать путь обработки и сопоставлять события разных компонентов[25].

Анализ изменений и регрессий

При появлении ошибки после изменения исходного кода область поиска можно ограничить историей версий программы. Системы управления версиями позволяют сопоставлять состояния исходного кода до и после появления дефекта[4].

При большом количестве изменений применяется двоичный поиск по истории. Например, команда `git bisect` автоматически выбирает промежуточные состояния между известной исправной и неисправной версиями, что позволяет существенно сократить число проверок[36].

Результат такого поиска указывает на изменение, после которого появилось наблюдаемое поведение, но не обязательно на саму логическую причину. Найденное изменение может активировать дефект, существовавший ранее, поэтому после определения области изменения требуется обычная локализация.[2]

Диагностические данные и наблюдаемость

К основным диагностическим данным относятся входные параметры, сообщения об ошибках, журналы, трассы, стеки вызовов, дампы памяти, сведения о потоках и результаты тестов. Стек характеризует состояние вызовов в момент сбоя, дамп позволяет исследовать состояние процесса после его завершения, журнал показывает зарегистрированные события, а трасса связывает операции одного запроса или нескольких компонентов[8][23].

Для редких сбоев важна возможность повторить эксперимент. При наличии случайности, конкурентного выполнения или внешних событий необходимо учитывать факторы, влияющие на результат. Для распределённых систем особенно важны корреляция событий между компонентами и сохранение достаточного контекста выполнения[18][24].

Таким образом, диагностируемость зависит не только от наличия отладчика. Структура программы, информативность сообщений об ошибках, качество журналирования и возможность воспроизведения сбоя непосредственно влияют на трудоёмкость поиска причины[23][25].

Автоматизация

Автоматизации поддаются отдельные этапы отладки: запуск тестов, статический и динамический анализ, локализация неисправностей, уменьшение тестовых входов, анализ дампов и формирование вариантов исправлений[4].

Отдельным направлением является автоматическое исправление программ (англ. automated program repair). Такие системы пытаются построить изменение исходного кода, удовлетворяющее тестам или другому формализованному критерию. Одним из наиболее известных ранних исследовательских подходов является GenProg[37].

Автоматически найденное исправление не гарантирует устранения всех проявлений дефекта. Тестовый набор проверяет только те свойства программы, которые представлены в тестах, поэтому результат автоматического исправления требует дополнительной проверки[2].

Искусственный интеллект в отладке

Методы машинного обучения применяются и исследуются для автоматизации различных задач отладки. Они используются для анализа кода и трасс выполнения, классификации и локализации ошибок, анализа журналов, генерации тестов и поиска вариантов исправления[34].

В последние годы отдельным направлением стали большие языковые модели, способные анализировать исходный код и диагностические данные и формировать гипотезы о причинах ошибок. Исследования 2025 года рассматривают применение LLM для локализации неисправностей, в том числе с использованием тестов, журналов и результатов работы других инструментов.[38]

Результат работы автоматической модели представляет собой гипотезу, которая требует проверки. Ошибочное объяснение причины или изменение программы, нарушающее свойства, не представленные в тестах, может остаться незамеченным без дополнительной верификации[38].

Отдельным исследовательским направлением является отладка квантовых программ. Непосредственное наблюдение квантового состояния имеет ограничения, а классическое моделирование усложняется с ростом числа кубитов. Исследования 2025—2026 годов рассматривают квантовые assertions, моделирование и специализированные средства отладки; масштабируемая отладка квантового программного обеспечения остаётся открытой задачей[39][40].

Предотвращение дефектов и диагностируемость

Отладка дополняется практиками, направленными на снижение количества дефектов и облегчение их последующего поиска. К ним относятся анализ требований, рецензирование кода, автоматизированное тестирование, статический анализ, утверждения и разработка информативных диагностических сообщений[4][41].

Важной характеристикой является диагностируемость программного обеспечения — возможность по наблюдаемым данным установить состояние системы и причины её отклонения от требуемого поведения. Её повышают информативные сообщения об ошибках, структурированное журналирование, сохранение контекста отказа и возможность воспроизведения проблем[23].

Для распределённых систем диагностируемость зависит также от возможности связать события различных компонентов одного запроса. Поэтому идентификаторы корреляции и распределённая трассировка являются частью архитектуры наблюдаемости современных программных систем[24][25].

Инструменты

Основные средства отладки и диагностики можно разделить на несколько классов.

Отладчики обеспечивают интерактивное управление выполнением программы. К распространённым средствам относятся GDB, LLDB, отладчик Visual Studio и WinDbg.[21].

Средства статического анализа исследуют исходный код или промежуточное представление без запуска программы. В России к таким средствам относится Svace, разрабатываемый в ИСП РАН[15].

Средства динамического анализа исследуют выполняющуюся программу и позволяют выявлять ошибки работы с памятью, синхронизации и другие свойства исполнения. Примером служит Valgrind[30].

Профилировщики применяются для исследования времени выполнения и потребления ресурсов. Они позволяют определить функции и операции, связанные с наибольшими затратами вычислительных ресурсов[22].

Системы журналирования и трассировки собирают сведения о событиях работы программы и позволяют анализировать их последовательность. Они особенно важны для серверных и распределённых систем[23][24].

Средства анализа дампов используются после аварийного завершения программы для исследования её состояния, стека вызовов и другой сохранённой информации[16].

Средства записи и воспроизведения позволяют повторно исследовать выполнение программы, включая редкие недетерминированные ошибки[18][35].

Примечания

  1. ↑ Котляров В. П. Отладка программы. Большая российская энциклопедия. Дата обращения: 1 октября 2026.
  2. ↑ 1 2 3 4 5 6 7 8 9 10 11 12 Плаксин, М. А. Тестирование и отладка программ для профессионалов будущих и настоящих. — 4-е. — Москва : Лаборатория знаний, 2020. — P. 170. — ISBN 978-5-00101-810-0.
  3. ↑ 1 2 3 4 Игнатьев, А. В. Тестирование и отладка программного обеспечения. — Волгоград : ВолгТУ, 2018. — P. 63. — ISBN 978-5-9948-3024-6.
  4. ↑ 1 2 3 4 5 6 7 Лаврищева, Е. М. Программная инженерия и технологии программирования сложных систем. — 2-е, испр. и доп. — Москва : Юрайт, 2023. — P. 432. — ISBN 978-5-534-07604-2.
  5. ↑ ISO/IEC/IEEE 12207:2026 — Systems and software engineering — Software life cycle processes. International Organization for Standardization. Дата обращения: 1 октября 2026.
  6. ↑ ISO/IEC/IEEE 24765:2017 — Systems and software engineering — Vocabulary. International Organization for Standardization. Дата обращения: 1 октября 2026.
  7. ↑ Chapter 10: Software Quality. SWEBOK. IEEE Computer Society. Дата обращения: 1 октября 2026.
  8. ↑ 1 2 3 4 5 Zeller, Andreas. Why Programs Fail: A Guide to Systematic Debugging. — 2. — San Francisco : Morgan Kaufmann, 2009. — ISBN 978-0-12-374515-6.
  9. ↑ Telephone Bugs. Rutgers University. The Thomas Edison Papers. Дата обращения: 1 октября 2026.
  10. ↑ 1 2 Log Book With Computer Bug. Smithsonian Institution, National Museum of American History. Дата обращения: 1 октября 2026.
  11. ↑ Kidwell, Peggy Aldrich (1998). “Stalking the Elusive Computer Bug”. IEEE Annals of the History of Computing. 20 (4): 5—9.
  12. ↑ Gill, S. (1951). “The Diagnosis of Mistakes in Programmes on the EDSAC”. Proceedings of the Royal Society of London. Series A. 206 (1087): 538—554.
  13. ↑ 1 2 3 Weiser, Mark (1984). “Program Slicing”. IEEE Transactions on Software Engineering. SE-10 (4): 352—357.
  14. ↑ Wong, W. Eric; Gao, Ruizhi; Li, Yihao; Abreu, Rui; Wotawa, Franz (2016). “A Survey on Software Fault Localization”. IEEE Transactions on Software Engineering. 42 (8): 707—740.
  15. ↑ 1 2 3 Иванников, В. П.; Белеванцев, А. А.; Бородин, А. Е.; Игнатьев, В. Н.; Журихин, Д. М.; Аветисян, А. И.; Леонов, М. И. (2014). “Статический анализатор Svace для поиска дефектов в исходном коде программ”. Труды Института системного программирования РАН. 26 (1): 231—250.
  16. ↑ 1 2 3 4 5 Хоперскова, Л. В. Тестирование и отладка программного обеспечения. — Волгоград : ВолгТУ, 2018. — P. 93. — ISBN 978-5-9948-2965-3.
  17. ↑ 1 2 Zeller, Andreas; Hildebrandt, Ralf (2002). “Simplifying and Isolating Failure-Inducing Input”. IEEE Transactions on Software Engineering. 28 (2): 183—200.
  18. ↑ 1 2 3 4 Geels, Dennis; Altekar, Gautam; Shenker, Scott; Stoica, Ion (2006). “Replay Debugging for Distributed Applications”. 2006 USENIX Annual Technical Conference. pp. 289—300.
  19. ↑ Pressman, Roger S. Software Engineering: A Practitioner's Approach / Roger S. Pressman, Bruce R. Maxim. — 9. — New York : McGraw-Hill Education, 2019. — ISBN 978-1-260-56965-0.
  20. ↑ 1 2 Savage, Stefan; Burrows, Michael; Nelson, Greg; Sobalvarro, Patrick; Anderson, Thomas (1997). “Eraser: A Dynamic Data Race Detector for Multithreaded Programs”. ACM Transactions on Computer Systems. 15 (4): 391—411.
  21. ↑ 1 2 Debugging with GDB. GNU Debugger. GNU Project. Дата обращения: 1 октября 2026.
  22. ↑ 1 2 3 4 Киселев, А. Б.; Киселев, С. Н. (2020). “Отладчик параллельных программ для ОС Linux”. Труды Института системного программирования РАН. 32 (4): 97—114.
  23. ↑ 1 2 3 4 5 Резуник, Л. А.; Перевозникова, А. И.; Еремина, Д. В.; Мицюк, А. А. (2023). “Применение методов интеллектуального анализа процессов в ходе разработки семейства мобильных приложений”. Труды Института системного программирования РАН. 35 (3): 171—186.
  24. ↑ 1 2 3 4 5 Sigelman, Benjamin H.; Barroso, Luiz André; Burrows, Mike; Stephenson, Pat; Plakal, Manoj; Beaver, Donald; Jaspan, Saul & Shanbhag, Chandan (2010), Dapper, a Large-Scale Distributed Systems Tracing Infrastructure, <https://research.google/pubs/dapper-a-large-scale-distributed-systems-tracing-infrastructure/>. 
  25. ↑ 1 2 3 4 Observability primer. OpenTelemetry. Дата обращения: 1 октября 2026.
  26. ↑ 1 2 Бородин, А. Е.; Белеванцев, А. А. (2015). “Статический анализатор Svace как коллекция анализаторов разных уровней сложности”. Труды Института системного программирования РАН. 27 (6): 111—134.
  27. ↑ Мулюков, Р. Р.; Бородин, А. Е. (2016). “Использование анализа недостижимого кода в статическом анализаторе для поиска ошибок в исходном коде программ”. Труды Института системного программирования РАН. 28 (5): 145—158.
  28. ↑ Дудина, И. А.; Кошелев, В. К.; Бородин, А. Е. (2016). “Поиск ошибок доступа к буферу в программах на языке C/C++”. Труды Института системного программирования РАН. 28 (4): 149—168.
  29. ↑ Меркулов, А. П.; Поляков, С. А.; Белеванцев, А. А. (2017). “Анализ программ на языке Java в инструменте Svace”. Труды Института системного программирования РАН. 29 (3): 57—74.
  30. ↑ 1 2 Nethercote, Nicholas; Seward, Julian (2007). “Valgrind: a framework for heavyweight dynamic binary instrumentation”. Proceedings of the 28th ACM SIGPLAN Conference on Programming Language Design and Implementation: 89—100.
  31. ↑ dynamic application security testing. National Institute of Standards and Technology. Дата обращения: 1 октября 2026.
  32. ↑ Wong, W. Eric; Gao, Ruizhi; Li, Yihao; Abreu, Rui; Wotawa, Franz (2016). “A Survey on Software Fault Localization”. IEEE Transactions on Software Engineering. 42 (8): 707—740.
  33. ↑ Jones, James A.; Harrold, Mary Jean (2005). “Empirical Evaluation of the Tarantula Automatic Fault-Localization Technique”. 20th IEEE/ACM International Conference on Automated Software Engineering. pp. 273—282.
  34. ↑ 1 2 Достовалова, А. М.; Шерминская, А. А. (2023). “Автоматическая локализация ошибок времени выполнения в программном обеспечении с помощью нейронных сетей”. Программные продукты и системы. 36 (4): 551—560.
  35. ↑ 1 2 Process Record and Replay. GNU Debugger. GNU Project. Дата обращения: 1 октября 2026.
  36. ↑ git-bisect Documentation. Git. Дата обращения: 1 октября 2026.
  37. ↑ Le Goues, Claire; Nguyen, ThanhVu; Forrest, Stephanie; Weimer, Westley (2012). “GenProg: A Generic Method for Automatic Software Repair”. IEEE Transactions on Software Engineering. 38 (1): 54—72.
  38. ↑ 1 2 Pan, Tian; Liu, Pan; Li, Yihao (2025). “Review of Large Language Model-Based Software Fault Localization Techniques”. 2025 12th International Conference on Dependable Systems and Their Applications. pp. 84—92.
  39. ↑ Rosa, Evandro; Santiago, Rafael (2026). “Schrödinger's bug: a survey on quantum software debugging”. Quantum Information Processing. 25. статья 96. Дата обращения 2026-10-01.
  40. ↑ Rovara, Damian; Burgholzer, Lukas; Wille, Robert (2025). “A Framework for Debugging Quantum Programs”. 2025 IEEE International Conference on Quantum Software. pp. 130—136.
  41. ↑ Fagan, Michael E. (1986). “Advances in Software Inspections”. IEEE Transactions on Software Engineering. SE-12 (7): 744—751.

Литература

Нормативные документы

Категории

Pause