plik

Bugzilla

uproszczona instrukcja użytkowania

TOMASZ ŁUKASZUK

STRESZCZENIE:

Dokument zawiera podstawowe informacje dotyczące użytkowania systemu

zarządzania błędami Bugzilla. Opisane są podstawowe funkcje produktu z punktu widzenia
użytkownika. Przedstawiony został także graf prezentujący cykl życia błedu.

1. WPROWADZENIE

Bugzilla jest systemem zarządzania błędami. Aplikacje tego rodzaju pozwalają

osobom indywidualnym oraz grupom utrzymywać porządek w błędach i zadaniach.
Napisana w Perlu, Bugzilla jest uznawana za de-facto standardowy system zarządzania
błędami, do którego porównuje się wszystkie inne. W tym momencie, Bugzilla jest
używana w bardzo wielu firmach do pomocy przy rozwoju ich własnych aplikacji.

Bugzilla jest bardzo stabilną aplikacją i oferuje wiele zaawansowanych funkcji.

Między innymi:



Zintegrowany, oparty na produktach schemat bezpieczeństwa



Zależności między błędami i możliwość tworzenia z nich grafów



Zaawansowane funkcje związane z raportowaniem błędów



Szybki, stabilny system RDBMS



Ogromne możliwości konfiguracji



Bardzo wygodny i naturalny system rozwiązywania błędów



API do E-maili, XMLa, konsoli, i HTTP



Możliwa integracja z automatycznymi aplikacjami konfiguracji zarządzania, takimi
jak Perforce czy CVS (przez interfejs e-mail Bugzilli oraz skrypty zapisu/odczytu)



… i wiele innych funkcji.

Wbrew nazwie (zarządzanie, monitorowanie błędów), systemy typu bugzilla

służą raczej do monitorowania wymaganych zmian - czymkolwiek by były (błędami do
usunięcia, rozszerzeniami do dodania, operacjami administracyjnymi do wykonania).
Mają one następujące podstawowe zastosowania, które mogą być ze sobą łączone:



w trakcie trwania projektu - rejestracja rzeczy, które mniej lub bardziej warto zrobić
ale nie ma na to na razie czasu - warto jednak by gdzieś ten pomysł został;



testowanie - usprawnienie przebiegu informacji o błędach wykrywanych w trakcie
testów i zapewnienie, że żaden wykryty błąd nie zostanie zapomniany i że każdy trafi
do właściwej osoby;



po wdrożeniu  - ułatwienie osobom świadczącym wsparcie techniczne rejestrowania
zgłaszanych   przez   klientów   problemów   i   wymaganych   zmian   -   wraz   z
automatycznym   powiadamianiem   o   nich   odpowiedzialnych   za   poszczególne
komponenty;



jeśli nasi klienci są tym zainteresowani (i im na to pozwolimy) - mogą oni
bezpośrednio wprowadzać opisy problemów a także obserwować co się z nimi dzieje
(w szczególności być powiadamiani o rozwiązaniu lub odrzuceniu problemu).

Bugzilla stwarza także możliwość generowania efektownie wyglądających

raportów typu "liczby zgłoszonych i usuniętych błędów tygodniowo".

2. TWORZENIE KONTA UŻYTKOWNIKA

Aby używać Bugzilla'i użytkownik potrzebuje własnego konta w serwisie. Na

stronie głównej należy kliknąć „Open new Bugzilla account”, następnie podać swój adres
mailowy i, opcjonalnie, pełne imię i nazwisko, potem kliknąć „Create Account”. Po
momencie użytkownik powinien otrzymać na podany adres wiadomość zawierającą login
(zazwyczaj identyczny jak adres mailowy) i hasło. Hasło jest losowo generowane, ale
później możliwa jest jego zmiana na łatwiejsze do zapamiętania.

Po założeniu konta użytkownik może się zalogować. Bugzilla używa cookies do

pamiętania o logowaniu, dlatego dopóki cookies nie zostaną unieważnione albo adres IP
zmieniony nie ma potrzeby ponownego logowania.

3. ANATOMIA BŁĘDU

Najważniejszym elementem Bugzilla'i jest ekran wyświetlający informacje o

błędzie. Zawiera on następujące pola:

–

Product and Component – określenie jakiego produktu i komponentu (elementu
produktu) dotyczy błąd,

–

Status and Resolution – definiuje aktualny status błędu, począwszy od
niepotwierdzonego błędu, poprzez błąd w trakcie rozwiązywania aż do
potwierdzonego rozwiązania błędu,

–

Assigned To – osoba odpowiedzialna za poprawienie błędu,

–

URL – url związany z błędem, element opcjonalny,

–

Summary – jednozdaniowy opis problemu,

–

Status Whiteboard – krótka notatka dotycząca błędu,

–

Keywords – administrator może zdefiniować słowa kluczowe, które można użyć do
etykietowania i kategoryzowania błędów, np. krytyczny błąd, itp.,

–

Platform and OS – środowisko, w którym błąd został wykryty,

–

Version – wersja produktu lub/i komponentu, do których odnosi się błąd,

–

Priority – używane do priorytetowania błędów,

–

Severity – określenia jak poważny jest błąd, od uniemożliwiającego poprawną pracę
aplikacji do trywialnego,

–

Target – numer przyszłej wersji produktu, która będzie pozbawiona rozpatrywanego
błędu,

–

Reporter – osoba opisująca/zgłaszająca błąd,

–

CC list – lista osób, która otrzymają maila z informacją w momencie gdy błąd
ulegnie zmianie,

–

Time Tracking – śledzenie, estymowanie czasu naprawy błędu,

–

Attachments – pliki dołączone, powiązane z błędem (np. przypadki testowe, patch'e,
inne pliki),

–

Dependiences – określone jeżeli błąd nie może być naprawiony dopóki inne błędy nie
zostaną naprawione (depends on), lub rozpatrywany błąd blokuje naprawę innych
błędów (blocks), wyliczone są numery błędów,

dla wszystkich elementów opisu błędu. Dla niektórych pól możliwe jest określenie wielu
wartości jednocześnie. Bugzilla zwraca błędy, których elementy opisu pasują do wartości
określonych przez użytkownika.

6. RAPORTY I WYKRESY

Bugzilla pozwala na prezentowanie nawet złożonych zapytań w postaci raportów

i wykresów.

Zapytanie określa się w postaci Field Operator Value. Możliwe jest łączenie

zapytań za pomocą operatorów „And”, „Or” lub poprzez użycie przycisku „Add Another
Boolean Chart”. Wynikiem może być wykres liniowy, słupkowy lub tabela z wartościami.

Politechnika Białostocka
Wydział Informatyki
Katedra Oprogramowania
ul. Wiejska 45A
15-351 Białystok

10 maja 2006