Wyślij zapytanie Dołącz do Sii

Jeśli przygotowujesz się do egzaminu ISTQB z pewnością trafisz na tematykę testowania opartego na strukturze. W dużym uogólnieniu opiera się ono na testowaniu przepływu sterowania i przepływu danych. Przykładowo, dla testowania przepływu sterowania poziomu podstawowego sylabusa, tester będzie sprawdzał instrukcje i decyzje, a dla poziomu zaawansowanego warunki, warunki w decyzjach, zmodyfikowane pokrycie warunków i decyzji, wielokrotne pokrycie warunków i decyzji, testowanie ścieżek i gałęzi. Obydwie techniki wiążą się z projektowaniem i analizą grafów przepływu, będzie więc wymagana przynajmniej podstawowa umiejętność czytania kodu źródłowego i rozpisania go na schematy blokowe. Z pomocą przyjdzie nam wówczas code2flow.

Na potrzeby wpisu skupimy się na podstawowym testowaniu pokrycia instrukcji i decyzji, aby pokazać możliwości aplikacji. W moim odczuciu sylabusy traktują ten temat 'po macoszemu’, opisując go w kilku zdaniach bez odwoływania się do konkretnych przykładów. Aby więc zapoznać się z wyżej wymienionymi technikami, tester musi szukać tej wiedzy na własną rękę, czyli w książkach technicznych, prezentacjach, tutorialach. Moim celem jest pokazać, jak można ułatwić proces nauki tego zagadnienia przy użyciu narzędzia do generowania schematów blokowych. Ale najpierw słów kilka o pseudokodzie i schematach blokowych.

Pseudokod

Pseudokod jest luźnym zapisem imitującym kod. Charakteryzuje się tym, że nie odnosi się bezpośrednio do żadnego języka programowania. Służy do opisania działania danej funkcji lub całego programu. Dobrze sformatowany i opisany pseudokod umożliwia testerowi oprogramowania stworzenie schematu blokowego, dzięki któremu łatwe będzie obliczenie takich metryk jak pokrycie instrukcji, pokrycie decyzji, czy nawet zmodyfikowanego pokrycia warunków i decyzji.

Schematy blokowe

Schemat blokowy to nic innego jak wizualny zapis analizowanego fragmentu kodu/-pseudokodu. Schemat blokowy składa się z bloków instrukcji – dla różnych rodzajów instrukcji bloki mają różne kształty – oraz strzałek, które określają kolejność wykonywania tych instrukcji. Składa się z bloku początkowego, bloku końcowego, bloku wejścia / wyjścia, bloku operacji, procedury, decyzji oraz łączników i punktów koncentracji. W ramach poznawania schematów blokowych, tester oprogramowania powinien znać bloki: początkowe, końcowe, operacji, decyzji oraz punkty koncentracji. Wymagana będzie również znajomość podstawowych instrukcji warunkowych oraz pętli. Wśród nich najważniejsza będą:

  • If
  • If…then
  • for
  • do…while
  • while…do
  • SWITCH-CASE

Narzędzia do generowania schematów blokowych i pseudokodu

Internet obfituje w gotowe rozwiązania, które mogą ułatwić nam naukę tworzenia schematów blokowych oraz czytania pseudokodu. Czynnikami, które brałem pod uwagę podczas swoich poszukiwań były: możliwość darmowego wypróbowania funkcji programu oraz (ewentualnie) łatwość w instalacji. Zarówno popularny Lucidchart, jak i Flowgorithm nie przekonały mnie do siebie, w pierwszym przypadku wymagając wykupienia licencji bez możliwości próbnego wykorzystania funkcji, a w drugim wymagając instalacji oprogramowania na swoim komputerze. Idealnym rozwiązaniem okazała się być internetowa aplikacja code2flow. Można ją znaleźć pod linkiem: code2flow.

Znaczącą zaletą przemawiającą za wybraniem właśnie tego narzędzia był dla mnie fakt, że nie wymaga ona od nas zainstalowania żadnego dodatkowego oprogramowania na komputerze (poza przeglądarką internetową).

