Menu

Samouczek dotyczący testowania konstrukcji - co to jest testowanie strukturalne

  • Główny
  • Inny
  • Samouczek dotyczący testowania konstrukcji - co to jest testowanie strukturalne

structural testing tutorial what is structural testing

Wypróbuj Nasz Instrument Do Eliminowania Problemów

Ten kompleksowy samouczek dotyczący testowania strukturalnego wyjaśnia, czym są testy strukturalne, ich rodzaje, czym są testy przepływu sterowania i wykres przepływu sterowania, poziomy pokrycia itp .:

Szybkie wyszukiwanie w Google jednych z najdroższych błędów oprogramowania przyprawiło mnie o zawrót głowy - 500 miliardów dolarów. Tak, właśnie tyle może kosztować błąd. Czytanie wszystkiego, co dotyczy ofiar śmiertelnych w branży transportowej i opieki zdrowotnej z powodu błędu oprogramowania, również może być przerażające.

Chociaż błędy w kodzie nie zawsze są tak skrajne, gdy wiążą się z utratą dużej ilości pieniędzy i życia, jedynym kluczowym wnioskiem, który próbujemy przekazać, jest to, że nie można przeoczyć testowania.

Testowanie strukturalne

Często przeprowadzane testy w SDLC pozwalają nam wyłapać błędy, których naprawienie wymagałoby znacznie więcej czasu po wysyłce produktu.

Istotne są wybrane przez nas typy testów oprogramowania. Istnieje kilka z nich, w tym testy funkcjonalne, strukturalne i oparte na zmianach.

W tym samouczku wyjaśniono również typy testów strukturalnych. Dowiedz się, jak wykonywać testy mutacji, testy oparte na wycinkach, testy przepływu danych szczegółowo wraz z przykładami i objaśnieniami.

Czego się nauczysz:

Dlaczego testowanie oprogramowania jest ważne

Oprócz oszczędzania pieniędzy i unikania katastrof, takich jak wspomniane powyżej przypadki, istnieje kilka innych powodów uzasadniających znaczenie testów.

Poniżej wymieniono kilka powodów:

# 1) Aby zapewnić spełnienie określonych wymagań przed rozpoczęciem budowy projektu. Zainteresowane strony (na przykład programiści i klienci) muszą uzgodnić wszystkie aspekty rozwiązania / produktu / oprogramowania, które są wymagane do zbudowania projektu.

Testowanie obejmuje sprawdzenie, czy spełnione są wymagania dotyczące oprogramowania. Deweloper lub firma zajmująca się budową rozwiązania zyskała również dobrą opinię dzięki zaprojektowaniu tak wysokiej jakości rozwiązania, które jest uruchamiane przez kod eclat.

# 2) Sprawdza, czy funkcja kodu działa zgodnie z przeznaczeniem. Testowanie obejmuje również weryfikację funkcjonalności oprogramowania, aw przypadku jakiejkolwiek usterki, należy ją naprawić we wczesnych fazach SDLC (cyklu życia oprogramowania).

# 3) Sprawdza wydajność: na przykład aby określić całkowity czas, który upłynął podczas wykonywania kodu. Jeśli użyjemy kilku For Loops w naszym kodzie uzyskanie zamierzonych wyników zajmie dużo czasu, a czasami może nawet przekroczyć limit czasu.

# 4) Pomaga osiągnąć lepsze wrażenia użytkownika. Użytkownicy nie będą zadowoleni z używania oprogramowania, które działa nieprawidłowo, zawiera błędy lub jest „zbyt wolne”. Użytkownicy prawdopodobnie się niecierpliwią i zrezygnują z korzystania z oprogramowania. Testowanie daje nam lepsze możliwości zapewnienia użytkownikom łatwego korzystania z naszych produktów.

# 5) Sprawdza skalowalność. Deweloper powinien dążyć do tworzenia oprogramowania, które można skalować.

# 6) Sprawdza pod kątem luk w kodzie. Testowanie daje nam możliwość wyszukania luk w zabezpieczeniach, Na przykład, kod, który może zagrażać bezpieczeństwu PII (Dane osobowe), które są priorytetem RODO.

W tym artykule skupimy się na jednym rodzaju testów, tj. Testowanie strukturalne . Jak sama nazwa wskazuje, ma to związek ze strukturą kodu. Różni się to od tego, o czym wspomnieliśmy wcześniej, że testowanie pomaga określić takie aspekty, jak wydajność kodu, funkcjonalność i bezpieczeństwo.

Testowanie strukturalne a inne typy testów

Istnieje wiele rodzajów testowania oprogramowania. Jednakże ZATRZYMAĆ (International Software Testing Qualifications Board) definiuje 4 główne typy testów oprogramowania, a mianowicie

