Какую информацию вы запрашиваете при решении проблемы на коробке клиента с помощью настольного приложения? - PullRequest
5 голосов
/ 01 марта 2010

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

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

То, что мы получили до сих пор:

  • Номер версии нашего приложения,
  • Номер версии ОС и ОС
  • Информация прокси
  • .NET версия и номер обновления
  • Информация, относящаяся к нашему приложению (например, версии данных)
  • Доступ и журналы ошибок

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

Редактировать: Уточнение: не спрашивать, какую информацию пользователь должен предоставить в случае ошибки, а какую информацию мы должны собрать программно ?

Ответы [ 3 ]

4 голосов
/ 01 марта 2010

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

2 голосов
/ 01 марта 2010

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

В аналогичной ситуации, несмотря на меньшее количество пользователей, наше приложение получило кнопку «Журналы пакетов для поддержки», которая создаст zip-файл со всеми файлами журнала и текущий открытый файл проекта, если таковой имеется. Вся остальная информация, которую вы описали, уже является частью одного из файлов журнала. Таким образом, клиент может удобно отправить нам ZIP-файл, что можно сделать из главного окна приложения, не открывая файл проекта или не подключаясь к сетевому интерфейсу, что является двумя основными моментами, когда что-то может пойти не так. Это делает это намного проще, чем полагаться на то, что пользователь предоставляет обратную связь «от руки».

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

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

  • Информация о пользователе / ​​учетной записи. Это может помочь с вопросами разрешения. Возможно, вы захотите включить такие вещи, как часовой пояс, локаль, тема Windows.
  • Конфигурация приложения, включая место его установки.
  • Как уже говорилось, текущий файл, с которым работает пользователь, потому что это может быть причиной проблемы.
  • Пользовательские настройки, то есть данные, которые приложение сохраняет для каждого пользователя. Видел странные вещи с этим. Список MRU также может быть полезен.
1 голос
/ 01 марта 2010

Помимо основного состояния приложения (версия, конфигурация и т. Д.), Наиболее важная информация, которую необходимо получить:

  • Шаги, необходимые для воспроизведения ошибки или ошибки, включая, если возможно, входные данные
  • Ожидаемый результат
  • Фактический объем производства
  • Контактная информация на случай, если вам понадобится последующее наблюдение (если ваше программное обеспечение используется анонимно)

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

...