Difference between revisions of "Bugzilla"

From Wiki4Intranet
Jump to: navigation, search
m
 
(много мелких изменений, требующие уточнения места выделены красным)
 
(14 intermediate revisions by 7 users not shown)
Line 1: Line 1:
Bugzilla — «система контроля ошибок», разработанная «The Mozilla Organization»
+
 
 +
[[Файл:Bugzilla_logo.png|frame|Логотип Bugzilla]]
 +
 
 +
'''Bugzilla''' система отслеживания ошибок, разрабатываемая Mozilla Foundation.
  
 
{{note}} Может также упоминаться (и с некоторыми оговорками использоваться) как:
 
{{note}} Может также упоминаться (и с некоторыми оговорками использоваться) как:
* «система учета заданий»
+
* Система учета заданий
* «система контроля дел»
+
* Система ведения дел
* «система регистрации инцидентов»
+
* Система регистрации инцидентов
* система управления «требованиями», «идеями», «предложениями», «заявками» и т. п.
+
* Система управления требованиями, идеями, предложениями, заявками и т.п.
 
+
 
* Сайт: http://www.bugzilla.org
 
* Сайт: http://www.bugzilla.org
* Распространение: freeware, opensource
+
* Распространение: freeware, open source
 +
 
  
 
= Введение =
 
= Введение =
  
Ключевым понятием системы является баг («Bug») — суть «issue» — некоторое задание, запрос, рекламация по поводу ошибки в системе, или просто сообщение, требующее обратной связи, и назначение системы — регистрация и предоставление заинтересованным лицам целостной информации об состоянии этого «issue»,
+
Ключевым понятием системы является '''Bug''' (баг) — некоторое задание, запрос, рекламация по поводу ошибки в системе или просто сообщение, требующее обратной связи. Баги регистрируют и предоставляют заинтересованным лицам целостную информации о состоянии этого issue, включая интерфейсы редактирования, запроса и поиска, механизмы почтового и [[RSS]]-оповещений.
включая интерфейсы редактирования, запроса и поиска, механизмы почтового и [[RSS]]-оповещений.
+
  
