1/30 Testowanie oprogramowania Adam Roman Instytut Informatyki UJ Wykład 1 dlaczego testowanie jest niezbędne czym jest testowanie ogólne zasady testowania
Podstawowy proces testowy role i aktywności w procesie WYKONANIE PLANOWANIE ANALIZA PROJEK- TOWANIE IMPLE- MENTACJA EWALUACJA KRYT. WYJŚCIA, RAPORTOWANIE ZAMYKANIE KONTROLA analityk testów (Test Analyst) techniczny analityk testów (Technical Test Analyst) menedżer testów (Test Manager) czas 2/30
3/30 Dlaczego testowanie jest niezbędne? Przyczyny i skutki usterek w oprogramowaniu
Przyczyny usterek w oprogramowaniu 4/30
5/30 Skutki usterek w oprogramowaniu AT&T blackout (1990) Therac-25 (1985-1987) Ariane 5 (1996) Mars Climate Orbiter (1999)
6/30 Skutki usterek w oprogramowaniu $ 60 000 000 5 $ 500 000 000 $ 125 000 000
Inne katastrofy Rok Incydent Komentarz 1962 1982 1988 1988-1996 Próbnik kosmiczny Mariner I Sowiecki rurociąg gazowy Berkeley Unix finger daemon Kerberos 1993 Intel Pentium 1994/5 Gra Król Lew Disneya 1995 The Ping of Death 2000 National Cancer Institute Błąd w oprogramowaniu zmienia tor lotu; kontrola misji niszczy rakietę nad Oceanem Atlantyckim Działania CIA powodują największą nienuklearną eksplozję w historii planety Błąd przepełnienia bufora umożliwia przejęcie kontroli nad maszyną; 2-6 tysięcy infekcji w 1 dzień Generator liczb losowych w Kerberosie był błędnie inicjalizowany system trywialnie można było złamać Błąd w dzieleniu zmiennoprzecinkowym (koszt: 475 000 000 $) Klienci nie byli w stanie uruchomić programu (brak testów dla najpopularniejszych modeli komputerów) Błędy przy składaniu pakietów IP pozwalają zawiesić system spreparowanym poleceniem ping Historia podobna do Therac-25 7/30
Czym jest testowanie? 8/30
9/30 Paradoks testowania TWORZENIE OPROGRAMOWANIA TESTOWANIE OPROGRAMOWANIA
10/30 Błędne opinie o testowaniu Testowanie jest procesem mającym wykazać, że przedmiotowy program jest wolny od błędów Celem testowania jest udowodnienie, że program prawidłowo realizuje swe funkcje
11/30 Definicja testowania Testowanie programu polega na jego wykonywaniu z intencją wykrywania tkwiących w nim błędów Stanowisko IEEE: Celem testowania oprogramowania jest takie wyszukiwanie awarii, że gdy oprogramowanie ulegnie awarii podczas testów, usterki odpowiedzialne za te awarie będą mogły być znalezione i poprawione
Psychologia w kontekście testowania 12/30
13/30 Psychologia testowania (1) CEL TESTOWANIA Wykazać, że testowany program nie zawiera błędów Konstrukcja złych (słabych) przypadków testowych Podświadome dążenie do przekonania, że tak rzeczywiście jest Wykazać, że testowany program zawiera mnóstwo błędów Dobrze skonstruowane, przemyślane testy Brak objawów błędów Większe przekonanie, że w programie nie ma błędów Większe prawdopodobieństwo wykrycia błędu!
Psychologia testowania (2) implikacja przyjętej definicji 14/30
15/30 Psychologia testowania (3) wymówki deweloperów od testowania Eee, pisanie testów zajmuje zbyt dużo czasu Przeprowadzenie testów zajmuje zbyt dużo czasu Testowanie? Nie, to nie mój obowiązek! Are you crazy? Firma nie pozwoli mi robić testów na działającym systemie! Och, nie chcę odbierać pracy testerom i działowi kontroli jakości Sorry, ale płacą mi za pisanie kodu, a nie za testowanie Hmm Nie wiem jak powinien zachowywać się kod, więc nie mogę go przetestować Hello! Przecież program się poprawnie skompilował?!
Psychologia testowania (4) Projektant testów vs. poziom niezależności: 1. Programista 2. Inny członek zespołu 3. Osoba z innego zespołu 4. Osoba z innej organizacji 16/30
17/30 Ogólne zasady testowania Podstawowe defincje
Ogólne zasady testowania 1. Testowanie ujawnia usterki 2. Testowanie gruntowne jest niewykonalne 3. Wczesne testowanie 4. Kumulowanie się błędów 5. Paradoks pestycydów 6. Testowanie zależy od kontekstu 7. Mylne przekonanie o braku błędów 18/30
19/30 Poziomy testowania wg Beizera nic nie dowodzić, redukować ryzyko pokaż, że program działa pokaż, że program nie działa testowanie = dyscyplina umysłu testowanie = debugowanie
Czynności testowania planowanie i nadzór wybór warunków testowych projektowanie przypadków testowych wykonywanie przypadków testowych sprawdzanie wyników ocena spełnienia kryteriów zakończenia raportowanie procesu testowania zamykanie testów 20/30
Jak dużo testowania jest potrzebne? 21/30
22/30 Podstawowe pojęcia (1) walidacja vs. weryfikacja walidacja (ang. validation) ewaluacja oprogramowania w końcowej fazie procesu budowy, dokonywana w celu potwierdzenia zgodności z założonymi celami użycia are we building the right thing? weryfikacja (ang. verification) ewaluacja we wczesnych fazach, sprawdzająca, czy produkt danej fazy spełnia wymagania ustalone podczas poprzedniej fazy are we building the thing right?
23/30 Podstawowe pojęcia (2) usterka, błąd, awaria usterka (ang. fault, defect, bug) statyczny defekt w oprogramowaniu błąd (ang. error) nieprawidłowy stan wewnętrzny, będący manifestacją jakiejś usterki awaria (ang. failure) zewnętrzne, nieprawidłowe zachowanie ze względu na wymagania lub inny opis oczekiwanego zachowania
Podstawowe pojęcia (3) błąd dokumentacji błąd oznacza, że program produkuje nieoczekiwany wynik wynik może być poprawny, ale różny od oczekiwanego mówimy wtedy o błędzie dokumentacji do eliminacji tego typu błędów służą metody analizy statycznej, a w szczególności inspekcje i przeglądy 24/30
Przykład public static int numzero(int[] x) { //Effects: if x==null throw //NullPointerException, else return //the number of occurences of 0 in x int count = 0; for (int i=1; i<x.length; i++) { } if (x[i]==0) { } count++; return count; } gdzie jest usterka? 25/30
Przykład public static int numzero(int[] x) { //Effects: if x==null throw //NullPointerException, else return //the number of occurences of 0 in x int count = 0; for (int i=1; i<x.length; i++) { } if (x[i]==0) { } count++; return count; } gdzie jest usterka? 26/30
Przykład public static int numzero(int[] x) { //Effects: if x==null throw //NullPointerException, else return //the number of occurences of 0 in x int count = 0; for (int i=1; i<x.length; i++) { } if (x[i]==0) { } count++; return count; } gdzie jest usterka? numzero([2,7,0]) usterka powoduje błąd nie ma awarii stan programu: (x=[2,7,0], count=0, i=1, PC=if) numzero([0,7,2]) usterka powoduje błąd jest awaria 27/30
Testowanie a debugowanie testowanie = ewaluacja programu poprzez obserwację jego wykonania awaria testowa = wykonanie prowadzące do awarii debugowanie = znajdowanie usterki mając awarię nie każde dane wejściowe aktywują usterkę często trudno odnieść awarię do usterki analiza takiego odniesienia prowadzi do modelu usterka/awaria 28/30
29/30 Model RIP (usterka/awaria) mówi o 3 warunkach, jakie muszą zajść aby móc zaobserwować awarię 1. Reachability (miejsce zawierające usterkę musi być osiągalne) 2. Infection (po wykonaniu w tym miejscu stan programu jest nieprawidłowy) 3. Propagation (zainfekowany stan propaguje się na wyjście programu)
KONIEC 30/30