Efektywne zarządzanie błędami

Prezentacja na temat: "Efektywne zarządzanie błędami"— Zapis prezentacji:

1 Efektywne zarządzanie błędami
Hubert Pardel Tomasz Pękalski

2 Czym są błędy oprogramowania?
Błąd oprogramowania lub w żargonie informatycznym bug - wyrażenie oznaczające pewien błąd, usterkę, niepożądane, powtarzające się przy zajściu określonych czynników działanie programu, wynikające z błędu człowieka na jednym z etapów tworzenia oprogramowania (zwykle na etapie projektowania lub tworzenia kodu źródłowego).

3 Rodzaje błędów Składniowe Logiczne
Błędy nie pozwalające na kompilację programu, np. literówki, brak średnika – łatwe do usunięcia Logiczne błędy, które nie przerywają kompilacji, lecz powodują niewłaściwe działanie warstwy logicznej aplikacji – dużo trudniejsze do usunięcia

4 Najczęstsze typy błędów logicznych
Próba dzielenia przez 0 Nieskończona pętla Użycie niezainicjowanej zmiennej Wyciek pamięci Przepełnienie bufora Arytmetyczny nadmiar/niedomiar Zakleszczenie Utrata precyzji przy konwersji typów

5 Cykl życia błędu Wykrycie błędu Zgłoszenie błędu
Przypisanie błędu do programisty Naprawa błędu

6 Efektywne zgłaszanie błędu
Sprawdź listę znanych błędów Bądź konkretny Bądź gadatliwy Uważaj na zaimki Przeczytaj to co napisałeś 1 błąd – 1 raport

7 Co powinien zawierać raport o błędzie?
Numer błędu Unikalny identyfikator, dzięki któremu błąd może zostać zidentyfikowany Krótki opis Traktowany także jako „tytuł” błędu Jeden z najważniejszych elementów raportu

8 Co powinien zawierać raport o błędzie? (2)
Nazwa produktu/projektu Nazwa może zawierać także nazwę kodową produktu Wersja produktu Dokładna numer wersji produktu, w którym wystąpił błąd

9 Co powinien zawierać raport o błędzie? (3)
Kolejne kroki: Łatwe do odtworzenia, jak najbardziej dokładne opisy kolejnych czynności, które doprowadziły do wystąpienia błędu Otworzyłem aplikację Otworzyłem nowy project(File->New->Project) Wpisałem wyrażenie ”5*x” w polu wzór funkcji, „-10” w polu x_min i „100” w x_max Kliknąłem 3 razy szybko myszką w ikonkę(w prawym dolnym rogu) „Rysuj Wykres”

10 Co powinien zawierać raport o błędzie? (3)
Aktualny Rezultat: Co aplikacja zrobiła po wykonaniu powyższych kroków. Aplikacja się wyłączyła. Oczekiwany Rezultat: Co aplikacja powinna zrobić, gdyby błąd nie zaistniał. Aplikacja powinna narysować wykres (I nie powinna sie wyłączyć.)

11 Co powinien zawierać raport o błędzie? (4)
Data I System Operacyjny: Data pierwszego zauważonego błędu i system operacyjny lub sprzęt na którym to miało miejsce na Mac OS Dodatkowe Daty: Jeśli błąd wystąpił na innym sprzęcie na Windows XP Home (Service Pack 2)

12 Co powinien zawierać raport o błędzie? (5)
Dodatkowe Informacje: Inne pomocne informacje Dla wyskakujących błędów: Win32: Jeśli zauważysz jakiś błąd zapisz jego rodzaj oraz program w którym miało to miejsce. Mac OS X: Kiedy aplikacja się nieoczekiwanie zamknie naciśnij przycisk “Report” w oknie które się pojawi i skopiuj cały tekst z ramki pod wiadomością "Problem and system information"

13 Co powinien zawierać raport o błędzie? (6)
Dodaj Załącznik: Możesz również dodać załącznik zawierający raport błędu, np. uzyskany podczas debuggowania błędu(przyjmuje się że jeśli informacja jest dłuższa niż 20 linijek to wówczas najlepiej dodać załącznik). Jeśli masz również jakiś plik który pokazuje moment wystąpienia błędu możesz również go umieścić w raporcie.

14 Co powinien zawierać raport o błędzie? (7)
Programista Pole może zostać przypisane automatycznie lub pozostać puste Stan błędu „Otwarty”, „W toku”, „Zweryfikowany”, „Zamknięty”

15 Co powinien zawierać raport o błędzie? (8)
Priorytet błędu „Pilny”, „Wysoki”, „Średni”, „Niski” Historia błędu Lista wszystkich zmian dotyczących danego błędu

16 Możliwe odpowiedzi W odpowiedzi na zgłoszenie, programista odpowiedzialny za dany błąd może dać jedną z poniższych odpowiedzi: Fix Programista naprawił błąd (lub tak mu się wydaje)

17 Możliwe odpowiedzi(2) Defer Dupe (Duplicate)
Błąd nie jest poważny i jego naprawa może zostać odłożona na później Dupe (Duplicate) Ktoś inny zgłosił dany błąd wcześniej

18 Możliwe odpowiedzi(3) Need More Information (NMI) Not a Bug (NAB)
Programista nie dostał wystarczających informacji, aby zająć się błędem Not a Bug (NAB) Zachowanie aplikacji było zamierzone

19 Możliwe odpowiedzi(4) Not Reproducible (NREP) Not Plan to Fix (NPTF)
Programiście nie udało się odtworzyć błędu Not Plan to Fix (NPTF) Błąd został uznany za istotny, ale programiści nie planują na razie nic z nim zrobić User Error Delikatny sposób na stwierdzenie, że to nie program stanowi problem

20 Źródła http://www.chiark.greenend.org.uk/~sgtatham/bugs.html

21 Dziękujemy za uwagę