Typy testów: funkcjonalne, niefunkcjonalne, strukturalne i regresywne


Testowanie oprogramowania to bardzo rozległy obszar branży IT. Testować aplikacje możemy na wiele sposobów, a same testy mogą mieć różne cele. I to właśnie wspomniane cele testowania, definiują typy testów, jakimi możemy poddać oprogramowanie. Jeśli celem testów jest np. zmierzenie wydajności systemu, wówczas wykonamy testy niefunkcjonalne, w skład których wejdą np. testy, wydajnościowe, obciążeniowe, przeciążeniowe. W tym materiale postaram się przedstawić i omówić szczegółowo najważniejsze typy testów. A zatem ruszamy!

Testy funkcjonalne

Testowanie funkcjonalne systemu polega na wykonaniu testów, które umożliwiają dokonanie oceny
funkcji, jakie system ten powinien realizować.

Podstawą tego typu testów zwykle bywa dokumentacja pod postacią specyfikacji funkcjonalnej, w której to powinny znaleźć się informacje dotyczące funkcji, jakie system powinien realizować i spełniać. Oczywiście z wielu przyczyn taka specyfikacja często bywa niekompletna, nieaktualna bądź nieprecyzyjna (w skrajnych przypadkach może jej nie być w ogóle!). Oprócz specyfikacji funkcjonalnej wymagania funkcjonalne możemy znaleźć w takich dokumentach projektowych jak:
specyfikacja wymagań biznesowych, scenariusze testowe, historyjki użytkownika czy
przypadki użycia. Testy funkcjonalne jak wskazuje sama nazwa, mają za zadanie zweryfikować funkcjonalności, jakie system powinien realizować. Dlatego kluczową rzeczą, jaką tester powinien zrobić, to skupić się na pełnym zrozumieniu wymagań (funkcjonalnych) stawianych przed testowanym systemem. W przypadku, gdy nie rozumiemy do końca, co w ogóle system powinien robić, to nigdy nie będziemy w stanie przeprowadzić wartościowych testów funkcjonalnych. Precyzyjną wiedzę o tym, jakie funkcje powinien spełniać system, możemy czerpać (oprócz wspomnianej już specyfikacji funkcjonalnej i innych wymienionych artefaktów projektowych) z rozmów z analitykami, developerami oraz klientami końcowymi.

Testy funkcjonalne odpowiadają na pytanie „co robi system


System może realizować takie funkcjonalności jak np.:

• Generowanie potwierdzenie zakupu
• Wystawianie faktury
• Wysyłanie przypomnień do klientów

Testy niefunkcjonalne

Celem testowania niefunkcjonalnego jest dokonanie oceny charakterystyk systemów i oprogramowania,
takich jak: użyteczność, wydajność, bezpieczeństwo itp.


Jak już mogliśmy się dowiedzieć kilka linii wyżej – testy funkcjonalne próbują znaleźć odpowiedź na pytanie „co robi” system, czyli weryfikują system, pod kątem tego, co robi / jakie spełnia funkcjonalności. Pozostając w tej konwencji – testy niefunkcjonalne są próbą odpowiedzi na pytanie „jak działa” system. Jak sama nazwa wskazuje testy niefunkcjonalne, nie odnoszą się do bezpośrednio do funkcjonalności systemu. Ten rodzaj testów skupia się na charakterystyce oprogramowania tzn. na jego zachowaniach w zdefiniowanych stanach, np. w stanie dużego natężenia ruchu, czy dużego wykorzystania zasobów infrastrukturalnych / sprzętowych takich jak: pamięć RAM, czy CPU.

Wbrew mylnemu przekonaniu testowanie niefunkcjonalne można, a nawet należy wykonywać na wszystkich poziomach testów.

Do testów niefunkcjonalnych zaliczamy:
– testy wydajnościowe, obciążeniowe, przeciążeniowe
– testy bezpieczeństwa
– testy użyteczności, ergonomii
– testy przenośności kodu

Testowanie funkcjonalne vs niefunkcjonalne