jak dodać maven do zaćmienia
  • Funkcjonalny
  • Niefunkcjonalne
  • Strukturalny
  • Oparte na zmianach

Różnice można wyjaśnić w następujący sposób:

Testy funkcjonalności: Obejmuje to weryfikację funkcjonalności oprogramowania pod kątem określonych wymagań. Dane testowe są używane jako dane wejściowe. Sprawdzamy również, czy podane dane wyjściowe są zgodne z oczekiwaniami.

Testowanie niefunkcjonalne : Obejmuje proces testowania w celu przeanalizowania, jak dobrze działa oprogramowanie, na przykład, liczbę użytkowników, których może obsługiwać jednocześnie.

Badania strukturalne: Ten typ testowania opiera się na strukturze kodu. Na przykład, jeśli kod ma na celu obliczenie średniej z liczb parzystych w tablicy, wówczas testowanie oparte na strukturze byłoby zainteresowane „krokami prowadzącymi do obliczenia średniej”, a nie tym, czy wynik końcowy jest prawidłową wartością liczbową.

Załóżmy, że musimy sprawdzić, czy zdefiniowaliśmy kod odróżniający liczby parzyste od nieparzystych. Możemy mieć tutaj instrukcję warunkową, na przykład, jeśli element tablicy jest podzielny przez dwa bez reszty, if (arr (i)% 2 === 0) wtedy liczbę można powiedzieć jako liczbę parzystą.

Testy strukturalne przeprowadzają te same osoby, które piszą kod tak, jak go najlepiej rozumieją.

Testowanie oparte na zmianach : Obejmuje to testowanie skutków wprowadzenia zmian w kodzie, a następnie upewnienie się, że wprowadzone zmiany zostały wdrożone. Zapewnia również, że zmiany w kodzie go nie zakłócą.

Czym nie są testy strukturalne

Wspomnieliśmy wcześniej, że testowanie strukturalne odnosi się do struktury kodu. Zwróć uwagę, że mamy tutaj do czynienia z rzeczywistym kodem. Nie sprawdzamy wymagań ani nawet nie testujemy danych wejściowych pod kątem oczekiwanych wyników. W tym momencie nie interesuje nas funkcjonalność, wrażenia użytkownika ani nawet wydajność.

Co to są testy strukturalne

Dlatego też testowanie strukturalne można zdefiniować jako rodzaj testowania oprogramowania, które testuje strukturę kodu i przewidziane przepływy. Na przykład, weryfikacja rzeczywistego kodu pod kątem takich aspektów, jak poprawna implementacja instrukcji warunkowych oraz czy każda instrukcja w kodzie jest poprawnie wykonywana. Jest również znany jako testowanie strukturalne.

Aby przeprowadzić tego typu testy, musimy dokładnie zrozumieć kod. Dlatego te testy są zwykle wykonywane przez programistów, którzy napisali kod tak, jak go najlepiej rozumieją.

Jak przeprowadzić testy strukturalne

Aby przetestować różne aspekty kodu, musimy najpierw zrozumieć przepływy sterowania.

Testowanie przepływu kontrolnego

Wynika to z testów na podstawie przepływów kontrolnych kodu (kolejności implementacji instrukcji, funkcji i różnych aspektów kodu).

Proces testowania przepływu sterowania:

Wykres przepływu sterowania

Proces kontroli rozpoczyna się od stworzenia wizualnej reprezentacji różnych sekcji kodu, która pomaga nam zdefiniować ścieżki, którymi można podążać podczas wykonywania.

Te wizualne reprezentacje są znane jako Control Flow Graphs (CFG) i mają kilka komponentów, takich jak węzły, krawędzie, ścieżki, skrzyżowania i punkty decyzyjne. Wykres można utworzyć ręcznie lub automatycznie, gdzie oprogramowanie jest używane do wyodrębnienia wykresu z kodu źródłowego.

Spójrzmy na poniższe komponenty:

Węzły i krawędzie

# 1) Blok procesu

Ta część służy do reprezentowania sekcji kodu, która jest wykonywana sekwencyjnie. Oznacza to, że za każdym razem jest wykonywana w ten sam sposób i nie trzeba podejmować żadnych decyzji ani „rozgałęzień”. Składa się z węzłów z jedną ścieżką wejścia i wyjścia.

Przykład bloku procesu:

Blok procesu

(wizerunek źródło )

Blok procesowy nie jest istotną częścią przepływu sterowania i dlatego musi być przetestowany tylko raz.

# 2) Punkty decyzyjne

