Bugzilla

Материал из Национальной библиотеки им. Н. Э. Баумана
Последнее изменение этой страницы: 22:19, 23 октября 2016.
Bugzilla
Bugzilla-0d1d13253c39acc09666736956c77ffc.png
подпись
Разработчики: Dave Miller / Mozilla Foundation
Постоянный выпуск: 5.0 / 7 июля 2015
Предыдущий выпуск: 4.5.4 / 18 апреля 2014
Написана на: Perl[1]
Операционная система: Кросс-платформенный
Тип ПО: Багтрекер
Лицензия: Mozilla Public License
Веб-сайт http://www.bugzilla.org

Bugzilla (Багзилла) — свободная система отслеживания ошибок (багтрекинга) с веб-интерфейсом.

В 1998 году Bugzilla была выпущена как открытое программное обеспечение компанией Netscape. По состоянию на 2012 год разрабатывается фондом Mozilla Foundation.[2]

Приложения подобного рода позволяют разработчику или группам разработчиков отслеживать ошибки в приложениях и запросы на дополнение приложений новой функциональностью. Написанное на Perl, Bugzilla de-facto является стандартом для систем отслеживания ошибок в приложениях, служащая эталоном, с которой сравниваются другие системы со схожей функциональностью. Фактически, Bugzilla используется во многих корпорациях для разработки собственного программного обеспечения для корпоративных нужд.

Возможности Bugzilla

  • Интегрированная система безопасности с возможностью определения безопасности на уровне продуктов
  • Система зависимостей ошибок и вывод зависимостей ошибок в графическом виде
  • Развитая система составления отчетов
  • Стабильный, проверенный временем back-end на основе RDBMS
  • Обширная система конфигурирования
  • Очень понятный и хорошо продуманный протокол решения ошибок
  • API для электронной почты, XML, HTTP и консоли
  • Доступна интеграция с системами управления автоматического конфигурирования программного обеспечения, в том числе Perforce and CVS (через интерфейс электронной почты Bugzilla и скрипты для checkin/checkout)

Почему именно Bugzilla

  • Интегрированная система отслеживания ошибок уменьшает время простоя, увеличивает производительность и повышает удовлетворенность клиента от работы с их системами. Вместе с полным раскрытием информации, открытая система отслеживания ошибок позволяет производителям программного обеспечения поддерживать контакт со своими клиентами и реселлерами, для передачи сообщений об ошибках по всей цепи управления данными.
  • Многие корпорации также обнаруживают, что отслеживание ошибок уменьшает издержки, обеспечивая службе поддержки IT систему учета, телефонной поддержке - базы знаний, а всем - хорошо понятную систему для учета необычных проблем с системой или программным обеспечением.
  • Bugzilla может быть легко адаптирована к различным ситуациям. Развернутые в настоящее время инсталляции обеспечивают поддержку очередей обработки запросов в службу поддержки IT, управление внедрением менеджементом системы, отслеживание проблем возникающих при дизайне и разработке чипов (как до, так и после их производства), отслеживание проблем возникающих при разработке программного и аппаратного обеспечения такими грандами, как Redhat, Loki software, Linux-Mandrake и VA Systems. В связке с такими системами как CVS, Bonsai, или Perforce SCM, Bugzilla обеспечивает мощное, легкое в использовании решение для управления конфигурацией и проблемами возникающими при репликации.
  • Bugzilla может резко увеличить производительность труда и подотчетность работников, обеспечивая автоматизацию работы с документами и положительные отзывы на хороших исполнителей.
  • Поместите свой план дня в Bugzilla, и у вас появится запись, из которой вы можете экстраполировать этапы развития, предсказывать версии продукта предназначенные для интеграции, и используя тесную интеграцию Bugzilla с системой электронной почты, вы можете следовать за ходом дискуссии, ведущей к судьбоносным решениям.[3]

Атрибуты

подпись

Ключевым понятием системы является Bug (баг) — некоторое задание, запрос, рекламация по поводу ошибки в системе или просто сообщение, требующее обратной связи. Баги регистрируют и предоставляют заинтересованным лицам целостную информации о состоянии этого issue, включая интерфейсы редактирования, запроса и поиска, механизмы почтового и RSS-оповещений.

Сущность Bug имеет набор атрибутов, работа с которыми — редактирование и запросы — является основными сценариями использования Bugzilla

Структурные атрибуты

  • Product (Продукт) - основной атрибут, задающий структуру. Каждый Product состоит из набора Компонентов. Можно включить классификацию продуктов — дополнительное подразделение продуктов на группы (исключительно двухуровневое), что отразится на интерфейсе заведения новых багов и на интерфейсе запросов.
  • Component (Компонент) - дополнительная структурная классификация. В зависимости от выбранного компонента баг может иметь разный набор компонентов.