Testy funkcjonalnościTesty niefunkcjonalne
Testy funkcjonalne wykonywane są z wykorzystaniem specyfikacji funkcjonalnej i innych artefaktów projektowych, weryfikują system pod kątem wymagań funkcjonalnychTesty niefunkcjonalne sprawdzają wydajność, niezawodność, skalowalność, bezpieczeństwo i inne niefunkcjonalne aspekty systemu oprogramowania
Testy funkcjonalne są wykonywane w pierwszej kolejnościTesty niefunkcjonalne powinny być wykonywane po testach funkcjonalnych
Testy mogą odbywać się ręcznie (czyli bez obecności dedykowanych narzędzi i rozwiązań). Oczywiście mogą być również wykonywanie automatycznie z wykorzystaniem specjalistycznego oprogramowaniaNiezbędne korzystanie z dedykowanych narzędzi i rozwiązań
Dane wejściowymi: Wymagania biznesoweDane wejściowe: np. parametry wydajności, takie jak szybkość, skalowalność
Testy funkcjonalne opisują, „co robi” systemTesty niefunkcjonalne opisują, „jak działa” system
Przykładami testów funkcjonalnych są: Testy jednostkowe, Testy integracyjne, Testowanie białoskrzynkowe, Testowanie czarnoskrzynkowe, Testowanie akceptacyjne, Testy regresjiPrzykładami testów niefunkcjonalnych są: Testowanie wydajnościowe, Testowanie obciążenia, Testowanie bezpieczeństwa, Testowanie instalacji, Testy penetracyjne, Testowanie zgodności, Testowanie migracji

Dwa kluczowe rodzaje testów niefunkcjonalnych to testy wydajnościowe oraz testy bezpieczeństwa. W dużym skrócie przedstawiam poniżej oba wspomniane rodzaje testów.

Testy wydajnościowe

Testy wydajnościowe są przeprowadzane, w celu oceny spełnienia wymagań wydajnościowych oprogramowania.


Głównym zadaniem tego typu testów jest weryfikacja tego, jak zachowuje się oprogramowanie w różnych stanach obciążenia. To bardzo ważne testy, które powinny być wykonywane na różnych poziomach testów, gdyż warto pamiętać, że nawet bardzo dobrze (funkcjonalnie) działająca aplikacja będzie spisana na straty, gdy jej działanie okaże się wolne, niewydajne np. przy większej liczbie jednocześnie działających na aplikacji użytkowników. Należy mieć również na uwadze, że poprawnie działająca funkcjonalność przy znikomym obciążeniu może przestać działać, bądź działać niepoprawnie przy większym obciążeniu aplikacji. W takim przypadku należy jak najszybciej wdrożyć poprawki optymalizacyjne i przeprowadzić retesty na odpowiednim obciążeniu aplikacji. Częstym błędem niedoświadczonych zespołów testowych jest odkładanie testów wydajnościowych na sam koniec procesu testowego/ developerskiego. W tak później fazie poprawki optymalizacyjne mogą być bardzo kosztowne, czasochłonne a w skrajnych przypadkach wręcz niemożliwe architektoniczne do wprowadzenia.
Do testów wydajnościowych konieczne jest użycie narzędzi generujących obciążenie i analizujących czasy odpowiedzi. Popularne i często wykorzystywane na rynku narzędzia to np: Jmeter, Gatling, LoadView. Do ich obsługi wymagane są umiejętności techniczne, jak chociażby znajomość języków skryptowych/programowania.