Oto kilka kluczowych elementów przepływu sterowania w kodzie. W tych węzłach podejmowane są decyzje. Odbywa się to zwykle poprzez porównanie, a przepływ sterowania zmienia się w zależności od decyzji. Ta część CFG składa się z jednego węzła z co najmniej 2 wyjściami.

Decyzją podjętą tutaj mogą być instrukcje warunkowe, takie jak instrukcje if-else (które mają dwa możliwe wyjścia) i instrukcje case (które mogą mieć więcej niż dwa wyjścia).

CFG

(wizerunek źródło )

Na powyższym diagramie znajduje się punkt decyzyjny (od warunkowego „wieku = 18”), po którym następuje opcja „tak” lub „nie”.

# 3) Punkty połączenia

Z powyższego diagramu możemy łatwo zidentyfikować punkty węzłowe, gdzie łączą się punkty decyzyjne. Punkty skrzyżowania mogą mieć wiele ścieżek wejściowych, ale mogą mieć tylko jedną ścieżkę wyjściową.

Najlepsze praktyki dotyczące wykresów przepływu sterowania:

Podczas tworzenia wykresów przepływu sterowania należy zwrócić uwagę na kilka rzeczy:

  • Postaraj się, aby CFG było proste. Możemy to zrobić, łącząc części, które można uznać za „mniej istotne”, na przykład, bloki procesowe.
  • Upewnij się, że w punktach decyzyjnych jest podejmowana tylko jedna decyzja. W bardziej złożonych CFG istnieją „konsekwencje”, które pojawiają się po podjęciu decyzji. W naszym powyższym przykładzie możemy również dodać, że jeśli osoba ma 18 lat lub więcej, to kwalifikuje się i musi zapłacić za bilet. Jeśli tak nie jest, wstęp jest bezpłatny. Decyzja „else” wymaga „pominięcia” kilku węzłów, a wszystkie te kroki należy przedstawić w naszej CFG.

Kiedy już zdefiniowaliśmy nasze CFG, czas przejść do następnego kroku w procesie testowania przepływu sterowania, tj. Zdefiniować zakres, w jakim będziemy testować kod.

Określenie, ile przetestować:

Jaka część kodu źródłowego powinna zostać przetestowana? Czy powinniśmy przetestować każdą możliwą ścieżkę? Pokonanie wszystkich ścieżek w naszych testach jest praktycznie niemożliwe. Musimy znaleźć kompromis, aby określić, ile testów możemy przeprowadzić.

Jeśli powiemy, że naszym celem jest przetestowanie 50% naszego kodu, może to oznaczać, że zdefiniujemy wszystkie instrukcje kodu wykonywalnego i będziemy dążyć do przetestowania co najmniej połowy z nich. Jednak pojawia się tutaj pytanie „czy w takim razie musimy zdefiniować wszystkie możliwe ścieżki wykonywalne?”

To znowu może być praktycznie niemożliwe. Lepszym podejściem może być przetestowanie 50% ścieżek, które możemy zidentyfikować w każdej sekcji kodu.

Istnieją różne poziomy pokrycia, a mianowicie pokrycie instrukcji, gałęzi i ścieżki. Przyjrzymy się im pokrótce później.

Tworzenie przypadków testowych:

Następnym krokiem jest stworzenie przypadków testowych, z których będziemy korzystać. Przypadki testowe w testowaniu opartym na strukturze są oparte na następujących czynnikach:

  • Instrukcje wykonywalne.
  • „Decyzje”, które należy podjąć.
  • Możliwe ścieżki, którymi można podążać.
  • Warunki, które należy spełnić (mogą być wielokrotne lub logiczne).

Powyższe czynniki dają nam wyobrażenie o typach przypadków testowych, które musimy utworzyć. Możemy również skorzystać z narzędzia do generowania testów strukturalnych. Jeśli nasz kod jest w języku C, możemy użyć PathCrawlera do wygenerowania kodu testowego. Kolejnym narzędziem, z którego możemy skorzystać, jest fMBT.

Wykonywanie przypadków testowych:

Tutaj możemy przeprowadzić testy. Możemy wprowadzić dane wejściowe lub dane, aby sprawdzić, jak kod je wykonuje, a następnie zweryfikować, czy otrzymujemy oczekiwane rezultaty. Na przykład, wprowadź tablicę w wywołaniu funkcji, aby obserwować wyniki, które otrzymujemy po jej przejściu w pętli, lub sprawdzić, czy punkty decyzyjne podejmują prawidłowe decyzje.

Analiza wyników:

