Testowanie oprogramowania

Marcin Ugarenko

Dawid Szołucha

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

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

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

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ółoweprojektowanie

Testowaniemodułów

Implementacja

TestowanieWedług techniki

wykonywania

Testy dynamiczne

Polegają na wykonywaniu programui porównywaniu uzyskanych wyników z

Wynikami poprawnymi.

Pozwalają wykryć wyłącznie błędyWykonania. Poznanie przyczyny

Wymaga testów statycznych.

Testy statyczne

Polegają na analizie kodu programu.Zazwyczaj wykonywane przez

programistę lub przy użyciu odpowiednich narzędzi.

TestowanieZorientowane 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 implementacjifunkcjonalności.

- Dane dobrane na podstawie analizy strukturyprogramu.

- Przetestowanie wszystkich ścieżek- Nie pozwala znaleźć brakującej funkcjonalności.

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

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.

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.

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)

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.

Bibliografia

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