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

Question

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

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

Answer 1

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

Answer 2

JIRA поддерживает автоматическое создание проблем с использованием так называемых сервисов : документации .

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

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

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

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

Answer 3

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

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

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

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

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

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

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