W tej części wszystko, co robimy, to sprawdzenie, czy po wykonaniu otrzymujemy poprawne wyniki. Na przykład, jeśli wprowadzimy tablicę, w której wszystkie wartości są powyżej 18, powinniśmy mieć wszystkie punkty decyzyjne skutkujące „kwalifikującymi się”.

Założenia dotyczące przepływu sterowania

Należy zauważyć, że aby przeprowadzić testowanie przepływu kontrolnego, należy przyjąć kilka założeń. Obejmują one:

  • Jedyne obecne błędy to te, które mogą wpływać na przepływ sterowania.
  • Wszystkie zmienne, funkcje i elementy są dokładnie zdefiniowane.

Poziomy pokrycia w przepływach sterowania

Jak wspomnieliśmy wcześniej, istnieją różne poziomy pokrycia w testowaniu przepływu sterowania.

Przyjrzyjmy się im pokrótce.

1) Zakres oświadczenia

W testowaniu strukturalnym instrukcje kodu wykonywalnego odgrywają istotną rolę przy decydowaniu o metodach projektowania testów.

Naszym celem jest osiągnięcie 100% pokrycia, co oznacza, że ​​każda instrukcja wykonywalna została przynajmniej raz przetestowana. Im wyższy zasięg, tym mniejsze prawdopodobieństwo pominięcia błędów i błędów.

Konieczne jest tutaj użycie przypadków testowych. Dane, których potrzebujemy, mają zapewnić, że każda wykonywalna instrukcja w bloku kodu zostanie wykonana przynajmniej raz.

# 2) Pokrycie oddziałów

Ten poziom pokrycia obejmuje testowanie punktów w gałęziach CFG (gdzie podejmowane są decyzje). Wyniki są logiczne. Nawet jeśli używana jest instrukcja switch i istnieje wiele wyników, w istocie każdy blok case jest porównaniem pary wartości.

Podobnie jak w przypadku pokrycia wyciągów, powinniśmy dążyć do 100% pokrycia oddziałów. Aby to osiągnąć, musimy przynajmniej raz przetestować każdy wynik na każdym poziomie decyzyjnym. Ponieważ mamy do czynienia z wynikami boolowskimi, powinniśmy dążyć do uruchomienia co najmniej 2 testów na sekcję kodu.

# 3) Pokrycie ścieżki

Ten poziom pokrycia jest dokładniejszy w porównaniu z zakresem decyzji i oświadczeń. Celem jest „odkrycie” wszystkich możliwych ścieżek i przetestowanie ich przynajmniej raz. Może to być niezwykle czasochłonne. Może jednak pomóc wykryć błędy lub błędy w naszym kodzie, a nawet aspekty, które musimy zdefiniować, na przykład, dane wejściowe użytkownika.

Typy testów strukturalnych

Typy testów strukturalnych
(wizerunek źródło )

Testowanie mutacji

Testowanie mutacji jest techniką testowania opartą na błędach, w której różne warianty aplikacji są testowane względem zestawu danych testowych.

>> Zapoznaj się z tym samouczkiem, aby uzyskać szczegółowe informacje Testowanie mutacji.

Testowanie oparte na plasterkach

Testowanie oparte na plasterkach (SBT) można zdefiniować jako technikę testowania oprogramowania opartą na platformie plastry - wykonywalne części programu lub grupy instrukcji, które wpływają na pewne wartości w określonych punktach zainteresowania programu, na przykład, części, w których zdefiniowane są zmienne, lub dane wyjściowe grupy instrukcji.

Jak zrobić krojenie

Przykład krojenia w SBT: Kod do drukowania liczb parzystych i nieparzystych (Python)

num_list = range(1,12) even_nums = () odd_nums = () for var in num_list: if var%2==0: even_nums.append(var) print(f'Even numbers: {even_nums}') elif var%3==0: odd_nums.append(var) print(f'Odd numbers: {odd_nums}')

Testowanie oparte na wycinkach

Istnieją dwa sposoby patrzenia na plasterek: Podążając ścieżką interesującej nas zmiennej lub częścią kodu, która wpływa na dane wyjściowe.

W naszym przykładzie, jeśli spojrzymy na dane wyjściowe liczb nieparzystych, możemy prześledzić część kodu, która prowadzi nas do tego wyniku.

W kryteriach krojenia podanych przez Marka Weisera (który wprowadził SBT) plasterek definiuje się za pomocą następującego wzoru: S (v, n) , gdzie, v odnosi się do danej zmiennej ( na przykład, gdzie zdefiniowano zmienną) i n to deklaracja zainteresowania ( na przykład, gdzie dane wyjściowe są podane) i S oznacza kawałek.

W powyższym przykładzie, aby uzyskać wycinek, zaczynamy od naszego wyniku w linii 10, który staje się naszym n . Nasza zmienna to gdzie .