Атрибуты жизненного цикла

  • Status (Статус) - основной атрибут, определяющий текущее состояние бага. Отражает меру активности бага от начального состояния, когда он еще не подтвержден как баг, до завершения, когда баг исправлен/решен, что подтверждено Службой Качества. Набор состояний зависит от конкретной инсталляции и настроек Bugzilla.

Стандартный набор:

UNCONFIRMED (Не подтвержден) Наличие этого состояния зависит от настроек конкретного Продукта. Например, если считается, что баг-отчеты в Продукт могут составлять неконтролируемое множество пользователей (например, интернет-аудитория), в этом состоянии имеется смысл. Тогда для перехода в следующее состояние (NEW) необходимо решение пользователя системы с правами canconfirm. Если же новые баги ставят только обученные сотрудники, то это состояние скорее всего не нужно;
NEW (Новый) Баг только что зарегистрирован или проверен (если был зарегистрирован в состоянии UNCONFIRMED)
ASSIGNED (Назначен) Пользователь в поле Assigned To назначен ответственным за этот баг. Баг может быть назначен на другого сотрудника или переведен в состояние NEW
REOPENED (Открыт заново) Баг был решен ранее, однако возникла необходимость вернуться к нему (решение было неверным либо неокончательным)
  • Resolution (Резолюция, Решение) - атрибут имеет смысл только для багов в состояниях RESOLVED, VERIFIED, CLOSED. Набор значений атрибута настраиваемый, стандартный набор:
FIXED (Решено) стандартная резолюция, означающая, что задание выполнено или баг исправлен
INVALID (Некорректно) неправильная или некорректная постановка задачи
WONTFIX (Проблема есть, но решаться не будет) - такая резолюция может быть в отношении request for enhancement, которые хоть и имеют смысл, являются слишком трудновыполнимыми и не являются обязательными
DUPLICATE (Дублирует) описанная проблема уже зарегистрирована в другом баге
WORKSFORME (А у меня работает…) не удалось воспроизвести описанную проблему ни эмуляцией сценария, ни анализом кода
MOVED (Перенесено) проблема перенесена в иную систему-tracker.

Также можно использовать:

  • LATER (Позже) - задача зафиксирована, но ее решение откладывается на неопределенный срок. Возможно, для ее решение необходимо некоторое внешнее событие или решение других задач. Если в продукте есть веха «неопределенное будущее», разумно также установить target milestone на эту веху. [4]

Описание бага

  • Summary - аннотация задачи/проблемы одним предложением. По правилам хорошего тона при регистрации нового бага следует дублировать (не обязательно дословно) содержимое Summary в первом комментарии. Атрибут Summary может быть несколько раз отредактирован, что приведет к утере первоначального смысла бага. Конечно, доступна история изменений, но лучше зафиксировать историю в комментариях, которые отображаются всегда.
  • Version - номер версии продукта (компонента продукта), в которых наблюдается описанная проблема.
  • Priority - приоритет бага, указывается Assigned To пользователем на основе собственной оценки. Менять приоритет у чужих багов неправильно. Стандартный набор значений — от P1 (наивысший приоритет) до P5 (наименьший).
  • Severity - критичность возникшей проблемы.

Список допустимых значений настраивается, стандартный набор:

Blocker разработка или использования продукта невозможна. Требуется немедленное решение проблемы;
Critical серьезные проблемы — не работает критичный для использования функционал, наблюдаются серьезные ошибки, связанные с потерей данных и т.п;
Major проблема связана с важным функционалом продукта;
Minor проблема связана со второстепенным функционалом продукта или есть легкий обходной путь для решения проблемы;
Trivial проблема косметического уровня. Например, недоработанный интерфейс - опечатки, не выровненные поля, разнобой цветов и пр.;
Enhancement Request for enhancement - запрос на усовершенствование
  • Target (Target Milestone, Веха) - здесь указывается веха (версия, стадия) проекта, к которой баг должен быть решен. Не путать с Version. Например, баг может описывать ошибку, возникшую в версии 1.17, которую было решено исправить к версии 1_21. Веха не обязательно привязана к версии продукта, она может быть привязана к определенному времени. Набор вех — набор единых для каждого продукта событий, которые должны синхронизировать процессы исправления, тестирования и пронесения изменений. Каждый продукт имеет атрибут Milestone URL, содержащий ссылку на документ с именованными и описанными вехами, то есть где будет приведен некоторый Roadmap проекта.
  • Comments - комментарии к багу. Первый — это Description, остальные в форме редактирования бага именуются Additional Comments. Bugzilla рассылает всем связанным с багом пользователям комментарии по почте.

