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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Наконец, как сказал Дэвид, внимательно изучите код.

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

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

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

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

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

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

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

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

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

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