Więc nasze kryteria krojenia to:

S(v,n) = S(var,10)

Naszym zmartwieniem są stwierdzenia, które prowadzą nas do wyjścia.

To są:
10,9,8,4,3,1

Tak więc nasz wycinek w tym kodzie to:

num_list = range(1,12) odd_nums = () for var in num_list: elif var%3==0: odd_nums.append(var) print(f'Odd numbers: {odd_nums}')

SBTSlice

Typy testów oparte na wycinkach

Istnieją dwa typy SBT: statyczne i dynamiczne

# 1) Testowanie dynamiczne oparte na wycinkach

Przykład SBT wyjaśniony powyżej, w którym przyjrzeliśmy się instrukcjom wpływającym na drukowanie liczb nieparzystych, to dynamiczny SBT. Nasza obawa jest bardzo specyficzna. Skupiamy się tylko na tym, co bezpośrednio wpływa na konkretny wynik.

Wykonujemy kod i używamy danych testowych, aby upewnić się, że działa tak, jak powinno. Moglibyśmy zwiększyć zakres do zakresu (1,50), na przykład, aby sprawdzić, czy nadal generuje tylko liczby nieparzyste. Dynamiczne SBT jest również znane jako testowanie walidacyjne.

# 2) StatyczneTestowanie oparte na plasterkach

W przeciwieństwie do Dynamic SBT, testy statyczne koncentrują się na określonej zmiennej. Jeśli pomyślimy o naszym wyniku w powyższym przykładzie jako gdzie , możemy prześledzić wycinek, który na to wpływa, jako 10,9,8,7,6,5,4,3,2,1

W zasadzie jest to cały blok kodu! Tutaj sprawdzamy, czy kod jest poprawny pod względem składni i wymagań, a my go nie wykonujemy. Statyczny SBT jest również nazywany testowaniem weryfikacyjnym.

Należy zauważyć, że dynamiczny SBT jest „mniejszy” w porównaniu ze swoim statycznym odpowiednikiem. Jest też bardziej szczegółowy.

Najlepsze praktyki / wytyczne dotyczące testowania opartego na plasterkach

Kryteria krojenia powinny być określone przez:

  • Instrukcje, w których wartości są zdefiniowane lub przypisana wartość, a także ponownie przypisana wartość.
  • Instrukcje, w których wartości są pobierane spoza programu, na przykład, poprzez wejście użytkownika.
  • Instrukcje, które wyświetlają dane wyjściowe / zwracają dane wyjściowe.
  • Ostatnie oświadczenie programu, na przykład, wywołanie funkcji, które może definiować wartości lub dostarczać wartości argumentom

Zalety testów opartych na wycinkach obejmują:

  • Ponieważ w SBT pracujemy tylko z określonymi obszarami zainteresowań, ułatwia to efektywne generowanie zestawów testów.
  • Ścieżka jest definiowana przez zależności w kodzie, co jest lepsze niż użycie pokrycie trasy.
  • Dzięki SBT łatwiej jest znaleźć błędy w kodzie źródłowym.

Wady testów opartych na wycinkach obejmują:

  • Jeśli używamy testów dynamicznych podczas testowania dużej bazy kodu, będziemy potrzebować dużo zasobów obliczeniowych.
  • Jeśli użyjemy testów statycznych, możemy przegapić błędy.

Testowanie przepływu danych

Testowanie przepływu danych można zdefiniować jako technikę testowania oprogramowania, która opiera się na wartościach danych i ich wykorzystaniu w programie. Sprawdza, czy wartości danych zostały prawidłowo wykorzystane i czy generują prawidłowe wyniki. Testowanie przepływu danych pomaga prześledzić zależności między wartościami danych na określonej ścieżce wykonywania.

Anomalie przepływu danych

Anomalie przepływu danych to po prostu błędy w programie. Są one podzielone odpowiednio na typy 1, 2 i 3.

Przyjrzyjmy się im poniżej:

Typ 1: Zdefiniowano zmienną i dwukrotnie przypisano jej wartość.

Przykładowy kod: Python

lst_1 = (1,2,3,4) lst_1 = (5,6,7,8) for var in lst_1: print(var)

Typ 1

Lst_1 jest zdefiniowana i przypisywane są do niej dwie różne wartości. Pierwsza wartość jest po prostu ignorowana. Anomalie typu 1 nie powodują awarii programu.

Typ 2: Wartość zmiennej jest używana lub przywoływana przed jej zdefiniowaniem.

Przykładowy kod: Python

for var in lst_1: print(var)

Wpisz 2

