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