«Работает на моей машине» - Как исправить невоспроизводимые ошибки?

Question

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

( Извинения Джеффу за «заимствование» значка)

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

• Запрашивать у клиента все больше и больше контекста: (systeminfo)
• Файлы журналов из нашего приложения
• Специальные тесты с клиентом для попытки изменить поведение
• Предоставление клиенту новой сборки с дополнительной диагностикой
• Думая о проблеме в бане ...
• Посещение объекта (при условии, что клиент где-то теплый и солнечный)

Существуют ли установленные процедуры или другие методы, которые кто-либо использует для решения подобных проблем?

Answer 1

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

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

Answer 2

Я думаю, что следование за действиями, которые предпринял пользователь, может привести нас к причинам отказа или выборочных отказов. Но в большинстве случаев пользователи не могут точно описать взаимодействие с приложениями, автоматическое создание снимков экрана (если это приложение для настольного компьютера. Для приложения .net вы можете проверить Jeff's UnhandledExceptionHandler). Регистрация всех важных действий, которые изменяют состояние объектов, также может помочь нам понять это.

Answer 3

Второй пилот (при условии, что клиент где-то холодный и дождливый:)

Answer 4

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

Кроме того, одним из наиболее важных подходов является ведение журнала с богатой информацией. Я также использую много перечислений для описания состояния процесса в зависимости от рассматриваемого сценария. например, я использовал «Инициировано», «Триггер», «Запуск», «Ожидание восстановлено» и т. д. для описания состояний расписаний и сохранения их в БД на разных этапах.

Answer 5

Просто короткий анекдот (отсюда и «вики сообщества»): на прошлой неделе я подумал, что в приложении Django была умная идея импортировать модуль pprint для красивой печати данных Python только , если DEBUG Правда:

if settings.DEBUG:
    from pprint import pprint

Затем я использовал здесь и там команду pprint в качестве оператора отладки:

pprint(somevar) # show somevar on the console

После окончания работы я протестировал приложение с настройкой DEBUG=False. Вы можете догадаться, что произошло: сайт сломался с ошибками HTTP500 повсюду, и я не знал, почему, потому что нет обратной трассировки, если DEBUG равно False. Я был озадачен тем, что ошибки волшебным образом исчезли, если я снова переключился в режим отладки.

Мне потребовалось 1-2 часа, чтобы поместить операторы print по всему коду, чтобы обнаружить, что код вылетает точно в указанной выше строке pprint(). Затем мне потребовалось еще полчаса, чтобы убедить себя прекратить стучать головой по столу.

Теперь приходит мораль истории:

1. Не каждая вещь, которая на первый взгляд выглядит как умная идея, настолько умела в конце.

2. Важным моментом, который необходимо учитывать при отладке этих ошибок, являются все параметры конфигурации и переключатели платформы , которые сам код делает самостоятельно. Это может быть намного больше, чем просто некоторые пользовательские настройки. Документ хороший, если вы сделаете предположение о платформе пользователя (например, если вы тестируете только для Win / Mac / Linux, будет ли ваш код зависать на BSD или Solaris?)

Приветствия

Answer 6

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

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

Answer 7

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

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

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

При этом учтите:

1) Какие различия существуют между этой системой и другими работающими системами.

2) Что недавно изменилось в вашем продукте или конфигурации клиентов, что привело к возникновению проблемы.

Привет

Answer 8

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

Answer 9

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

Вот типичные проблемы, которые я видел, которые приводят к типам проблем, которые вы описываете:

1. Среда настроена неправильно (например, отсутствуют переменные среды, источники данных и т. Д.).
2. Приложение не полностью развернуто (например, схема базы данных не развернута).
3. Разница в конфигурации операционной системы (кодировка символов по умолчанию является для меня самой распространенной причиной).

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

Answer 10

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

Для приложений .Net мы также были Trace.Writeline, тогда мы можем заставить пользователя запустить DbgView и отправить нам вывод.