Формирование отчета об ошибках

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

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

Почему важно сообщать об ошибках и кто это делает

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

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

Тестировщиком реально стать даже без опыта в IT. Для этого пройдите курс Skypro «Инженер по тестированию». Научитесь писать тестовую документацию и составлять отчеты, тестировать веб- и мобильные приложения и API, освоите нужные инструменты. Внутри — мастер-классы с реальными рабочими задачами, домашки и разборы от наставника. Создадите четыре проекта для портфолио и получите диплом гособразца.

Основные принципы

Правильные отчеты помогают программистам быстрее исправлять ошибки. Детали зависят от типа багов. Но есть несколько основных принципов — что и как включать в баг-репорт, чтобы заранее снять вопросы разработчиков.

Указывайте:

1️⃣ Только одну ошибку на отчет. Это золотое правило, потому что так гораздо проще исправлять баги. Легче отслеживать статус отдельных отчетов и выставлять приоритеты задач, распределять работу между несколькими разработчиками. Да и меньшее количество информации проще запомнить и проанализировать.

2️⃣ Место интерфейса программного обеспечения, в котором возникла ошибка. Опишите экран, на котором находитесь, состояние интерфейса. Включите URL-адрес страницы, если это веб-приложение.

3️⃣ Действия в программе. Пошагово опишите действия, которые выполняли перед тем, как столкнулись с ошибкой. Это важно: может оказаться, что некорректное поведение программы началось до того, как вы его заметили.

4️⃣ Ожидания. Поведение программы может быть некорректным с точки зрения общей логики или вашего личного опыта — указывайте не только очевидные отказы выполнения и неверные результаты вычислений. Программы создают, чтобы облегчить пользователям жизнь, а не заставлять их подстраиваться под готовый результат.

5️⃣ Скриншот или запись экрана с ошибкой. Есть риск ошибиться, когда пишешь отчет об ошибке. Это значительно усложнит работу команды разработки. Визуальные материалы — более точный способ указать на проблему, чем просто описать ее.

6️⃣ Техническую информацию. То есть вашу операционную систему, браузер, тип устройства — персональный компьютер, мобильный телефон или планшет. А еще тип устройства ввода — клавиатуру, мышь, сенсорный экран и прочее. Будут полезны и параметры монитора, чтобы исправить ошибки в отображении пользовательского интерфейса.

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

8️⃣ Можете ли вы воспроизвести проблему. То есть происходит ли одно и то же каждый раз, когда вы пытаетесь выполнить задачу. Эта информация поможет разработчику найти причину ошибки.

9️⃣ Пробовали ли исправить проблему. Есть причина, по которой айтишник всегда спрашивает: «Вы пробовали выключить и снова включить?» или «Пытались ли обновить веб-страницу?». Перезагрузка может быть простым способом исправить проблему. Если она не исчезает — это дает много информации. Укажите, и это сэкономит время на последующее обсуждение проблемы.

🔟 Насколько проблема влияет на работу. Обычно серьезность варьируется от очень высокой (полностью останавливает работу) до очень низкой (визуальные недочеты). Эта информация поможет командам разработчиков расставить приоритеты, определить порядок, в котором устранять ошибки.

Основные элементы

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

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

👉 Резюме — краткое обозначение проблемы, причина и тип ошибки.

👉 Описание — подробности и любые сведения, которые помогут локализовать и исправить ошибку.

👉 Вложения — любые визуальные или другие материалы.

👉 Срок выполнения — если важно, чтобы ошибку исправили к определенной дате.

👉 Критичность — комментарий, насколько баг мешает нормальной работе приложения.

Часто выделяют следующие уровни критичности ошибок:

☝ Блокирующий (Blocker) — полностью блокирует нормальную работу программы, нужно исправить как можно быстрее.

☝ Критический (Critical) — сильно искажает логику приложения и значительно осложняет работу с ним.

☝ Значительный (Major) — затрагивает только отдельные элементы программы, существенно мешает работать.

☝ Незначительный (Minor) — либо не сильно влияет на работу программы, либо проявляется редко.

☝ Тривиальный (Trivial) — относится к визуальным недочетам в интерфейсе: опечатки, неудобные цвета и прочее.

Жизненный цикл

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

💡 Новый — только создан, ждет проверки разработчиком.

💡 Принят — отчет проверили, проблему подтвердили.

💡 Отклонен — отчет проверили, но команда разработки отказалась работать по нему. Например, потому что ошибку не удалось повторить. Или то, что показалось ошибкой, — нормальное поведение программы. Или проблему уже устранили, когда работали над другим отчетом.

💡 Назначен — ошибку передали исполнителю.

