4.3. Białoskrzynkowe techniki testowania Flashcards
Jakie dwie techniki białoskrzynkowe związane z kodem obejmuje sylabus poziomu podstawowego?
Sylabus podstawowy uwzględnia testowanie instrukcji (statement testing) oraz testowanie gałęzi (branch testing).
Zdefiniuj testowanie instrukcji (statement testing).
- Jednostkami pokrycia (coverage items) są instrukcje wykonywalne w kodzie.
- Celem jest tak zaprojektować przypadki testowe, aby przynajmniej raz wykonać każdą instrukcję.
- Poziom pokrycia mierzy się jako stosunek liczby wykonanych instrukcji do liczby wszystkich instrukcji wykonywalnych w badanym kodzie.
Czy osiągnięcie 100% pokrycia instrukcji oznacza wykrycie wszystkich defektów?
- Jeśli każda instrukcja zawierająca defekt zostanie wykonana, istnieje szansa na wywołanie awarii (failure) i ujawnienie defektu.
- Jednakże samo uruchomienie instrukcji z błędem nie zawsze powoduje awarię (np. defekt może ujawniać się tylko w specyficznym kontekście lub danych).
- Ponadto testowanie instrukcji nie gwarantuje, że sprawdzono całą logikę decyzyjną kodu — może więc pominąć pewne ścieżki (i ukryte defekty).
Czym jest gałąź (branch) w kontekście testowania kodu?
- Gałąź to przeniesienie sterowania między dwoma węzłami w grafie przepływu sterowania (control flow graph).
- Przykładem jest przejście z instrukcji warunkowej (np. if/else) albo wywołanie innego fragmentu kodu w sposób bezwzględny (unconditional).
- Każda gałąź może być bezwarunkowa (kod w linii prostej) lub warunkowa (np. wynik decyzji w if, case, pętla itp.).
Opisz testowanie gałęzi i pokrycie gałęzi.
- W testowaniu gałęzi (branch testing) elementami pokrycia są gałęzie w kodzie.
- Celem jest zaprojektowanie przypadków testowych, które wykonają (exercise) wszystkie zdefiniowane gałęzie do akceptowalnego poziomu pokrycia.
- Poziom pokrycia gałęzi (branch coverage) wyraża się jako (liczba wykonanych gałęzi) / (liczba wszystkich gałęzi w kodzie).
Czy osiągnięcie 100% pokrycia gałęzi umożliwia wykrycie wszystkich defektów?
- Nie. Uruchomienie danej gałęzi w teście nie zawsze prowadzi do awarii.
- Niektóre błędy mogą ujawniać się tylko przy pełnej sekwencji przejść lub przy konkretnych danych (np. brak pokrycia wszystkich kombinacji logicznych).
- Dlatego nawet 100% pokrycia gałęzi nie gwarantuje wykrycia wszystkich defektów.
Opisz możliwe wyniki testowania gałęzi warunkowych.
W przypadku gałęzi warunkowych (np. if/then, switch/case, pętla) mamy zwykle dwa wyniki:
* true / false w (if/else),
* poszczególne warianty w (switch/case),
* kontynuacja pętli (kolejna iteracja) lub wyjście z niej.
Każdy z tych wariantów może stanowić osobną gałąź do pokrycia w testach.
Czy pokrycie gałęzi jest „silniejsze” od pokrycia instrukcji?
- Pokrycie gałęzi w pewnym sensie zawiera pokrycie instrukcji.
- Jeśli mamy 100% branch coverage, to automatycznie osiągamy też 100% statement coverage (bo wykonujemy wszystkie instrukcje na wszystkich ścieżkach).
- Jednak 100% statement coverage nie gwarantuje 100% pokrycia gałęzi, bo możemy wykonać wszystkie instrukcje, ale pominąć jedną z gałęzi warunkowych.
Jakie są największe zalety i wady testowania białoskrzynkowego?
- Zaleta: pełny dostęp do implementacji oprogramowania, co ułatwia wykrywanie defektów nawet przy niekompletnej specyfikacji lub w sytuacji, gdy brakuje wymagań.
- Wada: skoro skupiamy się na kodzie, możemy nie zauważyć brakujących wymagań lub funkcjonalności (niewidocznych w kodzie). Testowanie białoskrzynkowe nie zastąpi weryfikacji, czy system robi to, czego oczekuje użytkownik.
Czy testowanie białoskrzynkowe jest przydatne w testach statycznych?
- Tak, analizę białoskrzynkową można stosować przy przeglądach kodu lub logiki (np. pseudokodu) przed uruchomieniem.
- Można też wykorzystać graf przepływu sterowania do wykrywania nieużywanych gałęzi, niespójnych instrukcji itp. w fazie przeglądu (ang. review).
Czy samo testowanie czarnoskrzynkowe mierzy pokrycie kodu?
- Nie. Tylko techniki białoskrzynkowe pozwalają w obiektywny sposób określić, ile instrukcji (statements) lub gałęzi zostało faktycznie uruchomionych.
- Testy czarnoskrzynkowe nie dają informacji o stopniu pokrycia kodu; mogą jedynie weryfikować działanie funkcjonalne wg wymagań.
- W praktyce często łączy się obie perspektywy (czarnoskrzynkową i białoskrzynkową), aby zwiększyć pokrycie i pewność jakości kodu.
