17 KiB
Przygotowanie do projektu badawczo-rozwojowego
8. Testowanie w programowaniu zwinnym[wykład]
Krzysztof Jassem (2021)
1. Przykłady katastrof spowodowanych złym testowaniem
Start sondy kosmicznej Mariner-1 (1962)
Przeczytaj w InternecieStart sondy kosmicznej Mariner-1 (1962)
Przeczytaj w InternecieMaszyna do radioterapii Therac-25 (1985-1987)
Przeczytaj w InternecieZestrzelenie Airbusa 290 (1988)
Przeczytaj w InternecieAwaria sieci AT T (1990)
Przeczytaj w InternecieBłąd systemu obrony przeciwrakietowej Patriot (1992)
Przeczytaj w InternecieAwaria rakiety Ariane-5 (1996)
Przeczytaj w InternecieBłąd konwersji w sondzie Mars Climate Orbiter (1999)
Przeczytaj w InternecieAwaria systemu PEKA (2014)
Przeczytaj w Internecie2. Podstawowe pojęcia testowania
Błąd (error)
Błąd to objaw nieoczekiwanego działania programu ujawniony podczas testów.Defekt (fault)
Defekt to niedoskonałość w kodzie programu.Błąd ujawniony w czasie testów świadczy o defekcie w testowanym kodzie.
Testowanie
Testowanie to proces, który ma na celu wykazanie istnienia defektów w kodzie programu poprzez wywołanie błędów w działaniu.Usuwanie defektów
Usuwanie defektów to proces lokalizacji i poprawiania defektów.Procesy testowania i usuwania defektów często przeplatają się w pętlach iteracyjnych:
- Wywołaj błąd (testowanie)
- Zlokalizuj defekt (usuwanie defektów)
- Zaprojektuj naprawę defektu (usuwanie defektów)
- Napraw defekt (usuwanie defektów)
- Wróć do 1.
Testy bialej skrzynki
Testy białej skrzynki zakładają wgląd w wewnętrzną strukturę (kod) programu – na tej podstawie tworzone są przypadki testowe.Testy czarnej skrzynki
W testach czarnej skrzynki program traktowany jest jak czarna skrzynka, której zawartość pozostaje nieznana;- Przypadki testowe tworzone są bez znajomości kodu.
- Celem testowania jest wykrycie sytuacji, w których dane wejściowe przekształcane są na wyniki niezgodnie z oczekiwaniami.
Zasady testowania
- Programiści nie testują swoich programów (poza tworzeniem testów jednostkowych).
- Firma nie testuje swoich produktów (a dokładniej: niezbędne jest testowanie zewnętrzne)
- Przypadki testowe muszą być zapisane. Nie należy tworzyć przypadków ulotnych.
- Testowanie jest czynnością kreatywną.
3. Przypadki testowe
Przypadek testowy
Przypadek testowy to eksperyment przeprowadzany w testowaniu, który można opisać w kategoriach:- wartości wprowadzanych danych,
- akcji wykonywanej przez użytkownika
- oczekiwanych wyników.
Przypadki testowe służą do ograniczenia przestrzeni sytuacji, które należy sprawdzić, aby wywołać błąd programu.
Jak tworzyć przypadki testowe?
- Analiza klas równoważności:
- Klasa równoważności – wszystkie możliwe wartości danych wejściowych przetwarzanych w ten sam sposób.
- Jeden przypadek testowy reprezentuje jedną klasę równoważności.
Przykład: Testowany komponent systemu operuje na parze danych, z których pierwszy element oznacza godzinę, a drugi minutę. Ile można wyróżnić klas równoważności?
![Klasy równoważności przypadków testowych](/kowalski/aitech-ppb-pbr/media/commit/72bb976a8ef30ffa5afcc171b0b46ceb2b9783b0/materia%C5%82y%20na%20PPB%20%28wyk%C5%82ad%29/obrazy/klasy%20r%C3%B3wnowa%C5%BCno%C5%9Bci.png)
- Analiza wartości brzegowych
- Metoda zakłada, że błędy mogą być spowodowane nieprzewidzianym zachowaniem programu w okolicach wartości brzegowych.
- Jeden przypadek testowy odpowiada jednej wartości brzegowej.
Przykład: Testowany komponent systemu operuje na parze danych, z których pierwszy element oznacza godzinę, a drugi minutę. Ile można wyróżnić przypadków testowych metodą analizy wartości brzegowych?
![Analiza wartości brzegowych](/kowalski/aitech-ppb-pbr/media/commit/72bb976a8ef30ffa5afcc171b0b46ceb2b9783b0/materia%C5%82y%20na%20PPB%20%28wyk%C5%82ad%29/obrazy/warto%C5%9Bci%20brzegowe.png)
Jak opisywać przypadki testowe?
W metodzie białej skrzynki – za pomocą testów jednostkowych, stosując metodę analizy wartości brzegowych lub klas równoważności
W metodzie czarnej skrzynki – w postaci:
- Prostej instrukcji do testera
- Scenariusza przypadku testowego
_Przykład opisu przypadków testowych z prostą instrukcją:*
_Przykład opisu przypadku testowego ze scenariuszem:*
4. Poziomy testowania
Znalezienie defektu jest tym trudniejsze, im dłuższa droga dzieli miejsce defektu od miejsca ujawnienia błędu.
Każdemu etapowi wytwarzania oprogramowania odpowiada określony poziom testowania.
![Poziomy testowania](/kowalski/aitech-ppb-pbr/media/commit/72bb976a8ef30ffa5afcc171b0b46ceb2b9783b0/materia%C5%82y%20na%20PPB%20%28wyk%C5%82ad%29/obrazy/poziomy%20testowania.gif)
- Zarządzanie poziomami testowania ma na celu skrócenie drogi od spowodowania defektu do wykrycia błędu.
Poziomy testowania w Scrumie
W programowaniu tradycyjnym testowanie odbywa się sekwencyjnie.
W Scrumie testowanie na wszystkich poziomach odbywa się równolegle (codziennie lub co przyrost).
Wnioski:
- 1: Każdy zespół powinien zawierać osobę, która zajmuje się testowaniem „na pełen etat”.
- 2: W każdym sprincie powinno odbyć się testowanie na każdym poziomie.
- 3: W każdym kolejnym sprincie pojawiają się nowe przypadki testowe, ale wszystkie „stare” pozostają.
5. Testowanie jednostkowe
Zasady testowania jednostkowego
- Przedmiotem testowania są podstawowe jednostki programu.
- Testy jednostkowe tworzone są przez dewelopera - programistę.
- W testowaniu jednostkowym (jak i w całym procesie Scrum) polecana strategia to Test First.
- Test jednostkowy powinien testować jednostkę w izolacji.
5.1. Przedmiotem testowania są podstawowe jednostki programu
- Every method needs to be tested.”
- W praktyce testowane są tylko metody publiczne…
- …Co oznacza, że testy metod publicznych muszą być tak dokładne, by testowały WSZYSTKIE wywoływane przez nie metody prywatne…
- …Co również oznacza, że defekty w metodach prywatnych ujawnione zostaną dopiero w testach dla metod publicznych.
- W praktyce testowane są tylko metody publiczne…
- „Keep test logic out of production code”
- Nie wprowadzaj testów jednostkowych do kodu produkcyjnego.
5.2. Testy jednostkowe tworzone są przez programistę
![Testy jednostkowe](/kowalski/aitech-ppb-pbr/media/commit/72bb976a8ef30ffa5afcc171b0b46ceb2b9783b0/materia%C5%82y%20na%20PPB%20%28wyk%C5%82ad%29/obrazy/testy%20jednostkowe.png)
5.3. W testowaniu jednostkowym (jak i w całym procesie Scrum) polecana strategia to Test First
Zasady strategii Test First
- Zanim napiszesz linijkę kodu, napisz test automatyczny, który się nie powodzi.
- Pisz kod tak długo, aż powiodą się wszystkie testy.
Zalety strategii TestFirst
- Testowanie zastępuje metodę prób i błędów.
- Realizacja przypadków testowych jest obiektywną miarą postępów w pracy.
- Przypadki testowe zastępują formalną specyfikację.
- „Test first” wprowadza porządek w interfejsach między klasami.
- „Test first” świetnie wpisuje się w Scrum.
5.4. Test jednostkowy powinien testować wyłącznie jednostkę (w izolacji)
Każdy obiekt testowany jest indywidualnie…
- …Ale działanie obiektu może zależeć od innych komponentów…
- …Które mogą być niezaimplementowane w czasie testowania.
- Takie komponenty zastępuje się zamiennikami (ang. placeholder).
- …Ale działanie obiektu może zależeć od innych komponentów…
Typy zamienników:
- Stub (zalążek) - imituje obiekt zewnętrzny, który przekazuje dane do testowanego obiektu).
- Spy (szpieg) - zapamiętuje historię danych przekazywanych przez testowany obiekt).
- Mock (atrapa) - "inteligentnie" imituje obiekt zewnętrzny, który reaguje na dane przekazywane z testowanego obiektu.
- Fake (podróbka) - mocno uproszczona atrapa obiektu zewnętrznego, która nie ma wpływu na wynik testowania.
- Dummy (manekin) - pusty obiekt.
Blog na temat zamienników: Przeczytaj o zamiennikach
*Przykład stuba (zalążka)**:
(rysunek na podstawie: wikipedia")
6. Testowanie integracyjne w Scrumie
- Celem testowania integracyjnego jest sprawdzenie, czy niezależne komponenty (np. klasy) prawidłowo ze sobą współpracują.
- Testowanie wykonują deweloperzy (na swojej maszynie) lub zespół testujący (w repozytorium).
- Metody testowania integracyjnego:
- Metoda wielkiego wybuchu
- Metoda stopniowej integracji i testowania
- W metodyce Scrum możliwe jest stosowanie obu metod:
- Metoda wielkiego wybuchu na zakończenie sprintu lub
- Metoda Ciągłej Integracji (testowanie po każdej zmianie)
- Systemy Ciągłej Integracji ułatwiają testowanie po każdej zmianie poprzez uruchamianie testów automatycznych.
Podsumowanie
- Niewykryte defekty w kodzie programu mogą doprowadzić do poważnej awarii lub katastrofy.
- Testowanie jest czynnością kreatywną, której celem jest wykazanie istnienia defektów w kodzie.
- Przypadki testowe mają na celu ograniczenie przestrzeni wyszukiwania defektów.
- Testowanie odbywa się na różnych poziomach – w tradycyjnych systemach jest to proces sekwencyjny, a w Scrumie – iteracyjny.