💡 В работе — разработчик исправляет ошибку.

💡 Проверяется — исполнитель закончил работу, результат проверяет старший специалист.

💡 Закрыт — ошибку исправили, результат доступен пользователям.

Системы для отчетов об ошибках

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

Такие программы называют баг-трекерами. Чаще всего они — часть более сложных систем: управления проектами или исходным кодом приложения.

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

К наиболее распространенным системам управления проектами относят:

• Jira.
• YouTrack.
• Redmine.

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

К основным системам управления исходным кодом относят:

• GitHub.
• GitLab.
• Bitbucket.

Интерфейсы и функции систем довольно сильно отличаются, но для работы с отчетами все предоставляют базовый набор функций:

✔️ форма создания отчета об ошибке с полями для ввода основных элементов;

✔️ управление состоянием и параметрами;

✔️ форма обсуждения, в которой команда задает вопросы и оставляет комментарии, указывает дополнительные детали;

✔️ уведомление об изменениях через имейл или другую систему обмена сообщениями.

У части баг-трекеров есть публичное голосование. Пользователи голосуют за или против бага: так повышают или понижают его приоритет.

Главное

• Баг-репорт — специальный вид отчета о неисправности в программном обеспечении или веб-сайте. Баг-репорт готовят тестировщики или специалисты из команды по контролю качества.
• Оформление баг-репорта сильно влияет на скорость, с которой исправят ошибки, на итоговый результат. Указывайте причину и тип ошибки, подробности, срок выполнения, критичность. Прикладывайте скриншоты или запись экрана.
• Прописывайте, пробовали ли исправить проблему, насколько она влияет на работу. Указывайте операционную систему, браузер, тип устройства, параметры монитора.
• Есть системы, с которыми проще создавать баг-репорты и управлять ими. Основные: Jira, YouTrack, Redmine, GitHub, GitLab, Bitbucket.

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

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

Пример одной из свободных систем
отслеживания ошибок с веб-интерфейсом.
является Bugzilla (разработка
компании Mozilla). Данная
система очень проста и популярна в
использовании [10].

Подобная
система обеспечивает следующие функции:

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

• система
  уведомления о появлении новых ошибок,
  об изменении статуса известных в системе
  ошибок (как правило, это уведомления
  по электронной почте);

• отчеты
  об актуальных ошибках по компонентам
  системы, по интервалам времени, по
  группам разработчиков и разработчикам;

• информация
  об истории ошибки (в том числе отслеживание
  похожих ошибок, отслеживание повторного
  возникновения ошибки);

• правила
  доступа к ошибкам тех или иных категорий;

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

Существуют основные виды продвижения
ошибки (на англ. «bug») по
системе (на англ. «Defect
flow»)(см. рисунок 6).

Рисунок 6 — Defect
flow

При поступление ошибки в систему, из
любого источника (заказчик, разработчик,
тестировщик), баг принимает статус new
(пер. с англ. «новый»). Затем рассматривается
программистом его описание и: или ошибка
решается (на англ. «resolve»)
или ей ставится статус duplicated
(пер. с англ. «дубль»), что означает, что
данная ошибка уже была и на данном этапе
решается, или же ей ставится статус
invalid (пер. с англ.
«необоснованный»)- неверное описание,
такой ошибки не существует. После всего
этого командой тестировщиков данная
ошибка перепроверяется и закрывается
(на англ. «verify») в случае,
если она больше не повторяется, или
переоткрывается (на англ. «reopen»), если
изменения все равно приводят к ошибке.

В отчете об ошибки необходимо соблюдать
некоторые правила:

1. В отчете должна быть с самого начала
понятна суть ошибки.

2.Должны быть четко понятны шаги
воспроизведения.

3.Должен быть известен альтернативный
правильный вариант поведения.

4. Указана версия и приоритет данной
ошибки.

Соседние файлы в предмете [НЕСОРТИРОВАННОЕ]

• #
• #
• #
• #
• #
• #
• #
• #
• #
• #
• #

Отображение ошибок

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

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

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

• ИТ-отделы компаний клиентов, а также компании, осуществляющие внедрения продуктов 1С: имеют возможность быстрого получения информации об ошибках и возможность проинформировать пользователя о том, куда обращаться для решения проблемы.

Сообщение об ошибке

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

Декларативная настройка текста сообщения об ошибке

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

Отчет об ошибке

Сообщение об ошибке может содержать ссылку для автоматического формирования отчета об ошибке. Доступно как интерактивное, так и программное формирование отчета. Программно можно добавлять в отчет свои вложения и объекты. Отчет об ошибке можно сохранить на диск или отправить в сервис регистрации ошибок.

