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

Question

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

Fine. Мы все были там.

У вас есть модульные тесты для записи и запуска, отладочные / логирующие операторы для вставки, SQL-операторы для записи и запуска, вещи, которые вы хотите проверить с помощью FireBug и т. Д.

Скажем, первым шагом является список потенциальных причин, которые вы хотите расследовать.

Теперь вы должны решить, в каком порядке делать вещи.

Вы:

1. Исследовать причины в порядке, основанном на чувстве кишки?
2. Расследовать причины, от самой быстрой проверки до самой медленной проверки?
3. Предполагаете, что ошибка связана с этой функцией, и исследуете от наиболее специфичного для кода кода до наименее специфичного для кода кода?
4. Предположим, что это чужая ошибка, и исследовать от самого общего кода до вашего конкретного кода?
5. Что-то еще я не упомянул?

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

Есть мысли?

Answer 1

Я считаю, что стратегия Rubber Duck Debugging тоже работает хорошо.

Answer 2

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

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

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

Answer 3

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

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

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

Answer 4

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

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

Answer 5

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

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

Answer 6

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

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

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

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

Answer 7

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

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

Answer 8

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

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

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

Answer 9

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

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

Answer 10

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

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