jassem/SysInf

Fork 0

jassem cc678ba092 aktualizacja materiałów na wykład 8 i laboratorium 8

2023-11-22 19:52:04 +01:00

17 KiB

Raw Blame History

Systemy informatyczne analizy danych

8. Testowanie w programowaniu zwinnym[wykład]

Krzysztof Jassem (2023)

1. Przykłady katastrof spowodowanych złym testowaniem

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

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?

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.

(źródło: https://edux.pjwstk.edu.pl/mat/200/lec/wyklady/11_3.html)

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.
„Keep test logic out of production code”
- Nie wprowadzaj testów jednostkowych do kodu produkcyjnego.

5.2. Testy jednostkowe tworzone są przez programistę

(rysunek na podstawie: Tilo Linz, "Testing in Scrum")

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

7. Metoda ciągłej ewaluacji

Opracuj zbiór testowy

Wydziel zbiór testowy ze zbioru treningowego ALBO
Opracuj zbiór testowy z wykorzystaniem ludzi

Określ metrykę ewaluacji.
Opracuj wyzwanie w systemie ciągłej ewaluacji (np. Gonito).
Opracuj łatwe rozwiązanie bazowe.
Zmierz jakość rozwiązania bazowego na zbiorze testowym.
Iteracyjnie:

Opracuj nowe rozwiązanie;
Zmierz jego jakość na zbiorze testowym;
Jeśli jest lepsze od poprzednich, to wdrażaj go w systemie.

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.
Metoda ciągłej ewalaucji dobrze harmonizuje z metodyką Scrum.

17 KiB Raw Blame History Unescape Escape