Зависимости между багами

В Bugzilla регистрируется только один единственный вид зависимостей: «баг X зависит от решения бага Y». Нет разделения структурных зависимостей вида «проблема X подразделяется на проблемы X1,X2,X3» и сетевых зависимостей общего вида, но в целом ничто не мешает представлять структурные зависимости в общем виде («баг X зависит от решения багов X1,X2,X3»).

Зарегистрированные зависимости видны и при просмотре атрибутов отдельно выбранных багов, и могут быть просмотрены в виде ориентированного графа вида:

Bugzilla имеет две дополнительные особенности:
подпись
  • «Важные» баги отображаются более крупными, и их заголовки отображаются прямо на графе. Важными считаются баги, имеющие в трудозатратах или их оценке более 40 часов, либо блокирующие более 4-х багов.
  • Можно выбрать альтернативный алгоритм построения графов, располагающий баги на поверхности более плотно — twopi - Баг 11407 зависит от решенного 11406 и нерешенного 11405.
  • Depends on указывает, от решения каких багов зависит данный баг.

Bugzilla показывает также активность по блокирующим багам, а именно:

Процент выполненности блокирующих

Blockers completed ~16%,

Дата последнего изменения блокирующих багов

last changed 2009-02-12 12:57:45
  • Blocks указывает, решение каких багов зависит от данного бага.

Советы по использованию

В процессе использования Bugzilla было сделано много доработок.

Поддерживайте целостность

  • Дублируйте содержимое Summary
  • Указывайте корректные значения в полях или не указывать никаких. Например, не пишите строки «any», «нет», "-" и прочее в URL, если нет конкретного связанного с багом URL.

Вложения

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

  • Сделана специальная доработка (Bug:15001 и Bug:53638, которая позволяет присоединить текстовое вложение к багу через буфер обмена, без создания файла, с одновременным добавлением комментария, фиксацией времени и изменением некоторых атрибутов бага. Таким образом, если Вы получили текстовое сообщение об ошибке с большим стеком, то надо не писать комментарий, а добавить вложение, где вставить это сообщение в текстовое окно вложения (переключив radio button на Enter text), а ниже написать комментарий с краткой формулировкой ошибки.
  • Обрезайте и сжимайте скриншоты. Нет необходимости показывать весь экран, если вы хотите указать на проблему в одном окне.
  • Не вкладывайте простые тестовые примеры (например HTML-файл, ссылающийся на CSS и картинку) как архив. Вместо этого загрузите перечисленные файлы в обратном порядке, и отредактируйте вкладываемый HTML-файл, чтобы он ссылался непосредственно на загруженные вложения. Bugzilla хранит и использует Content-Type для каждого вложения (например, text/html).
  • Чтобы выгружать вложение с другим Content-Type (например, application/xhtml+xml), надо добавить CGI-параметр Content-type в URL, то есть &content-type=text/plain.

Комментирование

  • Если вы изменяете баг, добавляйте комментарий, только если вам действительно есть что сказать или если этого требует Bugzilla (для некоторых типов переходов). В противном случае, вы будете без нужды засыпать письмами связанных с багом пользователей. Например, люди могут настроить свой аккаунт (см. Field/recipient specific options), чтобы не получать извещений при событиях вида «Изменился CC List». Но если доброжелатель добавляя себя, добавит комментарий «Я, типа, себя добавил», это будет уже добавление комментария и обойдет вышеуказанный фильтр.
  • Не используйте подписей в комментариях, особенно модные многострочные подписи с ASCII-картинками.[5]

Требования

Для работы Bugzilla требуются:

  • веб-сервер с поддержкой CGI (рекомендуется Apache);
  • поддержка языка Perl 5;
  • база данных MySQL, MariaDB, PostgreSQL или Oracle ;
  • SMTP или почтовый сервер.

Установка

Скачать язык Perl и систему отслеживания ошибок Bugzilla, а так же найти информацию по ее установке Вы можете здесь: [1]

подпись

Примечания

  1. Bugzilla
  2. Bugzilla [Электронный ресурс] : Материал из Википедии — свободной энциклопедии: — Режим доступа:https://ru.wikipedia.org/wiki/Bugzilla
  3. Bugzilla [Электронный ресурс] : Материал из :http://mozilla-russia.org/products/bugzilla/ — Режим доступа:http://mozilla-russia.org/products/bugzilla/
  4. Bugzilla[Электронный ресурс] : Материал из :http://lib.custis.ru/Bugzilla — Режим доступа:http://lib.custis.ru/Bugzilla
  5. Bugzilla[Электронный ресурс] : Материал из :http://lib.custis.ru/Bugzilla — Режим доступа:http://lib.custis.ru/Bugzilla