Testowanie systemów informatycznych
Podstawowe pojęcia
Błąd (error)
Defekt (fault)
Błąd to objaw nieoczekiwanego działania programu ujawniony podczas testu
Defekt to niedoskonałość w kodzie programu
Czym jest testowanie?
Testowanie to proces, który ma na celu wykazanie istnienia defektów w kodzie programu poprzez wywołanie błędów w działaniu
Usuwanie defektów
- Wywołaj błąd (testowanie)
- Zlokalizuj defekt (usuwanie defektów)
- Zaprojektuj naprawę defektu (usuwanie defektu)
- Napraw defekt (usuwanie defektów)
- Wróć do 1.
Przypadek testowy
To eksperyment, który można opisać w kategoriach wartości wprowadzanych danych, akcji wykonywanej przez użytkownika i oczekiwanych wyników
Do czego służą przypadki testowe?
Przypadki testowe służą do ograniczenia przestrzeni sytuacji, które należy sprawdzić, aby wywołać błąd programu
Test białej skrzynki
Zakłada wgląd w wewnętrzną strukturę (kod) programu - na tej podstawie tworzone są przypadki testowe
Test czarnej skrzynki
Celem testowania jest wykrycie sytuacji, w których dane wejściowe przekształcane są na wyniki niezgodnie z oczekiwaniami
Zasady testowania programu
- Programiści nie testują swoich programów (konstrukcja a destrukcja)
- Firma nie testuje swoich programów
- Przypadki testowe muszą być zapisane. Nie należy tworzyć przypadków ulotnych
- Testowanie jest czynnością kreatywną
Poziomy testowania
Wywołanie błędu a znalezienie defektu
Znalezienie defektu jest tym trudniejsze, im dłuższa droga dzieli miejsce defektu od miejsca ujawnienia błędu
Poziomy testowania
Testowanie modułów (testowanie jednostkowe)
Przedmiotem testowania są podstawowe jednostki programu
Testy jednostkowe tworzone są najczęściej przez dewelopera programistę
Stosowane są tzw. „mocki” (jednostki niepodlegające testom zastąpione są stałym wyjściem)
Testy jednostkowe mogą zostać zautomatyzowane
Testowanie integracyjne
Przedmiotem testowania integracyjnego są mechanizmy współpracy poszczególnych komponentów systemu
Plan testowania integracyjnego powinien powstawać w czasie opracowywania architektury programu
Testowanie wykonują deweloperzy lub zespół testujący
podprogramy, metody, klasy, skrypty SQL
pojedyncze kontrolery w aplikacjach webowych
„endpointy” w web service’ach
widoki w aplikacjach klienckich
Metody testowania integracyjnego
Metoda wielkiego wybuchu
Metoda stopniowej integracji i testowania
Testowanie systemowe
Przedmiotem testowania jest całość oprogramowania zainstalowana w pewnym środowisku wykonawczym
Środowisko testowania musi być zbliżone do środowiska pracy
Testowanie systemowe to metoda „czarnej skrzynki”
Testowanie akceptacyjne
Przedmiotem jest oprogramowanie stanowiące przedmiot dostawy do użytkownika w docelowym środowisku pracy
Testowana jest zgodność z wymaganiami i potrzebami użytkownika
Testowanie akceptacyjne przeprowadza użytkownik
W przypadku systemów ogólnodostępnych testy akceptacyjne można podzielić
Testy alfa (w siedzibie wytwórcy)
Testy beta (u wytypowanych odbiorców lub dystrybutorów)
Test połówkowy
Plan testów
Czym jest plan testów?
Plan testów to dokument opisujący organizację procesu planowania
Plan testów składa się z następujących elementów
- Zakres testów
- Strategia testowania
- Niezbędne zasoby
- Specyfikacja testów
Zakres testów
Identyfikacja testowanego produktu (co testujemy?)
Określenie wymagań (właściwości), które testujemy
Określenie wymagań (właściwości), których nie testujemy
Strategia testowania
Wskazanie typu testowania (np. testowanie wydajności, testowanie funkcjonalności)
Zdefiniowanie metod oceny testu
Określenie postaci raportu z testów
Określenie kryteriów pozytywnego zakończenia testów
Zasoby testowe
Środowisko testowe
Zespół wykonawców
Warunki początkowe
np. wykonane prace instalacyjne lub konfiguracyjne
stopień ukończenia prac implementacyjnych
Specyfikacja testów
Specyfikacja testów to lista przypadków testowych
Przypadek testowy może być opisany za pomocą
Prostej instrukcji do testera
Scenariusza przypadku testowego
Analiza klas równoważności
Analiza wartości brzegowych
Typy testowania
Testowanie funkcjonalne
Jest to próba wykazania rozbieżności między programem a jego specyfikacją zapisaną w postaci wymagań funkcjonalnych lub przypadków użycia
Testowanie wydajności
Zadaniem jest wykazanie, że system nie daje odpowiedzi w wystarczająco krótkim czasie
Testowanie przeciążeń
Przeciążenie to skumulowanie w krótkim okresie czasu dużej ilości danych lub czynności do wykonania
Testowanie ochrony danych (bezpieczeństwa)
Proces ma wykazać, że dane nie są chronione w odpowiedni sposób
Testowanie pamięci
Celem jest wykazanie, że system narusza narzucone wymagania pamięciowe
Testowanie konfiguracji (zgodności)
Testowanie pracy w różnych konfiguracjach sprzętowych i programowych
Testowanie zgodności wersji
Chodzi o zgodność z przeszłymi i przyszłymi wersjami programu
Testowanie zgodności z dokumentacją użytkownika
Jest to próba wykrycia rozbieżności między programem a jego specyfikacją zapisaną w dokumentacji użytkownika
Testowanie procedury instalacyjnej
Testowanie odporności
Zadaniem testowania jest postawienie pod znakiem zapytania odporności systemu na awarie
Test końcowy
Testowanie automatyczne
Co to jest testowanie automatyczne?
Automatyzacja testowania polega na zastąpienia testera oprogramowaniem, które:
Steruje testem
Porównuje wyniki z oczekiwaniami
Raportuje błędy
Code-driven testing
Testowane są publiczne interfejsy do klas (modułów, bibliotek) poprzez podanie różnorakich danych wejściowych i walidacji wyników
Graphical user interface testing
Generowane są zdarzenia interfejsu takie jak: kliknięcia myszką czy naciśnięcie klawiszy i obserwowane są zmiany w interfejsie użytkownika
Testowanie za pomocą makr
nagrywamy makro realizujące ciąg zdarzeń (kliknięć, klawiszy itp.)
przygotowujemy zestaw plików graficznych, które obrazują kolejne oczekiwane wyglądy interfejsu
podczas testowania każdorazowo porównujemy obrazy interfejsu z obrazami oczekiwanymi
Zalety testowania za pomocą makr
Może być stosowane do każdego oprogramowania z graficznym interfejsem użytkownika
Nie wymaga żadnego specjalistycznego oprogramowania do testów
Znakomicie wkomponowuje się w paradygmat „continous integration”
Wady testowania za pomocą makr
Przygotowanie przypadków testowych jest czasochłonne
Każda najmniejsza zmiana interfejsu powoduje konieczność opracowania nowego zestawu testowego
Podczas nagrywania makr często popełnia się drobne błędy
Podczas nagrywania wykonuje się często operacje nieistotne z punktu widzenia testowania