Стратегии поиска ошибки?

По моему опыту, вероятно, лучше всего потратить 30 минут или около того на интуицию (1).

Если ничего не выйдет, поговорите об этом с кем-нибудь еще.

] Удивительно, как разговор с кем-нибудь (даже если он не является техническим) может помочь.

1. Воспроизвести ошибку в среде отладки.
2. Изучите состояние системы в момент возникновения ошибки, чтобы найти несогласованные / неправильные / неожиданные элементы состояния, которые непосредственно, явно привели к возникновению ошибки. Часто, просто взглянув на код и стек вызовов, вы сразу поймете, в чем проблема.
3. Добавьте тесты ко всем точкам, где это состояние может быть создано / изменено в рамках обычного потока управления.
4. Считая неудачи этих тестов новой ошибкой, вернитесь к шагу 2.

Промойте, вспеньте, повторите, пока не будет найдена первоначальная причина проблемы. Утомительно и механически, но вы туда доберетесь.

За исключением ... иногда тесты в итерации шага 3 не дают сбоев; чаще всего потому, что некоторая несвязанная система повреждает память, что приводит к недопустимому состоянию, или потому, что проблема зависит от потоковой передачи / синхронизации / неинициализированных данных, и введение тестов изменяет тайминги и / или структуру данных в достаточной степени, чтобы изменить или скрыть симптомы. На этом этапе, по крайней мере для этого плаката, процесс становится более интуитивным,

Я бы сказал, что это не имеет значения, если это задокументировано и методично. В программировании есть странная банальная истина, что иногда выполнение действий в случайном порядке более эффективно, чем тратить много времени на поиск «наилучшего» способа.

Никогда не недооценивайте интуицию; это опыт, предупреждающий вас. Я почти всегда начинаю с того, что вы, вероятно, считаете моим «внутренним» чувством. Я смотрю на ошибку и проверяю действия, которые, по моему мнению, могут вызвать такого рода проблемы.

Мой первый шаг в подобной ситуации - обычно проверять вещи в том порядке, который быстрее всего сокращает количество вещей, оставшихся для проверки. Вы можете почти представить это как выполнение двоичного поиска ошибки: «Ну, параметры POST выглядят правильно, поэтому я могу исключить все до отправки формы» и т. Д.

Тем не менее, если у меня есть сильное чувство что проблема может быть в определенном месте, я сначала проверю это.

Я склонен руководствоваться интуицией и подходом «разделяй и властвуй»; изоляция фрагментов кода уменьшающегося размера, в которых, как я думаю, «ошибка».

Это не сработает, если вы не знаете или не понимаете кодовую базу - в этом случае найдите кого-нибудь, кто знает, и следовать их интуиции.

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

Кроме того, когда я исследую причину, я стараюсь напрямую добавлять действительно быстрые проверки, когда я проверяю код в любом случае (добавьте некоторые временные операторы вывода отладки, добавьте утверждения и т. д.)

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

Независимо от порядка, важно то, что вы делаете со своей гипотезой. Начните пытаться опровергнуть каждую гипотезу, а не проверять ее, и вы охватите больше (см. Психология анализа интеллекта Ричардса Дж. Хойера-младшего, бесплатный PDF-файл). 1145973]

Послушайте, как эксперты отлаживают программное обеспечение по радио «Программная инженерия»:

Дэйв Томас рассказывает об археологии программного обеспечения , в которой есть несколько действительно полезных советов по отладке.

Андреас Зеллер появляется в эпизоде ​​, посвященном отладке.

Я с @moonshadow , но я добавлю, что в некоторой степени это зависит от того, в чем заключается сбой. То есть некоторые виды сбоев имеют довольно хорошо известные причины, и я бы начал с известной причины

. Например, в системах Windows ошибки «Нарушение доступа» почти всегда возникают из-за попытки использовать или просмотреть (доступ ) нераспределенная память. Чтобы найти источник такой ошибки, рекомендуется посмотреть все места, где выделена (или не выделена) память.

Если известно, что «проблема» вызвана неверными данными, то исправление может потребовать изменений в проверке или сборе данных, даже после того, как ошибка будет отслежена для анализа.

Еще один момент, пока обдумываю ошибку. Часто стоит попытаться создать небольшую программу для его создания.

Мой приказ:

1. Посмотрите на код 1-2 наиболее вероятных причин (выбранных на основе интуиции).
2. Если ничего не найдено, выполните код в отладчике (или если это невозможно, вставьте в код операторы отладки / ведения журнала).
3. Если ничего не найдено, вызовите кого-нибудь еще и повторите шаги 1 и 2 вместе с ним.

Вот несколько полезных советов:

