Как вы воспроизводите ошибки, которые возникают спорадически?

Question

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

Отказ от ответственности: эта ошибка существует, и я видел ее. Это не pebkac или что-то подобное.

Каковы общие подсказки для воспроизведения такого рода ошибки?

Answer 1

Тонны регистрации и тщательного анализа кода - ваши единственные варианты.

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

Answer 2

все вышеперечисленное, плюс добавьте в него какого-нибудь полуслучайного софт-робота грубой силы и уберите много утверждений / подтверждений (c / c ++, вероятно, похожих на другие языки) через код

Answer 3

Допустим, я начинаю с производственного приложения.

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

2. Я повторяю шаг 1 до тех пор, пока у меня не будет хорошего представления о том, где я могу начать отладку кода в отладчике

3. Иногда количество итераций выполняемого кода является ключевым, но в других случаях это может быть взаимодействие компонента с внешней системой (база данных, конкретный пользовательский компьютер, операционная система и т. Д.). Потратьте некоторое время, чтобы настроить среду отладки, максимально соответствующую производственной среде. Технология VM является хорошим инструментом для решения этой проблемы.

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

5. Отладка, отладка, отладка. Если через несколько часов вы никуда не пойдете, сделайте перерыв и поработайте над чем-то не связанным некоторое время. Вернись со свежим умом и перспективой.

6. Если вы до сих пор никуда не попали, вернитесь к шагу 1 и сделайте еще одну итерацию.

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

Answer 4

Если вы работаете в Windows, и ваша "ошибка" - это сбой или какое-то повреждение в неуправляемом коде (C / C ++), тогда взгляните на Application Verifier от Microsoft. У инструмента есть несколько остановок, которые можно включить, чтобы проверить вещи во время выполнения. Если у вас есть представление о сценарии возникновения ошибки, попробуйте выполнить сценарий (или стрессовую версию сценария) при работающем AppVerifer. Обязательно включите pageheap в AppVerifier или попробуйте скомпилировать код с ключом / RTCcsu (см. http://msdn.microsoft.com/en-us/library/8wtf2dfz.aspx для получения дополнительной информации).

Answer 5

Модульные тесты. Тестирование ошибки в приложении часто ужасно, потому что там так много шума, так много переменных факторов. В общем, чем больше стог (сена), тем сложнее определить проблему. Творческое расширение вашей системы модульных тестов для охвата крайних случаев может сэкономить часы или даже дни просеивания

Сказав, что серебряной пули нет. Я чувствую твою боль.

Answer 6

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

Вы можете взглянуть на Дизайн по контракту

Answer 7

Попробуйте добавить код в свое приложение для автоматического отслеживания ошибки, как только она произойдет (или даже предупредить вас по почте / SMS)

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

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

Answer 8

наймите несколько тестеров!

Answer 9

@p.marino - недостаточно комментариев для комментария = /

tl; dr - сбои сборки из-за времени суток

Вы упомянули время суток, и это привлекло мое внимание. Однажды была ошибка, когда кто-то оставался на работе позже ночью, пытался строить и фиксировать перед тем, как уйти, и продолжал получать ошибку. В конце концов они сдались и пошли домой. Когда они поймали на следующее утро, он сработал нормально, они совершили (вероятно, следовало быть более подозрительным =]), и сборка сработала для всех. Неделю или две спустя кто-то остался с опозданием и неожиданно потерпел неудачу. Оказывается, в коде была ошибка, которая делала любую сборку после перерыва на 7 вечера>.>

Мы также обнаружили ошибку в одном редко используемом уголке проекта в январе этого года, которая вызвала проблемы с распределением между различными схемами, поскольку мы не учитывали разные календари, основанные на 0 И 1 месяц. Поэтому, если бы никто не запутался в этой части проекта, мы бы не нашли ошибку до января. 2011

Их было легче исправить, чем проблемы с многопоточностью, но я думаю, что они по-прежнему интересны.

Answer 10

Это варьируется (как вы говорите), но некоторые вещи, которые вам пригодятся, могут быть

• немедленно входит в отладчик, когда возникает проблема, и сбрасывает все потоки (или эквивалентный, такой как немедленный сброс ядра или что-то в этом роде).
• работает с включенным ведением журнала, но в остальном полностью в режиме выпуска / производства. (Это возможно в некоторых случайных средах, таких как c и rails, но не во многих других.)
• делать что-то, чтобы ухудшить условия на компьютере ... заставить малую память / высокую нагрузку / больше потоков / обслуживать больше запросов
• Убедитесь, что вы действительно слушаете то, что на самом деле говорят пользователи, столкнувшиеся с проблемой. Убедиться, что они на самом деле объясняют соответствующие детали. Похоже, это тот, который сильно ломает людей на поле. Попытка воспроизвести не ту проблему скучна.
• Привыкайте читать сборку, созданную оптимизирующими компиляторами. Это, кажется, иногда останавливает людей, и не применимо ко всем языкам / платформам, но может помочь
• Будьте готовы признать, что это ваша (разработчик) ошибка. Не попадайтесь в ловушку, настаивая на том, что код идеален.
• иногда вам нужно отследить проблему на машине, на которой она происходит.