Rodzaje testów wydajnościowych:

  • Load testing (Testy obciążeniowe) — weryfikują zdolność aplikacji do działania przy przewidywanym, standardowym obciążeniu ze strony użytkowników. Celem jest zidentyfikowanie wąskich gardeł związanych z wydajnością
  • Stress testing (Testy przeciążeniowe) — weryfikują działanie aplikacji przy ekstremalnych obciążeniach, (na granicy wydajności i poza nią), aby zobaczyć, jak aplikacja radzi sobie z dużym ruchem lub przetwarzaniem danych. Celem jest zidentyfikowanie punktu krytycznego aplikacji, czyli „punktu przeciążenia”
  • Endurance testing (Testy wytrzymałościowe) – są wykonywane, aby upewnić się, że oprogramowanie poradzi sobie z oczekiwanym obciążeniem przez długi czas
  • Spike testing – testy reakcji oprogramowania na nagłe, duże skoki obciążenia generowane przez użytkowników
  • Scalability testing (Testowanie skalowalności) — Testowanie skalowalności służy do określenia, czy oprogramowanie skutecznie obsługuje rosnące obciążenia. Można to określić, stopniowo zwiększając obciążenie użytkownika lub ilość danych, jednocześnie monitorując wydajność systemu. Ponadto obciążenie może pozostać na tym samym poziomie podczas zmiany zasobów, takich jak procesory i pamięć.

Więcej o testach wydajnościowych możecie przeczytać w innym moim materiale: https://odlaikadoautomatyka.pl/testy-wydajnosciowe/

Testy bezpieczeństwa

Testy bezpieczeństwa – proces polegający na przeprowadzeniu kontrolowanego ataku na system teleinformatyczny, mający na celu praktyczną ocenę bieżącego stanu bezpieczeństwa tego systemu, w szczególności obecności znanych podatności i odporności na próby przełamania zabezpieczeń.


Testy bezpieczeństwa inaczej nazywane testami penetracyjnymi są typem testów, którego celem jest weryfikacja czy oprogramowanie jest odporne na ataki i ingerencję osób nieuprawionych do korzystania z oprogramowania. Na tym etapie testów wykonuje się różnego rodzaju „planowane ataki”, które mają za zadanie przejąć kontrolę nad oprogramowaniem, uzyskać dostępy do poufnych danych, zmodyfikować oprogramowanie, czy całkowicie je unieruchomić. Mówiąc krócej, testerzy (pentesterzy) starają się wykryć luki, za pomocą których niepowołane osoby mogłyby dokonać ataku hakerskiego. Musimy pamiętać, że zwykle najsłabszym ogniwem oprogramowania jest człowiek (w końcu wszyscy popełniamy błędy). Dlatego najwięcej ataków opiera się o metody socjotechniczne. W obliczu podanych wyżej informacji nie muszę już tłumaczyć, jak istotne i krytyczne są wszystkie znalezione luki, incydenty bezpieczeństwa. Bezdyskusyjnie powinny być one poprawiane, łatane tak szybko, jak to tylko możliwe – z najwyższym priorytetem.

Rodzaje testów bezpieczeństwa:
Możemy wyróżnić kilka, kluczowych rodzajów testów bezpieczeństwa:

Skanowanie luk w zabezpieczeniach : odbywa się za pomocą zautomatyzowanego oprogramowania do skanowania systemu pod kątem znanych sygnatur luk w zabezpieczeniach.
Skanowanie zabezpieczeń: obejmuje identyfikowanie słabych punktów sieci i systemu, a następnie zapewnia rozwiązania zmniejszające te zagrożenia. To skanowanie można wykonać zarówno w przypadku skanowania ręcznego, jak i automatycznego.
Testy penetracyjne : symulacja ataków hakerskich. Testy te obejmują analizę konkretnego systemu w celu sprawdzenia potencjalnych podatności na zewnętrzne próby włamania.
Ocena ryzyka: Analiza zagrożeń bezpieczeństwa zaobserwowanych w organizacji. Ryzyka są klasyfikowane jako niskie, średnie i wysokie. Celem analizy ryzyka jest wypracowanie zaleceń kontroli i środków, aby zmniejszyć potencjalne ryzyka.
Audyt bezpieczeństwa: jest to wewnętrzna inspekcja aplikacji i systemów operacyjnych pod kątem luk w zabezpieczeniach. Audyt można również przeprowadzić poprzez inspekcję kodu linia po linii
Etyczne hakowanie: to hakowanie systemów oprogramowania organizacji. W przeciwieństwie do hakerów, którzy kradną dla własnych korzyści, celem jest ujawnienie luk w zabezpieczeniach systemu.
Ocena stanu: łączy skanowanie bezpieczeństwa, etyczne hakowanie i ocenę ryzyka, aby pokazać ogólny stan bezpieczeństwa organizacji.