• Если вы используете язык, который генерирует трассировку стека при исключениях, начните с него.
• По возможности получите копию исходных данных, вызвавших проблему.
• Используйте хороший отладчик.
• Если у вас есть доступ к одному, есть такие вещи, как ODB для разных языков это может быть полезно, позволяя выполнять быструю перемотку вперед или назад после возникновения события
• Исключите невозможное, и вы останетесь с решением!

Я предлагаю прочитать «Отладка мышлением».

Андреас Зеллер также проделал некоторую работу по систематическим исследованиям отладки.

Обычно я делаю это:

1) Добавляю новый функциональный тестовый пример (-ы) в автоматизированную систему регрессионного тестирования. Обычно я начинаю программный проект с собственной системы регрессионного тестирования с

• библиотекой Excel VBA + C для управления интерфейсом / устройством SCSI / IDE (13 лет назад), отчет об испытаниях представляет собой электронную таблицу Excel.
• TCL Ожидается, что для Комплексное тестирование системы сетевого маршрутизатора. Отчет об испытаниях находится на веб-странице. (6 лет назад)
• Сегодня я использую Python / Expect. Отчет о тестировании представляет собой XML + базовый XML-анализатор Python.

Цель всей этой работы - убедиться, что после обнаружения любой ошибки она никогда больше не появится в коде проверки или производственной системе. Также легче воспроизвести случайные и долгосрочные проблемы.

Не проверяйте код, если он не проходит ночной автоматический регрессионный тест .

Обычно я пишу 1: 1 соотношение между кодом продукта и кодом тестирования. 20 тыс. Строк TCL-эксперта на 20 тыс. Строк кода C ++. (5 лет назад.) Например:

• C-код будет реализовывать настройку туннельного прокси-сервера TCP-соединения.
• Тестовые примеры TCL: (a) Настройте соединения, убедитесь, что данные передаются. (b) Установите соединения с различными сетевыми элементами. (c) Сделайте это 10, 100, 1000 раз и проверьте на предмет утечки памяти, проблем с системными ресурсами и т. д.
• Сделайте это для всех функций в системе, и вы сможете понять, почему соотношение тестовой программы и кода 1: 1.

Я не хочу, чтобы группа QA выполняла автоматическое тестирование моей тестовой системы, поскольку весь мой код проверки должен пройти тесты. Я обычно провожу двухнедельный долгосрочный регрессионный тест, прежде чем передать код команде QA.

Команда QA, выполняющая ручные тестовые примеры, также проверяет, есть ли в моей программе достаточно встроенной диагностической информации для выявления любых будущих ошибок. Цель состоит в том, чтобы получить достаточно диагностической информации, чтобы устранить 95% ошибок менее чем за 2 часа. Мне удалось это сделать в моем последнем проекте. (Видео сетевое оборудование в RBG Networks.)

2) Добавьте диагностическую процедуру (в настоящее время веб-база) , чтобы получить всю внутреннюю информацию. (Текущее состояние, журналы и т. Д.). > 50% моего кода (особенно c / c ++) - это диагностический код.

3) Добавить подробный журнал для проблемной области, которую я не понимаю.

4) Проанализируйте информацию.

5) Попробуйте исправить ошибку.

6) Выполните регрессионные тесты в ночное время / в выходные дни. Когда я работал в НИОКР, я обычно прошу по аренде 5-10 тестовых систем для непрерывного выполнения регрессионных тестов 24x7. Обычно это помогает идентифицировать и решать проблемы с памятью, ресурс и долгосрочная проблема производительности до того, как код попадет в SQA.

Если встроенная система не загружается, время от времени появляется приглашение Linux. Я добавил тестовый пример, в котором он снова и снова включает и выключает систему с помощью программируемой розетки, чтобы убедиться, что она «видит» командную строку и запускает тест в одночасье. Нам удалось быстро выявить проблему с кодом FPGA и убедиться, что система всегда работает после 5000 циклов включения питания. Был добавлен тестовый пример, и все было построено для проверки кода Verilog / кода FPGA. Этот тестовый пример был запущен. Это больше никогда не было проблемой.

в командной строке и начните выполнение теста в одночасье. Нам удалось быстро выявить проблему с кодом FPGA и убедиться, что система всегда работает после 5000 циклов включения питания. Был добавлен тестовый пример, и все было построено для проверки кода Verilog / кода FPGA. Этот тестовый пример был запущен. Это больше никогда не было проблемой.

в командной строке и начните выполнение теста в одночасье. Нам удалось быстро выявить проблему с кодом FPGA и убедиться, что система всегда работает после 5000 циклов включения питания. Был добавлен тестовый пример, и все было построено для проверки кода Verilog / кода FPGA. Этот тестовый пример был запущен. Это больше никогда не было проблемой.