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

  1. Wywołaj błąd (testowanie)
  1. Zlokalizuj defekt (usuwanie defektów)
  1. Zaprojektuj naprawę defektu (usuwanie defektu)
  1. Napraw defekt (usuwanie defektów)
  1. 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

  1. Programiści nie testują swoich programów (konstrukcja a destrukcja)
  1. Firma nie testuje swoich programów
  1. Przypadki testowe muszą być zapisane. Nie należy tworzyć przypadków ulotnych
  1. 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

  1. Zakres testów
  1. Strategia testowania
  1. Niezbędne zasoby
  1. 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