Powyższa pętla nie ma wartości do iteracji. Anomalie typu 2 powodują awarię programu.

Typ 3: A. wartość danych jest generowana, ale nigdy nie jest używana.

Przykładowy kod: Python

lst_1 = (1,2,3,4) lst_2 = (5,6,7,8) for var in lst_1: print(var)

Wpisz 3

Zmienna lst_2 nie ma odniesienia. Anomalie typu 3 nie mogą powodować awarii programu.

Proces testowania przepływu danych

Aby zdefiniować zależności między wartościami danych, musimy zdefiniować różne ścieżki, którymi można podążać w programie. Aby to skutecznie zrobić, musimy zapożyczać z innego typu testów strukturalnych znanego jako testowanie przepływu kontrolnego .

Krok 1) Narysuj wykres przepływu sterowania

Musimy narysować wykres przepływu sterowania, który jest graficzną reprezentacją ścieżek, które moglibyśmy podążać w naszym programie.

Przykładowy kod: Python

cost = 20 y = int(input('How many visitor seats did you reserve? ')) x = int(input('How many member seats did you reserve? ')) if y>x: bill = cost -1 else: bill = cost print(bill)

Testowanie przepływu danych

W powyższym przykładzie kodu członek powinien otrzymać zniżkę, jeśli zaprosi gościa.

Wykres przepływu sterowania (CFG):

Wykres przepływu sterowania

Krok 2) Zapoznaj się z definicją i wykorzystaniem zmiennych i wartości danych.

Zmienna w programie jest zdefiniowana lub używana. W CFG mamy zmienne w każdym węźle. Każdy węzeł jest nazywany zgodnie z typem zmiennej, który zawiera. Jeśli zmienna jest zdefiniowana w określonym węźle, tworzy węzeł definiujący. Jeśli zmienna jest używana w węźle, tworzy węzeł użycia.

Jeśli weźmiemy pod uwagę koszt zmienny w CFG, są to węzły definiujące i użytkowe:

WęzełRodzajKod
1 Węzeł definiującykoszt = 20
5 Węzeł użytkowaniarachunek = koszt -1
7 Węzeł użytkowaniarachunek = koszt

Krok 3) Zdefiniuj ścieżki użycia definicji.

Istnieją dwa typy ścieżek użycia definicji: ścieżki du i ścieżki dc. ścieżki du to ścieżki definicji, które zaczynają się węzłem definicji i kończą węzłem użytkowania. Tak jest w przypadku ścieżki w odniesieniu do kosztu zmiennego powyżej.

Przykładem ścieżki dc, ścieżki decyzyjnej, jest ścieżka odnosząca się do zmiennej rachunku, jak poniżej:

WęzełRodzajKod
5 Węzeł definiującyrachunek = koszt -1
7 Węzeł definiującyrachunek = koszt
8 Węzeł użytkowaniadrukuj (rachunek)

ścieżka DC ma więcej niż jeden węzeł definicji, mimo że nadal kończy się na węźle użytkowania.

Krok 4) Utwórz zestaw testów.

To jest dodawanie danych wejściowych. Zauważ, że musimy mieć inny zestaw testów dla każdej zmiennej. Zestaw testów pomoże nam zidentyfikować anomalie przepływu danych.

Typy testów przepływu danych

Istnieją dwa typy - Statyczne i dynamiczne .

Statyczny oznacza, że ​​przechodzimy przez kod i CFG, aby zidentyfikować anomalie danych, bez ich wykonywania. Dynamiczny oznacza, że ​​faktycznie identyfikujemy określone ścieżki, a następnie tworzymy zestawy testów, aby przetestować je w celu „wychwycenia” anomalii, które mogliśmy przeoczyć podczas testów statycznych.

Zalety i wady testowania przepływu danych:

  • Testowanie przepływu danych jest idealne do identyfikowania anomalii przepływu danych, co czyni go bardzo skuteczną metodą testowania strukturalnego.
  • Wadą jest to, że trzeba dobrze znać język używany do pisania kodu, aby móc korzystać z testowania przepływu danych. Jest to również czasochłonne.

Zalety i wady testów strukturalnych

Znajdźmy teraz powody, dla których testowanie strukturalne jest świetnym podejściem, i zbadajmy również niektóre z jego wad.

