Система отслеживания ошибок Bugzilla Цель работы

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

Краткие теоретические сведения

Bugzilla - приложение для отслеживания ошибок, разработанная «The Mozilla Organization». Приложения подобного рода позволяют разработчику или группам разработчиков отслеживать ошибки в приложениях и запросы на дополнение приложений новой функциональностью. Фактически, Bugzilla ис- пользуется во многих корпорациях для разработки собственного программного обеспечения для корпоративных нужд.

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

Bug имеет свои атрибуты:

1) Product and Component (Продукт и компонент):

«Продукт». Основной атрибут, задающий структуру. Каждый «Product» состоит из набора компонентов.

Например, продукт "Bugzilla" состоит из нескольких компонентов:

· Administration – администрирование;

· Bugzilla-General – всё, что не вписывается в другие компоненты, или охватывает несколько компонентов;

· Creating/Changing Bugs – создание, изменение и просмотр ошибок;

· Documentation – документация по продукту;

· Email – всё, что связано с электронной почтой;

· Installation – процесс установки Bugzilla;

· Query/Buglist – поиск ошибок и просмотр «баг-листов»;

· и т.д.

2) Status (Статус)

Основной атрибут, определяющий текущее состояние бага, то есть меру его активности — от самого «начального» состояния, когда он даже не под- твержден, как баг, до благополучного завершения, когда баг исправлен/решен, что подтверждено Службой Качества.

Статус может быть пяти видов: UNCONFIRMED

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

«canconfirm». Если же новые баги ставят только обученные сотрудники, то в это состояние, скорее всего не нужно.

CONFIRMED («Подтверждён»); IN PROGRESS («В процессе»); RESOLVED («Решён»);

VERIFIED («Проверен»).

3) Resolution («Решение»)

Этот атрибут имеет смысл только для багов в состояниях «RESOLVED»,

«VERIFIED», «CLOSED». Также, набор «решений» можно настраивать, но стандартный набор следующий:

· FIXED («Решено»);

· INVALID («Некорректно» — неправильная или некорректная поста- новка, не имеющая смысла);

· WONTFIX («Проблема есть, но решать ее не будем»);

· DUPLICATE («Дубль» — описанная проблема уже регистрировалась в определенном баге);

· WORKSFORME («А у меня работает…» — не удалось воспроизвести описанную проблему ни эмуляцией сценария, ни анализом кода);

· MOVED (Проблема перенесена в иную систему);

· LATER (Задача зафиксирована, но ее решение откладывается на не- определенный срок. Возможно для ее решение нужно некоторое внешнее собы- тие, или решение каких-либо задач).

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

· Assigned_To (Лицо (сотрудник, пользователь), ответственное за реше- ние (исправление) бага);

· Reporter (Пользователь, собственно составивший (заполнивший ин- формацию) о баге);

· QA (Пользователь, ответственный за проверку решения бага);

· CC («СС list»: Список людей, извещаемых при изменениях бага).

5) и др.

Ход работы