Aplikacja składa się z dwóch sekcji. Pierwsza jest edytorem umożliwiającym wprowadzenie pseudokodu. Autor zadbał również o odpowiednie formatowanie tekstu oraz możliwość wpisywania składni, dzięki czemu edytor jeszcze bardziej przypomina IDE.

Możliwości aplikacji

Możliwości edytora mogą kojarzyć się z popularnym językiem znaczników Markdown. Dodatkowo, poza czystym tekstem edytor przyjmuje instrukcje:

  • Instrukcje warunków (if/else if)
  • Słowa kluczowe return
  • Instrukcja switch…case…break
  • Pętle while/for/do i słowa kluczowe goto
  • Funkcje

Umożliwia również komentowanie wybranych linii za pomocą ukośników //. Takie komentarze na schemacie blokowym konwertowane są w ‘chmurki’ zawierające komentowany tekst/linie kodu.

Przydatną możliwością aplikacji może okazać się podświetlanie konkretnych linii kodu na wygenerowanym schemacie blokowym, dzięki któremu nawet osoba bez przygotowania technicznego zobaczy kod i jego wywołania w przystępnej graficznej formie. Użytkownik ma również możliwość dodatkowego dostosowania aspektów kosmetycznych utworzonego grafu w zakładce APPEARANCE oraz możliwość zapisu schematu do formatów: PDFSVGPNG w sekcji DOWNLOAD. Więcej możliwości samego edytora opisane zostało w sekcji HELP. 

code2flow edytor Testing - Tworzenie schematów blokowych i pseudokodu wspomagane narzędziami

Druga sekcja jest stroną wyświetlającą wynik pseudokodu w formie schematu blokowego.

code2flow schemat blokowy Testing - Tworzenie schematów blokowych i pseudokodu wspomagane narzędziami

Schematy blokowe zastosowane w przykładach dalszej części wpisu są wyeksportowane za pomocą aplikacji code2flow. Aplikacja umożliwia również dostosowanie formatu wyświetlanego schematu blokowego oraz jego wydrukowanie. Co ciekawe, istnieje również wersja aplikacji, która integruje się z Jirą, oprogramowaniem do śledzenia błędów i zarządzania projektami. Dla zainteresowanych wypróbowaniem lub wdrożeniem narzędzia do swojego projektu w narzędziu Jira, umieszczam link do Atlassian Marketplace. Jak proces generowania schematu z pseudokodu wygląda w praktyce? Przykłady przedstawię poniżej.

Testowanie pokrycia instrukcji

Pokrycie instrukcji oblicza się przez podzielenie liczby wykonywalnych instrukcji pokrytych przez (zaprojektowane lub wykonane) przypadki testowe, przez liczbę wszystkich wykonywalnych instrukcji w testowanym kodzie. Przepływ powinien przejść przez wszystkie bloki instrukcji pseudokodu najkrótszą drogą.

Przykład 1

int a,b
if (a > 0) {
printf ("a jest dodatnia");
}
if (b > 0) {
printf ("dodatnia");
}
end
przyk1 testowanie instrukcji Testing - Tworzenie schematów blokowych i pseudokodu wspomagane narzędziami

Aby pokryć wszystkie instrukcje tego pseudokodu, wymagany będzie jeden przypadek testowy. Przepływ oznaczono kolorem czerwonym. Dzięki takiemu wizualnemu zapisowi widzimy wszystkie bloki instrukcji zawarte we fragmencie pseudokodu (niebieskie prostokąty).


Przykład 2

int a, b, c, d;
if (a > 0) {
printf ("a jest dodatnia");
if (c==0) {
printf ("c jest równe 0");
}
} else {
printf ("a nie jest dodatnia");
}
if (b > 0) {
printf ("b jest dodatnia");
if (d==0) {
printf ("d jest równe 0");
}
} else {
printf ("b nie jest dodatnia");
}
end
przyk2 testowanie instrukcji Testing.png - Tworzenie schematów blokowych i pseudokodu wspomagane narzędziami

