Методология отслеживания ошибок

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

У меня есть несколько методов, чтобы дать мне нужные мне данные. Вот шаги, которые я сделал:

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

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

ОТВЕТЫ

Ответ 1

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

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

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

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

Ответ 2

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

Ответ 3

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

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

Ответ 4

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

https://store.techsmith.com/order/snagit.asp

Будьте терпеливы и работайте с ними (индивидуально) для улучшения коммуникации.

Ответ 5

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

Но большой вопрос: у вашего программного обеспечения слишком много ошибок? Часть их неудовлетворенности может быть связана с качеством программного обеспечения! Ваше упоминание о том, что сейчас помещается в петли try-catch, похоже, указывает на это.

Улучшение качества программного обеспечения.

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

  • Есть ли у вас тестеры, единственной целью которых является тестирование программного обеспечения?

  • Есть ли у вас документальный набор тестов и планов тестирования для тестеров?

  • У вас есть автоматические модульные тесты для всего вашего треда?

  • Есть ли у вас условные обозначения и стандарты кодирования, соглашения/стандарты требований/конструкции, соглашения и стандарты плана тестирования/тестирования, процесс для SDLC, анализ основных причин?

  • Есть ли у вас экспертные обзоры?

  • Есть ли у вас проверки, чтобы все проблемы, связанные с экспертными обзорами, были рассмотрены до перехода в тестовую/производственную среду?

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

Теперь о вашем первоначальном вопросе.

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

  • Улучшите ведение журнала, чтобы получить информацию после факта. Вы делаете это.

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

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

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

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

Ответ 6

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

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

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

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

Надеюсь, что это поможет.

Ответ 7

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

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

Ответ 8

Мы использовали rt для отчетов об ошибках пользователей, я имею в виду сообщения пользователями об ошибках, которые они находят, а не сообщения об ошибках в пользователях, конечно. Оптимальная вещь о rt заключается в том, что она может быть представлена ​​пользователям просто как адрес электронной почты. Инструкции примерно такие же простые, как можно: найдите ошибку, отправьте электронное письмо. По моему опыту это намного проще, чем Trac, Bugzilla и все остальное. Они хороши по-разному, но все они выглядят для большинства пользователей, подобно заполнению формы.

Ответ 9

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

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

Ответ 10

Существуют различные способы отслеживания сбоев приложений (.Net Specific) Windows и веб-приложения    1. В файле Global.asax.cs в режиме Application_Error записывайте журнал в текстовый файл, чтобы вы могли сортировать исключения со своей трассировкой стека и всеми вещами.    2. В обычном сценарии, отличном от .net Environment, вы можете создать общий метод, чтобы его можно было вызывать для записи журнала всякий раз, когда у вас есть исключение, означает в каждом try-catch или если есть какая-либо платформа для такого.

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

Также Nlog - хороший способ регистрации.

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

Надеюсь, что это поможет

Ответ 11

Следуйте этим правилам для ведения журнала исключений

  • Форма/страница, на которой произошла ошибка
  • Событие/метод
  • дата/время
  • Его трассировка стека
  • Сообщение об ошибке
  • Некорректный код
  • Пользователь
  • Номер строки, если возможно