Сервис регистрации ошибок

Сервис регистрации ошибок — внешний по отношению к платформе компонент, представляющий собой набор НТТР-сервисов с определенными интерфейсами. Он может быть реализован с помощью любой подходящей технологии. Например, это может быть информационная база «1С:Предприятия» с набором HTTP-сервисов.

Перейти к содержанию

Отчет об ошибке (программирование)

Введение

В программировании отчёт об ошибке (англ. error report или crash report) — это файл, содержащий техническую информацию об исключительной ситуации (исключении), произошедшем в программе на компьютере пользователя. В терминологии программирования критическая ошибка, которая приводит к аварийному завершению программы, также называется крэшем (англ. crash).

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

Создание отчета об ошибке

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

Mac OS X

В Mac OS X cуществует стандартная программа — сборщик отчетов об ошибке: /System/Library/CoreServices/Crash Reporter.app. Crash Reporter.app отправляет креш-логи, стандартные для ОС Unix, в компанию Apple Computer, где эти логи анализируют их инженеры. В верхнем поле окна отчета об ошибке содержится креш лог, а в нижнем пользователь может ввести свои комментарии, например, рассказать что он делал в момент, когда произошел креш. Пользователи также могут скопировать лог и отправить его разработчику ПО для анализа. Crash Reporter.app работает в трех основных режимах в случае ошибки: ничего не делать, вывести сообщение «Application has crashed» или вывести окно отчета об ошибке.

Windows

Microsoft Windows XP включает в себя службу отправки отчетов об ошибке, называемую Windows Error Reporting (неформально называемую Dr. Watson), которая позволяет оправить отчет об ошибке в компанию Microsoft для онлайн-анализа. Информация отправляется в централизованную базу данных, управляемую Microsoft. Отчет содержит необходимую информацию, которая позволяет разработчику диагностировать причину ошибки и исправить ее.

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

GNOME

На платформе GNOME для сбора и отправки отчетов об ошибке используется утилита Bug Buddy. Когда приложение, использующее библиотеки GNOME аварийно завершается, Bug Buddy генерирует снимок стека, используя отладчик gdb и предлагает пользователю отправить отчет в систему GNOME bugzilla. Пользователь может добавить свой комментарий и посмотреть, что содержится в отчете.

KDE

Утилита для отправки отчетов об ошибках в KDE называется Dr. Konqi.

Mozilla

Talkback

(также известный как Quality Feedback Agent) являлся утилитой для отправки сообщений об ошибках в программном обеспечении Mozilla вплоть до версии 1.8.1 для отправки отчетов об ошибках на централизованный сервер.^[1] Talkback является проприетарным ПО, на которое Mozilla Corporation получила лицензию у компании SupportSoft. Когда продукты Mozilla (например Mozilla Firefox, Mozilla Thunderbird) аварийно завершали свою работу, агент Talkback предлагал пользователю ввести описание ошибки. Talkback не заменет собой встроенной в операционную систему программы для отправки отчетов об ошибке, которая, запускается наряду с агентом Talkback. Talkback был заменен на программу Breakpad в браузере Firefox начиная с версии 3.

Breakpad

Breakpad (ранее также известный как Airbag) — это замена Talkback. Он является ПО с открытым исходным кодом. Breakpad разрабатывается совместно Google и Mozilla, и используется в текущих продуктах, основанных на движке Mozilla, таких как Firefox или Thunderbird.^[2][3] Этот продукт имеет большое значение, так как это первая мультиплатформенная утилита с открытым исходным кодом, предназначенная для отправки отчетов об ошибках.

Начиная с 27 мая 2007, Breakpad включен в стволовые сборки (trunk builds) Firefox 3 для Windows NT и Mac OS X, а также, несколько недель спустя, в Linux.^[4]

Ubuntu

Вместе с релизом Ubuntu 6.10, Ubuntu включает утилиту Apport^[5].

Apport перехватывает процессы, в которых произошло исключение и которые готовы создать дамп ядра (core dump), и записывает отчеты об ошибках в определенное место. Затем специальный демон, предлагает пользователю отправить отчеты в Ubuntu для их анализа.^[6]

World of Warcraft

World of Warcraft — еще одна программа, использующая свое собственное средство доставки отчетов об ошибке, называемое «Error Reporter». Однако данная утилита не всегда перехватывает исключения; иногда вместо него вызывается стандартная утилита-креш репортер, встроенная в ОС. Известно, что Error Reporter иногда сам завершается аварийно в процессе отправки отчета об ошибке.

CrashRpt

