Testowanie oprogramowania

Transkrypt

Testowanie oprogramowania
Testowanie oprogramowania
Wykład 03
dr inż. Grzegorz Michalski
20 października 2015
Testowanie oprogramowania 1/22
Warunki graniczne
Można założyć, że realizowany w oprogramowaniu algorytm oraz jego
implementacja są poprawne, a wszelkie błędy wynikają z ograniczeń
związanych z platformą sprzętową lub zastosowanym językiem
programowania.
W przypadku testowania warunków granicznych celem jest
zaprojektowanie przypadków testowych sprawdzających wartości
graniczne i unikatowe związane z architekturą komputera na której
będzie uruchamiany program, językiem programowania lub
zastosowanym algorytmem.
Testowanie oprogramowania 2/22
Wartości specjalne i transcendentne
Dla wszelkich operacji matematycznych można dobrać maksymalne i
minimalne wartości operandów, elementy jednostkowe i zerowe.
Dla tablic dobór takich wartości może uwzględniać pustą tablicę,
wartości wykraczające poza zakres tablicy (w kontekście indeksów)
oraz poprawnych wartości indeksów.
Dla złożonych struktur danych takich jak drzewa czy listy mogą to
być puste wskaźnikiem jednoelementowe obiekty, czy listy z tak
zwanym zerwanym wskaźnikiem.
Testowanie oprogramowania 3/22
Klasy równoważności
Metoda klas równoważności
Pozwala ona na znaczące ograniczenie, często ogromnego zbioru
zadań testowych do mniejszej, ściśle określonej klasy danych
testowych.
Klasa równoważności jest tutaj określana jako zbiór zadań testowych,
które sprawdzają aplikację lub jej fragment pod kątem tego samego
błędu.
Pojedyncza klasa równoważności zawiera przeważnie wiele zestawów
testowych, zgodnych lub niezgodnych z pewnymi warunkami
wejściowymi.
Testowanie oprogramowania 4/22
Testy jednostkowe
Test jednostkowy.
Fragment kody sprawdzający działanie pewnego niewielkiego, ale
dokładnie określonego obszaru funkcjonalności testowanego kodu.
Cel testów jednostkowych.
Głównym zadaniem testów jednostkowych jest udowodnienie, że badany
kod działa zgodnie z założeniami programisty.
Testowanie oprogramowania 5/22
Właściwości poprawnych testów jednostkowych.
automatyzacja
kompletność,
powtarzalność,
niezależność,
profesjonalizm.
Testowanie oprogramowania 6/22
Automatyzacja testów jednostkowych
Testy jednostkowe muszą być wykonywane w automatyczny sposób
bez konieczności angażowania testera.
Automatyzacja w kontekście testów jednostkowych dotyczy nie tylko
uruchamiana testów, ale również sprawdzania ich wyników.
Testy jednostkowe powinny być relatywnie proste, ponieważ są
wykonywane wielokrotnie.
Testowanie oprogramowania 7/22
Kompletność testów jednostkowych
Testy muszą testować wszystko co może zawieść w danym programie.
Możliwe jest testowanie każdego wiersza kodu każdego rozgałęzienia
sterowania. Alternatywą jest testowanie fragmentów narażonych na
błędy.
Wymagane stosowanie narzędzi umożliwiających przedstawienie jaka
część testowanego kodu jest tak naprawdę wykonywana.
Testowanie oprogramowania 8/22
Powtarzalność testów jednostkowych
Testy powinny być niezależne od siebie oraz od środowiska.
Wielokrotne wykonywanie testów, nawet w różnej kolejności powinno
zawsze dać te same wyniki.
Obiekty imitacji pozwalają na odseparowanie testowanej metody od
zmian zachodzących w środowisku.
Testowanie oprogramowania 9/22
Obiekty imitacji
Działanie kodu może być zależne od różnych czynników, niezależnych
od kodu oraz innych części systemu.
Testy muszą inicjować wiele komponentów systemu, co jest trudne w
sytuacji ciągle zmieniającego się systemu.
Powyższe problemu można rozwiązać stosując namiastki rzeczywistych
obiektów, tak zwane obiekty imitacji.
Testowanie oprogramowania 10/22
Obiekt imitacji
Kiedy je stosować?
Obiekt rzeczywisty zachowuje się niedeterministycznie – nie można
przewidzieć wyniku jego działania.
Obiekt rzeczywisty jest trudny do skonfigurowania.
Wywołanie istotnych z punktu widzenia testowania zachowań obiektu
rzeczywistego jest skomplikowane.
Działanie obiektu rzeczywistego jest powolne.
Obiekt rzeczywisty ma graficzny interfejs użytkownika lub jest jego
częścią.
Test musi uzyskać informacje o sposobie użycia rzeczywistego obiektu.
Obiekt rzeczywisty jeszcze nie istnieje.
Testowanie oprogramowania 11/22
Etapy testowania z zastosowaniem obiektów imitacji.
Opracowanie interfejsu do opisu obiektu
Implementacja interfejsu dla kodu produkcyjnego.
Implementacja interfejsu przez obiekt imitacji dla potrzeb testowania.
Testowanie oprogramowania 12/22
Niezależność testów jednostkowych
Testy powinny być ukierunkowane na testowaną w danym momencie
metodę i w miarę możliwości niezależne od środowiska i innych
testów.
Testy muszą testować jeden aspekt działającego kodu (sprawdzanie
działania pojedynczej metody, zestawu współpracujących metod –
dostarczających określoną funkcjonalność).
Przeprowadzenie testu nie może zależeć od wyniku innego testu.
Testowanie oprogramowania 13/22
Profesjonalizm testów jednostkowych
Kod testujący powinien spełniać te same wymagania co kod
produkcyjny.
Muszą być przestrzegane zasady poprawnego projektowania – np.
hermetyzacja, reguła DRY (Don’t Repeat Yourself)
Brak testów dla nieistotnych fragmentów (banalne metody
dostępowe).
Liczba wierszy kodu testującego porównywalna do liczby wierszy kodu
produkcyjnego.
Testowanie oprogramowania 14/22
Obszary testowania
Czy wyniki są poprawne?
Czy warunki brzegowe są określone poprawnie?
Czy można sprawdzić relacje zachodzące w odwrotnym kierunku?
Czy można uzyskać wyniki korzystając z alternatywnego sposobu?
Czy można wymusić warunki zachodzenia błędu?
Czy efektywność jest poprawna?
Testowanie oprogramowania 15/22
Poprawność wyników
Wyniki działania kodu znajdują się często w specyfikacji wymagań.
Można założyć własne wymagania odnośnie wyników metod – brak
dokładnej specyfikacji.
Weryfikacja założeń w współpracy z użytkownikami.
Dla zestawu testów wymagających dużej liczby danych wejściowych
używanie plików.
Testowanie oprogramowania 16/22
Warunki brzegowe
Typowe warunki brzegowe
Wprowadzenie błędnych lub niespójnych danych wejściowych:
nieprawidłowy format, nieodpowiednie wartości, dane przekraczające
znacznie oczekiwania.
Pojawienie się duplikatów na listach.
Wystąpienie list nieuporządkowanych.
Zakłócenie typowego porządku zdarzeń.
Testowanie oprogramowania 17/22
Poszukiwanie warunków brzegowych
Zgodność – z oczekiwanym formatem.
Uporządkowanie – poprawne uporządkowanie zbioru wartości.
Zakres – poprawny zakres danych wejściowych.
Odwołanie – do zewnętrznych obiektów znajdujących się poza
kontrolą kodu.
Istnienie – wartość istnieje.
Liczność – dokładnie tyle wartości ile jest oczekiwanych.
Czas – zdarzenia zachodzą w oczekiwanej kolejności.
Testowanie oprogramowania 18/22
Odwrócenie relacji
Działanie niektórych funkcji można przetestować stosując logikę
działania w odwrotnym kierunku: pierwiastkowanie – podnoszenie do
kwadratu.
Zalecana ostrożność – implementacje obu funkcji mogą zawierać
podobne błędy.
Testowanie oprogramowania 19/22
Kontrola wyników na wiele sposobów
Wyniki działania testowanych metod można sprawdzać na wiele
sposobów – zazwyczaj istnieje więcej niż jeden sposób wyznaczania
wartości.
Implementacja kodu produkcyjnego z wykorzystaniem
najefektywniejszego algorytmu, inne algorytmy można użyć do
sprawdzenia czy wersja produkcyjna daje te same wyniki.
Testowanie oprogramowania 20/22
Wymuszanie warunków powstawania błędów
Rzeczywisty system narażony jest na różnego rodzaju zewnętrzne
błędy – np. brak miejsca na dysku, awarie infrastruktury zewnętrznej
(sieci), problemy z rozdzielczością ekranu, przeciążenie systemu.
Przekazywanie niepoprawnych parametrów, symulacje zewnętrznych
błędów z wykorzystaniem obiektów imitacji.
Testowanie oprogramowania 21/22
Charakterystyka efektywnościowa
Sposób zmiany efektywności kodu w odpowiedzi na rosnącą liczbę
danych, rosnącą komplikację problemu.
Zmiany efektywności programu w zależności od wersji kodu.
Testy sprawdzające czy krzywa efektywności jest stabilna w różnych
wersjach algorytmu.
Testowanie oprogramowania 22/22