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

Question

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

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

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

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

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

Answer 1

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

1. запросить дамп памяти
2. установить удаленный отладчик на клиентском компьютере
3. добавить код трассировки в сборки
4. добавить код регистрации для отладки
5. добавить счетчики производительности
6. добавляет параметры конфигурации к различным фрагментам подозрительного кода, чтобы я мог включать и выключать функции
7. переписать и реорганизовать подозрительный код
8. попытаться повторить проблему локально на другой ОС или компьютере
9. использовать средства отладки, такие как верификатор приложений
10. использовать сторонние инструменты генерации нагрузки
11. написать собственные инструменты моделирования для генерации нагрузки при сбое вышеуказанного
12. использовать инструменты, такие как Glowcode, для анализа утечек памяти и проблем с производительностью
13. переустановить клиентский компьютер с нуля
14. получить дампы реестра и применить их локально
15. использовать инструменты реестра и наблюдения за файлами

В конце концов, я обнаружил, что ошибка просто перестает трепетать от моей настойчивости. Или клиент понимает, что это, вероятно, проблема установки или настройки на стороне компьютера или клиента.

Answer 2

Обычно помогает расширенная регистрация.

Answer 3

Самый простой способ - это всегда видеть клиента в действии (при условии, что он легко воспроизводится клиентом). Часто проблемы возникают из-за проблем с компьютерной средой клиента, конфликтов с другими программами и т. Д. - это детали, которые вы не сможете уловить на своем устройстве разработчика. Так что посещение сайта может быть полезным; но если это не удобно, такие инструменты, как RealVNC , также могут помочь вам увидеть, как клиент "делает свое дело".

(наблюдение за клиентом в действии также позволяет вам поймать его в любой WTF момент, который он может иметь)

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

Answer 4

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

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

Покупатели также обычно (как бы) впечатлены тем, что я узнаю об их проблеме, как только они столкнутся с ней!

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

Answer 5

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

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

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

Answer 6

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

Answer 7

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

Телепатия также была бы полезна ...

Answer 8

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

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

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

Answer 9

У меня тоже были эти проблемы. Мое решение состояло в том, чтобы добавить много журналов и предоставить клиенту отладочную сборку со всей возможной отладочной информацией. Затем убедитесь, что доктор Ватсон (это было в Windows NT) создал дамп памяти с достаточным количеством информации. После загрузки дампа памяти в отладчике я смог узнать, где и почему он вышел из строя.

РЕДАКТИРОВАТЬ: О, это, очевидно, работает, только если приложение принудительно завершается ...

Answer 10

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

Начиная с

сломалось!

до

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

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

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