Aby w pełni pokryć instrukcje w pseudokodzie, wymagane będą dwa przypadki testowe. Pierwszy przepływ oznaczono kolorem czerwonym i obejmuje on bloki instrukcji dla warunków True, drugi zaś kolorem niebieskim i obejmuje on bloki instrukcji dla warunków False.

Uwaga: Wyjątkiem tutaj są warunki False dla (c==0) orac (d==0), które nie posiadają bloków instrukcji!


Przykład 3

int x, a;
while (x <=a) {
printf ("x nie jest więsze od a");
x = x+1;
}
printf ("x jest więsze od a");
end
przyk3 testowanie instrukcji Testing.png - Tworzenie schematów blokowych i pseudokodu wspomagane narzędziami

Aby w pełni pokryć instrukcje w pseudokodzie, wymagany będzie jeden przypadek testowy. Pętla wykonywana jest jednorazowo. Jej wykonanie pozwala w pełni pokryć wszystkie bloki instrukcji za jednym przejściem (kolor czerwony).

Testowanie pokrycia decyzji

Pokrycie decyzji, spokrewnione z testowaniem gałęzi, polega na zmierzeniu jaki odsetek wyników decyzji (np. wyniku prawda lub fałsz instrukcji if) został przetestowany przez zestaw testów. W technice testowania decyzji projektuje się przypadki testowe tak, aby pokryć określone wyniki decyzji. Jest wyliczane przez podzielenie liczby wyników decyzji pokrytych przez (zaprojektowane lub wykonane) przypadki testowe przez liczbę wszystkich wyników decyzji znajdujących się w testowanym kodzie.

Testowanie decyzji jest jedną z form testowania przepływu sterowania, ponieważ podąża za konkretnym przepływem sterowania przez punkty decyzyjne. Pokrycie decyzji jest mocniejsze niż pokrycie instrukcji. 100% pokrycia decyzji gwarantuje 100% pokrycia instrukcji, ale nie odwrotnie. Widać to wyraźnie w przykładach poniżej, gdzie podczas testowania decyzji brane są pod uwagę wszystkie bloki instrukcji.

Przykład 1

int a,b;
if (a > 0) {
printf ("a jest dodatnia");
}
if (b > 0) {
printf ("b jest dodatnia");
}
end
przyk1 testowanie decyzji Testing - Tworzenie schematów blokowych i pseudokodu wspomagane narzędziami

Do pełnego pokrycia decyzji będą wymagane dwa przypadki testowe. Pierwszy przypadek testowy pokrywa wszystkie bloki instrukcji (kolor czerwony) dla warunków True, a drugi przypadek testowy pokrywa warunki False dla decyzji (kolor niebieski).


Przykład 2

int a, b, c, d;
if (a > 0) {
printf ("a jest dodatnia");
if (c==0) {
printf ("c jest równe 0");
}
} else {
printf ("a nie jest dodatnia");
}
if (b > 0) {
printf ("b jest dodatnia");
if (d==0) {
printf ("d jest równe 0");
}
} else {
printf ("b nie jest dodatnia");
}
end
przyk2 testowanie decyzji Testing.png - Tworzenie schematów blokowych i pseudokodu wspomagane narzędziami

Do pełnego pokrycia decyzji będą wymagane trzy przypadki testowe. Pierwszy przepływ (kolor czerwony) pokrywa wszystkie bloki instrukcji i warunki True dla decyzji. Drugi przepływ (kolor niebieski) pokrywa wszystkie bloki instrukcji dla warunku False, z wyłączeniem warunku False dla instrukcji (c==0) i (d==0), które nie mają bloków instrukcji. Trzeci przypadek testowy pokrywa wspomniane warunki False dla instrukcji (c==0) i (d==0) (kolor żółty).


Przykład 3

int x, a;
while (x <=a) {
printf ("x nie jest więsze od a");
x = x+1;
}
printf ("x jest więsze od a");
end
przyk3 testowanie decyzji Testing.png - Tworzenie schematów blokowych i pseudokodu wspomagane narzędziami

