Рекомендации по автоматическому регистрации неожиданных ошибок/трассов стека.

Question

Мы рассмотрели автоматически регистрировать все неожиданные ошибки клиента в нашем трекере ошибок. Для ссылки наше приложение записано в Java/GWT/Guice/Hibernate/Jetty, а наш трекер ошибок является размещенной версией Fogbugz, которая может создавать ошибки программатически или по электронной почте.

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

Answer 1

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

Answer 2

Вы уверены, что хотите это сделать?

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

Как насчет этого? Код вашего приложения так, чтобы каждый раз, когда было выпущено исключение, вы собираете информацию о клиенте (IP, вход в систему, версии приложения и т. Д.) и отправляете этот + стек трассировку (или весь объект исключения .toString ()) по электронной почте себе (или команда разработчиков).

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

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

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

Надеюсь, это помогло!

Answer 3

Jira поддерживает создание автоматизированных вопросов с использованием так называемого Сервисы: документация.

У кого -нибудь есть предлагаемый способ обработки автоматического создания ошибок ...?

Ну, у меня есть. Не делай этого.

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

• А наименьший контрпродуктивный Я могу себе представить, что будет что -то вроде создания специальной категории ошибок или экземпляра трекера, так что только тестеры могут видеть и использовать ее.
  В этом «Песочнице» ошибки с автоматическими созданиями могут быть назначены тестерам, которые позже пройдут анализируется и агрегирована Отчеты об ошибках разработчикам.
  И даже в этом случае я бы рекомендовал обратить пристальное внимание на то, что пользователи (тестеры) говорят о системе. Если они, скажем, начнут жаловаться на систему, подумайте о том, чтобы попробовать ручной способ ведения дел.