В компьютерном программировании и разработка программного обеспечения, отладка - это процесс поиска и устранения ошибок (дефектов или проблем, препятствующих правильной работе) в компьютерных программах, программное обеспечение или системы.
Тактика отладки может включать интерактивную отладку, анализ потока управления, модульное тестирование, интеграционное тестирование, анализ файла журнала, мониторинг на уровне приложения или системы, дампы памяти и профилирование. Многие языки программирования и инструменты разработки программного обеспечения также предлагают программы для помощи в отладке, известные как отладчики.
Термины «ошибка» и «отладка» обычно приписываются адмиралу Грейс Хоппер в 1940-х годах. Когда она работала над компьютером Mark II в Гарвардском университете, ее сотрудники обнаружили моль, застрявшую в реле и тем самым препятствующую работе, после чего она заметила, что они «отлаживают» систему. Однако термин «ошибка» в смысле «техническая ошибка» восходит как минимум к 1878 году и относится к Томасу Эдисону (см. программная ошибка для более полного обсуждения). Точно так же термин «отладка», кажется, использовался как термин в аэронавтике до того, как войти в мир компьютеров. В самом деле, в интервью Грейс Хоппер отметила, что она не придумывала этот термин. Ночная бабочка соответствовала уже существующей терминологии, поэтому ее спасли. Письмо от Дж. Роберт Оппенгеймер (руководитель проекта создания атомной бомбы Второй мировой войны «Манхэттен» в Лос-Аламосе, Нью-Мексико) использовал этот термин в письме доктору Эрнесту Лоуренсу в Калифорнийский университет в Беркли от 27 октября 1944 года относительно набор дополнительного технического персонала.
В статье Оксфордского словаря английского языка для слова «отладка» цитируется термин «отладка», использованный в отношении испытаний авиационных двигателей в статье 1945 года в Журнале Королевского авиационного общества. Статья в «Военно-воздушных силах» (июнь 1945 г., стр. 50) также относится к отладке, на этот раз авиационных камер. Ошибка Хоппера была обнаружена 9 сентября 1947 года. Программисты не использовали этот термин до начала 1950-х годов. Основополагающая статья Гилла в 1951 году - самое раннее подробное обсуждение ошибок программирования, но в ней не используются термины «ошибка» или «отладка». В цифровой библиотеке ACM термин «отладка» впервые используется в трех статьях, опубликованных на Национальных собраниях ACM 1952 года. Двое из трех используют этот термин в кавычках. К 1963 году термин «отладка» был достаточно распространенным, чтобы его можно было упомянуть мимоходом без объяснения на странице 1 руководства по CTSS.
Статья Пегги А. Кидвелл «Преследование неуловимой компьютерной ошибки» обсуждает этимологию понятий «ошибка» и «отладка» более подробно.
По мере того, как программное обеспечение и электронные системы в целом стали более сложными, различные общие методы отладки расширились за счет большего количества методов для обнаружения аномалий, оценки воздействия и планирования исправлений программного обеспечения или полные обновления системы. Слова «аномалия» и «несоответствие» могут использоваться как более нейтральные термины, чтобы избежать слов «ошибка» и «дефект» или «ошибка», где могло бы быть следствие, что все так- так называемые ошибки, дефекты или недочеты должны быть исправлены (любой ценой). Вместо этого можно выполнить оценку воздействия, чтобы определить, будут ли изменения для устранения аномалии (или несоответствия) рентабельными для системы, или, возможно, запланированный новый выпуск может сделать изменение (я) ненужным. Не все проблемы являются критически важными для безопасности или критически важными в системе. Кроме того, важно избегать ситуации, когда изменение может больше расстраивать пользователей в долгосрочной перспективе, чем жизнь с известной проблемой (ами) (где «лекарство будет хуже, чем болезнь»). Основываясь на решениях о приемлемости некоторых аномалий, можно избежать культуры мандата «нулевого дефекта», когда у людей может возникнуть соблазн отрицать существование проблем, чтобы результат выглядел как нулевой дефект. Принимая во внимание сопутствующие проблемы, такие как оценка влияния затрат и выгод, тогда будут расширены более широкие методы отладки, чтобы определить частоту аномалий (как часто возникают одни и те же «ошибки»), чтобы помочь оценить их влияние на систему в целом.
Диапазон сложности отладки: от исправления простых ошибок до выполнения длительные и утомительные задачи по сбору, анализу и планированию обновлений данных. Навыки отладки программиста могут быть основным фактором в способности отлаживать проблему, но сложность отладки программного обеспечения сильно зависит от сложности системы, а также в некоторой степени зависит от языка программирования (а) и доступные инструменты, такие как отладчики. Отладчики - это программные инструменты, которые позволяют программисту отслеживать выполнение программы, останавливать ее, перезапускать, устанавливать точки останова и изменять значения в памяти. Термин «отладчик» также может относиться к человеку, выполняющему отладку.
Как правило, языки программирования высокого уровня, такие как Java, упрощают отладку, поскольку у них есть такие функции, как обработка исключений и проверка типов, которые упрощают выявление реальных источников неустойчивого поведения. В языках программирования, таких как C или ассемблер, ошибки могут вызывать скрытые проблемы, такие как повреждение памяти, и часто бывает трудно увидеть, где возникла первоначальная проблема. В таких случаях могут потребоваться инструменты отладчика памяти.
В определенных ситуациях могут быть очень полезны программные инструменты общего назначения, специфичные для языка. Они принимают форму инструментов статического анализа кода. Эти инструменты ищут очень специфический набор известных проблем, некоторые общие и некоторые редкие, в исходном коде, уделяя больше внимания семантике (например, потоку данных), а не синтаксису, как это делают компиляторы и интерпретаторы.
Существуют как коммерческие, так и бесплатные инструменты для разных языков; некоторые утверждают, что могут обнаружить сотни различных проблем. Эти инструменты могут быть чрезвычайно полезны при проверке очень больших деревьев исходного кода, где непрактично выполнять обход кода. Типичным примером обнаруженной проблемы может быть разыменование переменной, которое происходит до того, как переменной будет присвоено значение. В качестве другого примера, некоторые такие инструменты выполняют строгую проверку типов, когда язык не требует этого. Таким образом, они лучше обнаруживают вероятные ошибки в синтаксически правильном коде. Но эти инструменты имеют репутацию ложных срабатываний, когда правильный код помечается как сомнительный. Старая программа Unix lint является ранним примером.
Для отладки электронного оборудования (например, компьютерного оборудования ), а также низкоуровневого программного обеспечения (например, BIOS, драйверов устройств ) и микропрограммное обеспечение, такие инструменты, как осциллографы, логические анализаторы или внутрисхемные эмуляторы (ICE), часто используются по отдельности или в комбинации. ICE может выполнять многие типичные задачи программного отладчика на низкоуровневом программном обеспечении и микропрограммном обеспечении.
Обычно первым шагом в отладке является попытка воспроизвести проблема. Это может быть нетривиальная задача, например, как с параллельными процессами и некоторыми Heisenbugs. Кроме того, конкретная пользовательская среда и история использования могут затруднить воспроизведение проблемы.
После воспроизведения ошибки, возможно, потребуется упростить ввод программы, чтобы упростить отладку. Например, ошибка в компиляторе может привести к сбою при синтаксическом анализе какого-то большого исходного файла. Однако после упрощения тестового примера всего нескольких строк из исходного исходного файла может быть достаточно для воспроизведения того же сбоя. Такое упрощение можно сделать вручную, используя подход разделяй и властвуй. Программист попытается удалить некоторые части исходного тестового примера и проверить, сохраняется ли проблема. При отладке проблемы в GUI, программист может попытаться пропустить некоторые действия пользователя из исходного описания проблемы и проверить, достаточно ли оставшихся действий для появления ошибок.
После того, как тестовый пример будет достаточно упрощен, программист может использовать инструмент отладчика для проверки состояний программы (значения переменных плюс стек вызовов ) и отследить источник проблемы ( с). В качестве альтернативы можно использовать отслеживание. В простых случаях трассировка - это всего лишь несколько операторов печати, которые выводят значения переменных в определенных точках выполнения программы.
В отличие от среды разработки компьютерного программного обеспечения общего назначения, основной характеристикой встроенных сред является огромное количество различные платформы, доступные разработчикам (архитектуры ЦП, производители, операционные системы и их варианты). Встроенные системы по определению не являются проектами общего назначения: они обычно разрабатываются для одной задачи (или небольшого круга задач), и платформа выбирается специально для оптимизации этого приложения. Этот факт не только усложняет жизнь разработчикам встроенных систем, но также усложняет отладку и тестирование этих систем, поскольку для разных платформ требуются разные инструменты отладки.
Несмотря на упомянутую выше проблему неоднородности, некоторые отладчики были разработаны как в коммерческих целях, так и в качестве исследовательских прототипов. Примеры коммерческих решений поступают от Green Hills Software, Lauterbach GmbH и MPLAB-ICD от Microchip (для внутрисхемного отладчика). Двумя примерами инструментов исследовательских прототипов являются Aveksha и Flocklab. Все они используют функциональность, доступную на недорогих встраиваемых процессорах, модуль отладки на кристалле (OCDM), сигналы которого отображаются через стандартный интерфейс JTAG. Они оцениваются на основе того, сколько изменений требуется в приложении, и скорости событий, за которыми они могут успевать.
В дополнение к типичной задаче выявления ошибок в системе, отладка встроенной системы также направлена на сбор информации о рабочих состояниях системы, которая затем может быть использована для анализа системы: найти способы улучшить ее производительности или для оптимизации других важных характеристик (например, энергопотребления, надежности, реакции в реальном времени и т. д.).
Анти-отладка - это «реализация одного или нескольких методов в компьютерном коде, которая препятствует попыткам обратного проектирования или отладки целевого процесса». Он активно используется признанными издателями в схемах защиты от копирования, но также используется вредоносным ПО, чтобы усложнить его обнаружение и устранение. Методы, используемые в противодействии отладке, включают:
Ранний пример анти-отладки существовал в ранних версиях Microsoft Word, который, если был обнаружен отладчик, выдавал сообщение, в котором говорилось: «Древо зла приносит горькие плоды. Теперь мусор программный диск.», После чего привод гибких дисков издавал тревожные звуки с намерением отпугивания пользователя от повторной попытки.
Викицитатник содержит цитаты, связанные с: Отладкой |
Викибуке Компьютерное программирование В Principles есть страница по теме: Отладка |