Еще одной библиотекой для доставки отчетов об ошибке в операционной системе Windows является CrashRpt^[7]. Библиотека CrashRpt позволяет отлавливать исключения в программах, созданных в Microsoft Visual C++ и работающих в Windows. Библиотека распространяется по «новой» лицензии BSD.

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

Cмотрите также

• Core dump
• Баг
• Обработка исключений

Ссылки

1. ↑ Mozilla Talkback server. Проверено 21 сентября 2006.
2. ↑ Deploying the Airbag. BSBlog (Mozilla developer Benjamin Smedberg’s weblog).
3. ↑ Using Breakpad with Gran Paradiso (1.9a3). BSBlog (Mozilla developer Benjamin Smedberg’s weblog).
4. ↑ Bug 381099 – Turn on crash reporting by default (Win+Mac), mozilla.org bug tracker]
5. ↑ EdgyReleaseNotes. Проверено 14 февраля 2007.
6. ↑ Apport. Ubuntu Wiki. Проверено 14 февраля 2007.
7. ↑ CrashRpt Project Page.

Если Вы зафиксировали какую-либо ошибку в работе WCS, и данная ошибка устойчиво воспроизводится на Вашем сервере, отчет об ошибке должен быть подготовлен следующим образом:

Формирование отладочных логов и дампа трафика

1. Включите вывод отладочной информации в лог, добавив в файл настроек /usr/local/FlashphonerWebCallServer/conf/flashphoner.properties строку

2. Перезапустите WCS командой

sudo systemctl restart webcallserver

3. Запустите сбор pcap-дампа трафика командой

sudo tcpdump -i any -s 0 -B 10240 -w log.pcap

4. Воспроизведите зафиксированную Вами ошибку

5. Остановите сбор дампа трафика нажатием Ctrl+C в окне терминала, где был запущен tcpdump.

Сбор отладочных логов в ручном режиме

1. Перейдите к расположению сегодняшних логов, например

cd /usr/local/FlashphonerWebCallServer/logs/client_logs/2018-04-19

2. Выведите список логов на экран, отсортировав его по времени модификации командой

Примерный результат:

├── 13i19gto2ob34utrfs6v2er1it-11-11-11
│ ├── client-13i19gto2ob34utrfs6v2er1it-2018.04.19.12.16.08-1524118568678.report
│ └── flashphoner.log
├── 7g2hq7ah5sda3r108917v15k4c-11-10-46
│ ├── client-7g2hq7ah5sda3r108917v15k4c-2018.04.19.12.16.07-1524118567482.report
│ ├── flashphoner.log
│ └── flashphoner.log.2018-04-19-11

Здесь
13i19gto2ob34utrfs6v2er1it-11-11-11 — каталог с отладочным логом для первого клиентского соединения.
7g2hq7ah5sda3r108917v15k4c-11-10-46 — каталог с отладочным логом для второго клиентского соединения

Сбор отладочных логов при помощи скрипта report.sh

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

cd /usr/local/FlashphonerWebCallServer/tools
sudo ./report.sh --sysinfo --conf --tar

Скрипт соберет текущие логи и отобразит результат:

Scheduled report:

* logs
* netstat
* lsof
* pmap
* jstack
* sysinfo
* conf
* tar

Progress:

[DONE] logs
[DONE] netstat
[DONE] lsof
[DONE] pmap
[DONE] jstack
[DONE] sysinfo
[DONE] conf
[DONE] tar
Report complete in 15 seconds. Check /usr/local/FlashphonerWebCallServer/report/report-2019-07-17-10-28-35

В данном примере, архив с собранными логами располагается по следующему пути

/usr/local/FlashphonerWebCallServer/report/report-2019-07-17-10-28-35.tar.gz

Сбор статистики работы WCS

Начиная со сборки 5.2.967, в отчет может быть включена текущая статистика работы сервера:

cd /usr/local/FlashphonerWebCallServer/tools
sudo ./report.sh --sysinfo --conf --stats --tar

Формирование отчета об ошибке

Отчет об ошибке должен включать:

• Отладочные логи
• Файл /usr/local/FlashphonerWebCallServer/logs/server_logs/flashphoner.log
• Каталог /usr/local/FlashphonerWebCallServer/conf
• Результат выполнения команды ifconfig на Вашем сервере
• Результат выполнения команды iptables -L  на Вашем сервере

или результат выполнения скрипта для сбора логов

Также отчет должен включать собранный дамп трафика

Отправка отчета

Отправьте отчет об ошибке на адрес техподдержки support@flashphoner.com. В случае, если Вы создавали тему на форуме технической поддержки Flashphoner, включите в письмо ссылку на эту тему.