Сейчас Bugzilla используют [http://www.bugzilla.org/installation-list/ более семиста] компаний и организаций по всему миру. Из наиболее известных имен компаний и проектов: NASA, IBM, Mozilla, Linux Kernel, Gnome, KDE, Apache Project, Open Office.
+
Bugzilla используют многие компании и организации по всему миру. Из наиболее известных: NASA, IBM, Mozilla, Linux Kernel, Gnome, KDE, Apache Project, Open Office.
  
 
= Анатомия бага =
 
= Анатомия бага =
  
Сущность ''Bug'' имеет набор атрибутов, работа с которыми — редактирование и запросы — является основными сценариями использования [[Bugzilla]].
+
Сущность Bug имеет набор атрибутов, работа с которыми — редактирование и запросы — является основными сценариями использования Bugzilla. Рассмотрим эти атрибуты.
  
 
[[File:Bugs have feeling too (cartoon tester).jpg|center]]
 
[[File:Bugs have feeling too (cartoon tester).jpg|center]]
  
  
Опишем эти атрибуты.
+
== Структурные атрибуты==
 
+
== Структурные ==
+
 
+
=== Product ===
+
 
+
«Продукт». Основной атрибут, задающий структуру. Каждый «Product» состоит из набора [[#Component|компонентов]]. Можно включить классификацию продуктов — дополнительное подразделение продуктов на группы (исключительно двухуровневое), что отразится на интерфейсе заведения новых багов и на интерфейсе запросов.
+
 
+
=== Component ===
+
 
+
«Компонент». Дополнительная структурная классификация. В зависимости от выбранного компонента, баг может иметь разный набор флагов.
+
 
+
== Атрибуты жизненного цикла ==
+
  
=== Status ===
+
1. '''Product (Продукт)''' - основной атрибут, задающий структуру. Каждый Product состоит из набора Компонентов. Можно включить классификацию продуктов — дополнительное подразделение продуктов на группы (исключительно двухуровневое), что отразится на интерфейсе заведения новых багов и на интерфейсе запросов.
  
«Статус». Основной атрибут, определяющий текущее состояние бага, то есть меру его активности — от самого «начального» состояния, когда он даже не подтвержден, как баг, до благополучного завершения, когда баг исправлен/решен, что подтверждено Службой Качества.
+
2. '''Component (Компонент)''' - дополнительная структурная классификация. В зависимости от выбранного компонента баг может иметь разный набор компонентов.
Набор состояний зависит от конкретной инсталляции и настройки [[Bugzilla]], однако, стандартный набор:
+
;UNCONFIRMED: «Не подтвержден». Наличие этого состояния зависит от настройки конкретного [[#Product|продукта]]. Например, если считается, что баг-отчеты в продукт могут составлять неконтролируемое множество пользователей (например, интернет-аудитория), то в этом состоянии имеется смысл. Тогда, для перехода в следующее состояние («NEW»), необходимо решение пользователя системы с правами «canconfirm». Если же новые баги ставят только обученные сотрудники, то в это состояние, скорее всего не нужно.
+
;NEW: «Новый». Только что зарегистрирован или проверен (если был зарегистрирован в состоянии «UNCONFIRMED»).
+
;ASSIGNED: «Акцептован». Пользователь, указанный в «Assigned-to», подтвердил свою ответственность за этот баг. Баг может быть «перенаправленным» другому лицу, и снова стать «NEW».
+
;REOPENED: Баг уже был однажды решен, однако, решение было либо неправильными, либо неокончательным.
+
  
=== Resolution ===
+
== Атрибуты жизненного цикла==
  
«Резолюция», «Решение» — этот атрибут имеет смысл только для багов в состояниях «RESOLVED», «VERIFIED», «CLOSED». Также, набор «резолюций» можно настраивать, но стандартный набор следующий:
+
1. '''Status (Статус)''' - основной атрибут, определяющий текущее состояние бага. Отражает меру активности бага от начального состояния, когда он еще не подтвержден как баг, до завершения, когда баг исправлен/решен, что подтверждено Службой Качества.
 +
Набор состояний зависит от конкретной инсталляции и настроек Bugzilla. Стандартный набор:
 +
* ''UNCONFIRMED (Не подтвержден)''
 +
: Наличие этого состояния зависит от настроек конкретного Продукта. Например, если считается, что баг-отчеты в Продукт могут составлять неконтролируемое множество пользователей (например, интернет-аудитория), в этом состоянии имеется смысл. Тогда для перехода в следующее состояние (NEW) необходимо решение пользователя системы с правами canconfirm. Если же новые баги ставят только обученные сотрудники, то это состояние скорее всего не нужно;
 +
*''NEW (Новый)''
 +
:Баг только что зарегистрирован или проверен (если был зарегистрирован в состоянии UNCONFIRMED);
 +
*''ASSIGNED (Назначен)''
 +
:Пользователь в поле Assigned To назначен ответственным за этот баг. Баг может быть назначен на другого сотрудника или переведен в состояние NEW;
 +
*''REOPENED (Открыт заново)''
 +
:Баг был решен ранее, однако возникла необходимость вернуться к нему (решение было неверным либо неокончательным).
  
;FIXED: «Решено» — наиболее стандартная резолюция — означает, что задание выполнено или баг исправлен.
 
;INVALID: «Некорректно» — неправильная или некорректная постановка, не имеющая смысла.
 
;WONTFIX: «Проблема есть, но решать ее не будем». Например, такое может быть в отношении «request for enhancement», которые хоть и имеют смысл, но являются слишком трудновыполнимыми и не являются обязательными.
 
;DUPLICATE: «Дубль» — описанная проблема уже регистрировалась в определенном баге.
 
;WORKSFORME: «А у меня работает…» — не удалось воспроизвести описанную проблему ни эмуляцией сценария, ни анализом кода.
 
;MOVED: Проблема перенесена в иную систему- «tracker».
 
  
 +
2. '''Resolution (Резолюция, Решение)''' - атрибут имеет смысл только для багов в состояниях RESOLVED, VERIFIED, CLOSED. Набор значений атрибута настраиваемый, стандартный набор:
 +
*''FIXED (Решено)'' — стандартная резолюция, означающая, что задание выполнено или баг исправлен;
 +
*''INVALID (Некорректно)'' — неправильная или некорректная постановка задачи;
 +
*''WONTFIX (Проблема есть, но решаться не будет)'' - такая резолюция может быть в отношении request for enhancement, которые хоть и имеют смысл, являются слишком трудновыполнимыми и не являются обязательными;
 +
*''DUPLICATE (Дублирует)'' — описанная проблема уже зарегистрирована в другом баге;
 +
*''WORKSFORME (А у меня работает…)'' — не удалось воспроизвести описанную проблему ни эмуляцией сценария, ни анализом кода;
 +
*''MOVED (Перенесено)'' - проблема перенесена в иную систему-tracker.
 
Также можно использовать:
 
Также можно использовать:
;LATER: Задача зафиксирована, но ее решение откладывается на неопределенный срок. Возможно для ее решение нужно некоторое внешнее событие, или решение каких-либо задач. Если в продукте есть веха «неопределенное будущее», то разумно также установить «target milestone» на эту веху.
+
*''LATER (Позже)'' - задача зафиксирована, но ее решение откладывается на неопределенный срок. Возможно, для ее решение необходимо некоторое внешнее событие или решение других задач. Если в продукте есть веха «неопределенное будущее», разумно также установить '''target milestone''' на эту веху.
  
=== Диаграмма ===
+
3. '''Диаграмма'''
  
Жизненный цикл бага, он же граф переходов состояний, он же work flow, жестко задан в коде, и представлен ниже, на графе.
+
Жизненный цикл бага (он же граф переходов состояний, workflow) жестко задан в коде и представлен ниже, на графе.
  
 
<graph>
 
<graph>
Line 107: Line 102:
 
</graph>
 
</graph>
  
== Связанные пользователи ==
+
== Связанные пользователи==
  
=== Assigned_To ===
+
*''Assigned To (ответственный)'' - пользователь, ответственный за решение (исправление) бага. Подтверждение ответственности происходит при переводе бага из состояний NEW и REOPENED в ASSIGNED.
  
Лицо (сотрудник, пользователь), ответственное за решение (исправление) бага. Подтверждение ответственности происходит при переводе бага из состояний «NEW» или «REOPENED» в состояние «ASSIGNED».
+
*'' Reporter (автор)'' - пользователь, создавший баг.
  
=== Reporter ===
+
* ''QA Contact (проверяющий, тестировщик)'' - пользователь, ответственный за проверку решения бага.
  
Пользователь, собственно составивший (заполнивший информацию) о баге.
+
* ''CC List (список наблюдателей)'' - список заинтересованных в баге пользователей, оповещаемых об изменениях бага.
  
=== QA ===
+
== Описание бага==
  
Пользователь, ответственный за проверку решения бага.
+
1. '''Summary''' - аннотация задачи/проблемы одним предложением. По правилам хорошего тона при регистрации нового бага следует дублировать (не обязательно дословно) содержимое Summary в первом комментарии. Атрибут Summary может быть несколько раз отредактирован, что приведет к утере первоначального смысла бага. Конечно, доступна история изменений, но лучше зафиксировать историю в комментариях, которые отображаются всегда.
  
=== CC ===
+
2. '''Version''' - номер версии продукта (компонента продукта), в которых наблюдается описанная проблема.
  
«СС list»: Список людей, извещаемых при изменениях бага.
+
3. '''Priority''' - приоритет бага, указывается Assigned To пользователем на основе собственной оценки. Менять приоритет у чужих багов неправильно. Стандартный набор значений — от P1 (наивысший приоритет) до P5 (наименьший).
  
== Описание бага ==
+
4. '''Severity''' - критичность возникшей проблемы. Список допустимых значений настраивается, стандартный набор:
 +
*''Blocker'' - разработка или использования продукта невозможна. Требуется немедленное решение проблемы;
 +
*''Critical'' - серьезные проблемы — не работает критичный для использования функционал, наблюдаются серьезные ошибки, связанные с потерей данных и т. п;
 +
*''Major'' - проблема связана с важным функционалом продукта;
 +
*''Minor'' - проблема связана со второстепенным функционалом продукта или есть легкий обходной путь для решения проблемы;
 +
*''Trivial'' - проблема косметического уровня. Например, недоработанный интерфейс - опечатки, не выровненные поля, разнобой цветов и пр.;
 +
*''Enhancement: Request for enhancement - запрос на усовершенствование.
  
=== Summary ===
+
5. '''Target (Target Milestone, Веха)''' - здесь указывается веха (версия, стадия) проекта, к которой баг должен быть решен.
 +
Не путать с Version. Например, баг может описывать ошибку, возникшую в версии 1.17, которую было решено исправить к версии 1_21. Веха не обязательно привязана к версии продукта, она может быть привязана к определенному времени. Набор вех — набор единых для каждого продукта событий, которые должны синхронизировать процессы исправления, тестирования и пронесения изменений. Каждый продукт имеет атрибут '''Milestone URL''', содержащий ссылку на документ с именованными и описанными вехами, то есть где будет приведен некоторый Roadmap проекта.
  
Аннотация задачи/проблемы одним предложением. В правилах «хорошего тона» обязательно дублировать (не обязательно дословно) при регистрации нового бага, содержимое «Summary» в первом комментарии, ибо атрибут «Summary» может быть несколько раз отредактирован, будет утерян смысл бага. Конечно, можно посмотреть историю изменений, но лучше, чтобы эта история была зафиксирована в комментариях, которые показываются всегда.
+
6. '''Comments''' - комментарии к багу. Первый — это Description, остальные в форме редактирования бага именуются Additional Comments. Bugzilla рассылает всем [[#Связанные пользователи|связанным с багом пользователям]] комментарии по почте.
 +
В нашей инсталляции Bugzilla есть возможность «Silent» комментариев (checkbox Silent), уведомления о которых не рассылаются по почте. Использовать '''Silent''' следует только в том случае, когда информация в комментарии действительно мало интересна — например, worklog-запись о выполненной промежуточной (не решающей баг) работе, или если основная ценность записи - регистрация личных трудозатрат (см. [[#Учет времени (Time tracking)|Учет времени (Time tracking)]]).
  
=== Version ===
+
Не стоит злоупотреблять комментариями, превращая баг в форум. Для обсуждения постановки задачи, продуктивней завести ассоциированную с багом статью в Wiki-системе, и обсуждать там (см. [[#Интеграция с Wiki|Интеграция с Wiki]]).
  
Обычно используется для указания конкретных версий продукта (вернее компонента продукта), в которых наблюдается описанная проблема.
+
== Зависимости между багами==
  
=== Priority ===
+
В Bugzilla регистрируется только один единственный вид зависимостей: «баг X зависит от решения бага Y». Нет разделения структурных зависимостей вида «проблема X подразделяется на проблемы X<sub>1</sub>,X<sub>2</sub>,X<sub>3</sub>» и сетевых зависимостей общего вида, но в целом ничто не мешает представлять структурные зависимости в общем виде («баг X зависит от решения багов X<sub>1</sub>,X<sub>2</sub>,X<sub>3</sub>»).
  
[[#Assigned_To|Ответственный]] указывает приоритет (именно свою оценку приоритета) описанной проблемы или задания. Поэтому менять приоритет у чужих багов-заданий считается неправильным. Стандартный набор значений — от «P1» (наивысший приоритет) до «P5» (наименьший).
 
 
=== Severity ===
 
 
Указывает на критичность возникшей проблемы. Домен значений можно настраивать, стандартный набор следующий:
 
 
;Blocker: Разработка или использования продукта невозможна. Нужно немедленное исправление проблемы.
 
;Critical: Серьезные проблемы — не работает критический блок функционала, наблюдаются серьезные ошибки, связанные с потерей данных и т. п.
 
;Major: Проблема связана с важным функционалом продукта.
 
;Minor: Проблема связана с второстепенным функционалом продукта, или есть легкий обходной путь для этой проблемы.
 
;Trivial: Проблема косметического уровня — например, «недоработанный» интерфейс (опечатки, не выровненные поля, разнобой с цветами и т. п.)
 
;Enhancement: «Request for enhancement».
 
 
=== Target ===
 
 
«Target Milestone», «Веха».
 
 
Указание вехи, (версии, стадии) проекта, к которой баг должен быть решен.
 
Не путать с [[#Version|версией]]. Например, баг может описывать ошибку, возникшую в версии «1.17», но которую было решено исправить к вехе «1_21», в которой будет выпущена версия продукта «1.21». Веха не обязательно должна быть привязана к версии продукта — она может быть привязана и к определенному времени. Набор вех — набор единых для каждого продукта событий, которые должны синхронизировать процессы исправления, тестирования и пронесения изменений. Каждый продукт имеет атрибут «Milestone URL», содержащий ссылку на документ, где вехи продукта должны быть поименованы и описаны, то есть где будет приведен некоторый «Roadmap» проекта.
 
 
=== Comments ===
 
 
Комментарии. Первый комментарий по багу — это «Description», остальные в форме редактирования бага именуются «Additional Comments». Используется всеми связанными с багом пользователями для централизованных комментариев, которых [[Bugzilla]] рассылает всем ([[#Reporter]],[[#CC]],[[#QA]],[[#CC]]) по почте.
 
В нашей инсталляции, есть возможность «Silent»-комментариев (checkbox «Silent»), информация о которых не рассылается по почте. Использовать только в том случае, когда информация в комментарии действительно малоинтересна — например, просто worklog-запись о выполненной промежуточной (не «решающей» баг) работе, например, если основная ценность записи — с регистрация личных трудозатрат (см. [[#Учет времени (Timetracking)]]).
 
 
Также, не стоит злоупотреблять комментарии, и превращать их в форум. Для обсуждения постановки задачи, продуктивней завести ассоциированную с багом статью в [[WikiWiki]]-системе, и обсуждать там (см. [[#Интеграция с Wiki]]).
 
 
== Зависимости между багами ==
 
 
В [[Bugzilla]] регистрируется только один единственный вид зависимостей: «баг X зависит от решения бага Y». То есть нет разделения структурных зависимостей вида «проблема X подразделяется на проблемы X<sub>1</sub>,X<sub>2</sub>,X<sub>3</sub>» и сетевых зависимостей общего вида, но в целом, ничто не мешает представлять структурные зависимости в общем виде («баг X зависит от решения багов X<sub>1</sub>,X<sub>2</sub>,X<sub>3</sub>».
 
 
Зарегистрированные зависимости видны и при просмотре атрибутов отдельно выбранных багов, и могут быть просмотрены в виде ориентированного графа вида:
 
Зарегистрированные зависимости видны и при просмотре атрибутов отдельно выбранных багов, и могут быть просмотрены в виде ориентированного графа вида:
  
Line 183: Line 156:
 
В нашей инсталляции Bugzilla 3 графы зависимостей имеют две дополнительные особенности:
 
В нашей инсталляции Bugzilla 3 графы зависимостей имеют две дополнительные особенности:
  
* «Важные» баги отображаются более крупными и их заголовки отображаются прямо на графе. «Важными» считаются баги, имеющие в трудозатратах или их оценке более 40 часов, либо блокирующие более, чем 4 бага.
+
* «Важные» баги отображаются более крупными, и их заголовки отображаются прямо на графе. Важными считаются баги, имеющие в трудозатратах или их оценке более 40 часов, либо блокирующие более 4-х багов.
* Можно выбрать «альтернативный» алгоритм построения графов, располагающий баги на поверхности более плотно — «twopi».
+
* Можно выбрать альтернативный алгоритм построения графов, располагающий баги на поверхности более плотно — '''twopi''' - Баг 11407 зависит от решенного 11406 и нерешенного 11405.
  
(Баг «11407» зависит от решенного «11406» и нерешенного «11405»).
+
* '''Depends on''' указывает, от решения каких багов зависит '''данный баг'''.
  
=== Depends on ===
+
В нашей инсталляции Bugzilla показывается также активность по блокирующим багам, а именно:
 
+
Указывает, от решения каких багов '''зависит данный баг'''.
+
 
+
В нашей инсталляции, показывается также активность по блокирующим багам, а именно:
+
 
;Процент выполненности блокирующих:
 
;Процент выполненности блокирующих:
 
  Blockers completed ~16%,  
 
  Blockers completed ~16%,  
Line 198: Line 167:
 
  last changed 2009-02-12 12:57:45
 
  last changed 2009-02-12 12:57:45
  
=== Blocks ===
+
* '''Blocks''' указывает, решение каких багов зависит от '''данного бага'''.
  
Указывает, решение каких багов '''зависит от данного бага'''.
+
== Прочее ==
  
== Misc ==
+
* '''URL''' - ассоциированный с багом URL, указывающий на документ с описанием/постановкой проблемы, если таковой имеется.
  
=== URL ===
+
В нашей инсталляции Bugzilla можно пользоваться автоматической связью между багом и ассоциированной с каждым Component'ом Wiki-системой, в которой можно делать пристойно отформатированную постановку задачи и даже вести ее обсуждение (См. [[#Интеграция с Wiki|Интеграция с Wiki]]).
Ассоциированный с багом URL, указывающий на документ с описанием/постановкой проблемы, если таковой имеется.
+
В нашей инсталляции [[Bugzilla]], можно также пользоваться автоматической связью между багом и ассоциированной с каждым [[#Component|компонентом]] [[WikiWiki]]-системой, в которой можно делать пристойно отформатированную постановку задачи и даже вести ее обсуждение (См. [[#Интеграция с Wiki]]).
+
  
=== Whiteboard ===
+
* '''Whiteboard''' - текстовая зона свободной формы для задания кратких заметок или тегов к багу.
Текстовая зона свободной формы для задания кратких заметок или тегов к багу.
+
  
=== Keywords ===
+
* '''Keywords''' - ключевые слова, используемые для пометки и даже для классификации багов.
Ключевые слова, используемые для пометки и даже для классификации багов.
+
Набор ключевых слов «глобальный», общий для всех продуктов внутри инсталляции [[Bugzilla]], поэтому, рекомендуется ответственно относиться к заведению каждого нового ключевого слов, чтобы не «замусоривать» общее пространство.
+
  
=== Platform ===
+
Набор ключевых слов «глобальный», общий для всех продуктов внутри инсталляции Bugzilla, поэтому рекомендуется ответственно относиться к заведению каждого нового ключевого слова, чтобы не замусоривать общее пространство.
Вычислительная платформа (железо), на которой наблюдается проблема.
+
В нашей инсталляции [[Bugzilla]] этот атрибут не используется.
+
  
=== OS ===
+
* '''Attachments''' - прикрепленные к багам файлы (сценарии тестирования, патчи и пр.).
Операционная система, на которой наблюдается проблема.
+
В нашей инсталляции [[Bugzilla]] этот атрибут не используется.
+
  
=== Attachments ===
+
Атрибуты, не используемые в нашей инсталляции Bugzilla:
К багам можно прикреплять файлы (например сценарии тестирования, патчи)
+
  
=== Votes ===
+
* Platform - вычислительная платформа (железо), на которой наблюдается проблема;
Собрал ли баг сколько либо голосов (в нашей инсталляции отсутствует). Используется, в основном, для автоматического перевода бага из состояния «UNCONFIRMED» в состояние «NEW».
+
  
 +
* OS - операционная система, на которой наблюдается проблема;
  
 +
* Votes - голоса за баг. Используется в основном для автоматического перевода бага из UNCONFIRMED в NEW.
  
 
= Поиск багов =
 
= Поиск багов =
Line 235: Line 195:
 
== Основные атрибуты ==
 
== Основные атрибуты ==
  
На странице «Bugzilla Search» представлен интерфейс к поиску любых зарегистрированных багов, комментариев и патчей. Интерфейс позволяет задать поисковые значения для всех перечисленных полей бага, причем для некоторых полей может быть задано несколько значений из домена (с помощью списков с множественным выбором). Если значение не выбрано — атрибут бага может принимать любое значение.
+
На странице Bugzilla Search представлен интерфейс для поиска любых зарегистрированных багов, комментариев и патчей. Интерфейс позволяет задать поисковые значения для всех перечисленных полей бага, причем для некоторых полей может быть задано несколько значений из домена (с помощью списков со множественным выбором). Если значение не выбрано — атрибут бага может принимать любое значение.
  
 
== Хранение запросов ==
 
== Хранение запросов ==
  
Любой выполненный запрос можно сохранить под неким выбранным именем («Remember Search As»), тогда результат этого запроса можно будет всегда получить за один «клик», активировав одноименную с запросом ссылку, которая будет показываться внизу страницы, в линейке «Saved Searches».
+
Любой выполненный запрос можно сохранить под выбранным именем ('''Remember Search As'''). Ссылка на сохраненный поиск отобразится в линейке Saved Searches, результат запроса можно будет получить за один клик, перейдя по ссылке.
  
 
== Временные условия ==
 
== Временные условия ==
  
Можно накладывать временные условия на изменение бага, запрашивая только баги, по которым было какое нибудь движение (изменение атрибутов, комментарии) в определенном интервале времени — см. группу полей «Bug Changes». Интервал времени можно задавать как в абсолютной форме (дата в ISO-формате yyyy-mm-dd), так и в форме, относительной текущей даты, таким образом можно сделать хранимый запрос, показывающий только баги измененные в течении предшествующих 24 часов (или недели, или месяца).
+
Можно накладывать временные условия на изменение бага, запрашивая только баги, по которым было какое-либо движение (изменение атрибутов, комментарии) в определенном интервале времени — см. группу полей '''Bug Changes'''. Интервал времени можно задавать как в абсолютной форме (дата в формате YYYY-MM-DD), так и в форме, относительной текущей дате. Можно сделать хранимый запрос, показывающий только баги, измененные в течение предшествующих 24 часов (или недели, месяца).
  
Конкретно, можно использовать слова:
+
Можно использовать слова:
* Now — «сейчас», разумно использовать для задания верхней границы интервала.
+
* '''Now''' сейчас, разумно использовать для задания верхней границы интервала.
* 1d — день назад (2d — два дня назад …). 0d — последняя полночь, до текущего момента.
+
* '''1d''' — день назад. 2d — два дня назад, 0d — последняя полночь до текущего момента.
* 1w — то же самое в неделях. 0w — начало недели.
+
* '''1w''' — то же самое в неделях. 0w — начало недели.
* 1m — то же в месяцах. 0m — начало месяца.
+
* '''1m''' — то же в месяцах. 0m — начало месяца.
* 1y — то же в годах. 0y — начало года.
+
* '''1y''' — то же в годах. 0y — начало года.
  
Можно добавить перед относительными датами знак «+», это будет означать, что относительная дата не вычитается из «Now», а прибавляется (в будущее).
+
Можно добавить перед относительными датами знак '''+''', это будет означать, что относительная дата не вычитается из '''Now''', а прибавляется (в будущее).
  
 
== Полнотекстовый поиск ==
 
== Полнотекстовый поиск ==
  
Начиная с версии 3.0, Bugzilla поддерживает честный полнотекстовый поиск по MySQL [http://dev.mysql.com/doc/refman/5.1/en/fulltext-search.html FULLTEXT-индексам], а с нашими доработками — и русскоязычную морфологию через стеммер Портера {{CPAN|Lingua::Stem::Ru}} (порт из [http://snowball.tartarus.org/algorithms/russian/stemmer.html snowball]).
+
Начиная с версии 3.0 Bugzilla поддерживает честный полнотекстовый поиск по MySQL [http://dev.mysql.com/doc/refman/5.1/en/fulltext-search.html FULLTEXT-индексам], а с нашими доработками — и русскоязычную морфологию через стеммер Портера {{CPAN|Lingua::Stem::Ru}} (порт из [http://snowball.tartarus.org/algorithms/russian/stemmer.html snowball]).
  
То есть, по слову «завтрака» ищется и «завтрак», и «завтраков» и т. п.
+
То есть по слову «завтрака» ищется и «завтрак», и «завтраков» и пр.
  
Искать по словам можно из двух мест: со страницы поиска [http://bugs.office.custis.ru/bugs/query.cgi] и из поля «Quicksearch», расположенного в шапке и подвале страниц Bugzilla.
+
Искать по словам можно из двух мест: [http://bugs.office.custis.ru/bugs/query.cgi со страницы поиска] и из поля '''Quicksearch''' в шапке и подвале страниц Bugzilla.
  
 
По умолчанию ищутся баги, содержащие в описании и/или комментариях ''все введённые слова'' с учётом морфологии. Однако, также действует специальный синтаксис, на самом деле совпадающий с синтаксисом [http://dev.mysql.com/doc/refman/5.1/en/fulltext-boolean.html MySQL Fulltext Boolean Search]. При встрече во введённом запросе любого элемента этого синтаксиса запрос автоматически переключается в режим поиска ''любого из введённых слов'', если не указано обратное.
 
По умолчанию ищутся баги, содержащие в описании и/или комментариях ''все введённые слова'' с учётом морфологии. Однако, также действует специальный синтаксис, на самом деле совпадающий с синтаксисом [http://dev.mysql.com/doc/refman/5.1/en/fulltext-boolean.html MySQL Fulltext Boolean Search]. При встрече во введённом запросе любого элемента этого синтаксиса запрос автоматически переключается в режим поиска ''любого из введённых слов'', если не указано обратное.
Line 266: Line 226:
 
Описание синтаксиса:
 
Описание синтаксиса:
  
; +слово: Слово обязательно должно присутствовать в тексте бага.
+
* '''слово''' - слово не обязательно должно присутствовать в тексте бага, однако тексты, содержащие данное слово, ранжируются выше других;
; -слово: Слово не должно присутствовать в тексте бага. Работает только в сочетании с заданными «положительными» словами — запрос, состоящий из просто «-слова», не вернёт ни один баг.
+
* '''+слово''' - слово обязательно должно присутствовать в тексте бага;
; слово: Слово не обязательно должно присутствовать в тексте бага, однако тексты, содержащие данное слово, ранжируются выше других.
+
* '''-слово''' - слово не должно присутствовать в тексте бага. Работает только в сочетании с заданными «положительными» словами — запрос, состоящий из просто «-слова», не вернёт ни один баг;
; >слово: Повышенная «важность» слова — больше вклад в ранжирование.
+
* '''>слово''' - повышенная важность слова — больше вклад в ранжирование;
; <слово: Пониженная «важность» слова.
+
* '''<слово''' - пониженная важность слова;
; +(слово1 слово2) слово3: Группировка выражений скобками. Может быть вложенной.
+
* '''+(слово1 слово2) слово3''' - группировка выражений скобками. Может быть вложенной;
; ~слово: Ранжировать тексты, содержащие слово ниже других, но не исключать окончательно.
+
* '''~слово''' - ранжировать тексты, содержащие слово ниже других, но не исключать окончательно;
; <nowiki>сло*</nowiki>: Знак шаблона (wildcard). Такой запрос найдёт и «слона», и «слово».
+
* '''<nowiki>сло*</nowiki>''' - знак шаблона (wildcard). Такой запрос найдёт и «слона», и «слово»;
; <nowiki>"слово, или фраза"</nowiki>: Искать словосочетания, а не слова. Знаки препинания между словами не учитываются. Морфология учитывается всё равно.
+
* '''<nowiki>"слово, или фраза"</nowiki>''' - поиск словосочетаний, а не слов. Знаки препинания между словами не учитываются, морфология учитывается.
  
Кроме того, слова короче 3 символов в поиске не учитываются.
+
Слова короче 3 символов в поиске не учитываются.
  
 
== Boolean Charts ==
 
== Boolean Charts ==
  
Можно также задавать «продвинутые» запросы используя «Boolean Charts».
+
Можно также задавать продвинутые запросы, используя '''Boolean Charts'''.
Хотя использование «Boolean Charts» несколько менее «интуитивно» и возможно требует большего времени, чем задание атрибутов в основной форме, с их помощью можно построить запрос, практически произвольной сложности, вида
+
Хотя использование '''Boolean Charts''' несколько менее интуитивно и требует больше времени, чем задание атрибутов в основной форме, с их помощью можно построить запрос любой сложности вида
 +
 
 
  [ NOT ]
 
  [ NOT ]
 
   ( (Атрибут<sub>11</sub> Операция<sub>11</sub> Значение<sub>11</sub>) OR
 
   ( (Атрибут<sub>11</sub> Операция<sub>11</sub> Значение<sub>11</sub>) OR
Line 293: Line 254:
 
   )
 
   )
  
В частности, там можно накладывать условия по флагам, например,
+
Можно накладывать условия по флагам, например:
;Только баги, содержащие флаги установленные пользователем «user@company.com»: «Flag Setter» «is equal to» «user@company.com»
+
Только баги, содержащие флаги, установленные пользователем user@company.com - «Flag Setter» «is equal to» «user@company.com»
;Только баги, в которых флаг «флаг_утвердить» установлен в «+»: «Flag» «is equal to» «флаг_утвердить+»
+
Только баги, в которых флаг флаг_утвердить установлен в + - «Flag» «is equal to» «флаг_утвердить+» (аналогично с ?,-)
;Только баги, в которых флаг «флаг_утвердить» установлен в «?»: «Flag» «is equal to» «флаг_утвердить?» (аналогично с «-»).
+
  
В [[Bugzilla]] 3 появилась возможность, ранее имевшаяся только в нашей версии — «подзапросы» по сохранённым запросам поиска в лице операций «matched by saved search» (присутствует в списке, возвращаемом запросом таким-то), и «not matched by saved search» (''отсутствует'' в списке, возвращаемом запросом таким-то)
+
В Bugzilla 3.0 появилась возможность, ранее имевшаяся только в нашей версии — подзапросы по сохранённым запросам поиска в лице операций '''matched by saved search''' (присутствует в списке, возвращаемом запросом таким-то), и '''not matched by saved search''' (отсутствует в списке, возвращаемом запросом таким-то).
  
Например, вы можете сформулировать условие «Блокируется багом из списка, возвращаемого сохранённым запросом поиска My Bugs» — для этого нужно выбрать поле «Depends On», операцию «matched by saved search» и значение «My Bugs».
+
Например, вы можете сформулировать условие «Блокируется багом из списка, возвращаемого сохранённым запросом поиска My Bugs» — для этого нужно выбрать поле '''Depends On''', операцию '''matched by saved search''' и значение '''My Bugs'''.
  
 
Чуть менее тривиально: можно задавать и запросы вида «найти все мои баги в открытом состоянии, для которых все блокирующие выполнены». Для этого просто нужно создать сохранённый запрос, находящий все выполненные баги, и подменить в запросе из предыдущего абзаца My Bugs этим запросом.
 
Чуть менее тривиально: можно задавать и запросы вида «найти все мои баги в открытом состоянии, для которых все блокирующие выполнены». Для этого просто нужно создать сохранённый запрос, находящий все выполненные баги, и подменить в запросе из предыдущего абзаца My Bugs этим запросом.
  
Желательно, чтобы вспомогательные запросы возвращали небольшое число багов, иначе это сильно влияет на скорость ответа. Также, весьма желательно, при использовании этих условий, задавать дополнительные, «простые» условия фильтрации.
+
Желательно, чтобы вспомогательные запросы возвращали небольшое число багов, иначе это сильно влияет на скорость ответа. Также весьма желательно при использовании этих условий задавать дополнительные, «простые» условия фильтрации.
  
Заметим, запросы типа «баги, у которых нет блокирующих» или «баги, у которых нет зависимых»
+
Заметим, запросы типа «баги, у которых нет блокирующих или «баги, у которых нет зависимых»
 
можно реализовать стандартными условиями типа:
 
можно реализовать стандартными условиями типа:
 +
 
  NOT(Depends On "contains regexp" "[0-9]+" )
 
  NOT(Depends On "contains regexp" "[0-9]+" )
 
  NOT(Blocks    "contains regexp" "[0-9]+" )
 
  NOT(Blocks    "contains regexp" "[0-9]+" )
Line 313: Line 274:
 
= Списки багов =
 
= Списки багов =
  
После выполнения запроса система возвращает выборку — список удовлетворяющих запросу багов. Формат этого списка настраиваемый, по ссылке «Change Columns» можно настроить набор показываемых в списке атрибутов.
+
После выполнения запроса система возвращает выборку — список удовлетворяющих запросу багов. Формат этого списка настраиваемый, по ссылке '''Change Columns''' можно настроить набор показываемых в списке атрибутов.
 
+
Также можно включить настройку '''Stagger headers''' — разнесение заголовка таблицы списка на два уровня.
Также можно включить настройку «Stagger headers» — разнесение заголовка таблицы списка на два уровня.
+
  
После выбора списка, его можно отсортировать щелчками по заголовкам колонок (что приводить к сортировке списка в порядке возрастания выбранного атрибута-колонки).
+
После выбора списка его можно отсортировать щелчками по заголовкам колонок (что приводить к сортировке списка в порядке возрастания выбранного атрибута-колонки).
  
 
Другие полезные возможности вызываются ссылками, расположенными внизу списка:
 
Другие полезные возможности вызываются ссылками, расположенными внизу списка:
  
;CSV: выдает список в CSV формате (разделенным запятыми), например, для импорта в программу электронных таблиц.
+
* '''CSV''' - выдает список в CSV формате (разделенным запятыми) например, для импорта в программу электронных таблиц;
;Buglist feed: выдает список в RSS формате, для чтения через RSS-агрегатор. Список отсортирован по убыванию времени открытия бага, набор полей тоже задан жестко. Может быть полезным для отслеживания «поступления» новых багов. Для пользователей Mozilla Firefox рекомендуется установить [http://sage.mozdev.org Sage], чтобы использовать Bugzilla-авторизацию, полученную браузером после логина.
+
* '''Buglist feed''' - выдает список в RSS формате, для чтения через RSS-агрегатор. Список отсортирован по убыванию времени открытия бага, набор полей задан жестко. Может быть полезным для отслеживания поступления новых багов. Для пользователей Mozilla Firefox рекомендуется установить [http://sage.mozdev.org Sage], чтобы использовать Bugzilla-авторизацию, полученную браузером после логина.
;Activity feed: показывает RSS-ленту последних комментариев и активности по выбранным в списке багам.
+
* '''Activity feed''' - показывает RSS-ленту последних комментариев и активности по выбранным в списке багам;
;Change Columns: изменить список атрибутов, показываемых в списке (см. выше).
+
* '''Change Columns''' - изменение списка атрибутов, показываемых в списке;
;Change several bugs at once: Если у вас достаточно привилегий, то вы можете делать некоторые изменения одновременно над всеми багами в списке — например, сменить ответственного («owner»), «закрыть» группу багов, перенести их в другой продукт или компонент.
+
* '''Change several bugs at once''' - если у вас достаточно привилегий, вы можете делать некоторые изменения одновременно над всеми багами в списке — например, сменить ответственного, закрыть группу багов, перенести их в другой Product или Component.
;Send Mail to Bug Assignees: Послать письмо всем ответственным по всем багам в списке.
+
* '''Send Mail to Bug Assignees''' - отправить письмо всем ответственным по всем багам в списке;
;Edit Search: Можно вернуться на страницу запроса для дополнительного уточнения запроса.
+
* '''Edit Search''' - вернуться на страницу запроса для его уточнения;
;Remember Search As: Можно присвоить этому запросу имя и сохранить его, ссылка на сохраненный запрос будет показываться внизу вашей страницы.
+
* '''Remember Search As''' - присвоить этому запросу имя и сохранить, ссылка на сохраненный запрос отобразится в Saved Searches внизу страницы.
  
 
Также есть 3 кнопки:
 
Также есть 3 кнопки:
;Long format: показывает несколько багов на одной странице в подробном формате со всеми атрибутами и полными обсуждениями.
+
* '''Long format''' -  показывает несколько багов на одной странице в подробном формате со всеми атрибутами и полными обсуждениями;
;XML: даёт возможность выгрузить баги в XML-файл, для последующего импорта в другую Bugzilla или какой-то специальной обработки.
+
* '''XML''' - даёт возможность выгрузить баги в XML-файл для специальной обработки или импорта в другую Bugzilla;
;Time Summary: перенаправляет на страницу просмотра отчётов по трудозатратам по выбранным багам (см. [[#Time Summary|Time Summary]]).
+
* '''Time Summary''' - перенаправляет на страницу просмотра отчётов по трудозатратам по выбранным багам (см. [[#Time Summary|Time Summary]]).
  
В нашей инсталляции [[Bugzilla]], есть также пункты:
+
В нашей инсталляции Bugzilla также есть пункты:
  
;Graph: Просмотр выбранного списка багов в виде ориентированного графа.
+
* '''Graph''' - просмотр выбранного списка багов в виде ориентированного графа;
;Summary Report: Просмотр табличной агрегации (См. [[#Отчеты]]) выбранного списка багов по выбранному срезу (набору атрибутов). Каждая ячейка табличного отчета будет содержать число багов, обладающих соответствующими атрибутами и ссылка на список этих багов. Таким образом, можно легко делать настоящий «OLAP drill-down», то есть формулировать «широкий запрос», переходя от списка к табличному отчету «раскладывать» по выбранным измерениям (от одного до трех), и далее, получать списки багов по отдельным ячейкам «среза», возможно повторяя процедуру раскладки по другим измерениям.
+
* '''Summary Report''' - просмотр табличной агрегации (. [[#Отчеты|Отчеты]]) выбранного списка багов по выбранному срезу (набору атрибутов). Каждая ячейка табличного отчета будет содержать число багов, обладающих соответствующими атрибутами и ссылка на список этих багов. Таким образом, можно легко делать настоящий '''OLAP drill-down''', то есть формулировать "широкий" запрос, переходя от списка к табличному отчету, раскладывать по выбранным измерениям (от одного до трех), и далее получать списки багов по отдельным ячейкам среза, возможно повторяя процедуру раскладки по другим измерениям.
  
= Заведение багов =
+
= Создание багов =
  
Процедура заведения бага следующая:
+
== Создание багов вручную ==
  
* Кликните на ссылке «New» в нижней или верхней линейке «Actions».
+
Процедура следующая:
* Выберите классификацию и продукт.
+
* Заполните поля. Уделите особое внимание атрибутам, идентифицирующим проблему или задание (что, где, насколько срочно) — [[#Component|Component]], [[#Version|Version]], [[#Severity|Severity]]. Старайтесь сделать так, что все, что написано в [[#Summary|summary]] также было записано (не обязательно дословно) в первом комментарии (поле [[#Comments|Description]]). Дело в том, что «summary» бага меняется, и нужно, чтобы первоначальная информация не пропадала.
+
* Нажмите «Commit» — это зафиксирует и отправит ваш «bug report».
+
  
Для быстрого заведения багов по образцу уже созданных например, если происходит декомпозиция крупной проблемы на мелкие можно применять [[#Клонирование|клонирование]] багов.
+
* Кликните на ссылке '''New''' в нижней или верхней линейке '''Actions''';
 +
* Выберите классификацию и продукт;
 +
* Заполните поля. Уделите особое внимание атрибутам, идентифицирующим проблему или задание (что, где, насколько срочно) Component, Version, Severity. Старайтесь дублировать (не обязательно дословно) содержимое Summary  в первом комментарии (поле '''Comments'''). Атрибут Summary может быть несколько раз отредактирован, что приведет к утере первоначального смысла бага;
 +
* Нажмите '''Commit''' это зафиксирует и отправит ваш bug report.
  
== Импорт багов из Excel-листов ==
+
Для быстрого заведения багов по образцу уже созданных — например, если происходит декомпозиция крупной проблемы на мелкие — можно применять [[#Клонирование бага|клонирование бага]].
  
Наша инсталляция Bugzilla 3 поддерживает массовый импорт багов из Excel-файлов — как бинарных <code>*.xls</code>, так и [[rupedia:Office_Open_XML|OOXML]] <code>*.xlsx</code>.
+
== Создание бага клонированием другого бага ==
  
Система подразумевает, что первая строка Excel-файла содержит заголовки колонок, а последующие — описания багов. Обязательными полями бага являются только [[#Product|продукт]], [[#Component|компонент]] и [[#Summary|заголовок]].
+
[[#Клонирование бага|См. ниже]]
  
Процедура импорта багов из Excel-файла следующая делится на два этапа. На первом этапе вы выбираете Excel-файл и устанавливаете начальные параметры импорта. На втором этапе система разбирает загруженный файл и отображает его на веб-странице для проверки и, возможно, изменения каких-либо полей, или сопоставления каких-либо полей колонкам таблицы.
+
== Импорт из Excel-файла ==
  
После проверки и нажатия «Import selected bugs» отображается страница с результатами импорта:
+
Bugzilla 3.0 поддерживает массовый импорт багов из Excel-файлов — как бинарных <code>*.xls</code>, так и [[rupedia:Office_Open_XML|OOXML]] <code>*.xlsx</code>.
  
* Либо с ошибкой, и в этом случае '''ни один''' из выбранных багов не импортируется, то есть, гарантируется транзакционность.
+
Система подразумевает, что первая строка Excel-файла содержит заголовки колонок, а последующие — описания багов. Обязательными полями бага являются  Product, Component и Summary.
* Либо с успехом, и в этом случае на странице будет текст «Successfully imported ''X'' bugs:» и список их ID со ссылками.
+
  
Итак, для запуска Excel-импорта:
+
Процедура импорта багов из Excel-файла следующая. Сначала вы выбираете Excel-файл и устанавливаете начальные параметры импорта. Далее система разбирает загруженный файл и отображает его на веб-странице для проверки и изменения каких-либо полей или сопоставления полей колонкам таблицы.
  
* Кликните на ссылке «New» в нижней или верхней линейке «Actions».
+
После проверки и нажатия '''Import selected bugs''' отображается страница с результатами импорта:
* Внизу страницы, под списком классификаций или продуктов, вы увидите ссылку «'''See also:''' Mass bug import from Excel files». Перейдите по этой ссылке.
+
* Выберите Excel-файл кликом по кнопке «Обзор…»
+
* Если ваш Excel-файл содержит несколько листов, а вы хотите импортировать только один из них, введите его название в поле «Enter sheet name to process:». Если вы хотите импортировать все листы, очистите это поле.
+
* После загрузки файла система автоматически проверяет список на наличие уже импортированных ранее багов по точного совпадению названия и максимальному возрасту бага, указываемому в днях в поле «Maximum bug duplicate age:». Поэтому, если вы производите повторный импорт файла (возможно, модифицированного), укажите такой максимальный возраст, чтобы баги, импортированные ранее из того же файла, попали в этот возраст.
+
* Если вы хотите установить значение определённых полей по умолчанию для всех импортируемых багов, можно выбрать поле, нажать «Add field value for all bugs» и заполнить выбранное поле.
+
* Нажмите кнопку «Parse File».
+
  
После нажатия кнопки «Parse File» будет показана страница с таблицей так, как её видит система. Если колонки в Excel-файле имели названия, совпадающие с названиями полей в багзилле, они автоматически сопоставятся нужным полям бага. Если же автоматическое сопоставление не удастся, то в любом случае по клику на название колонки будет показан выпадающий список для выбора нужного поля.
+
* с ошибкой, в этом случае '''ни один''' из выбранных багов не импортируется;
 +
* с успехом, в этом случае будет присутствовать текст '''Successfully imported ''X'' bugs''' и список ID созданных багов.
  
Значения полей, то есть значения ячеек, должны в точности соответствовать значениям полей в Bugzilla. Все поля отображаются редактируемыми, и вы можете исправить любые значения, если увидите несоответствия.
+
Для запуска Excel-импорта:
  
По результатам автоматической проверки существующих импортированных багов из списка будут установлены флажки слева каждой строки. По нажатию кнопки «Import selected bugs» будет предпринята попытка импорта ''только помеченных флажками'' багов.
+
* Кликните на ссылке '''New''' в нижней или верхней линейке '''Actions''';
 +
* Внизу страницы, под списком классификаций или продуктов, перейдите по ссылке '''See also: Mass bug import from Excel file''';
 +
* Выберите Excel-файл кликом по кнопке '''Обзор…''';
 +
* Если ваш Excel-файл содержит несколько листов, а вы хотите импортировать только один из них, введите его название в поле '''Enter sheet name to process'''. Если вы хотите импортировать все листы, очистите это поле;
 +
* После загрузки файла система автоматически проверяет список на наличие уже импортированных ранее багов по точному совпадению названия и максимальному возрасту бага, указываемому в днях в '''Maximum bug duplicate age'''. Поэтому, если вы производите повторный импорт файла (модифицированного), укажите такой максимальный возраст, чтобы баги, импортированные ранее из того же файла, попали в этот возраст;
 +
* Если вы хотите установить значение определённых полей по умолчанию для всех импортируемых багов, можно выбрать поле, нажать '''Add field value for all bugs''' и заполнить выбранное поле;
 +
* Нажмите кнопку '''Parse File'''.
  
Также после успешно выполненного импорта вы увидите ссылку «'''Import another Excel file''' — you can bookmark this link as a template». В этой ссылке сохранена вся информация о сопоставлении полей и значениях полей для всех багов по умолчанию. Поэтому, переходя по ней, вы сможете импортировать другой файл того же формата без лишних усилий. Также вы можете сохранить её в закладки браузера, и воспользоваться ей в будущем.
+
После нажатия кнопки '''Parse File''' будет показана страница с таблицей так, как её видит система. Если колонки в Excel-файле имели названия, совпадающие с названиями полей в Bugzilla, они автоматически сопоставятся нужным полям бага. Если автоматического сопоставления не произошло, кликом на название колонки можно выбрать нужное поле из выпадающего списка.
 +
 
 +
Значения полей (то есть значения ячеек) должны соответствовать значениям полей в Bugzilla. Все поля отображаются редактируемыми, вы можете исправить любые значения, если увидите несоответствия.
 +
 
 +
По результатам автоматической проверки существующих импортированных багов из списка будут установлены флажки слева каждой строки. По нажатию кнопки '''Import selected bugs''' будет предпринята попытка импорта '''только помеченных флажками''' багов.
 +
 
 +
После успешно выполненного импорта вы увидите ссылку '''Import another Excel file — you can bookmark this link as a template'''. В этой ссылке сохранена информация о сопоставлении полей и значениях полей для всех багов по умолчанию. Поэтому, переходя по ней, вы сможете импортировать другой файл того же формата без лишних усилий. Также вы можете сохранить ссылку в закладки браузера для использования в будущем.
  
 
= Редактирование багов =
 
= Редактирование багов =
  
Редактирование багов необходимо, для поддержания (и распространения по заинтересованным лицам) актуальной информации по обозначенной в описании бага проблеме или задаче.
+
Редактирование багов необходимо для поддержания (и распространения по заинтересованным лицам) актуальной информации по обозначенной в описании бага проблеме или задаче.
Редактирование бага включает изменение значений [[#Анатомия бага|атрибутов]] бага (причем ведется полная история их изменения, и написания комментариев (по сути рабочих журналов по решению проблемы).
+
Редактирование бага включает изменение значений [[#Анатомия бага|атрибутов]] бага (ведется история их изменения и написания комментариев).
То есть основной принцип «трекинга» — регистрация и хранение истории всех изменений. Поэтому, комментарии не удаляются и не редактируются, после того, как произошло их добавление в журнал комментариев к багу.
+
Основной принцип трекинга — регистрация и хранение истории всех изменений. Поэтому комментарии не удаляются после их добавления.
Кроме текстовых комментариев, можно также («аддитивно») регистрировать различные вложения («attachments») — логи ошибок, скриншоты, примеры патчей («patches»), и т. п.
+
Кроме текстовых комментариев, можно также добавлять различные вложения (attachments) — логи ошибок, скриншоты, примеры патчей (patches) и др.
  
В основном, редактированием основных атрибутов бага занимаются наиболее тесно связанные с багом
+
В основном редактированием основных атрибутов бага занимаются связанные с багом пользователи, указанные в атрибутах Reporter, Assigned To и QA Contact. Регламент работы с багом жестко не определен, любой пользователь, обладающий соответствующими правами, может изменять состояние и атрибуты бага.
участники, указанные в атрибутах [[#Reporter|Reporter]], [[#Assigned_To|Assigned_To]] и [[#QA|QA]], но конкретный регламент использования жестко не определен, и в принципе, любой пользователь (даже никак не связанный с багом), обладающий соотв. правами, может менять состояние бага и другие атрибуты.
+
  
 
Впрочем, обычно:
 
Впрочем, обычно:
* «Reporter» ответственен за указание атрибутов идентифицирующих проблему (что, где, насколько срочно) — [[#Product|Product]], [[#Version|Version]], [[#Severity|Severity]];
+
* Reporter ответственен за указание атрибутов, идентифицирующих проблему (что, где, насколько срочно) — Product, Version, Severity;
* «Assignee» определяет [[#Priority|Priority]], [[#Status|Status]], переводя баг по состояниям «NEW»-> «ASSIGNED»-> «RESOLVED».
+
* Assignee определяет Priority, Status, переводя баг по состояниям NEW -> ASSIGNED -> RESOLVED.
* «QA» определяет [[#Status|Status]], переводя баг из состояния «RESOLVED» в состояния «VERIFIED» или «REOPENED».
+
* QA Contact определяет Status, переводя баг из RESOLVED в VERIFIED или REOPENED.
  
Если в инсталляции включены функции регистрации времени (см., например, параметр «timetrackinggroup»), то можно, регистрировать предварительную оценку сложности задачи,
+
Если в инсталляции Bugzilla включены функции регистрации времени (например, параметр timetrackinggroup), то можно регистрировать предварительную оценку сложности задачи и с каждым комментарием свои трудозатраты, корректировать оценку оставшийся работы (См. [[#Учет времени (Time tracking)|Учет времени (Time tracking)]]).
и с каждым комментарием также регистрировать свои трудозатраты и корректировать оценку оставшийся работы (См. [[#Учет времени (Timetracking)]]).
+
  
В окне редактирования бага можно выяснить различные аспекты решаемой проблемы, зарегистрированные как в [[Bugzilla]]:
+
В окне редактирования бага можно выяснить различные аспекты решаемой проблемы, зарегистрированные в Bugzilla:
  
 
* Лента комментариев к багу, отсортированная по времени;
 
* Лента комментариев к багу, отсортированная по времени;
* Ссылка «View Bug Activity» ведет на историю изменения всех атрибутов бага;
+
* '''View Bug Activity''' - история изменения всех атрибутов бага.
 
+
* '''Look for Bug in CVS, SVN, <font color = "red">Git</font>''' - ссылка на страницу [[ViewVC]] — выполняет поиск в [[CVS]] и [[Subversion]] - репозитариях ревизий файлов, в комментариях к которым указан номер этого бага. Страница результатов поиска содержит также ссылки на другие действия с файлами. Оставленная до поры, до времени <sup>+Old</sup> — ссылка на аналогичную страницу поиска в [[Bonsai]] в будущем будет удалена. См. [[#Интеграция с системами контроля версий|интеграция с системами контроля версий]].
так и в других системах (есть в нашей инсталляции):
+
* '''Look for Bug in Wiki''' - перенаправляет на ассоциированную с багом статью Wiki см. [[#Интеграция с Wiki|Интеграция с Wiki]].
;Look for Bug in CVS/SVN: Ссылка на страницу [[ViewVC]] — выполняет поиск в [[CVS]] и [[Subversion]]-репозитариях ревизий файлов, в комментариях к которым указан номер этого бага. Страница результатов поиска содержит также и ссылки на различные другие действия с файлами. Оставленная до поры, до времени <sup>+Old</sup> — ссылка на аналогичную страницу поиска в [[Bonsai]] в будущем будет удалена. См. [[#Интеграция с системами контроля версий]].
+
;Look for Bug in Wiki: Перенаправляет на ассоциированную с багом статью. См. [[#Интеграция с Wiki]].
+
  
 
== Комментарии ==
 
== Комментарии ==
  
Заметим, что комментарии к багу нельзя редактировать задним числом (это принципиальная позиция),
+
<font color = "red">'''Заметим, что комментарии к багу нельзя редактировать задним числом (это принципиальная позиция)'''</font>, разве что член специальной группы '''insidergroup''' может сделать их '''private''' — невидимыми для обычных пользователей.
разве что член специальной группы «insidergroup» может сделать их «private» — невидимыми для обычных пользователей.
+
  
В нашей инсталляции можно воспользоваться ссылкой «Preview» (например, проверить, правильно ли «прогиперлинкуются» различные ссылки, см. [[#Автоматические ссылки]]), и убедившись, что все хорошо, вернуться кнопкой «Back» броузера и выполнить «Commit».
+
В нашей инсталляции Bugzilla можно воспользоваться ссылкой '''Preview''' (например, проверить, правильно ли гиперлинкуются ссылки, см. [[#Автоматические ссылки|Автоматические ссылки]]), и убедившись, что все хорошо, вернуться кнопкой браузера '''Назад''' и выполнить '''Commit'''.
  
В стандартной инсталляции для этого можно использовать страничку c адресом вида:
+
В стандартной инсталляции для этого можно использовать страничку c адресом вида
http://bugs.office.custis.ru/bugs/page.cgi?id=linkify.html
+
http://bugs.office.custis.ru/bugs/page.cgi?id=linkify.html
  
== Клонирование ==
+
== Клонирование бага ==
Для быстрого заведения новых багов (схожих с имеющимися) — например, если необходимо провести декомпозицию, то есть выделить некоторую подзадачу из крупной задачи, можно применять «клонирование», вызываемое ссылкой «Clone This Bug to other/same product».
+
  
Клонирование бага приводит к заведению бага унаследовавшего все атрибуты (заполнять которых с нуля может быть очень муторно и долго) от исходного бага + являющегося блокирующим для родительского бага (впрочем, при клонировании можно и подредактировать родительские атрибуты и отказаться от блокирования родительского бага). «Клонирование в тот же продукт» выделено отдельной ссылкой, так как это ускоряет наиболее распространенный сценарий клонирования, исключая одну или две страницы выбора продукта.
+
Для быстрого заведения новых багов (схожих с имеющимися) — например, если необходимо выделить подзадачу из крупной задачи, можно применять клонирование бага:
 +
* ссылка '''clone to other/same/int product''' на первом комментарии;
 +
* ссылка '''Clone This Bug''' внизу страницы (аналог clone to '''other''' product на первом комментарии).
  
В нашей инсталляции также можно клонировать в баг любой комментарий исходного бага — через ссылку «clone as bug» над комментарием.
+
Клонирование бага приводит к созданию бага, унаследовавшего все атрибуты и являющегося блокирующим для исходного (родительского) бага. Впрочем, при клонировании можно редактировать родительские атрибуты и отказаться от блокирования родительского бага.
  
= Полезности =
+
В нашей инсталляции Bugzilla также можно клонировать в баг любой комментарий исходного бага ссылкой '''clone to other/same/int product''' на комментарии.
  
== Автоматические ссылки ==
+
= Полезности Bugzilla =
Комментарии в Bugzilla разрешены только plain текстом, то есть печатая <pre><U></pre> вы получите не подчеркнутый текст, а <pre><U></pre>
+
  
Также нет списков и иных структурных элементов. Тем не менее, Bugzilla делает гиперссылки для определенного рода комментариев, например распознаются и «гиперлинкуются» основные типы URL, типа:
+
== Автоматические ссылки ==
 +
Комментарии в Bugzilla разрешены только plain текстом, то есть печатая <pre><U></pre> вы получите не подчеркнутый текст, а <pre><U></pre>.
 +
Также нет списков и иных структурных элементов. Тем не менее, Bugzilla делает гиперссылки для определенного рода комментариев, например распознаются и гиперлинкуются основные типы URL:
 
* «<nowiki>http://</nowiki>»,
 
* «<nowiki>http://</nowiki>»,
 
* «<nowiki>ftp://</nowiki>»,
 
* «<nowiki>ftp://</nowiki>»,
 
* «<nowiki>mailto:</nowiki>»,
 
* «<nowiki>mailto:</nowiki>»,
* почтовые адреса «someone@somewhere.org».
+
* почтовые адреса someone@somewhere.org.
 +
 
 
Дополнительно гиперлинкуются ссылки на внутрибагзильные элементы (баги, комменты, вложения):
 
Дополнительно гиперлинкуются ссылки на внутрибагзильные элементы (баги, комменты, вложения):
  
Line 445: Line 409:
 
== Интеграция с системами контроля версий ==
 
== Интеграция с системами контроля версий ==
  
Очень важно, описать связь между багами (заданиями или сообщениями об ошибках) и производимым (или исправляемым) Разработчиком артефактом — программным кодом (включая документацию). В нашей Компании, весь код (то есть практически все производимое Разработчиком) находится в репозиториях принятых в Компании систем управления версиями [[CVS]] и [[Subversion]].
+
Очень важно описать связь между багами (заданиями или сообщениями об ошибках) и производимым (исправляемым) разработчиком артефактом — программным кодом (включая документацию). В нашей Компании весь код (то есть практически все производимое разработчиком) находится в репозиториях принятых в Компании систем управления версиями [[CVS]] и [[Subversion]] и <font color = "red">'''Git'''</font>.
 +
 
 +
Наша инсталляция Bugzilla интегрирована с системой [[ViewVC]], в которую оперативно загружается информация о всех правках в [[CVS]]- и [[Subversion]]-репозиториях Компании. Поэтому, если при работе над багом XXX ведутся правки файлов, находящихся под [[CVS]] или [[Subversion]], при фиксации (выполнении commit) не нужно писать длинных комментариев, описывающих суть изменений, а достаточно указать номер бага. Например, выполнить
  
Наша инсталляция [[Bugzilla]] интегрирована с системой [[ViewVC]], в которую оперативно загружается информация о всех правках в [[CVS]] и [[Subversion]]-репозитариях Компании. Поэтому, если при работе над багом XXX, ведутся правки файлов, находящихся под [[CVS]] или [[Subversion]], то при фиксации, (то есть при выполнении «commit») не нужно писать длинных комментариев, описывающих суть изменений, а достаточно указать идентификатор заявки/задания (номер бага), например, выполнить
 
 
  <nowiki>cvs commit -m "Bug 1234"</nowiki>
 
  <nowiki>cvs commit -m "Bug 1234"</nowiki>
Комментарий можно вводить и через опции командной строки и через редактор, см. ссылки на документацию в [[CVS]], [[Subversion]].
 
  
При соблюдении этого правила, для каждой заявки можно найти все коммиты, в комментариях к которым указан номер этой заявки, с помощью ссылки «Look for Bug in CVS/SVN» на странице редактирования бага.
+
Комментарий можно вводить и через опции командной строки, и через редактор, см. ссылки на документацию в [[CVS]], [[Subversion]].
 +
 
 +
При соблюдении этого правила для каждого бага можно найти все commit'ы, в комментариях к которым указан номер этого бага, с помощью ссылки '''Look for Bug in CVS, SVN, Git''' на странице бага.
  
Ранее похожую функцию выполнял [[Bonsai]], однако был сделан переход на [[ViewVC]] по причине поддержки не только системы контроля версий [[CVS]], но также и [[Subversion]] последним. Посему ссылки «Look for Bug in CVS/SVN» теперь ведут именно в [[ViewVC]].
+
Ранее похожую функцию выполнял [[Bonsai]], однако был сделан переход на [[ViewVC]] по причине поддержки не только системы контроля версий [[CVS]], но также и [[Subversion]] последним. Посему ссылки '''Look for Bug in CVS, SVN, Git''' теперь ведут именно в [[ViewVC]].
  
 
== Интеграция с Wiki ==
 
== Интеграция с Wiki ==
  
[[Bugzilla]] не является инструментом, подходящим для совместной работы над любым документом (пусть даже одностраничным), поэтому, при возникновении спорной или дискуссионной ситуации, когда нужно выработать постановку задачи (пусть даже и локальной), нужно использовать подходящий для этого инструмент: [[WikiWiki]]-систему.
+
Bugzilla не является инструментом, подходящим для совместной работы над любым документом, поэтому при возникновении спорной или дискуссионной ситуации, когда нужно выработать постановку задачи, нужно использовать подходящий для этого инструмент - Wiki-систему.
  
В нашей инсталляции Bugzilla, дополнительно к возможностям [[#Автоматические ссылки]],
+
В нашей инсталляции Bugzilla дополнительно к возможностям [[#Автоматические ссылки|автоматических ссылок]] можно делать читаемые гипертекстовые ссылки на статьи (разделы статей) в [[CustisWiki]], например:
можно делать читаемые гипертекстовые ссылки на статьи (и разделы статей) в
+
[[CustisWiki]], например
+
  
 
<pre>
 
<pre>
 
wiki:Bugzilla#Автоматические_ссылки
 
wiki:Bugzilla#Автоматические_ссылки
wiki:[[Bugzilla#Интеграция с Wiki]]
+
wiki:[[Bugzilla#Автоматические ссылки]]
 
</pre>
 
</pre>
  
 
будет ссылаться на [[Bugzilla#Автоматические_ссылки]].
 
будет ссылаться на [[Bugzilla#Автоматические_ссылки]].
  
 +
Если при работе над багом требуется сделать документ-постановку задачи и/или провести его обсуждение, можно воспользоваться ссылкой '''Look for Bug in Wiki''' на странице бага и перейти к одноименной с багом статье '''<nowiki>Bug XXX</nowiki>''' для чтения/редактирования/обсуждения.
  
 +
Рекомендуется после заведения статьи выполнить ее переименование (закладка '''move/переименовать''') в более понятное название, например «Ошибка ORA-YYY при загрузке каталога (Bug XXX)», copy-paste атрибута Summary.
  
Если при работе над багом (заданием или запросом), требуется сделать документ-постановку задачи и/или провести его обсуждение, то можно воспользоваться ссылкой «Look for Bug in Wiki» на странице редактирования бага, и мгновенно перейти к одноименной с багом статье «<nowiki>Bug XXX</nowiki>», для чтения/редактирования/обсуждения.
+
Таким образом, будет создана статья с смысловым заголовком и статья-перенаправление «Bug XXX».
  
Рекомендуется после заведения статьи выполнить ее переименование (закладка «move/переименовать») в более дескриптивное название, например «Ошибка ORA-YYY при загрузке каталога (Bug XXX)» (что можно сделать в два клика используя только copy-paste атрибута «Summary» бага и мышь).
+
Однако, стоит помнить, что в [[{{SITENAME}}]] не стоит помещать конфиденциальную информацию, так как тут уже не действует система прав Bugzilla.
  
Таким образом, будет создана статья с смысловым заголовком, и статья-перенаправление «Bug XXX».
+
== Учет времени (Time tracking) ==
Однако, стоит помнить, что в [[{{SITENAME}}]] не стоит помещать конфиденциальную информацию, так как тут уже не действует система прав [[Bugzilla]].
+
  
== Учет времени (Timetracking) ==
+
Пользователи, входящим в группу timetrackinggroup, могут вести учет трудоемкости каждого бага.
Пользователи, входящие в группу, указанную в настройках как «timetrackinggroup», могут вести учет трудоемкости каждого бага.
+
  
Для каждого бага ведется учет следующих полей
+
Ведется учет следующих полей:
 +
* '''Orig. Est.''' - начальная оценка трудоемкости бага. Разумно использовать как априорную оценку трудоемкости. Хотя ее можно менять, лучше это делать реже, чтобы сохранился смысл априорной оценки, данной разработчиком или руководителем проекта;
 +
* '''Current Est.'''- текущая оценка трудоемкости бага. Вычислимое поле, является суммой Hours Worked и Hours Left;
 +
* '''Hours Worked'''- число затраченных часов. Только увеличивается с каждым редактированием;
 +
* '''Hours Left''' - осталось затраченных часов. Изначально выставляется, как разница Current Est. и Hours Worked, но будучи отредактированным, влияет на Current Est. Например, если считалось, что на баг надо затратить 5 часов, а после некоторой работы выяснилось, что затрачено 3 часа, а осталось еще 7, то текущая оценка меняется на 10 часов.
 +
* '''% Complete''' - процент завершенности. Вычислимое поле, равно Hours Worked/Current Est.
 +
* '''Gain''' - Выигрыш. Вычислимое поле, является разностью Orig. Est. и Current Est.
 +
* '''Deadline''' - крайний срок решения/выполнения бага.
 +
Единица измерения — часы. Можно вводить дробные значения <tt>1.5</tt> = полтора часа.
  
; «Orig. Est.»: Начальная оценка трудоемкости бага. Разумно использовать как априорную оценку трудоемкости. Хотя ее можно менять, лучше это делать реже — то есть чтобы сохранился смысл априорной оценки, данной разработчиком или руководителем проекта.
+
== Time Summary ==
; «Current Est.»: Текущая оценка трудоемкости бага. Вычислимое поле, вычисляется как сумма «Hours Worked»+ «Hours Left».
+
; «Hours Worked»: Число затраченных часов времени. Может только увеличиваться с каждым редактированием.
+
; «Hours Left»: Осталось затратить времени. Изначально выставляется, как «Current Est.»- «Hours Worked», но будучи отредактированным, влияет на «Current Est.». То есть например, если считалось, что на баг надо затратить 5 часов, а после некоторой работы выяснилось, что затрачено 3 часа, а осталось еще 7, то текущая оценка меняется на 10 часов.
+
; «%Complete»: Процент завершенности — вычислимое поле, «Hours Worked»/«Current Est.».
+
; «Gain»: Выигрыш. Вычислимое поле — разность «Orig. Est.» — «Current Est.».
+
  
Единица измерения — часы. Можно вводить нецелые значения <tt>1.5</tt> — полтора часа.
+
Отчет Time Summary для выбранного списка багов показывает зарегистрированные трудозатраты за заданный период с группировкой по месяцам, с разбивкой по сотрудниками или багам.
  
 +
= Советы по использованию Bugzilla =
  
 +
В процессе использования Bugzilla было сделано много доработок. О них можно очень кратко прочитать здесь [[Bugzilla: Список доработок#Доработки 3.x]]
  
 +
* Поддерживайте целостность:
 +
** Дублируйте содержимое Summary в первом комментарии,
 +
** Указывайте корректные значения в полях или не указывать никаких. Например, не пишите строки «any», «нет», "-" и прочее в '''URL''', если нет конкретного связанного с багом URL.
  
=== Time Summary ===
+
* Вложения
Отчет «Time Summary», для выбранного списка багов показывает зарегистрированные трудозатраты за заданный период, с группировкой по месяцам, в разбивке по сотрудниками или багам.
+
** Используйте вложения, а не комментарии для больших блоков текстовых данных, таких как отладочная информация, логи и т. п. Иначе комментарии к багу будет неудобно читать, а связанные пользователи получат бессмысленные письма.
 +
Сделана специальная доработка ({{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, то есть <nowiki>&content-type=text/plain</nowiki>.
  
= Советы =
+
* Комментирование
 +
Если вы изменяете баг, добавляйте комментарий, только если вам действительно есть что сказать  или если этого требует Bugzilla (для некоторых типов переходов). В противном случае, вы будете без нужды засыпать письмами [[#Связанные пользователи|связанных с багом пользователей]]. Например, люди могут настроить свой аккаунт (см. [[#Email preferences|Field/recipient specific options]]), чтобы не получать извещений при событиях вида «Изменился CC List». Но если доброжелатель добавляя себя, добавит комментарий «Я, типа, себя добавил», это будет уже добавление комментария и обойдет вышеуказанный фильтр.
  
В процессе использования Bugzilla было сделано много доработок. О них можно кратко (очень кратко) прочитать здесь [[Bugzilla: Список доработок#Доработки 3.x]]
+
Не используйте подписей в комментариях, особенно модные многострочные подписи с ASCII-картинками.
  
== Поддерживайте целостность ==
+
* Конфликты
  
* Старайтесь сделать так, что все, что вы написано в «summary» также было записано в первом комментарии. Дело в том, что «summary» бага часто меняют, и нужно, чтобы первоначальная информация не пропала.
+
Если вы считаете, что отправленный вами баг некорректно помечен как '''DUPLICATE of another''', задавайте вопросы-комментарии в вашем баге, а не в том, который считается багом-оригиналом. Смело добавляйте в '''CC List''' бага человека, который принял такое решение, если его нет.
* Старайтесь указывать корректные значения в полях или не указывать никаких. Например, не пишите строки «any», «нет» и подобный мусор в поле «URL», если нет никакого конкретного URL, который связан с данным багом.
+
  
== Вложения ==
+
= Флаги=
Используйте вложения, а не комментарии, для больших блоков текстовых данных, таких как отладочная информация, логи и т. п. Иначе комментарии к багу станет невозможно читать, да и люди получать бессмысленные жирные письма.
+
  
Сделана специальная доработка ({{Bug|15001}} и {{Bug|53638}}, которая позволяет присоединить текстовое вложение к багу через буфер обмена, без создания файла, с одновременным добавлением комментария, фиксацией времени и изменением некоторых других атрибутов бага. Таким образом, если Вы получили текстовое сообщение об ошибке с большим стеком, то надо не писать комментарий, а добавить вложение, где вставить это сообщение в текстовое окно вложения (переключив  radio button Enter text), а ниже написать комментарий, где кратко сформулировать ошибку.
+
Флаг — это некий атрибут, разновидность статуса, который может быть установлен на баг или вложение, чтобы указать, что этот баг/вложение находятся в некотором состоянии. Каждая инсталляция Bugzilla может определить свой собственных набор флагов, которых можно устанавливать на баг или вложение. Флаги в отличие от ключевых слов, имеющих «глобальную область» видимости для всех продуктов и компонентов, можно делать локальными, устанавливая набор продуктов и компонентов, в которых может быть установлен этот флаг.
  
Обрезайте и сжимайте скриншоты. Нет необходимости показывать весь экран, если вы хотите указать на проблему в одном окне.
+
Вы можете установить или сбросить флаг, также разрешена функция запроса флагов - вы можете запрашивать другого пользователя установить флаг.
  
Не вкладывайте простые тестовые примеры (например HTML файл, ссылающийся на CSS и картинку) как архив. Вместо этого загрузите перечисленные файлы в обратном порядке, и отредактируйте вкладываемый HTML-файл, чтобы он ссылался непосредственно на загруженные вложения.
+
Чтобы установить флаг, выберите '''+''', или '''-''' из выпадающего списка '''Flags'''. Значение этих символов зависит от флага? в качестве примера, установление флага review в '''+''' может означать, что баг или вложение одобрены, а в '''-''' — отклонены. Чтобы сбросить флаг, выберите в выпадающем списке пустое значение.
  
Bugzilla хранит и использует «Content-Type» для каждого вложения (например «text/html»). Чтобы выгружать вложение с другим «Content-Type» (например «application/xhtml+xml»), надо добавить CGI-параметр «content-type» в URL, то есть <nowiki>&content-type=text/plain</nowiki>.
+
Чтобы сделать запрошенный флаг, установите флаг в '''?''' и введите имя пользователя, у которого запрашиваете установку флага.
  
== Комментирование ==
+
В нашей инсталляции Bugzilla есть доработка, позволяющая не вводить пользователей для запрашиваемых флагов вручную, а выбирать из списка связанных с багом пользователей (Reporter, Assignee, QA Contact, CC List).
Если вы изменяете баг, добавляйте комментарий только если вам действительно есть что сказать по делу, или если этого требует Bugzilla (для некоторых типов переходов). В противном случае, вы можете без нужды «заспамить» невинных людей. Например, люди могут настроить свой аккаунт (См. [[#«Field/recipient specific options»]]) чтобы не получать извещений при событиях вида «изменился CC». Но если доброжелатель добавляя себя, добавит еще комментарий «Я, типа, себя добавил», то это будет уже добавление комментария и это обойдет вышеуказанный фильтр.
+
  
Не используйте подписей в комментариях, особенно, модные многострочные подписи с ASCII-картинками.
+
Установленный флаг показывается на странице бага и странице '''edit attachment''' рядом с аббревиатурой установившего флаг пользователя. Например: <tt>Иван: review [ + ]</tt>.
 +
Аналогично показывается запрошенный флаг, только в скобках показывается имя пользователя, у которого запрошена установка флага, например <tt>Иван: review [ ? ] (Бибичев)</tt>.
  
== Конфликты ==
+
= Отчеты и графики =
  
Если вы считаете, что отправленный вами баг некорректно помечен как «DUPLICATE of another», пожалуйста, задавайте вопросы-комментарии в вашем баге, а не в том, который считается багом-оригиналом. Смело добавляйте в «CC» бага человека, который принял такое решение, если его в «CC» нет.
+
В дополнение к стандартному списку багов Bugzilla имеет некоторые аналитические возможности — просмотр количества зарегистрированных багов в виде таблиц и графиков с возможностью задания среза (перспективы) агрегации, а также графики, показывающие динамическое изменение состояния багов по времени.
  
= Флаги =
+
== Отчеты==
 
+
Флаг — это некий атрибут, разновидность статуса, который может быть установлен на баг или вложение, чтобы указать, что этот баг/вложение находятся в некотором состоянии. Каждая инсталляция может определить свой собственных набор флагов, которых можно устанавливать на баг или вложение. Более того, флаги, в отличие от ключевых слов, имеющих «глобальную область» видимости для всех продуктов и компонентов, можно делать локальными, устанавливая набор продуктов и компонентов, в которых может быть установлен этот флаг.
+
 
+
Если некий флаг определен в вашей конфигурации багзилла, то вы можете установить или сбросить этот флаг, и если разрешена функция запроса флагов (разрешается администратором системы), вы можете запрашивать другого пользователя установить флаг.
+
 
+
Чтобы установить флаг, выберите «+», или «-» из выпадающего списка за списком «Flags». Значение этих символов зависит от флага и в этой документации описано быть не может, но в качестве примера, установление флага «review» в «+» может означать что баг или вложение одобрены, а «-» — отклонены. Чтобы сбросить флаг, выберите в выпадающем списке пустое значение.
+
 
+
Если разрешено администратором, можно также делать «запрошенный флаг», устанавливая флаг в «?» и вводя рядом имя пользователя, от которого желается установка флага.
+
 
+
Установленный флаг показывается на странице бага и странице «edit attachment», рядом с аббревиатурой установившего флаг пользователя. Например: <tt>Иван: review [ + ]</tt>.
+
Аналогично показывается запрошенный флаг, только в скобках показывается имя пользователя, у которого запрошена установка флага, например <tt>Иван: review [ ? ] (Бибичев)</tt>.
+
 
+
В нашей инсталляции есть доработка, позволяющая не вводить «запрашиваемых флагами» пользователей руками, а выбирать их из списка пользователей ассоцированных с багом (Reporter, Assignee, QA, CC…).
+
 
+
= Отчеты и графики =
+
В дополнение к стандартному списку багов, багзилла имеет некоторые аналитические возможности — просмотр количества зарегистрированных багов в виде таблиц и графиков, с возможностью задания среза (перспективы) агрегации, + графики показывающие динамическое изменение состояния багов по времени.
+
  
== Отчеты ==
 
 
Отчет представляет собой некий информационный срез о текущем состоянии базы зарегистрированных багов. Можно сделать отчет как обычным, HTML-табличным, так и графическим, с различными видами графиков: линейными, круговыми, гистограммы (line/pie/bar), и переключаться между этими режимами просмотра онлайн.
 
Отчет представляет собой некий информационный срез о текущем состоянии базы зарегистрированных багов. Можно сделать отчет как обычным, HTML-табличным, так и графическим, с различными видами графиков: линейными, круговыми, гистограммы (line/pie/bar), и переключаться между этими режимами просмотра онлайн.
  
Очень удобно, что эти отчеты задаются с помощью стандартного интерфейса запросов и компактного интерфейса, определяющего выбор и расположение одного до трех измерений, по которым будет идти агрегация («трехмерная агрегация» это когда на выходе будет соответственно набор двухмерных таблиц или графиков).
+
Очень удобно, что эти отчеты задаются с помощью стандартного интерфейса запросов и компактного интерфейса, определяющего выбор и расположение от одного до трех измерений, по которым будет идти агрегация (трехмерная агрегация — когда на выходе будет набор двухмерных таблиц или графиков).
  
Например, можно выбрать в поисковой форме «все баги в продукте XXX» и затем отрисовать их серьезность относительно каждого компонента продукта, чтобы увидеть, какой компонент имеет наибольшее число серьезных проблем.
+
Например, можно выбрать в поисковой форме все баги в продукте XXX и затем отрисовать их серьезность относительно каждого компонента продукта, чтобы увидеть, какой компонент имеет наибольшее число серьезных проблем.
  
Или разработчик может выбрать все «свои» баги, распределив их по «критичности» и своей оценке приоритета, получив следующую таблицу, где каждая ячейка (например, «(major,P2)=> ) является гиперссылкой на выборку соответствующих багов (то есть, в данном случае, двух багов, у которых, в дополнению к условиям общего запроса «Severity=major», а «Priority=P2»):
+
Или разработчик может выбрать все свои баги, распределив их по критичности и своей оценке приоритета, получив следующую таблицу, где каждая ячейка (например, (major,P2)=> 2) является гиперссылкой на выборку соответствующих багов (в данном случае, двух багов, у которых в дополнение к условиям общего запроса Severity=major, а Priority=P2):
  
 
             Priority
 
             Priority
Line 565: Line 523:
 
   Total        10      2      5    3    20
 
   Total        10      2      5    3    20
  
От выборки багов можно снова перейти к таблице и продолжить детализацию далее
+
От выборки багов можно снова перейти к таблице и продолжить детализацию далее (см. описание Summary report в [[#Списки багов|списках багов]].
(см. описание «Summary report» в [[#Списки багов]]).
+
  
 +
После заполнения параметров и вызова '''Generate Report''' вы можете переключаться между форматами HTML, CSV, Bar, Line, Pie (формат Pie доступен, если вы определили только одну горизонтальную ось). Остальные интерфейсные элементы интуитивно понятны — можно изменять размер картинки, если текст наползает графику или слишком узкие столбцы гистограмм.
  
После того как вы заполнили параметры выборки и вызвали «Generate Report», вы можете переключаться между форматами «HTML», «CSV», «Bar», «Line», «Pie» (Формат «Pie» доступен если вы определили только одну горизонтальную ось). Остальные интерфейсные элементы интуитивно понятны — можно изменять размер картинки, если текст наползает графику или слишком узкие столбцы гистограмм.
+
В нашей инсталляции Bugzilla кроме числа багов можно просматривать агрегированные временные параметры бага:
 
+
В нашей инсталляции, кроме числа багов, можно просматривать агрегированные временные параметры бага:
+
 
* Remaining time;
 
* Remaining time;
 
* Estimated time.
 
* Estimated time.
  
То есть в вышеприведенном примере, разработчик может оценивать свою загрузку в временных единицах, сколько часов требуется от него на баги различной серьезности (и поможет например, ответить на вопрос — можно ли будет позволить себе отпуск в ближайший месяц или нет):
+
В примере выше разработчик может оценивать свою загрузку во временных единицах, сколько часов требуется на баги различной серьезности, что поможет ответить на вопрос — можно ли будет позволить себе отпуск в ближайший месяц:
  
 
           Priority
 
           Priority
Line 586: Line 542:
 
  Total          79.5  189      30      195    493.5
 
  Total          79.5  189      30      195    493.5
  
== Динамические графики (Charts) ==
+
== Динамические графики (Charts)==
 +
 
 +
Динамические график (chart, чарт) — это просмотр эволюции состояния базы багов во времени.
  
Динамические график, чарт (chart) это просмотр эволюции состояния базы багов по времени.
+
В данный момент в Bugzilla есть две системы построения таких графиков '''Old Charts''' и '''New Charts'''.
  
В данный момент в Bugzilla есть две системы построения таких графиков — «Old Charts» и «New Charts». «Old Charts» — это старая, давно используемая система, она отображает только изменения статусов и решений багов для каждого продукта. Она более не поддерживается и не развивается и будет вскоре исключена из системы. Развиваться будет система «New Charts», которая позволяет отрисовывать все, что можно задать поисковым запросом.
+
'''Old Charts''' — это старая, давно используемая система, она отображает только изменения статусов и решений багов для каждого продукта. Она более не поддерживается и не развивается, и будет вскоре исключена из системы. Развиваться будет система '''New Charts''', которая позволяет отрисовывать все, что можно задать поисковым запросом.
  
Обе системы требуют, чтобы администратор настроил скрипт собирающий данные.
+
Обе системы требуют, чтобы администратор настроил скрипт, собирающий данные.
  
Каждая отдельная линия в чарте представляется датасетом «data set», которые упорядочены в категории и подкатегории. Автоматически опеределяются категории/подкатегории на основе отношений Продукт/Компонент (для всех продуктов и компонентов), но также можно определять и любые другие категории.
+
Каждая отдельная линия в чарте представляется датасетом '''data set''', которые упорядочены в категории и подкатегории. Категории/подкатегории автоматически определяются на основе отношений Продукт/Компонент (для всех продуктов и компонентов), но также можно определять и любые другие категории.
  
Датасеты могут быть публичными, которых могут видеть все, или приватными, доступными только создателю. Причем сделать датасет публичным могут только администраторы.
+
Датасеты могут быть публичными (видимыми для всех) и приватными (доступными только создателю). Сделать датасет публичным могут только администраторы.
  
Датасеты, даже приватные не должны пересекаться по набору (Категория, Подкатегория, Имя). Поэтому личные датасеты лучше заводить под Категорией со своим именем.
+
Датасеты не должны пересекаться по набору (Категория, Подкатегория, Имя) - даже приватные. Поэтому личные датасеты лучше заводить под Категорией со своим именем.
  
=== Создание Динамических Графиков ===
+
* Создание Динамических графиков
  
Для создания чарта, надо для каждого нужного датасета, выбрать его в списке и нажать «Add To List». В списке «List Of Data Sets To Plot» вы можете задать название-заголовок для каждого отображаемого датасета, также можно заказать суммирование подмножества выбранных датасетов (то есть можно просуммировать датасеты представляющие баги в состоянии RESOLVED, VERIFIED и CLOSED для выбранного продукта, тем самым получив полное число исправленных багов). Ошибочно добавленный датасет можно исключить с помощью чекбокса и «Remove». Если вы добавили больше чем один датасет, то в списке автоматически появится линия «Grand Total». Если она не нужна, то ее можно также удалить, как и любую другую линию.
+
Для создания динамического графика необходимо выбрать в списке требуемые датасеты и нажать '''Add To List'''. В списке '''List Of Data Sets To Plot''' вы можете задать название для каждого отображаемого датасета, также можно заказать суммирование подмножества выбранных датасетов (то есть просуммировать датасеты? представляющие баги в состоянии RESOLVED, VERIFIED и CLOSED для выбранного продукта, получив полное число исправленных багов). Ошибочно добавленный датасет можно исключить с помощью чекбокса и '''Remove'''. Если вы добавили более одного датасета, в списке автоматически появится линия '''Grand Total'''. Если она не нужна, ее можно удалить, как и любую другую линию.
  
Также можно выбрать отрисовку только в определенном диапазоне дат, и аккумулирование результатов, то есть режим, когда каждая линия представляет собой сумму своего датасета и нижележащей линии, и верхняя линия представляет собой сумму всех датасетов. Лучше попробуйте, это проще, чем пытаться обьяснить.
+
Также можно выбрать отрисовку только в определенном диапазоне дат, и аккумулирование результатов (режим, когда каждая линия представляет собой сумму своего датасета и нижележащей линии? и верхняя линия представляет собой сумму всех датасетов). Лучше попробуйте - это проще, чем пытаться объяснить.
  
Для всех выбранных в список датасетов, если вы являетесь его владельцем или администратором можно редактировать его параметры — название, частоту и т. п.
+
Для всех выбранных в список датасетов, если вы являетесь его владельцем или администратором, можно редактировать его параметры — название, частоту и др.
  
По окончании настроек нажмите «Chart This List» для получения чарта.
+
По окончании настроек нажмите '''Chart This List''' для получения чарта.
  
=== Создание новых датасетов ===
+
* Создание датасетов
  
Для создания нового датасета следуйте ссылке «create a new data set» на странице «Create Chart». Там вы, используя стандартный интерфейс выбора определите нужную выборку, а внизу страницы, определите категорию, подкатегорию и имя для нового датасета.
+
Для создания нового датасета следуйте ссылке '''create a new data set''' на странице '''Create Chart'''. Используя стандартный интерфейс выбора определите нужную выборку, внизу страницы определите категорию, подкатегорию и имя для нового датасета.
  
 
Если вы обладаете достаточными полномочиями, вы можете сделать датасет общедоступным, и сделать частоту сбора данных меньшей, чем неделя (значение по умолчанию).
 
Если вы обладаете достаточными полномочиями, вы можете сделать датасет общедоступным, и сделать частоту сбора данных меньшей, чем неделя (значение по умолчанию).
Line 618: Line 576:
 
= Настройки пользователя =
 
= Настройки пользователя =
  
После того, как вы войдете в систему, вы можете поменять личные настройки Bugzilla, по ссылке «Edit prefs» внизу страницы.
+
После того, как вы войдете в систему, вы можете изменить личные настройки Bugzilla по ссылке '''Preferences'''.
Настройки разбиты на три группы-закладки:
+
  
== Account Settings ==
+
Настройки расположены на пяти вкладках: General preferences, Email preferences, Saved searches, Name and password, Permissoins. Рассмотрим подробнее каждую из них.
На этой закладке, вы можете менять основную информацию вашей личной записи — пароль, e-mail, настоящее имя. По соображениям безопасности, при изменении любых параметров на этой странице, вы должны подтвердить изменение вводом своего пароля. Если вы меняете своей email, то по обоим (старому и новому) адресам будет выслано письмо со ссылкой на подтверждение изменения.
+
  
== General Settings ==
+
== General preferences ==
  
Содержит простые настройки общеинтерфейсного плана.
+
Вкладка содержит простые настройки общеинтерфейсного плана.
  
В нашей инсталляции, мы дополнительно включили настройки:
+
В нашей инсталляции Bugzilla дополнительно включены настройки:
 +
* '''After changing a bug''' - по умолчанию, после правки бага Bugzilla перенаправляет на следующий баг в списке, однако большинство людей это смущает, и они путают следующий баг с предыдущим. Для борьбы с этим поведением и служит данная опция. Нужно выбрать '''Show the updated bug''';
 +
* '''Remind me to track worktime for each comment''' - запрос затраченного времени, если пользователь из '''timetrackinggroup''' не заполнил (поставил 0) в '''Hours Worked''' при введении комментария;
 +
* '''Remind me to track worktime for new bug''' - требование введения трудозатрат от пользователя из '''timetrackinggroup''' при постановке каждого нового бага;
 +
* '''Remind me about flag requests''' - при вводе комментария пользователем, на которого поставлены флаги-запросы (флаги в состоянии '''?''', у которых '''requestee''' = этому пользователю) — будет проверять и переспрашивать, не желает ли пользователь изменить состояния флагов (ответил ли он своим комментарием на эти вопросы).
  
;"After changing a bug": по умолчанию, после правки бага [[Bugzilla]] перенаправляет на следующий баг в списке, однако большинство людей это смущает и они путают этот «следующий» баг с предыдущим. Для борьбы с этим поведением и служит данная опция. Её нужно установить в «Show the updated bug».
+
== Email preferences ==
  
;"Remind me to track worktime for each comment": Будет дозапрашивать затраченное время, если пользователь из Timetracking Group не заполнил (или поставил «0») в трудозатраты («Hours Worked») при введении комментария.
+
Эти настройки определяют когда и сколько писем будет вам прислать Bugzilla. Если вы хотите получать все письма — нажмите кнопку '''Enable All Mail''', если не хотите получать письма от Bugzilla вообще — нажмите '''Disable All Mail'''.
;"Remind me to track worktime for new bug": Будет требовать введения трудозатрат от пользователя из Timetracking Group, при постановке каждого нового бага.
+
;"Remind me about flag requests": При вводе комментария пользователем, на которого поставлены флаги-запросы (флаги в состоянии '?', у которых «requestee» этот пользователь) — будет проверять, и переспрашивать, не желает ли пользователь изменить состояния этих флагов (то есть ответил ли он своим комментарием на эти вопросы).
+
  
 +
''Администратор Bugzilla может заблокировать получение почты пользователем через добавление имени пользователя в файл <tt>data/nomail</tt>. Такие меры применяются в исключительных случаях — например, для аккаунтов уволившихся сотрудников.''
  
 +
Раздел '''Global options''' содержит (пока?) только настройки извещений [[#Флаги|по флагам]]):
  
== Email Settings ==
+
* Email me when someone asks me to set a flag - уведомление о том, что вам адресован запрошенный флаг;
Эти настройки определяют когда и сколько писем будет вам слать Bugzilla.
+
* Email me when someone sets a flag I asked for - уведомление о том, что кто-то ответил (установил в + или -) на запрошенный вами флаг.
Если вы хотите получать максимальное объем писем — нажмите на кнопку «Enable All Mail». Если не хотите получать почту от Bugzilla вообще — нажмите «Disable All Mail».
+
  
''Администратор Bugzillы может также заблокировать получение почты пользователем через добавление имени пользователя в файл <tt>data/nomail</tt>. Но такие крутые меры применяются в исключительных случаях — например, для аккаунтов уволившихся сотрудников.''
+
Раздел '''Field/recipient specific options''' содержит настройки для определения случаев, когда вы хотите получать письма от Bugzilla, и в каких отношениях с багом вы должны при этом находиться. Поставьте/уберите галочки в соответствующих клетках.
  
Более детальную настройка описана ниже.
+
Каждая запись в таблице соответствует событию бага (новый комментарий, изменение приоритета и др.). Колонки в таблице соответствуют вашей связи с багом:
 +
* Reporter - вы указаны в поле Reporter;
 +
* Assignee - вы указаны в поле Assigned To;
 +
* QA Contact - вы указаны в поле QA Contact;
 +
* CCed - вы указаны в списке CC List.
  
=== «Global options» ===
+
Почту также можно фильтровать по различным заголовкам X-Bugzilla-Что-Нибудь, присутствующих во всех письмах от Bugzilla (см. [[#Дополнительные email-заголовки|Дополнительные email-заголовки).
Раздел «Global options» содержит (пока?) только настройки извещений по флагам (см. [[#Флаги]]):
+
  
; «Email me when someone asks me to set a flag»: известить, если кто-то адресовал к вам «запрошенный флаг».
+
По умолчанию Bugzilla рассылает почту вне зависимости от того, кто был автором изменения бага, и вы будете получать почту, даже если будете единственным лицом, связанным с багом. Если вы не хотите получать письма после своих изменений, поставьте галочки в строке '''but not when (overrides above): The change was made by me'''.
; «Email me when someone sets a flag I asked for»: известить, если кто-то ответил на (установил в «+» или «-») запрошенный вами флаг.
+
  
===  «Field/recipient specific options» ===
+
{{note}} Если использовать более-менее вменяемый почтовый клиент, лучше разрешить получать почту и комментарии при своих изменениях, добавив правило «помечать письма содержащие 'xxx@company.com changed:' как прочтенные» (Вместо xxx@company.com разумеется, ваш логин). Установив локальный поисковик и проиндексировав почту, это даст возможность удобного полнотекстового поиска по всем комментариям связанных с вами багов.
  
Если вы хотите получать почту, но не во всех случаях, то используйте таблицу «Field/recipient specific options». Каждая запись в таблице соответствует событию бага (новый комментарий, изменение приоритета и т. п.). Колонки в таблице соответствуют вашей связи с багом:
+
Раздел '''User Watching''' содержит пользователей, следящих за вашим потоком извещений от Bugzilla.
  
;Reporter: Вы являетесь инициатором бага, то есть вы указаны в поле бага «Reporter».
+
Если вы введете список (разделенный запятыми) пользовательских аккаунтов (обычно совпадающих с email-адресами) в '''Users to watch''', то будете получать копию всех писем, рассылаемых пользователю Bugzillой (с учетом настроек безопасности).  
  
;Assignee: Вы являетесь ответственным за баг, то есть вы указаны в поле бага «Assigned To».
+
В нашей инсталляции Bugzilla можно подписываться на почту других пользователей и подписывать (а также отписывать) других пользователей на себя.
  
;QA Contact: Вы являетесь контроллером бага, то есть вы указаны в поле бага «QA Contact».
+
{{caution}} Не злоупотребляйте этой возможностью!
  
;CC: Вы указаны в списке «CC» бага.
+
== Saved searches ==
  
;Voter: Вы голосовали за баг. Ваш аккаунт будет показан по ссылке «Show votes for this bug» из окна бага.
+
... добавить инфу ...
  
''Некоторые из описанных колонок могут отсутствовать, это определяется конфигурацией конкретной инсталляции''.
+
== Name and password ==
  
Определите, в каких случаях вы хотите получать письма от Bugzilla, и в каких отношениях с багом должны вы при этом находиться и поставьте/оставьте галочки только в соответствующих клетках.
+
На этой вкладке вы можете изменить основную информацию вашей личной записи — изменить пароль, настоящее имя. По соображениям безопасности при изменении любых параметров на этой странице вы должны подтвердить изменение вводом своего пароля.
+
Почту также можно фильтровать по различным заголовкам X-Bugzilla-ЧтоНибудь, присутствующих во всех письмах от Bugzilla. См. [[#Дополнительные email заголовки]].
+
  
По умолчанию, Bugzilla рассылает почту вне зависимости от того, кто был автором измения бага, и вы будете получать почту, даже если вы будете единственным лицом, связанным с багом. Если вы не хотите получать письма после своих собственных изменений, поставьте галочки в строке [ «but not when» ] «The change was made by me».
+
== Permissoins ==
  
{{note}} На самом деле, если использовать более-менее вменяемый почтовый клиент, лучше разрешить получать почту и комментарии при своих изменениях, добавив правило «помечать письма содержащие 'xxx@company.com changed:' как прочтенные» (Вместо «xxx@company.com» разумеется, подставьте ваш логин). Это даст вам возможность, установив локальный поисковик и проиндексировав почту, удобного полнотекстового поиска по всем комментариям «связанных» с вами багов.
+
Чисто информационная вкладка, описывающая все права пользователя в текущей инсталляции Bugzilla — какие группы продуктов доступны, может ли пользователь редактировать баги и осуществлять административные функции.
  
=== «User Watching» ===
+
= Фильтрация писем от Bugzilla =
  
Если вы введете список (разделенный запятыми) пользовательских аккаунтов (обычно совпадающих с email-адресами) в «Users to watch», то вы будете получать копию всех писем рассылаемых пользователю Bugzillой (с учетом настроек безопасности). Если вы не видите это поле в настройках — значит была Bugzilla установлена без этой возможности, и для ее активации нужно обратиться к системному администратору. В этом же разделе, в информационном поле «Users watching you» перечислены пользователи «следящие» за вашим потоком извещений от Bugzilla.
+
Bugzilla добавляет некоторые заголовки во все письма. В большинстве почтовых клиентов эти заголовки также можно использовать для фильтрации почты.
  
В нашей инсталляции, можно «подписываться» на почту других пользователей
+
Заголовки — это не subject, а внутренние заголовки письма, увидеть которые можно в свойствах письма или выбрав в почтовой программе пункт View Message Headers или подобный.
и «подписывать» (а также «отписывать») других пользователей на себя.
+
 
+
{{caution}} Не злоупотребляйте этой возможностью!
+
 
+
== Permissions ==
+
Это чисто информационная страница-закладка, описывающая все права пользователя в текущей инсталляции — какие группы продуктов доступны, может ли пользователь редактировать баги и осуществлять административные функции.
+
 
+
= Advanced =
+
 
+
== Дополнительные email заголовки ==
+
 
+
Bugzilla добавляет некоторые заголовки во все письма. Заголовки — это не subject, а внутренние заголовки письма, увидеть которые обычно можно, выбрав в почтовой программе пункт меню «View Message Headers» или подобный.
+
 
+
В большинстве почтовых клиентов эти заголовки также можно использовать для фильтрации почты.
+
  
 
Список заголовков:
 
Список заголовков:
 +
* X-Bugzilla-Reason - отношение получателя к упомянутому багу: <tt>Assigned To</tt> (ответственный), <tt>Reporter</tt> (создатель бага), <tt>QA Contact</tt> (тестировщик), <tt>CC List</tt> (наблюдатель), <tt>Voter</tt> (голосовал за баг);
 +
* X-Bugzilla-Watch-Reason - то же, но каждое значение означает, что получатель наблюдает за пользователем, имеющим соответствующее отношение к упомянутому багу. Плюс есть ещё одно значение — <tt>GlobalWatcher</tt>, означающее, что пользователь получает всю почту по всем багам;
 +
* X-Bugzilla-Type - <tt>new</tt> (новый баг), <tt>changed</tt> (изменение) или <tt>request</tt> (изменение флагов);
 +
* X-Bugzilla-Who - логин (то есть, e-mail адрес) изменившего баг;
 +
* X-Bugzilla-Changed-Fields - список изменённых полей упомянутого бага;
 +
* X-Bugzilla-Added-Comments - количество добавленных комментариев (0 или более).
  
;X-Bugzilla-Reason: отношение получателя к упомянутому багу: <tt>AssignedTo</tt> (ответственный), <tt>Reporter</tt> (создатель бага), <tt>QAContact</tt> (QA), <tt>CC</tt> (в списке копий), <tt>Voter</tt> (голосовал за баг).
+
Также есть набор заголовков, имеющих значением значение соответствующего атрибута бага:
;X-Bugzilla-Watch-Reason: то же, но каждое значение означает, что получатель наблюдает за пользователем, имеющим соответствующее отношение к упомянутому багу. Плюс есть ещё одно значение — <tt>GlobalWatcher</tt>, означающее, что пользователь получает всю почту по всем багам.
+
;X-Bugzilla-Type: <tt>new</tt> (новый баг), <tt>changed</tt> (изменение) или <tt>request</tt> (изменение флагов).
+
;X-Bugzilla-Who: логин (то есть, e-mail адрес) изменившего баг.
+
;X-Bugzilla-Changed-Fields: список изменённых полей упомянутого бага.
+
;X-Bugzilla-Added-Comments: количество добавленных комментариев (0 или более).
+
 
+
Также есть набор заголовков, имеющих значением значение соответствующего атрибута бага (какого — несложно понять по названию):
+
 
+
 
* X-Bugzilla-Classification
 
* X-Bugzilla-Classification
 
* X-Bugzilla-Product
 
* X-Bugzilla-Product
Line 718: Line 661:
 
* X-Bugzilla-Keywords
 
* X-Bugzilla-Keywords
  
=== Пример ===
+
'''Примеры:'''
  
'''Задача''': Фильтровать почту по багам, содержащую только изменения связанных багов.
+
'''Задача 1''': Фильтровать почту по багам, содержащую только изменения связанных багов.
  
 
'''Решение''': Заголовок X-Bugzilla-Added-Comments равен 0 и заголовок X-Bugzilla-Changed-Fields пуст.
 
'''Решение''': Заголовок X-Bugzilla-Added-Comments равен 0 и заголовок X-Bugzilla-Changed-Fields пуст.
  
== Просмотр Патчей ==
+
'''Задача 2''': Перемещать в специальную папку письма по багам, назначенным на меня, созданным мной или содержащим вопрос ко мне.
  
Важно: под патчем или исправлением, здесь имеется в виду именно патч, то есть файл в специальном стандартном текстовом формате (patch) представляющий собой инструкции для специальной программы-патчера по проносу изменений. А не какие-то тексты программ или инструкции для человека.
+
'''Решение''': В Outlook [https://support.office.com/ru-RU/article/%D0%A3%D0%BF%D1%80%D0%B0%D0%B2%D0%BB%D0%B5%D0%BD%D0%B8%D0%B5-%D1%8D%D0%BB%D0%B5%D0%BA%D1%82%D1%80%D0%BE%D0%BD%D0%BD%D0%BE%D0%B9-%D0%BF%D0%BE%D1%87%D1%82%D0%BE%D0%B9-%D1%81-%D0%BF%D0%BE%D0%BC%D0%BE%D1%89%D1%8C%D1%8E-%D0%BF%D1%80%D0%B0%D0%B2%D0%B8%D0%BB-5D68E1F9-AE8E-4223-881E-7369EDC0D589 создать правило], которое будет перемещать письма, содержащие в заголовке "X-Bugzilla-Reason: Assigned-To" или "X-Bugzilla-Reason: CC Assigned-To" или "X-Bugzilla-Type: request" или "X-Bugzilla-Reason: Reporter", в нужную папку.
  
Просмотр и ревизия исправлений в Bugzilla часто затруднена из-за недостатка контекста, несоответствующих форматов и других сложностей. «Patch Viewer» это дополнение Bugzilla, предназначенное для улучшения контекста, интеграции с Bonsai, LXR, [[CVS]].
+
= Просмотр Патчей =
  
«Patch Viewer» позволяет:
+
Важно: под патчем или исправлением здесь имеется в виду именно патч, то есть файл в специальном стандартном текстовом формате (patch), представляющий собой инструкции для программы-патчера по проносу изменений. А не какие-либо тексты программ или инструкции для человека.
  
* Просмотр исправлений с раскраской, в режиме «side-by-side», а не интерпретация сырого содержимого исправления;
+
Просмотр и ревизия исправлений в Bugzilla часто затруднена из-за недостатка контекста, несоответствующих форматов и других сложностей. '''Patch Viewer''' это дополнение Bugzilla, предназначенное для улучшения контекста, интеграции с [[Bonsai]], <font color = "red">'''LXR'''</font>, [[CVS]].
 +
 
 +
Patch Viewer позволяет:
 +
* Просмотр исправлений с раскраской, в режиме side-by-side, а не интерпретация сырого содержимого исправления;
 
* Просмотр разницы между двумя исправлениями;
 
* Просмотр разницы между двумя исправлениями;
 
* Получение контекстной информации об исправлении;
 
* Получение контекстной информации об исправлении;
* Удобный просмотр исправления, с возможностью скрывать/раскрывать разделы;
+
* Удобный просмотр исправления с возможностью скрывать/раскрывать разделы;
 
* Ссылки на разделы исправления для обсуждения или ревизии;
 
* Ссылки на разделы исправления для обсуждения или ревизии;
 
* Ссылки на Bonsai или LXR для определения ответственности;
 
* Ссылки на Bonsai или LXR для определения ответственности;
* Создает исправления в унифицированном «diff»-формате.
+
* Создает исправления в унифицированном diff-формате.
 
+
В нашей инсталляции, мы не используем PatchViewer, так как есть гораздо более удобная система просмотра версионных репозиториев [[ViewVC]] (см. [[#Интеграция с системами контроля версий]]).
+
 
+
=== Просмотр в Patch Viewer ===
+
 
+
Самый удобный способ для просмотра патчей вызывается по ссылке «Diff» в списке «Attachments»,
+
либо ссылкой «View Attachment As Diff» на странице «Edit Attachment».
+
 
+
=== Изучение разницы между двумя исправлениями ===
+
 
+
Для просмотра разницы между двумя патчами, надо сначала в Patch Viewer войти в просмотр нового патча, затем выбрать в выпадающем списке нужный старый патч, и нажать на кнопку «Diff».
+
 
+
=== Получение большего контекста ===
+
 
+
Если патч был получен с помощью «cvs diff», то можно при просмотре больший контекст (больше строк кода окружающих изменение или добавление). Для этого можно ввести нужное число контекстных строк в текстовое поле над Patch Viewer («Patch / File / [textbox]») и нажать «Enter».
+
Дополнительно по ссылке «File» будут показаны изменения в контексте всего файла.
+
 
+
=== Схлопывание и раскрытие разделов Исправления ===
+
 
+
Можно просматривать исправления в разбивке по секциям-файлам — интерфейс понятен, нужно нажимать на ссылки «(+)» и «(-)» в каждом разделе или «Collapse All», «Expand All» (сверху страницы).
+
 
+
=== Ссылки на разделы Исправления ===
+
 
+
=== Ссылки на Bonsai ===
+
Чтобы перейти для детального изучения кода в [[Bonsai]], надо проследовать по ссылке «Lines XX-YY» в заголовке раздела. Это будет работать даже если патч был к старой версии файла, так как [[Bonsai]] хранит все версии файлов.
+
 
+
{{note}} [[Bonsai]] признан устаревшим и не используется в нашей компании. Ему на замену пришла [[ViewVC]].
+
 
+
=== Создание стандартного Diff ===
+
  
Патч может быть преобразован в «unified diff format» путем вызова ссылки «Raw Unified».
+
В нашей инсталляции Bugzilla мы не используем PatchViewer, так как есть гораздо более удобная система просмотра версионных репозиториев [[ViewVC]] (см. [[#Интеграция с системами контроля версий|Интеграция с системами контроля версий]]).
  
 
= Ссылки =
 
= Ссылки =
  
* [http://www.mozilla-russia.org/products/bugzilla/ «Bugzilla в России»];
+
[http://www.mozilla-russia.org/products/bugzilla/ Bugzilla в России];
* [[RuPedia:Bugzilla|Bugzilla в Википедии]];
+
[[RuPedia:Bugzilla|Bugzilla в Википедии]];
* [http://dmoz.org/Computers/Software/Configuration_Management/Bug_Tracking/Free/ Bug Tracking системы (бесплатные)].
+
[http://dmoz.org/Computers/Software/Configuration_Management/Bug_Tracking/Free/ Bug Tracking системы (бесплатные)].
  
 
[[Категория:Программирование]]
 
[[Категория:Программирование]]
Line 781: Line 698:
 
[[Категория:Bugzilla]]
 
[[Категория:Bugzilla]]
  
{{replicate-from-custiswiki-to-all}}
 
 
{{replicate-from-custiswiki-to-lib}}
 
{{replicate-from-custiswiki-to-lib}}
[[Категория:CustisWikiToTools]]
+
{{replicate-from-custiswiki-to-4intranet}}
 +
{{replicate-from-custiswiki-to-smwiki}}

Latest revision as of 13:52, 10 March 2016

frame|Логотип Bugzilla

Bugzilla — система отслеживания ошибок, разрабатываемая Mozilla Foundation.

Note.svg Может также упоминаться (и с некоторыми оговорками использоваться) как:

  • Система учета заданий
  • Система ведения дел
  • Система регистрации инцидентов
  • Система управления требованиями, идеями, предложениями, заявками и т.п.
  • Сайт: http://www.bugzilla.org
  • Распространение: freeware, open source


Contents

Введение

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

Bugzilla используют многие компании и организации по всему миру. Из наиболее известных: NASA, IBM, Mozilla, Linux Kernel, Gnome, KDE, Apache Project, Open Office.

Анатомия бага

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

Bugs have feeling too (cartoon tester).jpg


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

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

2. Component (Компонент) - дополнительная структурная классификация. В зависимости от выбранного компонента баг может иметь разный набор компонентов.

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

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

  • UNCONFIRMED (Не подтвержден)
Наличие этого состояния зависит от настроек конкретного Продукта. Например, если считается, что баг-отчеты в Продукт могут составлять неконтролируемое множество пользователей (например, интернет-аудитория), в этом состоянии имеется смысл. Тогда для перехода в следующее состояние (NEW) необходимо решение пользователя системы с правами canconfirm. Если же новые баги ставят только обученные сотрудники, то это состояние скорее всего не нужно;
  • NEW (Новый)
Баг только что зарегистрирован или проверен (если был зарегистрирован в состоянии UNCONFIRMED);
  • ASSIGNED (Назначен)
Пользователь в поле Assigned To назначен ответственным за этот баг. Баг может быть назначен на другого сотрудника или переведен в состояние NEW;
  • REOPENED (Открыт заново)
Баг был решен ранее, однако возникла необходимость вернуться к нему (решение было неверным либо неокончательным).


2. Resolution (Резолюция, Решение) - атрибут имеет смысл только для багов в состояниях RESOLVED, VERIFIED, CLOSED. Набор значений атрибута настраиваемый, стандартный набор:

  • FIXED (Решено) — стандартная резолюция, означающая, что задание выполнено или баг исправлен;
  • INVALID (Некорректно) — неправильная или некорректная постановка задачи;
  • WONTFIX (Проблема есть, но решаться не будет) - такая резолюция может быть в отношении request for enhancement, которые хоть и имеют смысл, являются слишком трудновыполнимыми и не являются обязательными;
  • DUPLICATE (Дублирует) — описанная проблема уже зарегистрирована в другом баге;
  • WORKSFORME (А у меня работает…) — не удалось воспроизвести описанную проблему ни эмуляцией сценария, ни анализом кода;
  • MOVED (Перенесено) - проблема перенесена в иную систему-tracker.

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

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

3. Диаграмма

Жизненный цикл бага (он же граф переходов состояний, workflow) жестко задан в коде и представлен ниже, на графе.

[svg]

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

  • Assigned To (ответственный) - пользователь, ответственный за решение (исправление) бага. Подтверждение ответственности происходит при переводе бага из состояний NEW и REOPENED в ASSIGNED.
  • Reporter (автор) - пользователь, создавший баг.
  • QA Contact (проверяющий, тестировщик) - пользователь, ответственный за проверку решения бага.
  • CC List (список наблюдателей) - список заинтересованных в баге пользователей, оповещаемых об изменениях бага.

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

1. Summary - аннотация задачи/проблемы одним предложением. По правилам хорошего тона при регистрации нового бага следует дублировать (не обязательно дословно) содержимое Summary в первом комментарии. Атрибут Summary может быть несколько раз отредактирован, что приведет к утере первоначального смысла бага. Конечно, доступна история изменений, но лучше зафиксировать историю в комментариях, которые отображаются всегда.

2. Version - номер версии продукта (компонента продукта), в которых наблюдается описанная проблема.

3. Priority - приоритет бага, указывается Assigned To пользователем на основе собственной оценки. Менять приоритет у чужих багов неправильно. Стандартный набор значений — от P1 (наивысший приоритет) до P5 (наименьший).

4. Severity - критичность возникшей проблемы. Список допустимых значений настраивается, стандартный набор:

  • Blocker - разработка или использования продукта невозможна. Требуется немедленное решение проблемы;
  • Critical - серьезные проблемы — не работает критичный для использования функционал, наблюдаются серьезные ошибки, связанные с потерей данных и т. п;
  • Major - проблема связана с важным функционалом продукта;
  • Minor - проблема связана со второстепенным функционалом продукта или есть легкий обходной путь для решения проблемы;
  • Trivial - проблема косметического уровня. Например, недоработанный интерфейс - опечатки, не выровненные поля, разнобой цветов и пр.;
  • Enhancement: Request for enhancement - запрос на усовершенствование.

5. Target (Target Milestone, Веха) - здесь указывается веха (версия, стадия) проекта, к которой баг должен быть решен. Не путать с Version. Например, баг может описывать ошибку, возникшую в версии 1.17, которую было решено исправить к версии 1_21. Веха не обязательно привязана к версии продукта, она может быть привязана к определенному времени. Набор вех — набор единых для каждого продукта событий, которые должны синхронизировать процессы исправления, тестирования и пронесения изменений. Каждый продукт имеет атрибут Milestone URL, содержащий ссылку на документ с именованными и описанными вехами, то есть где будет приведен некоторый Roadmap проекта.

6. Comments - комментарии к багу. Первый — это Description, остальные в форме редактирования бага именуются Additional Comments. Bugzilla рассылает всем связанным с багом пользователям комментарии по почте. В нашей инсталляции Bugzilla есть возможность «Silent» комментариев (checkbox Silent), уведомления о которых не рассылаются по почте. Использовать Silent следует только в том случае, когда информация в комментарии действительно мало интересна — например, worklog-запись о выполненной промежуточной (не решающей баг) работе, или если основная ценность записи - регистрация личных трудозатрат (см. Учет времени (Time tracking)).

Не стоит злоупотреблять комментариями, превращая баг в форум. Для обсуждения постановки задачи, продуктивней завести ассоциированную с багом статью в Wiki-системе, и обсуждать там (см. Интеграция с Wiki).

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

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

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

[svg]

В нашей инсталляции Bugzilla 3 графы зависимостей имеют две дополнительные особенности:

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

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

Процент выполненности блокирующих
Blockers completed ~16%, 
Дата последнего изменения блокирующих багов
last changed 2009-02-12 12:57:45
  • Blocks указывает, решение каких багов зависит от данного бага.

Прочее

  • URL - ассоциированный с багом URL, указывающий на документ с описанием/постановкой проблемы, если таковой имеется.

В нашей инсталляции Bugzilla можно пользоваться автоматической связью между багом и ассоциированной с каждым Component'ом Wiki-системой, в которой можно делать пристойно отформатированную постановку задачи и даже вести ее обсуждение (См. Интеграция с Wiki).

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

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

  • Attachments - прикрепленные к багам файлы (сценарии тестирования, патчи и пр.).

Атрибуты, не используемые в нашей инсталляции Bugzilla:

  • Platform - вычислительная платформа (железо), на которой наблюдается проблема;
  • OS - операционная система, на которой наблюдается проблема;
  • Votes - голоса за баг. Используется в основном для автоматического перевода бага из UNCONFIRMED в NEW.

Поиск багов

Основные атрибуты

На странице Bugzilla Search представлен интерфейс для поиска любых зарегистрированных багов, комментариев и патчей. Интерфейс позволяет задать поисковые значения для всех перечисленных полей бага, причем для некоторых полей может быть задано несколько значений из домена (с помощью списков со множественным выбором). Если значение не выбрано — атрибут бага может принимать любое значение.

Хранение запросов

Любой выполненный запрос можно сохранить под выбранным именем (Remember Search As). Ссылка на сохраненный поиск отобразится в линейке Saved Searches, результат запроса можно будет получить за один клик, перейдя по ссылке.

Временные условия

Можно накладывать временные условия на изменение бага, запрашивая только баги, по которым было какое-либо движение (изменение атрибутов, комментарии) в определенном интервале времени — см. группу полей Bug Changes. Интервал времени можно задавать как в абсолютной форме (дата в формате YYYY-MM-DD), так и в форме, относительной текущей дате. Можно сделать хранимый запрос, показывающий только баги, измененные в течение предшествующих 24 часов (или недели, месяца).

Можно использовать слова:

  • Now — сейчас, разумно использовать для задания верхней границы интервала.
  • 1d — день назад. 2d — два дня назад, 0d — последняя полночь до текущего момента.
  • 1w — то же самое в неделях. 0w — начало недели.
  • 1m — то же в месяцах. 0m — начало месяца.
  • 1y — то же в годах. 0y — начало года.

Можно добавить перед относительными датами знак +, это будет означать, что относительная дата не вычитается из Now, а прибавляется (в будущее).

Полнотекстовый поиск

Начиная с версии 3.0 Bugzilla поддерживает честный полнотекстовый поиск по MySQL FULLTEXT-индексам, а с нашими доработками — и русскоязычную морфологию через стеммер Портера Lingua::Stem::Ru (порт из snowball).

То есть по слову «завтрака» ищется и «завтрак», и «завтраков» и пр.

Искать по словам можно из двух мест: со страницы поиска и из поля Quicksearch в шапке и подвале страниц Bugzilla.

По умолчанию ищутся баги, содержащие в описании и/или комментариях все введённые слова с учётом морфологии. Однако, также действует специальный синтаксис, на самом деле совпадающий с синтаксисом MySQL Fulltext Boolean Search. При встрече во введённом запросе любого элемента этого синтаксиса запрос автоматически переключается в режим поиска любого из введённых слов, если не указано обратное.

Описание синтаксиса:

  • слово - слово не обязательно должно присутствовать в тексте бага, однако тексты, содержащие данное слово, ранжируются выше других;
  • +слово - слово обязательно должно присутствовать в тексте бага;
  • -слово - слово не должно присутствовать в тексте бага. Работает только в сочетании с заданными «положительными» словами — запрос, состоящий из просто «-слова», не вернёт ни один баг;
  • >слово - повышенная важность слова — больше вклад в ранжирование;
  • <слово - пониженная важность слова;
  • +(слово1 слово2) слово3 - группировка выражений скобками. Может быть вложенной;
  • ~слово - ранжировать тексты, содержащие слово ниже других, но не исключать окончательно;
  • сло* - знак шаблона (wildcard). Такой запрос найдёт и «слона», и «слово»;
  • "слово, или фраза" - поиск словосочетаний, а не слов. Знаки препинания между словами не учитываются, морфология учитывается.

Слова короче 3 символов в поиске не учитываются.

Boolean Charts

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

[ NOT ]
 ( (Атрибут11 Операция11 Значение11) OR
   (Атрибут12 Операция12 Значение12) OR
   ....)
 [ AND
   (Атрибут21 Операция21 Значение21) OR
   (Атрибут22 Операция22 Значение22) OR
   ....) ]
 [ AND ... ]
 )

Можно накладывать условия по флагам, например: Только баги, содержащие флаги, установленные пользователем user@company.com - «Flag Setter» «is equal to» «user@company.com» Только баги, в которых флаг флаг_утвердить установлен в + - «Flag» «is equal to» «флаг_утвердить+» (аналогично с ?,-)

В Bugzilla 3.0 появилась возможность, ранее имевшаяся только в нашей версии — подзапросы по сохранённым запросам поиска в лице операций matched by saved search (присутствует в списке, возвращаемом запросом таким-то), и not matched by saved search (отсутствует в списке, возвращаемом запросом таким-то).

Например, вы можете сформулировать условие «Блокируется багом из списка, возвращаемого сохранённым запросом поиска My Bugs» — для этого нужно выбрать поле Depends On, операцию matched by saved search и значение My Bugs.

Чуть менее тривиально: можно задавать и запросы вида «найти все мои баги в открытом состоянии, для которых все блокирующие выполнены». Для этого просто нужно создать сохранённый запрос, находящий все выполненные баги, и подменить в запросе из предыдущего абзаца My Bugs этим запросом.

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

Заметим, запросы типа «баги, у которых нет блокирующих или «баги, у которых нет зависимых» можно реализовать стандартными условиями типа:

NOT(Depends On "contains regexp" "[0-9]+" )
NOT(Blocks     "contains regexp" "[0-9]+" )

Списки багов

После выполнения запроса система возвращает выборку — список удовлетворяющих запросу багов. Формат этого списка настраиваемый, по ссылке Change Columns можно настроить набор показываемых в списке атрибутов. Также можно включить настройку Stagger headers — разнесение заголовка таблицы списка на два уровня.

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

Другие полезные возможности вызываются ссылками, расположенными внизу списка:

  • CSV - выдает список в CSV формате (разделенным запятыми) например, для импорта в программу электронных таблиц;
  • Buglist feed - выдает список в RSS формате, для чтения через RSS-агрегатор. Список отсортирован по убыванию времени открытия бага, набор полей задан жестко. Может быть полезным для отслеживания поступления новых багов. Для пользователей Mozilla Firefox рекомендуется установить Sage, чтобы использовать Bugzilla-авторизацию, полученную браузером после логина.
  • Activity feed - показывает RSS-ленту последних комментариев и активности по выбранным в списке багам;
  • Change Columns - изменение списка атрибутов, показываемых в списке;
  • Change several bugs at once - если у вас достаточно привилегий, вы можете делать некоторые изменения одновременно над всеми багами в списке — например, сменить ответственного, закрыть группу багов, перенести их в другой Product или Component.
  • Send Mail to Bug Assignees - отправить письмо всем ответственным по всем багам в списке;
  • Edit Search - вернуться на страницу запроса для его уточнения;
  • Remember Search As - присвоить этому запросу имя и сохранить, ссылка на сохраненный запрос отобразится в Saved Searches внизу страницы.

Также есть 3 кнопки:

  • Long format - показывает несколько багов на одной странице в подробном формате со всеми атрибутами и полными обсуждениями;
  • XML - даёт возможность выгрузить баги в XML-файл для специальной обработки или импорта в другую Bugzilla;
  • Time Summary - перенаправляет на страницу просмотра отчётов по трудозатратам по выбранным багам (см. Time Summary).

В нашей инсталляции Bugzilla также есть пункты:

  • Graph - просмотр выбранного списка багов в виде ориентированного графа;
  • Summary Report - просмотр табличной агрегации (cм. Отчеты) выбранного списка багов по выбранному срезу (набору атрибутов). Каждая ячейка табличного отчета будет содержать число багов, обладающих соответствующими атрибутами и ссылка на список этих багов. Таким образом, можно легко делать настоящий OLAP drill-down, то есть формулировать "широкий" запрос, переходя от списка к табличному отчету, раскладывать по выбранным измерениям (от одного до трех), и далее получать списки багов по отдельным ячейкам среза, возможно повторяя процедуру раскладки по другим измерениям.

Создание багов

Создание багов вручную

Процедура следующая:

  • Кликните на ссылке New в нижней или верхней линейке Actions;
  • Выберите классификацию и продукт;
  • Заполните поля. Уделите особое внимание атрибутам, идентифицирующим проблему или задание (что, где, насколько срочно) — Component, Version, Severity. Старайтесь дублировать (не обязательно дословно) содержимое Summary в первом комментарии (поле Comments). Атрибут Summary может быть несколько раз отредактирован, что приведет к утере первоначального смысла бага;
  • Нажмите Commit — это зафиксирует и отправит ваш bug report.

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

Создание бага клонированием другого бага

См. ниже

Импорт из Excel-файла

Bugzilla 3.0 поддерживает массовый импорт багов из Excel-файлов — как бинарных *.xls, так и OOXML *.xlsx.

Система подразумевает, что первая строка Excel-файла содержит заголовки колонок, а последующие — описания багов. Обязательными полями бага являются Product, Component и Summary.

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

После проверки и нажатия Import selected bugs отображается страница с результатами импорта:

  • с ошибкой, в этом случае ни один из выбранных багов не импортируется;
  • с успехом, в этом случае будет присутствовать текст Successfully imported X bugs и список ID созданных багов.

Для запуска Excel-импорта:

  • Кликните на ссылке New в нижней или верхней линейке Actions;
  • Внизу страницы, под списком классификаций или продуктов, перейдите по ссылке See also: Mass bug import from Excel file;
  • Выберите Excel-файл кликом по кнопке Обзор…;
  • Если ваш Excel-файл содержит несколько листов, а вы хотите импортировать только один из них, введите его название в поле Enter sheet name to process. Если вы хотите импортировать все листы, очистите это поле;
  • После загрузки файла система автоматически проверяет список на наличие уже импортированных ранее багов по точному совпадению названия и максимальному возрасту бага, указываемому в днях в Maximum bug duplicate age. Поэтому, если вы производите повторный импорт файла (модифицированного), укажите такой максимальный возраст, чтобы баги, импортированные ранее из того же файла, попали в этот возраст;
  • Если вы хотите установить значение определённых полей по умолчанию для всех импортируемых багов, можно выбрать поле, нажать Add field value for all bugs и заполнить выбранное поле;
  • Нажмите кнопку Parse File.

После нажатия кнопки Parse File будет показана страница с таблицей так, как её видит система. Если колонки в Excel-файле имели названия, совпадающие с названиями полей в Bugzilla, они автоматически сопоставятся нужным полям бага. Если автоматического сопоставления не произошло, кликом на название колонки можно выбрать нужное поле из выпадающего списка.

Значения полей (то есть значения ячеек) должны соответствовать значениям полей в Bugzilla. Все поля отображаются редактируемыми, вы можете исправить любые значения, если увидите несоответствия.

По результатам автоматической проверки существующих импортированных багов из списка будут установлены флажки слева каждой строки. По нажатию кнопки Import selected bugs будет предпринята попытка импорта только помеченных флажками багов.

После успешно выполненного импорта вы увидите ссылку Import another Excel file — you can bookmark this link as a template. В этой ссылке сохранена информация о сопоставлении полей и значениях полей для всех багов по умолчанию. Поэтому, переходя по ней, вы сможете импортировать другой файл того же формата без лишних усилий. Также вы можете сохранить ссылку в закладки браузера для использования в будущем.

Редактирование багов

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

В основном редактированием основных атрибутов бага занимаются связанные с багом пользователи, указанные в атрибутах Reporter, Assigned To и QA Contact. Регламент работы с багом жестко не определен, любой пользователь, обладающий соответствующими правами, может изменять состояние и атрибуты бага.

Впрочем, обычно:

  • Reporter ответственен за указание атрибутов, идентифицирующих проблему (что, где, насколько срочно) — Product, Version, Severity;
  • Assignee определяет Priority, Status, переводя баг по состояниям NEW -> ASSIGNED -> RESOLVED.
  • QA Contact определяет Status, переводя баг из RESOLVED в VERIFIED или REOPENED.

Если в инсталляции Bugzilla включены функции регистрации времени (например, параметр timetrackinggroup), то можно регистрировать предварительную оценку сложности задачи и с каждым комментарием свои трудозатраты, корректировать оценку оставшийся работы (См. Учет времени (Time tracking)).

В окне редактирования бага можно выяснить различные аспекты решаемой проблемы, зарегистрированные в Bugzilla:

  • Лента комментариев к багу, отсортированная по времени;
  • View Bug Activity - история изменения всех атрибутов бага.
  • Look for Bug in CVS, SVN, Git - ссылка на страницу ViewVC — выполняет поиск в CVS и Subversion - репозитариях ревизий файлов, в комментариях к которым указан номер этого бага. Страница результатов поиска содержит также ссылки на другие действия с файлами. Оставленная до поры, до времени +Old — ссылка на аналогичную страницу поиска в Bonsai в будущем будет удалена. См. интеграция с системами контроля версий.
  • Look for Bug in Wiki - перенаправляет на ассоциированную с багом статью Wiki см. Интеграция с Wiki.

Комментарии

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

В нашей инсталляции Bugzilla можно воспользоваться ссылкой Preview (например, проверить, правильно ли гиперлинкуются ссылки, см. Автоматические ссылки), и убедившись, что все хорошо, вернуться кнопкой браузера Назад и выполнить Commit.

В стандартной инсталляции для этого можно использовать страничку c адресом вида http://bugs.office.custis.ru/bugs/page.cgi?id=linkify.html

Клонирование бага

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

  • ссылка clone to other/same/int product на первом комментарии;
  • ссылка Clone This Bug внизу страницы (аналог clone to other product на первом комментарии).

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

В нашей инсталляции Bugzilla также можно клонировать в баг любой комментарий исходного бага ссылкой clone to other/same/int product на комментарии.

Полезности Bugzilla

Автоматические ссылки

Комментарии в Bugzilla разрешены только plain текстом, то есть печатая
<U>
вы получите не подчеркнутый текст, а
<U>
.

Также нет списков и иных структурных элементов. Тем не менее, Bugzilla делает гиперссылки для определенного рода комментариев, например распознаются и гиперлинкуются основные типы URL:

  • «http://»,
  • «ftp://»,
  • «mailto:»,
  • почтовые адреса someone@somewhere.org.

Дополнительно гиперлинкуются ссылки на внутрибагзильные элементы (баги, комменты, вложения):

  • bug 12345
  • comment 7
  • bug 23456, comment 53
  • attachment 4321

Интеграция с системами контроля версий

Очень важно описать связь между багами (заданиями или сообщениями об ошибках) и производимым (исправляемым) разработчиком артефактом — программным кодом (включая документацию). В нашей Компании весь код (то есть практически все производимое разработчиком) находится в репозиториях принятых в Компании систем управления версиями CVS и Subversion и Git.

Наша инсталляция Bugzilla интегрирована с системой ViewVC, в которую оперативно загружается информация о всех правках в CVS- и Subversion-репозиториях Компании. Поэтому, если при работе над багом XXX ведутся правки файлов, находящихся под CVS или Subversion, при фиксации (выполнении commit) не нужно писать длинных комментариев, описывающих суть изменений, а достаточно указать номер бага. Например, выполнить

cvs commit -m "Bug 1234"

Комментарий можно вводить и через опции командной строки, и через редактор, см. ссылки на документацию в CVS, Subversion.

При соблюдении этого правила для каждого бага можно найти все commit'ы, в комментариях к которым указан номер этого бага, с помощью ссылки Look for Bug in CVS, SVN, Git на странице бага.

Ранее похожую функцию выполнял Bonsai, однако был сделан переход на ViewVC по причине поддержки не только системы контроля версий CVS, но также и Subversion последним. Посему ссылки Look for Bug in CVS, SVN, Git теперь ведут именно в ViewVC.

Интеграция с Wiki

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

В нашей инсталляции Bugzilla дополнительно к возможностям автоматических ссылок можно делать читаемые гипертекстовые ссылки на статьи (разделы статей) в CustisWiki, например:

wiki:Bugzilla#Автоматические_ссылки
wiki:[[Bugzilla#Автоматические ссылки]]

будет ссылаться на Bugzilla#Автоматические_ссылки.

Если при работе над багом требуется сделать документ-постановку задачи и/или провести его обсуждение, можно воспользоваться ссылкой Look for Bug in Wiki на странице бага и перейти к одноименной с багом статье Bug XXX для чтения/редактирования/обсуждения.

Рекомендуется после заведения статьи выполнить ее переименование (закладка move/переименовать) в более понятное название, например «Ошибка ORA-YYY при загрузке каталога (Bug XXX)», copy-paste атрибута Summary.

Таким образом, будет создана статья с смысловым заголовком и статья-перенаправление «Bug XXX».

Однако, стоит помнить, что в Wiki4Intranet не стоит помещать конфиденциальную информацию, так как тут уже не действует система прав Bugzilla.

Учет времени (Time tracking)

Пользователи, входящим в группу timetrackinggroup, могут вести учет трудоемкости каждого бага.

Ведется учет следующих полей:

  • Orig. Est. - начальная оценка трудоемкости бага. Разумно использовать как априорную оценку трудоемкости. Хотя ее можно менять, лучше это делать реже, чтобы сохранился смысл априорной оценки, данной разработчиком или руководителем проекта;
  • Current Est.- текущая оценка трудоемкости бага. Вычислимое поле, является суммой Hours Worked и Hours Left;
  • Hours Worked- число затраченных часов. Только увеличивается с каждым редактированием;
  • Hours Left - осталось затраченных часов. Изначально выставляется, как разница Current Est. и Hours Worked, но будучи отредактированным, влияет на Current Est. Например, если считалось, что на баг надо затратить 5 часов, а после некоторой работы выяснилось, что затрачено 3 часа, а осталось еще 7, то текущая оценка меняется на 10 часов.
  • % Complete - процент завершенности. Вычислимое поле, равно Hours Worked/Current Est.
  • Gain - Выигрыш. Вычислимое поле, является разностью Orig. Est. и Current Est.
  • Deadline - крайний срок решения/выполнения бага.

Единица измерения — часы. Можно вводить дробные значения 1.5 = полтора часа.

Time Summary

Отчет Time Summary для выбранного списка багов показывает зарегистрированные трудозатраты за заданный период с группировкой по месяцам, с разбивкой по сотрудниками или багам.

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

В процессе использования Bugzilla было сделано много доработок. О них можно очень кратко прочитать здесь Bugzilla: Список доработок#Доработки 3.x

  • Поддерживайте целостность:
    • Дублируйте содержимое 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-картинками.

  • Конфликты

Если вы считаете, что отправленный вами баг некорректно помечен как DUPLICATE of another, задавайте вопросы-комментарии в вашем баге, а не в том, который считается багом-оригиналом. Смело добавляйте в CC List бага человека, который принял такое решение, если его нет.

Флаги

Флаг — это некий атрибут, разновидность статуса, который может быть установлен на баг или вложение, чтобы указать, что этот баг/вложение находятся в некотором состоянии. Каждая инсталляция Bugzilla может определить свой собственных набор флагов, которых можно устанавливать на баг или вложение. Флаги в отличие от ключевых слов, имеющих «глобальную область» видимости для всех продуктов и компонентов, можно делать локальными, устанавливая набор продуктов и компонентов, в которых может быть установлен этот флаг.

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

Чтобы установить флаг, выберите +, или - из выпадающего списка Flags. Значение этих символов зависит от флага? в качестве примера, установление флага review в + может означать, что баг или вложение одобрены, а в - — отклонены. Чтобы сбросить флаг, выберите в выпадающем списке пустое значение.

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

В нашей инсталляции Bugzilla есть доработка, позволяющая не вводить пользователей для запрашиваемых флагов вручную, а выбирать из списка связанных с багом пользователей (Reporter, Assignee, QA Contact, CC List).

Установленный флаг показывается на странице бага и странице edit attachment рядом с аббревиатурой установившего флаг пользователя. Например: Иван: review [ + ]. Аналогично показывается запрошенный флаг, только в скобках показывается имя пользователя, у которого запрошена установка флага, например Иван: review [ ? ] (Бибичев).

Отчеты и графики

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

Отчеты

Отчет представляет собой некий информационный срез о текущем состоянии базы зарегистрированных багов. Можно сделать отчет как обычным, HTML-табличным, так и графическим, с различными видами графиков: линейными, круговыми, гистограммы (line/pie/bar), и переключаться между этими режимами просмотра онлайн.

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

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

Или разработчик может выбрать все свои баги, распределив их по критичности и своей оценке приоритета, получив следующую таблицу, где каждая ячейка (например, (major,P2)=> 2) является гиперссылкой на выборку соответствующих багов (в данном случае, двух багов, у которых в дополнение к условиям общего запроса Severity=major, а Priority=P2):

            Priority
Severity       P2       P3     P4     P5   Total
 major         2        .       1     .     3
 normal        8        1       1     .     10
 minor         .        .       2     2     4
 trivial       .        1       .     .     1
 enhancement   .        .       1     1     2
 Total         10       2       5     3     20

От выборки багов можно снова перейти к таблице и продолжить детализацию далее (см. описание Summary report в списках багов.

После заполнения параметров и вызова Generate Report вы можете переключаться между форматами HTML, CSV, Bar, Line, Pie (формат Pie доступен, если вы определили только одну горизонтальную ось). Остальные интерфейсные элементы интуитивно понятны — можно изменять размер картинки, если текст наползает графику или слишком узкие столбцы гистограмм.

В нашей инсталляции Bugzilla кроме числа багов можно просматривать агрегированные временные параметры бага:

  • Remaining time;
  • Estimated time.

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

          Priority
Severity       P2      P3      P4      P5      Total
major          32      .       .       .       32
normal         47.5   184      .       .       231.5
minor          .       .       .       192     192
trivial        .       5       .       .       5
enhancement    .       .       30      3       33
Total          79.5   189      30      195     493.5

Динамические графики (Charts)

Динамические график (chart, чарт) — это просмотр эволюции состояния базы багов во времени.

В данный момент в Bugzilla есть две системы построения таких графиков — Old Charts и New Charts.

Old Charts — это старая, давно используемая система, она отображает только изменения статусов и решений багов для каждого продукта. Она более не поддерживается и не развивается, и будет вскоре исключена из системы. Развиваться будет система New Charts, которая позволяет отрисовывать все, что можно задать поисковым запросом.

Обе системы требуют, чтобы администратор настроил скрипт, собирающий данные.

Каждая отдельная линия в чарте представляется датасетом data set, которые упорядочены в категории и подкатегории. Категории/подкатегории автоматически определяются на основе отношений Продукт/Компонент (для всех продуктов и компонентов), но также можно определять и любые другие категории.

Датасеты могут быть публичными (видимыми для всех) и приватными (доступными только создателю). Сделать датасет публичным могут только администраторы.

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

  • Создание Динамических графиков

Для создания динамического графика необходимо выбрать в списке требуемые датасеты и нажать Add To List. В списке List Of Data Sets To Plot вы можете задать название для каждого отображаемого датасета, также можно заказать суммирование подмножества выбранных датасетов (то есть просуммировать датасеты? представляющие баги в состоянии RESOLVED, VERIFIED и CLOSED для выбранного продукта, получив полное число исправленных багов). Ошибочно добавленный датасет можно исключить с помощью чекбокса и Remove. Если вы добавили более одного датасета, в списке автоматически появится линия Grand Total. Если она не нужна, ее можно удалить, как и любую другую линию.

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

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

По окончании настроек нажмите Chart This List для получения чарта.

  • Создание датасетов

Для создания нового датасета следуйте ссылке create a new data set на странице Create Chart. Используя стандартный интерфейс выбора определите нужную выборку, внизу страницы определите категорию, подкатегорию и имя для нового датасета.

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

Настройки пользователя

После того, как вы войдете в систему, вы можете изменить личные настройки Bugzilla по ссылке Preferences.

Настройки расположены на пяти вкладках: General preferences, Email preferences, Saved searches, Name and password, Permissoins. Рассмотрим подробнее каждую из них.

General preferences

Вкладка содержит простые настройки общеинтерфейсного плана.

В нашей инсталляции Bugzilla дополнительно включены настройки:

  • After changing a bug - по умолчанию, после правки бага Bugzilla перенаправляет на следующий баг в списке, однако большинство людей это смущает, и они путают следующий баг с предыдущим. Для борьбы с этим поведением и служит данная опция. Нужно выбрать Show the updated bug;
  • Remind me to track worktime for each comment - запрос затраченного времени, если пользователь из timetrackinggroup не заполнил (поставил 0) в Hours Worked при введении комментария;
  • Remind me to track worktime for new bug - требование введения трудозатрат от пользователя из timetrackinggroup при постановке каждого нового бага;
  • Remind me about flag requests - при вводе комментария пользователем, на которого поставлены флаги-запросы (флаги в состоянии ?, у которых requestee = этому пользователю) — будет проверять и переспрашивать, не желает ли пользователь изменить состояния флагов (ответил ли он своим комментарием на эти вопросы).

Email preferences

Эти настройки определяют когда и сколько писем будет вам прислать Bugzilla. Если вы хотите получать все письма — нажмите кнопку Enable All Mail, если не хотите получать письма от Bugzilla вообще — нажмите Disable All Mail.

Администратор Bugzilla может заблокировать получение почты пользователем через добавление имени пользователя в файл data/nomail. Такие меры применяются в исключительных случаях — например, для аккаунтов уволившихся сотрудников.

Раздел Global options содержит (пока?) только настройки извещений по флагам):

  • Email me when someone asks me to set a flag - уведомление о том, что вам адресован запрошенный флаг;
  • Email me when someone sets a flag I asked for - уведомление о том, что кто-то ответил (установил в + или -) на запрошенный вами флаг.

Раздел Field/recipient specific options содержит настройки для определения случаев, когда вы хотите получать письма от Bugzilla, и в каких отношениях с багом вы должны при этом находиться. Поставьте/уберите галочки в соответствующих клетках.

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

  • Reporter - вы указаны в поле Reporter;
  • Assignee - вы указаны в поле Assigned To;
  • QA Contact - вы указаны в поле QA Contact;
  • CCed - вы указаны в списке CC List.

Почту также можно фильтровать по различным заголовкам X-Bugzilla-Что-Нибудь, присутствующих во всех письмах от Bugzilla (см. [[#Дополнительные email-заголовки|Дополнительные email-заголовки).

По умолчанию Bugzilla рассылает почту вне зависимости от того, кто был автором изменения бага, и вы будете получать почту, даже если будете единственным лицом, связанным с багом. Если вы не хотите получать письма после своих изменений, поставьте галочки в строке but not when (overrides above): The change was made by me.

Note.svg Если использовать более-менее вменяемый почтовый клиент, лучше разрешить получать почту и комментарии при своих изменениях, добавив правило «помечать письма содержащие 'xxx@company.com changed:' как прочтенные» (Вместо xxx@company.com разумеется, ваш логин). Установив локальный поисковик и проиндексировав почту, это даст возможность удобного полнотекстового поиска по всем комментариям связанных с вами багов.

Раздел User Watching содержит пользователей, следящих за вашим потоком извещений от Bugzilla.

Если вы введете список (разделенный запятыми) пользовательских аккаунтов (обычно совпадающих с email-адресами) в Users to watch, то будете получать копию всех писем, рассылаемых пользователю Bugzillой (с учетом настроек безопасности).

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

Caution.svg Не злоупотребляйте этой возможностью!

Saved searches

... добавить инфу ...

Name and password

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

Permissoins

Чисто информационная вкладка, описывающая все права пользователя в текущей инсталляции Bugzilla — какие группы продуктов доступны, может ли пользователь редактировать баги и осуществлять административные функции.

Фильтрация писем от Bugzilla

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

Заголовки — это не subject, а внутренние заголовки письма, увидеть которые можно в свойствах письма или выбрав в почтовой программе пункт View Message Headers или подобный.

Список заголовков:

  • X-Bugzilla-Reason - отношение получателя к упомянутому багу: Assigned To (ответственный), Reporter (создатель бага), QA Contact (тестировщик), CC List (наблюдатель), Voter (голосовал за баг);
  • X-Bugzilla-Watch-Reason - то же, но каждое значение означает, что получатель наблюдает за пользователем, имеющим соответствующее отношение к упомянутому багу. Плюс есть ещё одно значение — GlobalWatcher, означающее, что пользователь получает всю почту по всем багам;
  • X-Bugzilla-Type - new (новый баг), changed (изменение) или request (изменение флагов);
  • X-Bugzilla-Who - логин (то есть, e-mail адрес) изменившего баг;
  • X-Bugzilla-Changed-Fields - список изменённых полей упомянутого бага;
  • X-Bugzilla-Added-Comments - количество добавленных комментариев (0 или более).

Также есть набор заголовков, имеющих значением значение соответствующего атрибута бага:

  • X-Bugzilla-Classification
  • X-Bugzilla-Product
  • X-Bugzilla-Component
  • X-Bugzilla-Status
  • X-Bugzilla-Priority
  • X-Bugzilla-Severity
  • X-Bugzilla-Assigned-To
  • X-Bugzilla-QA-Contact
  • X-Bugzilla-Target-Milestone
  • X-Bugzilla-Keywords

Примеры:

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

Решение: Заголовок X-Bugzilla-Added-Comments равен 0 и заголовок X-Bugzilla-Changed-Fields пуст.

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

Решение: В Outlook создать правило, которое будет перемещать письма, содержащие в заголовке "X-Bugzilla-Reason: Assigned-To" или "X-Bugzilla-Reason: CC Assigned-To" или "X-Bugzilla-Type: request" или "X-Bugzilla-Reason: Reporter", в нужную папку.

Просмотр Патчей

Важно: под патчем или исправлением здесь имеется в виду именно патч, то есть файл в специальном стандартном текстовом формате (patch), представляющий собой инструкции для программы-патчера по проносу изменений. А не какие-либо тексты программ или инструкции для человека.

Просмотр и ревизия исправлений в Bugzilla часто затруднена из-за недостатка контекста, несоответствующих форматов и других сложностей. Patch Viewer это дополнение Bugzilla, предназначенное для улучшения контекста, интеграции с Bonsai, LXR, CVS.

Patch Viewer позволяет:

  • Просмотр исправлений с раскраской, в режиме side-by-side, а не интерпретация сырого содержимого исправления;
  • Просмотр разницы между двумя исправлениями;
  • Получение контекстной информации об исправлении;
  • Удобный просмотр исправления с возможностью скрывать/раскрывать разделы;
  • Ссылки на разделы исправления для обсуждения или ревизии;
  • Ссылки на Bonsai или LXR для определения ответственности;
  • Создает исправления в унифицированном diff-формате.

В нашей инсталляции Bugzilla мы не используем PatchViewer, так как есть гораздо более удобная система просмотра версионных репозиториев ViewVC (см. Интеграция с системами контроля версий).

Ссылки

Bugzilla в России; Bugzilla в Википедии; Bug Tracking системы (бесплатные).

Категория:Программирование Категория:Тестирование программного обеспечения Категория:Bugzilla



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


Статья реплицируется в Wiki4IntraNet.

Внимание! Данная статья выбрана для репликации в SMWiki.