Średni · lekcja 6

Testy niefunkcjonalne — użyteczność, wydajność, obciążenie, bezpieczeństwo

Aplikacja może przechodzić WSZYSTKIE testy jednostkowe i funkcjonalne, a mimo to być fatalna w użyciu — bo działa wolno, pada pod większym obciążeniem, jest niewygodna dla użytkownika albo ma dziury bezpieczeństwa. Testy niefunkcjonalne sprawdzają WŁAŚNIE te c...

Zacznij tutaj

Po co się tego uczymy?

Aplikacja może przechodzić WSZYSTKIE testy jednostkowe i funkcjonalne, a mimo to być fatalna w użyciu — bo działa wolno, pada pod większym obciążeniem, jest niewygodna dla użytkownika albo ma dziury bezpieczeństwa. Testy niefunkcjonalne sprawdzają WŁAŚNIE te cechy — wymagane wprost w INF.04.8.3 i równie ważne jak poprawność samej logiki.

Wprowadzenie

Teoria

Czym różnią się testy niefunkcjonalne od funkcjonalnych? Test funkcjonalny odpowiada na pytanie "CZY dana funkcja działa" (np. czy da się złożyć zamówienie). Test niefunkcjonalny odpowiada na pytanie "JAK DOBRZE" ta funkcja działa pod różnymi względami — nawet jeśli wynik jest poprawny, może być np. zbyt wolny albo niewygodny.

Testy użyteczności (usability) — sprawdzają, czy interfejs jest ZROZUMIAŁY i WYGODNY dla użytkownika: czy przyciski są czytelnie opisane, czy komunikaty o błędach są pomocne, czy da się wykonać typowe zadanie bez instrukcji obsługi. Zwykle wykonywane przez OBSERWACJĘ prawdziwych użytkowników próbujących wykonać zadanie, nie automatycznie.

Testy wydajności (performance) — mierzą CZAS odpowiedzi systemu w typowych warunkach: jak szybko ładuje się strona, jak szybko backend odpowiada na zapytanie API, ile trwa wygenerowanie raportu. Wynik wyrażany jest konkretną liczbą (np. "odpowiedź API poniżej 200 ms"), którą można obiektywnie zmierzyć i porównać z wymaganiem.

Testy obciążeniowe (load testing) — sprawdzają zachowanie systemu pod DUŻYM obciążeniem: co się stanie, gdy 1000 użytkowników jednocześnie złoży zamówienie? Czy serwer nadal odpowiada, czy zaczyna zwracać błędy, czy czas odpowiedzi drastycznie rośnie? Do symulacji dużego ruchu używa się narzędzi generujących sztuczne obciążenie (np. Apache JMeter, k6) — jeden komputer testowy symuluje setki/tysiące "wirtualnych użytkowników" naraz.

Testy zgodności (compatibility) — sprawdzają, czy aplikacja działa poprawnie w RÓŻNYCH środowiskach: różne przeglądarki (Chrome, Firefox, Edge), różne rozdzielczości ekranu, różne wersje systemu operacyjnego, różne urządzenia (desktop/tablet/telefon). Istotne zwłaszcza dla aplikacji webowych (dział Aplikacje webowe) i mobilnych (dział MAUI, lekcja o dostosowaniu do platformy).

Testy bezpieczeństwa (security) — sprawdzają odporność aplikacji na typowe ataki: SQL injection (poznane w dziale PHP/Bazy danych), nieautoryzowany dostęp do danych innych użytkowników, przesyłanie haseł jawnym tekstem, podatność na przechwycenie sesji. Podstawowa zasada: NIGDY nie ufaj danym przychodzącym od użytkownika bez walidacji, zarówno po stronie klienta, jak i (koniecznie) po stronie serwera.

Dlaczego "niefunkcjonalne" nie znaczy "mniej ważne" — sklep internetowy, który poprawnie oblicza sumę koszyka (funkcjonalność OK), ale ładuje się 15 sekund albo pada przy Black Friday, straci klientów mimo technicznie bezbłędnej logiki. W praktyce zawodowej testy niefunkcjonalne bywają decydujące dla sukcesu projektu.

Zobacz zależności

Schemat

TESTY NIEFUNKCJONALNE — pięć głównych kategorii

┌─────────────┬──────────────────┬───────────────────────────┐
│ Kategoria   │ Pytanie           │ Przykładowe narzędzie      │
├─────────────┼──────────────────┼───────────────────────────┤
│ Użyteczność │ Czy jest wygodne? │ obserwacja użytkowników    │
│ Wydajność   │ Jak szybko?       │ pomiar czasu odpowiedzi    │
│ Obciążenie  │ Co przy 1000 os.? │ JMeter, k6 (symulacja ruchu)│
│ Zgodność    │ Wszędzie działa?  │ testy na różnych przeglądarkach│
│ Bezpieczeństwo│ Czy odporne na atak?│ próby SQL injection, audyt│
└─────────────┴──────────────────┴───────────────────────────┘

Połącz z praktyką

Przykład z życia

Sklepy internetowe w Czarny Piątek (Black Friday) regularnie "padają" pod nawałem klientów — to klasyczny przykład zaniedbanego testu OBCIĄŻENIOWEGO: aplikacja działała bez zarzutu przy normalnym ruchu, ale nie sprawdzono, co się stanie przy dziesięciokrotnie większej liczbie jednoczesnych użytkowników. Podobnie strony rządowe udostępniające ważny formularz (np. zapisy na szczepienia) często padały w pierwszych minutach po starcie z powodu braku testów obciążeniowych na realistyczną skalę.