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

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

ваш приложение номер версии, номер сборки и т. д.? Вам нужно это, чтобы точно определить, какую версию вы отлаживаете (или нет!).

Если вы можете использовать свое приложение (например, с помощью JMX, если вы находитесь в мире Java), то используйте соответствующую область. Храните статистику, например, запросы+Параметры, Время и т. д. Используйте буферы для хранения последних " n " запросов/ответов/версий объектов/чего угодно и выгружайте их, когда пользователь сообщает о проблеме.

Если вы не можете воспроизвести его, вы можете исправить его, но не можете знать, что вы его исправили.

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

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

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

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

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

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

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

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

вносить случайные изменения пока что-то не работает :-)

думаю. Трудный. Запрись, не допускай никаких вмешательств.

У меня однажды была ошибка, когда доказательством был шестнадцатеричный дамп поврежденной базы данных. Цепочки указателей были систематически скручены. Все программы пользователя и программное обеспечение нашей базы данных работали безупречно при тестировании. Я смотрел на него в течение недели (это был важный клиент), и после устранения десятков возможных идей я понял, что данные были распределены по двум физическим файлам, и повреждение произошло там, где цепочки пересекали границы файлов. Я понял, что если операция резервного копирования/восстановления не удалась в критический момент, два файла могут оказаться "не синхронизированными", восстановленными в разные моменты времени. Если затем запустить одну из программ клиента на уже поврежденных данных, то получится именно та цепочка указателей, которую я видел. Затем я продемонстрировал последовательность событий, которая точно воспроизводила коррупцию.

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

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

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

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

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

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

предполагая, что вы уже добавили все журналы, которые, по вашему мнению, помогут, и это не так... на ум приходят две вещи:--1-->

1. работать в обратном направлении от симптома. Подумать про себя.. "если бы я хотел произвести симптом, о котором сообщалось, какой бит кода мне нужно было бы выполнить, и как бы я до него добрался, и как бы я до него добрался?"D приводит к C приводит к B приводит к A. примите, что если ошибка не воспроизводима, то обычные методы не помогут. Я пришлось смотреть на код в течение многих часов с такого рода мыслительных процессов происходит, чтобы найти некоторые ошибки. Обычно это оказывается чем-то действительно глупо.

2. помните первый закон отладки Боба: если вы не можете найти что-то, это потому, что вы ищете в неправильном месте: -)

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

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

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

наконец, как сказал Дэвид, посмотрите на код.

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

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

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

в большинстве случаев я бы сказал, что программное обеспечение не сообщает вам правильные сообщения об ошибках, например, в случае java и c# отслеживает все исключения.. не поймать все, но держать точку, где вы можете поймать и войти. Ошибки пользовательского интерфейса трудно решить, если вы не используете инструменты удаленного рабочего стола. И большую часть времени это может быть ошибка даже в стороннем программном обеспечении.

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

поэтому я боюсь, что, вероятно, закрою ошибку как WORKSFORME (Bugzilla), а затем исправлю некоторые более ощутимые ошибки. Или делать то, что решит руководитель проекта.

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