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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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