Zalety:

  • Pozwala na dokładne testowanie kodu, co skutkuje minimalnymi błędami. Testowanie strukturalne daje możliwość dokładnego przetestowania oprogramowania. Różne poziomy pokrycia - zestawienie po stwierdzeniu, każdy punkt decyzyjny i ścieżka mają na celu osiągnięcie 100% pokrycia, co znacznie zmniejsza ryzyko niewykrywania błędów.
  • Możliwość automatyzacji . Istnieje kilka narzędzi, których możemy użyć do automatyzacji testów. Pomoże nam to osiągnąć maksymalne pokrycie kodu i w krótszym czasie w porównaniu z wykonywaniem testów ręcznie.
  • Skutkuje to wyższą jakością kodu . Programiści mają szansę przestudiować strukturę i implementację kodu oraz naprawić wszelkie błędy, a także poprawić te aspekty. Pozwala nam to pamiętać o świetnej strukturze, pisząc kolejne części kodu lub implementując pozostałe funkcje.
  • Można to zrobić w każdej fazie SDLC - Testy strukturalne można przeprowadzić na każdym etapie SDLC bez czekania, aż programowanie zostanie ukończone w 100%. Ułatwia to identyfikację błędów we wczesnej fazie, a tym samym pozwala zaoszczędzić dużo czasu w porównaniu z testowaniem po zakończeniu projektowania.
  • Pomaga pozbyć się martwego kodu . Może to być postrzegane jako „dodatkowy” lub niepotrzebny kod, na przykład, kod, który obliczy wynik, ale nigdy nie użyje go w żadnym z poniższych obliczeń.
  • Wydajność - Ponieważ programiści piszący kod to ci sami, którzy go testują, nie ma potrzeby angażowania innych osób, takich jak kontrola jakości.

Niedogodności:

  • Programiści, którzy przeprowadzają testy strukturalne, muszą dokładnie rozumieć język . Inni programiści i osoby odpowiedzialne za kontrolę jakości, które nie są dobrze zorientowane w języku, nie mogą pomóc w testowaniu.
  • Może to stać się dość kosztowne pod względem czasu i pieniędzy . Skuteczne przeprowadzanie testów wymaga dużo czasu i zasobów.
  • Powoduje opóźnienia w dostarczaniu funkcji . Dzieje się tak, ponieważ programiści są odciągani od tworzenia oprogramowania do testowania.
  • Skalowanie jest problemem, zwłaszcza w przypadku dużych aplikacji . Duża aplikacja oznacza zbyt dużą liczbę tras do pokonania. Osiągnięcie 100% pokrycia staje się niemożliwe.
  • Mogą wystąpić pominięte przypadki i trasy , na przykład, w przypadku, gdy funkcje nie są w pełni rozwinięte lub nie zostały jeszcze opracowane. Oznacza to, że musi być łączone z innymi typami testów, takimi jak testowanie wymagań (gdzie sprawdzamy określone funkcje, które należało zbudować).

Najlepsze praktyki w testowaniu strukturalnym

Niektóre z czynników, które wymagają uwagi podczas przeprowadzania testów strukturalnych, są następujące:

  • Wyraźnie oznacz i nazwij testy . Jeśli ktoś inny musi przeprowadzić testy, musi mieć możliwość ich łatwego zlokalizowania.
  • Przed ulepszeniem kodu, tj. Jego refaktoryzacją i optymalizacją do użytku w różnych środowiskach, upewnij się, że jego struktura i przepływ są idealne.
  • Uruchom testy oddzielnie . W ten sposób łatwo jest zidentyfikować błędy i je naprawić. Z drugiej strony prawdopodobieństwo pominięcia błędów lub ścieżek jest mniejsze w wyniku nakładania się sekcji kodu, bloków lub ścieżek.
  • Generuj testy przed wprowadzeniem zmian . Testy muszą działać zgodnie z oczekiwaniami. W ten sposób, jeśli coś się zepsuje, łatwo jest wyśledzić i naprawić problem.
  • Przechowuj testy dla każdej sekcji lub bloku kodu oddzielnie . W ten sposób, jeśli w przyszłości nastąpią zmiany, nie będziemy musieli zmieniać wielu testów.
  • Napraw błędy, zanim przejdziesz do testowania . Jeśli zidentyfikujemy jakiekolwiek błędy, lepiej je naprawimy przed przystąpieniem do testowania następnej sekcji lub bloku kodu.
  • Nigdy nie pomijaj testów strukturalnych, zakładając, że osoba zapewniająca jakość „i tak będzie przeprowadzać testy”. Nawet jeśli błędy mogą na początku wydawać się nieistotne, łącznie, mogą skutkować błędnym kodem, który nigdy nie może osiągnąć zamierzonego celu.

Często zadawane pytania dotyczące testowania opartego na strukturze

W tym miejscu przeanalizujemy często zadawane pytania dotyczące testowania opartego na strukturze.

P # 1) Jaka jest różnica między testowaniem funkcjonalnym a testowaniem strukturalnym?