O testach bezpieczeństwa powstanie niebawem osobny, bardziej szczegółowy materiał!

Testowanie strukturalne – biała skrzynka

Testy strukturalne (ang. white-box testing,testy białej skrzynki) – rodzaj testów w inżynierii oprogramowania, polegających na testowaniu programu poprzez podawanie na wejściu takich danych, aby program przeszedł przez każdą zaimplementowaną ścieżkę. Zasady te są definiowane przez kryteria pokrycia wszystkich pętli oraz wszystkich warunków. Testy białej skrzynki nie są w stanie wykazać braku implementacji funkcji, którą powinien posiadać system docelowy. Sprawdzają jednak dokładnie operacje wykonywane w zaimplementowanych metodach.

Testy strukturalne to typ testów, który może być stosowany na każdym poziomie testów. Testowanie strukturalne wykorzystywane jest do pomiarów dokładności testowania poprzez ocenę pokrycia określonego typu struktury. Jest ono mierzone za pomocą przeprowadzonych testów i wyrażane jest procentowo.

Testowanie regresywne i potwierdzające

Testy potwierdzające wykonywane są, aby upewnić się, że znaleziony defekt został naprawiony.

Testy potwierdzające (retesty) wykonuje się, gdy wcześniej wykryty błąd, zostanie przez programistę naprawiony i trafia ponownie do weryfikacji (fazy testów). Wtedy to raz jeszcze wykonujemy test (który wcześniej wykrył dany błąd, czyli zakończył się w statusie „failed”) w celu sprawdzenia, czy błąd już nie występuje. Jeśli tym razem defekt już nie występuje, to przyjmujemy, że poprawka okazała się skuteczna, a sam błąd możemy zamknąć i test okrasić statusem „passed”.

Testy regresji to weryfikacje sprawdzające, czy ostatnie poprawki nie naruszyły dotychczas prawidłowo działających obszarów systemu.

Testy regresji wykonujemy na każdym poziomie testów. Ten rodzaj testów idealnie nadaje się do automatyzacji, gdyż regresję będziemy wykonywać wielokrotnie, a konkretniej mówiąc, możemy ją wykonywać po każdej podgrywce systemu. Celem tych testów jest zmniejszenie ryzyka, że jakaś wgrana poprawka, zepsuła inne do tej pory działające funkcjonalności. Dobrą praktyką każdego projektu testów jest budowa szerokiego zestawu automatycznych testów regresyjnych. W ten sposób wielokrotnie i szybko po każdej podrywce, możemy weryfikować stan głównych elementów aplikacji, bez konieczności za każdym razem przeprowadzania ich ręcznie, czyli angażowania w nie testerów manualnych.

Autor: Tomasz Stelmach

Notatka o autorze:

Zajmuję się testowaniem, zabezpieczaniem i zapewnianiem jakości oprogramowania od ponad 13 lat. Rozpocząłem swoją karierę od testów manualnych i analizy biznesowo-technicznej. Obecnie prowadzę firmę Quality Island, która zajmuje się szeroko pojętym testowaniem oprogramowania oraz szkoleniami dla przyszłych i obecnych testerów oprogramowania. Moją specjalnością są testy automatyczne aplikacji webowych oraz budowa procesów automatyzacji i robotyzacji. Od 8 lat prowadzę aktywnie szkolenia oraz konsultacje z tych tematów i wykonuję zlecenia dla firm trzecich jako konsultant, ekspert oraz audytor. Współpracuję również z firmami jako osoba do rekrutacji i weryfikacji technicznych. Interesują mnie głównie tematy związane z architekturą IT oraz zagadnienia DevOps/TestOps, ponieważ ściśle wiążą się z zapewnianiem jakości oprogramowania.

 

Tomasz Stelmach

CEO&Founder

 

0 komentarzy

Wyślij komentarz

Twój adres e-mail nie zostanie opublikowany. Wymagane pola są oznaczone *