Testowanie oprogramowania. Testowanie oprogramowania 1/34

Transkrypt

1 Testowanie oprogramowania Testowanie oprogramowania 1/34

2 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

3 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

4 Testowanie oprogramowania 4/34 Testowalność Miary testowalności operatywność obserwowalność sterowność podzielność prostota stabilność zrozumiałość

5 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.

6 Testowanie oprogramowania 6/34 Weryfikacja i walidacja oprogramowania Weryfikacja Czy zbudowaliśmy system dobrze? Walidacja Czy zbudowaliśmy dobry system?

7 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

8 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

9 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

10 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

11 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

12 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

13 Testowanie oprogramowania 13/34 Czym jest testowanie Wariant testu (przypadek testowy, ang. test case)

14 Czym jest testowanie Testowanie oprogramowania 14/34

15 Testowanie oprogramowania 15/34 Ograniczenia testowania testowanie + statyczna weryfikacja = pełne pokrycie dla weryfikacji i walidacji testowanie jest jedyną techniką walidacji dla wymagań niefunkcjonalnych

16 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 ] ; e l s e x [ i ] = x [ i ] / 2 ; } n Path No

17 aksjomat antyekstensjonalności Testowanie oprogramowania 17/34

18 Aksjomat antydekompozycji Testowanie oprogramowania 18/34

19 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.

20 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

21 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

22 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%

23 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

24 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

25 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ę

26 Testowanie oprogramowania 26/34 Rodzaje testów testy jednostkowe testy integracyjne testy systemowe testy akceptacyjne

27 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

28 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

29 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

30 Testowanie oprogramowania 30/34 Testowanie a debugowanie testowanie to nie debugowanie

31 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

32 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

33 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ść

34 Testowanie oprogramowania 34/34 Prezentacja oparta o: Wprowadzenie do testowania, Błażej Pietrzak,