Как Вы воспроизводите ошибки, которые происходят эпизодически?

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

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

Что общие подсказки должны воспроизвести этот вид ошибки?

62
задан Ash 26 March 2010 в 05:05
поделиться

27 ответов

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

Большинство людей инстинктивно говорят: "Добавьте больше логов", и это может быть решением. Но для многих проблем это только ухудшит ситуацию, поскольку протоколирование может изменить временные зависимости настолько, что проблема станет более или менее частой. Изменение частоты от 1 на 1000 до 1 на 1 000 000 не приблизит вас к истинному источнику проблемы.

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

27
ответ дан 24 November 2019 в 16:43
поделиться

Тонны журналирования и осторожности Код ревью - ваши единственные варианты.

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

2
ответ дан 24 November 2019 в 16:43
поделиться

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

25
ответ дан 24 November 2019 в 16:43
поделиться

Я бы посоветовал записать все, что пользователь делал делает. Если у вас есть, скажем, 10 таких отчетов об ошибках, вы можете попытаться найти что-то, что их связывает.

1
ответ дан 24 November 2019 в 16:43
поделиться

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

2
ответ дан 24 November 2019 в 16:43
поделиться

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

2
ответ дан 24 November 2019 в 16:43
поделиться

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

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

2
ответ дан 24 November 2019 в 16:43
поделиться

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

Edit: еще немного мыслей: если это приложение с графическим интерфейсом, запускайте тесты с помощью инструмента автоматизации qa, который позволяет воспроизводить макросы. Если это приложение служебного типа, попробуйте придумать хотя бы предположение о том, что происходит, а затем программно создать «странные» шаблоны использования, которые будут выполнять код, который вы подозреваете. Создавайте более высокие, чем обычно, нагрузки и т. Д.

4
ответ дан 24 November 2019 в 16:43
поделиться

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

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

И это не гарантирует, что мы все вместе сможем его найти ...

1
ответ дан 24 November 2019 в 16:43
поделиться

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

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

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

2
ответ дан 24 November 2019 в 16:43
поделиться

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

2
ответ дан 24 November 2019 в 16:43
поделиться

Наряду с большим терпением, тихой молитвой и проклятиями вам понадобятся:

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

HTH.

2
ответ дан 24 November 2019 в 16:43
поделиться

Есть большая вероятность, что ваше приложение является MTWIDNTBMT (многопоточность, когда не требуется многопоточность) или, может быть, просто многопоточным (чтобы быть вежливым). Хороший способ воспроизвести спорадические ошибки в многопоточных приложениях - это разбросать такой код вокруг (C #):

Random rnd = new Random();
System.Threading.Thread.Sleep(rnd.Next(2000));

и / или this:

for (int i = 0; i < 4000000000; i++)
{
    // tight loop
}

, чтобы имитировать потоки, выполняющие свои задачи в разное время, чем обычно, или занимающие процессор на длинные дистанции.

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

5
ответ дан 24 November 2019 в 16:43
поделиться

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

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

2
ответ дан 24 November 2019 в 16:43
поделиться

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

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

1
ответ дан 24 November 2019 в 16:43
поделиться

Поскольку это не зависит от языка, я упомяну несколько аксиом отладки.

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

Другой пользователь, тот же компьютер? Тот же пользователь, другой компьютер? Является ли событие сильно периодическим? Изменяет ли перезагрузка периодичность?

К вашему сведению. Однажды я видел ошибку, с которой столкнулся один человек. Я буквально имею в виду человека, а не учетную запись пользователя. Пользователь A никогда не увидит проблему в своей системе, пользователь B сядет за эту рабочую станцию ​​, войдет в систему как пользователь A и сможет немедленно воспроизвести ошибку. У приложения не должно быть никакого мыслимого способа узнать разницу между физическим телом в кресле. Однако-

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

ЛЮБОЕ отличие, которое влияет на поведение ошибки, должно быть исследовано, даже если оно не имеет смысла.

7
ответ дан 24 November 2019 в 16:43
поделиться

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

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

8
ответ дан 24 November 2019 в 16:43
поделиться

На этот вопрос нет общего хорошего ответа, но вот что я обнаружил:

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

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

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

  4. Дважды проверьте каждое предположение. Так много раз я видел, как проблема не решалась быстро, потому что некоторые общие вызовы методов не исследовались дополнительно, поэтому проблема просто считалась неприменимой. «Ой, это должно быть просто». (См. Пункт 1).

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

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

21
ответ дан 24 November 2019 в 16:43
поделиться

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

1
ответ дан 24 November 2019 в 16:43
поделиться

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

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

Для проектов .NET. Вы можете использовать Elmah (модули и обработчики регистрации ошибок) для отслеживания вашего приложения на предмет невыявленных исключений, его очень просто установить и он предоставляет очень удобный интерфейс для просмотр неизвестных ошибок

http://code.google.com/p/elmah/

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

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

Они в основном выходят ночью .... в основном

1
ответ дан 24 November 2019 в 16:43
поделиться

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

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

1
ответ дан 24 November 2019 в 16:43
поделиться

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

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

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

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

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

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

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

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

2
ответ дан 24 November 2019 в 16:43
поделиться

Какая среда разработки? Для C ++ лучшим вариантом может быть запись / воспроизведение VMWare Workstation, см. http://stackframe.blogspot.com/2007/04/workstation-60-and-death -of.html

Другие предложения включают проверку трассировки стека и тщательный обзор кода ... серебряной пули действительно нет :)

