Typy testów – testowanie oprogramowania
W dzisiejszym wpisie poruszymy kolejny ważny aspekt podstaw testowania oprogramowania, czyli typy testów. Jak możemy testować oprogramowanie, jakie typy testów mogą się nam przydać do naszego kontekstu? To wszystko poruszymy w dzisiejszym wpisie.
Typy testów, jakie możemy wyróżnić, dzielą się na cztery kategorie, są to:
– Testy niefunkcjonale
– Testy funkcjonalne
– Testy strukturalne
– Testy związane ze zmianami
Testy niefunkcjonalne
Trzeba zacząć od tego, że testy niefunkcjonalne są o wiele obszerniejszym tematem niż testy funkcjonalne. Testy niefunkcjonalne nie odnoszą się bezpośrednio do funkcji systemu. Testując oprogramowanie niefunkcjonalnie, skupiamy się na takich tematach jak testy:
– Testy bezpieczeństwa
– Testy wydajności
– Testy obciążeń
– Testy użyteczności
To, co jest ważne to aspekt, że testując oprogramowanie trzeba mieć z tyłu głowy, testy niefunkcjonalne, nawet jeśli nie są one podane w wymaganiach.
W tym wypadku możemy albo poprosić o podanie dokładnych wymagań bądź założyć wartości domyślne.
Czy aplikacja, która ma słaby performance, spełnia kryteria i nie będzie to uciążliwe dla klienta końcowego? Co z zapewnieniem nawet podstawowych zasad bezpieczeństwa?
Testy funkcjonale
Testy funkcjonalne są testami funkcjonalności, jakie ma nasz program (przykład: rejestracja użytkownika).
Najprościej mówiąc testy te, mają za zadanie sprawdzić, czy funkcje oprogramowania działają prawidłowo. Pytanie, jakie się nasuwa to, skąd mamy wiedzieć, czy rezultat testów jest pożądanym wynikiem?
Tutaj z pomocą przychodzi specyfikacja, w której mamy informacje na temat poprawnego działania testowanego oprogramowania.
Testy strukturalne
Testy strukturalne, które są testami białoskrzynkowymi, czyli operujemy tutaj na napisanym kodzie.
Celem testów strukturalnych jest sprawdzenie, czy wszystkie elementy zostały pokryte przez testy, mówimy tutaj o procencie pokrycia kodu testami.
Testy strukturalne sprawdzają takie elementy jak wywoływane funkcje, linie kodu czy sprawdzanie warunków logicznych i rozgałęzień.
Testy związane ze zmianami
Zacznijmy od tego, jakie scenariusze powodują zmiany w oprogramowaniu, główne przyczyny zmian to:
– naprawa defektu przez stworzenie nowego kodu, który go naprawia
– opublikowanie nowej wersji oprogramowania
– publikacja hotfix’a
– zmiana elementu środowiskowego, które wpływa na naszą aplikację, zmiana środowiska, baz danych
W testowaniu związanym ze zmianami wyróżniamy testy regresji oraz retesty.
Testy regresji kontra retesty
Czym różnią się testy regresji od retestów oraz kiedy je wykonujemy?
Testy regresji – mają na celu potwierdzenie braku regresji po modyfikacji oprogramowania, nad którym pracujemy. Testy regresji polegają na wykonaniu wcześniej zaprojektowanych przypadków testowych, które mają na celu dać nam informację zwrotną na temat stanu naszej aplikacji.
Testy regresji są też pierwszym kandydatem do zautomatyzowania z powodu rosnącego wolumenu testów, który będzie zwiększał się wraz z rozwojem aplikacji. Testy regresji wykonywane ręcznie będą zajmowały co raz większe ilości czasu, co może zdecydowanie wpłynąć na szybkość wydawania nowych wersji, z czasem może również nastąpić sytuacja, że testy regresji (niezautomatyzowane) staną się wąskim gardłem w naszym projekcie, który uniemożliwi szybkie dostarczenie aplikacji na serwer produkcyjny.
Retesty – retesty wykonujemy po znalezieniu usterki i naprawieniu jej przez developara. Retesty mają za zadanie sprawdzić czy dana usterka została naprawiona. To, co jest istotne to fakt, że może zdarzyć się sytuacja, gdzie naprawa takiej usterki wygeneruje kolejne w innych miejscach aplikacji.
Więcej artykułów o postawach testowania oprogramowania znajdziesz w naszym spisie: https://projectquality.it/testowanie-oprogramowania-podstawy/https://projectquality.it/testowanie-oprogramowania-podstawy/