Podobnie jak w przypadku testowania instrukcji, przez pętle poruszamy się jednokrotnie, a więc dla wymienionego przypadku wymagany będzie jeden przypadek testowy (kolor czerwony). W przypadku, kiedy pętla byłaby zagnieżdżona w warunku wielokrotnego wyboru jak SWITCH-CASE, liczba przypadków testowych wymaganych do pokrycia decyzji wzrośnie.

Podsumowując, uważam, że warto zainteresować się aplikacją code2flow. Przyznaję, że celowo zostawiam pewien niedosyt, aby zachęcić Was do wypróbowania działania aplikacji w praktyce, poeksperymentować z zagnieżdżaniem warunków i pętli. Jestem pewien, że w ten sposób szybciej opanujecie tworzenie pseudokodu, czytanie schematów blokowych oraz obliczanie pokrycia kodu. Jednocześnie, opanowanie tego materiału może zapewnić wam zaliczenie podczas egzaminu ISTQB, czego Wam z tego miejsca życzę.


Chcesz lepiej zrozumieć aplikacje i systemy, które testujesz? Dołącz do ModernTester, poznaj najpotrzebniejsze narzędzia, frameworki oraz języki programowania i ćwicz na specjalnie przygotowanych środowiskach testowych: Platforma e-learningowa ModernTester

4.7/5 ( głosy: 14)
Ocena:
4.7/5 ( głosy: 14)
Autor
Avatar
Remigiusz Bednarczyk

W Sii pracuję jako Test Development Engineer. Jestem Test Leadem w dwóch projektach związanych z procesowaniem ETL. Na codzień pracuję z zespołami ulokowanymi w USA, Szwajcarii i w Polsce, co wiąże się z wyzwaniami zarówno w komunikacji, jak i ze zwiększonymi oczekiwaniami ze strony klienta. Testowanie oprogramowania jest jednocześnie moją pasją, którą staram się nieustannie rozwijać i dzielić z innymi jako trener techniczny, twórca szkoleń e-learningowych i rekruter. W wolnym czasie angażuję się w rozwój lubelskiej grupy biegaczy Sii, oraz zajmuję się treningiem metodą Hardstyle Kettlebell wg. metody Pavela Tsatsouline'a.

Zostaw komentarz

Anuluj pisanie odpowiedzi

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

    1. Cześć! Dzięki za bardzo trafne pytanie. Bardziej rozbudowane pętle jak ta, o której napisałeś są przedmiotem Zaawansowanego Poziomu ISTQB Techniczny Analityk Testowy. Dla do…while w wybranej instukcji warunku jedną z decyzji będzie wykonanie pewnej zadeklarowanej instukcji, po czym wrócenie PRZED tę instrukcje warunku. Wobec tego takim sprawdzeniem ścieżka zwróci nas do punktu wyjściowego przed dany warunek. Dalej będzie obowiązywała nas zasada jak najbardziej optymalnego jednego przejścia – będziemy więc kontynuować sprawdzenie idąc po pozostałych decyzjach. Podobnie inne pętle rządzą się swoimi prawami, jednak zapis dwuwymiarowy daje nam pewną łatwość w ich interpretacji. Dla lepszego zaobrazowania polecam np. publikację „Zapis algorytmów: schematy blokowe i pseudokod”.

Może Cię również zainteresować

Pokaż więcej artykułów

Bądź na bieżąco

Zasubskrybuj naszego bloga i otrzymuj informacje o najnowszych wpisach.

Otrzymaj ofertę

Jeśli chcesz dowiedzieć się więcej na temat oferty Sii, skontaktuj się z nami.

Wyślij zapytanie Wyślij zapytanie

Natalia Competency Center Director

Get an offer

Dołącz do Sii

Znajdź idealną pracę – zapoznaj się z naszą ofertą rekrutacyjną i aplikuj.

Aplikuj Aplikuj

Paweł Process Owner

Join Sii

ZATWIERDŹ

This content is available only in one language version.
You will be redirected to home page.

Are you sure you want to leave this page?