Testy strukturalne to kolejny temat zaraz po testach funkcjonalnych i niefunkcjonalnych. Testy te w przeciwieństwie do poprzednich typów testów są nazywane testami białej skrzynki. Na pewno już zdążyliście się przyzwyczaić do tego, że zmiana nie polega tylko na innej nazwie, ale ma głębszy sens, który postaram się wam wytłumaczyć.  Na samym początku sięgnijmy do słownika pojęć ISTQB, aby zapoznać się z teorią tego pojęcia.

 

Testowanie strukturalne : patrz. Testowanie Białoskrzynkowe -> Testowanie oparte na analizie wewnętrznej struktury modułu lub systemu.

Testy białej skrzynki skupiają się tylko i wyłącznie na testowaniu kodu bądź systemu. Są one przeciwieństwem testów czarnej skrzynki. W naszych testach musimy podać taki zestaw danych na wejściu, aby program przeszedł wszystkie z zaimplementowanych ścieżek. Przy stosowaniu metody białej skrzynki musimy znać strukturę kodu. Wchodzimy w środek aplikacji w jej wnętrze. Dzięki temu możemy łatwo zoptymalizować nasz kod oraz mamy wiedzę na temat tego, gdzie znajduje się błąd i dlaczego występuje. Nie łatwo domyślić się, że dużym problemem przy stosowaniu tej metody jest znalezienie testera, który ma wiedzę programistyczną i zdolności do zapoznania się ze strukturą kodu. Bardzo często koszta zatrudnienia takiego testera, przewyższają budżet przeznaczony na konkretny projekt.

Poznaliśmy już kilka plusów i minusów testów strukturalnych (białoskrzynkowych). Powyższe informacje ułatwiają wam dokładne określenie celu tych testów. Celem jest oczywiście zbadanie pokrycia. Badamy je używając przygotowane wcześniej testy, które wyrażane są jako odsetek pokrytych elementów.

Poniższy obrazek zawiera informację na temat używanych technik białoskrzynkowych w testowaniu i pokryciu elementów:

Zapomniałam dodać, że testy te mogą mieć miejsce na każdym z poziomów testów. Z poprzednich wpisów wiecie, że przykładem testów strukturalnych są unit tests, czyli testy jednostkowe. Dzieje się tak dlatego, że kod tworzony jest dla poszczególnych elementów aplikacji, co powoduje, że sprawdzamy, czy właściwy (ten konkretny) kod aplikacji działa prawidłowo. Bardzo trudne jest sprawdzenie każdej linijki kodu, można to zrobić oczywiście na dwa sposoby. Jednym z nich to ręczne sprawdzenie kodu lub  napisanie testów automatycznych, które mogą wykonywać się każdego dnia o jednej godzinie i sprawdzać, czy program nadal działa poprawnie.

To chyba wszystko, co mogłam wam powiedzieć na temat testów strukturalnych. Mam nadzieję, że udało mi się wam dobrze wyjaśnić ten temat i z niecierpliwością będziecie czekać na kolejne 🙂 Moi kochani testerzy do następnego razu! Pozdrawiam was serdecznie.

 

Skomentuj Emilia Anuluj pisanie odpowiedzi

Twój adres e-mail nie zostanie opublikowany.

4 odpowiedzi na "Testy strukturalne"

Ten serwis wykorzystuje pliki cookies. Korzystanie z witryny oznacza zgodę na ich zapis lub odczyt wg ustawień przeglądarki. Więcej
Zgoda