Testowanie oprogramowania Testowanie oprogramowania 1/34
Testowanie oprogramowania 2/34 Cele testowania testowanie polega na uruchamianiu oprogramowania w celu wykrycia błędów, dobry test to taki, który z dużym prawdopodobieństwem pozwala znaleźć błąd wcześniej nie wykryty test można uznać za skuteczny, jeżeli doprowadził do wykrycia nowych błędów
Testowanie oprogramowania 3/34 Zasady testowania testy należy tworzyć na podstawie wymagań klientów testowanie należy zaplanować na długo przed jego rozpoczęciem do testowania stosuje się zasadą Pareto testowanie powinno postępować od szczegółu do ogółu testowanie gruntowne (wyczerpujące) jest niewykonalne testowanie przeprowadzane przez niezależne osoby daje lepsze wyniki
Testowanie oprogramowania 4/34 Testowalność Miary testowalności operatywność obserwowalność sterowność podzielność prostota stabilność zrozumiałość
Testowanie oprogramowania 5/34 Właściwości testu Cechy dobrego testu Dobry test daje prawdopodobieństwo wykrycia błędu. Testy nie powinny się dublować. Wybrane testy nie powinny być najlepsze w swoim rodzaju. Testy nie powinny być zbyt proste, ani zbyt skomplikowane.
Testowanie oprogramowania 6/34 Weryfikacja i walidacja oprogramowania Weryfikacja Czy zbudowaliśmy system dobrze? Walidacja Czy zbudowaliśmy dobry system?
Testowanie oprogramowania 7/34 Proces weryfikacji i walidacji Weryfikacja i walidacja powinna być obecna na każdym etapie tworzenia oprogramowania Główne cele weryfikacji i walidacji to: Wykrycie błędów w systemie Ocena czy możliwe jest używanie systemu w realnym świecie
Testowanie oprogramowania 8/34 Weryfikacja statyczna i dynamiczna Statyczna (inspekcje kodu) związane z analizą statycznej reprezentacji systemu w celu wykrycia problemów Dynamiczna (testowanie oprogramowania) System jest uruchamiany z danymi testowymi i sprawdzane jest jego zachowanie
Testowanie oprogramowania 9/34 Stosowalność metod statycznych i dynamicznych Statyczna weryfikacja i walidacja specyfikacja wymagań projekt architektury systemu projekt szczegółowy program Dynamiczna weryfikacja i walidacja specyfikacja wymagań (jeśli tworzony prototyp) program
Testowanie oprogramowania 10/34 Cele weryfikacji i walidacji Cele weryfikacji i walidacji Weryfikacja i walidacja! = brak błędów w systemie Uzyskanie poziomu pewności działania systemu Poziom pewności zależy od: funkcja oprogramowania oczekiwania użytkownika rynek
Testowanie oprogramowania 11/34 Plan testów oprogramowania proces testowania śledzenie wymagań testowane elementy harmonogram testów procedury nagrywania testów wymagania odnośnie sprzętów i oprogramowania ograniczenia
Testowanie oprogramowania 12/34 Czym jest testowanie Definicja Testowanie oprogramowania to wykonanie kodu dla kombinacji danych wejściowych i stanów w celu wykrycia błędów Udany test = wykrycie błędu Efektywność testu = zdolność do znajdowania błędów
Testowanie oprogramowania 13/34 Czym jest testowanie Wariant testu (przypadek testowy, ang. test case)
Czym jest testowanie Testowanie oprogramowania 14/34
Testowanie oprogramowania 15/34 Ograniczenia testowania testowanie + statyczna weryfikacja = pełne pokrycie dla weryfikacji i walidacji testowanie jest jedyną techniką walidacji dla wymagań niefunkcjonalnych
Testowanie oprogramowania 16/34 Ograniczenia testowania Wyczerpujące testowanie jest na ogół niemożliwe f o r ( i n t i = 0 ; i < n ; i ++) { i f ( a. g e t ( i ) == b. g e t ( i ) ) x [ i ] = x [ i ] + 1 0 0 ; e l s e x [ i ] = x [ i ] / 2 ; } n Path No. 1 3 2 5 10 1025 60 1 152 921 504 606 847 200
aksjomat antyekstensjonalności Testowanie oprogramowania 17/34
Aksjomat antydekompozycji Testowanie oprogramowania 18/34
Testowanie oprogramowania 19/34 Aksjomat antykompozycji Aksjomat antykompozycji Zestawy testów, z których każdy osobno jest adekwatny dla segmentów w module, niekoniecznie są odpowiednie dla modułu jako całości.
Testowanie oprogramowania 20/34 Pokrycie kodu ile kodu jest pokryte przez testy pokrycie instrukcji (ang. statement coverage) każda instrukcja jest sprawdzana pokrycie gałęzi (ang. branch coverage) każda gałąź była odwiedzona instrukcja warunkowa musi być przynajmniej raz prawdziwa i przynajmniej raz fałszywa
Testowanie oprogramowania 21/34 Pokrycie instrukcji i gałęzi przykład v o i d f u n c ( i n t l i c z b a ) { i f ( ( l i c z b a % 2) == 0) cout << " liczba parzysta " << endl ; f o r ( ; l i c z b a < 5 ; l i c z b a ++) cout << " liczba " << l i c z b a << e n d l ; } Pokrycie instrukcji Wystarczy przypadek testowy z liczba = 4 Pokrycie gałęzi Dwa przypadki testowe z liczba = 4 i liczba = 13
Testowanie oprogramowania 22/34 Problemy z pokryciem kodu l o n g m u l t i p l y ( i n t arg1, i n t arg2 ) { r e t u r n arg1 + arg2 ; } Dla arg1 = 0 oraz arg2 = 0 funkcja przyjmuje prawidłowy wynik, pokrycie 100%
Testowanie oprogramowania 23/34 Problemy z pokryciem kodu l o n g m u l t i p l y ( i n t arg1, i n t arg2 ) { r e t u r n arg1 + arg2 ; cout << " Martwy kod " << endl ; } 100% pokrycia kodu nie zawsze jest możliwe
Testowanie oprogramowania 24/34 Testowanie mutacyjne Sprawdzanie efektywności testu Test T program działa prawidłowo Test T jest efektywny, gdy wykryje zmutowany kod programu
Testowanie oprogramowania 25/34 Testowanie mutacyjne przykład l o n g dodawanie ( i n t arg1, i n t arg2 ) { r e t u r n arg1 arg2 ; } Przypadki testowe arg1 = 0 i arg2 = 0 nie wykrywa zmiany arg1 = 1 i arg2 = 1 wykrywa zmianę
Testowanie oprogramowania 26/34 Rodzaje testów testy jednostkowe testy integracyjne testy systemowe testy akceptacyjne
Testowanie oprogramowania 27/34 Testowanie regresyjne Testowanie regresyjne Ponowne wykonywanie opracowanych wcześniej testów Testowanie na dym (ang. smoke test) Czy program nadal się uruchamia
Testowanie oprogramowania 28/34 Zakres testów celem testów jest wykrywanie błędów w programach, tak aby mogły być poprawione testowanie nie udowadnia, że oprogramowanie zawsze działa poprawnie zakres testów może obejmować przeglądanie (inspekcję) kodu, jak również wykonywanie kodu w kontrolowanych warunkach
Testowanie oprogramowania 29/34 Metody tworzenia testów Metoda białej skrzynki (ang. white-box testing) sprawdza wewnętrzną strukturę programu testy jednostkowe, testy integracyjne Metoda czarnej skrzynki (ang. black-box testing) nie bierze pod uwagę wewnętrznej struktury programu wszystkie rodzaje testowania
Testowanie oprogramowania 30/34 Testowanie a debugowanie testowanie to nie debugowanie
Testowanie oprogramowania 31/34 Inspekcje a testowanie Angażują ludzi do przeglądania źródłowej reprezentacji systemu Nie wymagają uruchomienia systemu, więc mogą być użyte przed jego stworzeniem Mogą być zastosowane dla dowolnej reprezentacji systemu (wymagania, projekt itd.) Bardzo efektywna technika znajdowania błędów
Testowanie oprogramowania 32/34 Inspekcje a testowanie Wiele różnych błędów może zostać znalezione przez pojedynczą inspekcję W przypadku testowania, błąd może ukryć inny błąd Powtórne wykonanie testu w przypadku znalezienia i usunięcia błędu
Testowanie oprogramowania 33/34 Inspekcje a testowanie Inspekcje i testowanie są komplementarnymi technikami weryfikacji Obie powinny być używane podczas procesu weryfikacji i walidacji Inspekcje mogą znaleźć zgodność ze specyfikacją Nie sprawdzą zgodności z rzeczywistymi oczekiwaniami użytkownika Inspekcje nie mogą sprawdzić wymagań niefunkcjonalnych takich jak np. wydajność
Testowanie oprogramowania 34/34 Prezentacja oparta o: Wprowadzenie do testowania, Błażej Pietrzak, http://wazniak.mimuw.edu.pl/index.php?title=io-10-wyk-toc