Testowanie oprogramowania

1. Testowanie oprogramowania Marcin Ugarenko Dawid Szołucha

2. Podstawowe definicje • Testowanie – faza cyklu życia oprogramowania mająca na celu podniesienie jego niezawodności. Polega na wykrywaniu błędów w oprogramowaniu. Cele testowania: wykrycie błędu, zlokalizowanie błędu, usunięcie błędu, ocena niezawodności oprogramowania. • Weryfikacja – testowanie zgodności systemu lub komponentu z wymaganiami zdefiniowanymi w fazie określenia wymagań . • Atestowanie – weryfikacja końcowa systemu lub komponentu, inaczej zatwierdzenie. • Błąd – niepoprawna konstrukcja w programie mogąca prowadzić do niewłaściwego jego działania . • Błędne wykonanie – niepoprawne działanie systemu podczas jego pracy

3. Weryfikacja: metody • Przeglądy oprogramowania Spotkania podczas, których system jest prezentowany dla personelu, kierownictwa, użytkowników, klientów i innych zainteresowanych osób. Przeglądy mogą być formalne lub nieformalne. • Przeglądy techniczne Ocena zgodności postępu prac z przyjętym planem. • Przejścia Wczesna ocena dokumentów, modeli i kodu, celem rozważenia możliwych rozwiązań. • Audyty Ocena jakości oprogramowania, jego zgodności z założeniami, standardami, kontraktami oraz licencjami. • Inspekcje Ocena wymagań przez osoby nie będące ich autorami. • Testowanie

4. Co podlega testowaniu? • Wydajność • Interfejs • Własności operacyjne systemu • Użycie zasobów • Zabezpieczenia systemu • Przenaszalność oprogramowania • Niezawodność • Odtwarzalność • Bezpieczeństwo • Modyfikowalność • Obciążalność • Skalowalność sytemu • Kompletność wymagań • Akceptowalność • Jakość dokumentacji

5. Fazy testowania • Każdemu etapowi wytwarzania oprogramowania towarzyszy odpowiednia faza testowania. Zdefiniowanie wymagań użytkownika Testowanie akceptacyjne Definicja wymagań oprogramowania Testowanie całości systemu Projektowanie architektury Testowanie integracji Szczegółowe projektowanie Testowanie modułów Implementacja

6. Testowanie Według techniki wykonywania Testy dynamiczne Polegają na wykonywaniu programu i porównywaniu uzyskanych wyników z Wynikami poprawnymi. Pozwalają wykryć wyłącznie błędy Wykonania. Poznanie przyczyny Wymaga testów statycznych. Testy statyczne Polegają na analizie kodu programu. Zazwyczaj wykonywane przez programistę lub przy użyciu odpowiednich narzędzi.

7. Testowanie Zorientowane na wykrywanie błędów • Testy funkcjonalne „czarnej skrzynki” • Zakładają znajomość jedynie wymagań. • Tester niezaangażowany w tworzenie. • systemu. Najlepiej użytkownik. • - Podział na klasy równoważności danych. • Testy strukturalne „białej skrzynki” • Zakładają znajomości implementacji • funkcjonalności. • Dane dobrane na podstawie analizy struktury • programu. • Przetestowanie wszystkich ścieżek • Nie pozwala znaleźć brakującej funkcjonalności.

8. Testowanie statystyczne • Wykonywane w sposób cykliczny • Losowa konstrukcja danych wejściowych zgodnych z prawdopodobieństwem ich wystąpienia • Określenie poprawnych wyników dla danych losowych • Porównanie wyników oczekiwanych z otrzymanymi • Wady: • Trudne ustalenie danych losowych możliwie bliskich rozkładowi rzeczywistemu • Wnioski mogą być nietrafne • Zalety: • Możliwość automatyzacji procesu testowania • Możliwość wykonania dużej liczby testów

9. Testowanie systemu • Testowanie wstępujące: • Rozpoczęcie testowania od pojedynczych modułów, podsystemów, aż do całości. • Zastosowanie nie zawsze możliwe np. występują zależności między modułami. • Testowanie zstępujące: • Zaczynamy testowanie od modułów znajdujących się najwyżej w hierarchii. • Niższe moduły zastępuje się modelami szkieletowymi. • Po przetestowaniu modułów wyższego poziomu dołącza się moduły niższego poziomu. • Proces trawa aż do zintegrowania i przetestowania całego systemu.

10. Testy obciążenia i odporności • Testy obciążenia • Celem jest zbadanie obciążalności, wydajności i niezawodności systemu. • Przeprowadzane w warunkach maksymalnego lub nadmiernego obciążenia systemu. • Systemy wielodostępne i sieciowe. • Spełnienie wymagań niefunkcjonalnych dotyczących wydajności, liczby użytkowników itp. • Testy odporności • Celem jest zbadanie zachowań systemu w przypadku niepożądanych zdarzeń. • Awarie sprzętu, prądu, niepoprawne dane, niepoprawne polecenia.

11. Niezawodność oprogramowania • Szacowanie niezawodności: • Poziom niezawodności może być określony w wymaganiach klienta. • Informacja o niezawodności pozwala ustalić późniejsze koszty konserwacji systemu. • Umożliwia ocenę i polepszenie procesu wytwarzania, a co za tym idzie minimalizację kosztów. • Miary i metryki: • Prawdopodobieństwo błędnego wykonania. • Częstość występowania błędnych wykonań. • Ilość błędów w jednostce czasu np.. 0,2/h. • Średni czas między błędnymi wykonaniami. • Dostępność. • Stosunek czasu, w którym system jest dostępny, do czasu jaki jest potrzebny na usunięcie awarii. • Dostępność pozwala zmierzyć poza ilością błędów, także ich narzut • Niezawodność=niezawodność_początkowa*e(-C * liczba_testów)

12. Wnioski • Nie wykonywanie testów prowadzi do propagacji błędów i narastania kosztów i usuwania. • Nie wszystkie błędy udaje się znaleźć i naprawić. • Poprawiony model, kod, projekt, wymagania. • Raporty z testów i ich rezultatów. • Ograniczenie kosztów konserwacji. • Zwiększenie niezawodności oprogramowania i zadowolenia klienta. • Lepiej posiadać nie w pełni działającą funkcjonalność niż nie posiadać jej w ogóle.

13. Bibliografia • „Podstawy inżynierii oprogramowania” – Włodzimierz Dąbrowski i Kazimierz Subieta.