Odpowiedź: Testowanie funkcjonalne to rodzaj testowania oprogramowania oparty na wymaganiach określonych w SRS (Specyfikacje wymagań oprogramowania). Zwykle ma to na celu znalezienie rozbieżności między specyfikacjami w SRS a działaniem kodu. Testowanie strukturalne opiera się na wewnętrznej strukturze kodu i jego implementacji. Wymagane jest dokładne zrozumienie kodu.

P # 2) Jakie są rodzaje testów strukturalnych?

Odpowiedz na typy obejmują:

  • Testowanie przepływu danych
  • Testowanie mutacji
  • Testowanie przepływu kontrolnego
  • Testowanie oparte na wycinkach

P # 3) Co to jest przykład badania strukturalnego?

Odpowiedź: Oto przykład pokazujący zasięg oświadczenia:

const addNums = (num) => { let sum = num.reduce ((a,b) => a+b); if (sum > 0) { alert(sum); } else { alert(‘please enter positive numbers’); } }; addNums();

Wielkość pokrycia, którą otrzymujemy, zależy od danych testowych, które podamy jako dane wejściowe (czy spełniają sumę> 0 warunków).

P # 4) Jaka jest różnica między testowaniem przepływu danych a testowaniem przepływu kontrolnego?

Odpowiedź: Zarówno testowanie przepływu danych, jak i testowanie przepływu sterowania wykorzystują wykresy przepływu sterowania. Jedyna różnica polega na tym, że w testowaniu przepływu sterowania koncentrujemy się na ścieżkach generowanych z kodu, podczas gdy w testowaniu przepływu danych skupiamy się na wartościach danych, ich definicji i wykorzystaniu w ramach ścieżek zidentyfikowanych w programie.

P # 5) Do czego służy testowanie przepływu danych?

Odpowiedź: Testowanie przepływu danych jest idealne do identyfikacji anomalii w wykorzystaniu wartości danych w ścieżkach na wykresie przepływu sterowania, na przykład, jedna zmienna, której dwukrotnie przypisano wartość, zmienna, która została zdefiniowana i nieużywana lub zmienna, która była używana lub do której się odwoływano i nie została zdefiniowana.

Pytanie 6) Jaka jest różnica między krojeniem a krojeniem w testowaniu oprogramowania?

Odpowiedź: Cięcie na plasterki oznacza skupianie się na określonych deklaracjach zainteresowania w programie i ignorowanie pozostałych. Krojenie w kostkę ma miejsce, gdy identyfikujemy plasterek, który ma błędne dane wejściowe, a następnie kroimy go w celu śledzenia prawidłowego zachowania.

P # 7) Jaka jest różnica między testowaniem mutacji a pokryciem kodu?

Odpowiedź: W testowaniu mutacji rozważamy liczbę zabitych mutantów jako procent wszystkich mutantów. Pokrycie kodu to po prostu ilość kodu, który został przetestowany w programie.

Wniosek

W tym samouczku przyjrzeliśmy się dogłębnie testowaniu strukturalnemu - co to jest, czym nie jest, jak się do tego zabrać, typom pokrycia, zaletom i wadom, najlepszym praktykom, a nawet niektórym często zadawanym pytaniom dotyczącym tego typu testowania oprogramowania.

Nadal możemy dowiedzieć się o testowaniu strukturalnym o wiele więcej. W przyszłych samouczkach zbadamy pokrycie kodu (instrukcja, decyzja, gałąź i ścieżka), typy testów strukturalnych (mutacja, przepływ danych i oparte na wycinkach), a nawet narzędzia, których możemy użyć do automatyzacji tych procesów testowych.

Należy zauważyć, że nie ma metody testowania oprogramowania ani podejścia, które byłyby w 100% wydajne. Zawsze wskazane jest łączenie różnych typów testów i podejść.

Na przykład, testowanie strukturalne jest w dużym stopniu uzupełniane przez testowanie wymagań, ponieważ mogą istnieć funkcje, które mogły nie zostać opracowane w czasie, gdy przeprowadzano testy strukturalne.

Techniki testowania strukturalnego opierają się na błędach, które popełniają programiści podczas pisania kodu. Założenie jest takie, że programista jest ekspertem i wie, co koduje, ale od czasu do czasu popełnia błędy.

Różne typy testów strukturalnych, którym przyjrzeliśmy się - testowanie mutacji, testowanie oparte na wycinkach i testowanie przepływu danych można prześledzić wstecz do błędów, takich jak użycie niewłaściwego operatora (testowanie mutacji) lub odwoływanie się do zmiennej przed jej użyciem (testowanie przepływu danych) .

rekomendowane lektury

^