Есть ли хорошие стратегии для работы с «невоспроизводимыми» ошибками?

Question

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

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

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

Answer 1

Вы говорите о проблемах, которые можно воспроизвести, но только в некоторых системах. С ними легко обращаться:

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

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

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

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

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

Answer 2

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

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

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

Answer 3

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

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

Answer 4

Принятый ответ - лучший общий подход. На высоком уровне стоит взвесить важность исправления ошибки в сравнении с тем, что вы можете добавить в качестве функции или улучшения, которое принесет пользу пользователю. Может ли «невоспроизводимая» ошибка занять два дня, чтобы исправить? Может ли быть добавлена ​​функция в это время, которая дает пользователям больше преимуществ, чем это исправление ошибки? Возможно, пользователи предпочтут эту функцию. Иногда я зациклен как разработчик на недостатках, которые я вижу, и затем пользователей просят дать отзыв, и никто из них не упоминает об ошибках, которые я вижу, но в программном обеспечении отсутствует функция, которую они действительно хотят !

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

Answer 5

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

Answer 6

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