3
ответ дан 24 November 2019 в 16:43
поделиться

Это сработало для действительно странных хайзенбагов. (Я также рекомендовал бы получить копию "Отладки" Дэйва Арганса, эти идеи частично являются производными от его идей!)

(0) Проверьте оперативную память системы, используя что-нибудь вроде Memtest86!

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

Он не дает сбоев в 100% случаев, поэтому вы должны делать это чаще.

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

Посмотрим, не сработает ли он. Чаще ли он дает сбой?

Ведите надлежащие записи тестов и меняйте только одну переменную за раз!

В худшем случае вы используете приспособление и тестируете в течение нескольких недель, чтобы получить значимую статистику. Это трудно; но помните, приспособление делает свою работу.

У меня нет потоков и только один процесс, и я не общаюсь с оборудованием

Если в системе нет потоков, нет взаимодействующих процессов и нет контактов с оборудованием; это сложно; heisenbugs, как правило, являются синхронизацией, но в случае отсутствия потоков и процессов более вероятно, что это будут неинициализированные данные или данные, используемые после выпуска, либо в куче, либо в стеке. Попробуйте воспользоваться чекером типа valgrind.

Для многопоточных / многопроцессорных проблем:

Попробуйте запустить его на другом количестве процессоров. Если он работает на 1, примерьте 4! Попробуйте принудительно переключить систему с 4 компьютерами на 1. В большинстве случаев это гарантирует, что все будет происходить по очереди.

Если есть потоки или взаимодействующие процессы, это может избавить от ошибок.

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

И наоборот, попробуйте медленнее работать с временными интервалами.

Затем вы запускаете испытательное приспособление с подключенным отладчиком (-ами) повсюду и ждете, пока испытательное приспособление не остановится из-за ошибки.

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

1
ответ дан 24 November 2019 в 16:43
поделиться

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

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

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

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

Это было легче исправить, чем проблемы с потоками, но всё равно интересно, я думаю.

1
ответ дан 24 November 2019 в 16:43
поделиться

Используйте расширенный репортер сбоев. В среде Delphi у нас есть EurekaLog и MadExcept.Другие инструменты существуют в других средах. Или можно диагностировать дамп ядра. Вы ищете трассировку стека, которая покажет вам, где он взорвался, как он туда попал, что находится в памяти и т. Д. Также полезно иметь снимок экрана приложения, если это связано с взаимодействием с пользователем. И информация о машине, на которой произошел сбой (версия ОС и патч, что еще запущено в данный момент и т. Д.). Оба упомянутых мною инструмента могут это сделать.

Если что-то происходит с несколькими пользователями, но вы не можете воспроизвести это, а они могут, сядьте с ними и посмотрите. Если не видно, поменяйте местами - вы «едете», а вам говорят, что делать. Таким образом вы обнаружите тонкие проблемы юзабилити. двойной щелчок по кнопке с одним щелчком, например, инициирование повторного входа в событие OnClick. Что-то в этом роде. Если пользователи удаленные, используйте WebEx, Wink и т. Д., Чтобы записать их сбой, чтобы вы могли анализировать воспроизведение.

0
ответ дан 24 November 2019 в 16:43
поделиться
Другие вопросы по тегам:

Похожие вопросы: