Hejo,
Chyba jeszcze nie zdarzyło się, żebym publikował więcej, niż jeden post dziennie. Jesienna chandra, piąteczek oraz chęć przelania wiedzy tak, by móc ją usystematyzować są znacznie większe, niźli chęć wyjścia nawet na basen. #jakzostacnerdem
Żeby nie zwalniać będziemy kontynuować przyjęty wcześniej schemat. Cele nauczania i bezpośrednia odpowiedź. W tym poście zajmiemy się technikami projektowania samych testów, także będzie ciekawiej, niż poprzednio (chociaż w praktyce jest na odwrót).
Kandydat odróżnia projekt testów od specyfikacji przypadków testowych oraz od procedury testowej, potrafi porównać następujące pojęcia: warunek testowy, przypadek testowy, procedura testowa oraz potrafi ocenić jakość przypadków testowych, przez sprawdzenie czy mają one jednoznaczne powiązania z wymaganiami oraz czy zawierają wynik oczekiwany. Ponadto kandydat potrafi utworzyć z przypadków testowych dobrze ustrukturalizowaną procedurę testową na poziomie szczegółowości odpowiadającym wiedzy testerów.
Okay. Wiem, że cel pomimo tego, że opisany został konkretnie jest sporych rozmiarów. Dlatego przewrotnie proponowałbym obejrzeć film nt. przypadków testowych, który zamieszczę poniżej (zamieszczałem go również we wcześniejszych postach). Oczywiście niezbędna będzie znajomość angielskiego przynajmniej na poziomie B2 ale w tej branży bez tego języka imho nie ma sensu się wkręcać.
via. guru99
via software test training
Oczywiście ja sam rozpiszę się trochę dla czystego egoizmu i potrzeby poukładania sobie w głowie zdobytej niedawno wiedzy. Chciałbym tylko zaznaczyć, iż proces rozwoju testów, jaki przedstawię, to ten, na jakim opiera się sylabus ISTQB. Sam proces zazwyczaj wygląda przyjemniej, jest mniej formalny (zwłaszcza przy zgranym teamie) ale myślę, że warto znać pewien schemat, który jest zazwyczaj schematem wyjściowym znacznie zwiększającym produktywność wykonywanej przez team pracy.
Jak wiadomo podczas analizy testów przeglądana (baaardzooo dokładnie) jest dokumentacja podstawy testów w celu określenia co należy przetestować - czyli warunków testowych. Warunek testowy będziemy definiować zatem jako element lub zdarzenie, które może zostać sprawdzone przez jeden lub więcej przypadków testowych (np. funkcja, atrybut jakościowy, element struktury etc.).
Podczas projektowania testów tworzy się i opisuje przypadki testowe i dane testowe. Przypadek testowy składa się ze zbioru wartości wejściowych, warunków wstępnych, oczekiwanych wyników oraz warunków zakończenia utworzonych żeby pokryć pewne cele testów lub warunki testowe.
Przykład wymagania funkcjonalnego (testerzy.pl)
Przykład przypadku testowego bazującego na tabeli powyżej (testerzy.pl)
Jako część specyfikacji przypadku testowego powinny zostać określone wyniki oczekiwane (patrz tabela powyżej). Powinny one zawierać opis wyjść, zmian w danych i stanie oprogramowania oraz inne skutki testu. Gdy wyniki oczekiwane nie są zdefiniowane, może się zdarzyć, że wiarygodne ale błędne wyniki zostaną uznane za poprawne!
Oczywiście podczas implementacji testów przypadki testowe są rozwijane, priorytetyzowane oraz układane w specyfikację procedur testowych. Procedury te zawierają kolejności działań podczas wykonywania testów. Jeżeli testy wykonywane są przy pomocy narzędzia do wykonywania testów, ciąg akcji jest zawarty w skrypcie testowym. Przy tworzeniu harmonogramu wykonywania testów bierze się pod uwagę takie czynniki jak testy regresywne, priorytety oraz zależności techniczne i logiczne.
Kandydat pamięta do czego przydatne są techniki projektowania testów oparte na specyfikacji (czarnoskrzynkowe) oraz techniki oparte na strukturze (białoskrzynkow) oraz potrafi wymienić typowe dla nich techniki. Potrafi również objaśnić cechy, podobieństwa oraz różnice pomiędzy technikami opartymi na specyfikacji, strukturze i doświadczeniu.
Celem technik projektowania testów jest oczywiście zdefiniowanie warunków, przypadków i danych testowych.
Klasyczny podział wyróżnia techniki czarnoskrzynkowe oraz białoskrzynkowe.
Czarnoskrzynkowe techniki projektowania testów są sposobem na wywodzenie oraz wybieranie warunków testowych, przypadków testowych i danych testowych bazującym na analizie podstawy testów. Można ich używać zarówno w testowaniu funkcjonalnym, jak i niefunkcjonalnym. Techniki czarnoskrzynkowe z definicji nie wykorzystują żadnych informacji o strukturze wewnętrznej testowanego modułu lub systemu.
via guru99
Białoskrzynkowe techniki projektowania testów (również nazywane strukturalnymi lub technikami opartymi na strukturze) bazują na analizie struktury modułu lub systemu.
via guru99
Zarówno testy biało i czarnoskrzynkowe mogą korzystać z doświadczenia programistów, testerów i użytkowników w celu określenia CO powinno zostać przetestowane. Niektóre techniki da się przyporządkować jednoznacznie do jednej kategorii, niektóre jednak zawierają elementy więcej niż jednej kategorii.
Warto wiedzieć, że cechą wspólną testów opartych stricte na specyfikacji jest to, iż w specyfikacji problemu do rozwiązania, oprogramowania lub jego komponentów używane są modele, a z nim można w sposób usystematyzowany wywodzić przypadki testowe.
Cechy wspólne technik projektowania testów opartych na strukturze jest to, iż do tworzenia przypadków testowych wykorzystywana jest wiedza o tym, jak oprogramowanie jest skonstruowane (np. kod źródłowy). Cechą wspólną jest również to, że można mierzyć stopień pokrycia istniejących przypadków testowych, można też w sposób usystematyzowany tworzyć nowe przypadki testowe w celu zwiększenia pokrycia.
Cechy wspólne technik projektowania testów opartych na doświadczeniu to:
- przede wszystkim do tworzenia przypadków testowych niezbędna jest zaawansowana wiedza oraz doświadczenie ludzi biorących udział w projekcie tj:
> wiedza testerów, programistów, użytkowników o oprogramowaniu, jego środowisku i sposobie użytkowania,
> wiedza o prawdopodobnych defektach i ich położeniu (tak, z czasem zaczniecie zauważać, że jest wiele defektów, które są typowe dla danego poziomu testów, praktyka czyni mistrza!).
Kandydat potrafi napisać przypadki testowe na podstawie podanych modeli oprogramowania używając techniki klas równoważności, analizy wartości brzegowych, testowania w oparciu o tablicę decyzyjną, testowania przejść pomiędzy stanami. Potrafi również wyjaśnić główny cel każdej z czterech technik testowania, to na jakim poziomie testowania mogą zostać użyte i jak mozna dla nich zmierzyć pokrycie. Poza tym wie, jak wyjaśnić na czym polega testowanie w oparciu o przypadki użycia i korzyści płynące z jego zastosowania.
Tutaj warto się skupić, ponieważ wiedza z tego fragmentu jest niezbędna i będzie przewijać się praktycznie ciągle podczas waszych przyszłych doświadczeń. Podobnie będzie zresztą z następnym celem sylabusa. Obejrzyjcie również materiał z YouTube, który zamieściłem powyżej, myślę, że fajnie wprowadzi Was w kwestię technik czarnoskrzynkowych. Polecam również obejrzeć każdy z materiałów, jakie zamieściłem do każdego z opisu technik czarnoskrzynkowych :) Chyba lepiej słuchać, niż czytać, co nie?
Podział na klasy równoważności (Equivalence Partiotioning)
via guru99 (jest tutaj również wyjasnione BVA, o którym szerzej poniżej)
W tej technice wejścia programu lub systemu są dzielone na grupy, które powodują podobne zachowanie oprogramowania, więc wysoce prawdopodobne jest to, że są przetwarzane w ten sam sposób. Klasy równoważności można znaleźć dla danych poprawnych (dane akceptowalne przez oprogramowanie), jak i dla danych niepoprawnych (dane odrzucone). Klasy równoważności można znaleźć również dla wyjść, wartości wewnętrznych, wartości zależnych od czasu oraz parametrów interfejsów.
Testy można tak zaprojektować, żeby pokrywały akceptowalne i nieakceptowalne klasy równoważności. Technikę tę można zastosować na każdym poziomie testowania.
Zajrzyj również tutaj.
Analiza wartości brzegowych (Boundary Value Analysis)
BVA
Istnieje większe prawdopodobieństwo, że software będzie się błędnie zachowywać dla wartości krawędziach klas równoważności, niż w ich środku, więc testowanie tych obszarów najprawdopodobniej wykryje błędy. Minimum i maksimum klasy równoważności to jej wartości brzegowe. Testy można zaprojektować tak, aby pokrywały zarówno poprawne, jak i niepoprawne (wartość brzegowa niepoprawnego przedziału) wartości brzegowe.
Analiza wartości brzegowych może zostać zastosowana na każdym poziomie testowania. Technika ta jest często uważana za rozwinięcie techniki podziału na klasy równoważności.
Testowanie w oparciu o tablicę decyzyjną (Decision Table Testing)
via. guru99
Tablice decyzyjne są b. dobrym sposobem na uchwycenie tych wymagań na system, które zawierają zależności logiczne, oraz na udokumentowanie wewnętrznej budowy systemu. Mogą być używane do zapisywania złożonych reguł biznesowych, które system ma obsługiwać.
Podczas tworzenia tablic decyzyjnych analizuje się specyfikację systemu i wyszukuje warunki oraz wynikające z nich zachowanie systemu. Warunki wejściowe oraz zachowanie systemu często muszą być zapisane jako prawda lub fałsz (funkcja Boolean - jeśli sprawdzałeś kurs MySQL na moim blogu to teraz pewnie uśmiechasz się tak szeroko, jak ja). Właśnie stąd nazwa - tabela decyzyjna, bo zawiera warunki uruchamiające, często jako kombinacje prawy (1) i fałszu (0) oraz wszystkich warunków wejściowych oraz działania oprogramowania wynikające z każdej z tych kombinacji :)
Standardowe pokrycie stosowane dla testowania w oparciu o tabelę decyzyjną wymaga zaprojektowania jednego testu dl każdej kolumny w tablicy, co zwykle oznacza wykorzystanie wszystkich kombinacji warunków uruchamiających.
Testowanie przejść między stanami (State Transition Testing)
via guru99
System może różnie odpowiadać w zależności od aktualnych warunków oraz od jego stanu. W takim przypadku zachowanie systemu można opisać diagramem przejść stanów. Pozwala to testerowi spojrzeć na oprogramowanie od strony stanów, przejść między stanami, wejść lub zdarzeń, które powodują zmiany stanów (przejścia) oraz na działania, które mogą wynikać z tych przejść. Stany testowanego systemu są rozdzielne, zdefiniowane oraz ich liczba jest skończona.
Testy można zaprogramować tak, żeby pokrywały typowe sekwencje stanów, każdy stan, każde przejście, konkretny ciąg przejść lub żeby testowały przejścia nieprawidłowe.
Testowanie przejść między stanami jest często używane w testowaniu oprogramowania wbudowanego oraz ogólnie w automatyce.
Testowanie w oparciu o przypadki testowe
via guru99
Testy można projektować na podstawie przypadków użycia. Przypadek użycia opisuje interakcje pomiędzy aktorami (użytkownikami bądź systemami), które powodują powstanie wyniku wartościowego z punktu widzenia użytkownika lub klienta. Przypadek użycia może być opisany na wysokim poziomie abstrakcji lub na poziomie systemowym. Każdy przypadek użycia posiada warunki wstępne, które muszą zostać spełnione, żeby przypadek użycia został wykonany. Każdy przypadek użycia kończy się warunkami końcowymi. Przypadki użycia zwykle posiadają scenariusz główny (ten najbardziej prawdopodobny) oraz czasami scenariusze poboczne.
Co ważne i ciekawe to to, że przypadki użycia opisują 'przepływy' procesu przez system bazując na najbardziej prawdopodobnym rzeczywistym jego użyciu, co sprawia, że przypadki testowe wywiedzione z przypadków użycia najbardziej przydają się w wyrywaniu usterek w przepływach praocesów z rzeczywistego użytkowania systemu. Przydatne jest to przy testach akceptacyjnych, w których ma brać udział klient.
============
Kandydat potrafi opisać pojęcie pokrycia kodu u jego znacznie. Potrafi wyjaśnić pojęcia takie jak pokrycie instrukcji i pokrycie decyzji oraz podać powody, dla których te pojęcia mogą zostać użyte nie tylko na poziomie testów modułowych ale też np. dla procedur biznesowych. Potrafi napisać przypadki testowe dla danych przepływów sterowania stosując techniki testowania instrukcji i testowania decyzji. Potrafi też ocenić kompletność testów wg. zdefiniowanych kryteriów zakończenia na podstawie pokrycia instrukcji i decyzji.
No dobrze, po opisie technik czarnoskrzynkowych przejdziemy do technik białoskrzynkowych. Tak, jak w przypadku technik czarnoskorzynkowych i tutaj będę podawać materiały z YouTube, które wg. mnie lepiej wyjaśniają poszczególne kwestie :) Zacznijcie zatem najpierw od fajnego wprowadzenia (po raz kolejny) w świat technik opartych na strukturze kodu software'u.
via. guru99
Testowanie oparte na strukturze bazuje na rozpoznanej strukturze oprogramowania lub systemu. Przykładami takich struktur są:
- testy modułowe: kod, to jest instrukcje, decyzje, rozgałęzienia lub rozróżnialne ścieżki,
- w testach integracyjnych strukturą może być hierarchia wywołań - diagram, który pokazuje jak moduły wywołują moduły,
- w testach systemowych strukturą może być budowa menu, proces biznesowy lub struktura strony www.
Testowanie i pokrycie instrukcji.
Materiał jest długi ale warto go obejrzeć, ponieważ działając na wyobraźnie fajnie 'rozrysuje' Wam to czym są schematy blokowe, algorytmy i to w jaki sposób działają i oczywiście czym jest to pokrycie instrukcji ;)
W testowaniu instrukcji stosuje się pokrycie instrukcji, które polega na zmierzeniu, jaki odsetek instrukcji wykonywalnych został przetestowany przez zestaw testów. W technice tej projektuje się przypadki testowe, tak by wykonać określone instrukcje, zwykle po to, żeby zwiększyć pokrycie.
Pokrycie instrukcji oblicza się przez podzielenie liczby wykonywalnych instrukcji pokrytych przez przypadki testowe, przez liczbę wszystkich wykonywalnych instrukcji w testowanym kodzie.
Testowanie i pokrycie decyzji
Pokrycie decyzji (spokrewnione z testowaniem gałęzi) polega na zmierzeniu jaki odsetek wyników decyzji (np. wyniku true or false w instrukcji if) został przetestowany przez zestaw testów. W technice testowania decyzji projektuje się przypadki testowe tak, aby pokryć określone wyniki decyzji. Gałęzie zaczynają się w punktach decyzyjnych i pokazują przekazanie sterowania do różnych miejsc w kodzie. Testowanie decyzyjne skupia się tylko na samych gałęziach, w przeciwieństwie do testowania instrukcji, które skupia się również na mierzalności instrukcji.
Pokrycie decyzji jest wyliczane przez podzielenie liczby wyników decyzji pokrytych przez przypadki testowe przez liczbę wszystkich wyników decyzji znajdujących się w testowanym kodzie.
Należy pamiętać, iż 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. Sto% pokrycia decyzji gwarantuje sto% pokrycia instrukcji ale nie odwronie!
Inne techniki oparte na strukturze
Istnieją techniki jeszcze mocniejsze, niż pokrycie decyzji - na przykład pokrycie warunków lub wielokrotne pokrycie warunków.
Pojęcie pokrycia może zostać również zastosowane na innych poziomach testowania. Na przykład w testowaniu integracyjnym odsetek modułów, komponentów lub klas, które zostały przetestowane przez zestaw testów można wyrazić jako pokrycie modułów, komponentów lub klas.
===================
Kandydat pamięta powody pisania przypadków testowych opierających się na intuicji, doświadczeniu oraz wiedzy na temat często spotykanych usterek. Potrafi również porównywać techniki oparte na doświadczeniu z technikami opartymi na specyfikacji.
Testowanie oparte na doświadczeniu
Mamy z nim styczność wtedy, kiedy testy projektuje się na podstawie wiedzy i intuicji testerów (wow!) oraz ich doświadczenia z podobnymi aplikacjami i technologiami. Zaleca się, aby zostało użyte jako uzupełnienie technice systematycznych zaraz po nich, co może okazać się użyteczne w uchwyceniu specjalnych przypadków testowych, których nie da się łatwo zaprojektować używając technik formalnych. Należy pamiętać, że skuteczność testowania oparta jest na doświadczeniu testerów ;)
Szeroko wykorzystywaną technika opartą na skillu jest zgadywanie błędów. Testerzy przewidują usterki bazując na autopsji. Ustrukturalizowane podejście do zgadywania błędów polega na sporządzeniu listy możliwych defektów i zaprojektowaniu testów, które atakują te defekty. To systematyczne podejście jest nazywane atakiem usterkowym.
Testowanie eksploracyjne polega na równoległym projektowaniu testów, ich wykonaniu, zapisaniu wyników i uczeniu się, bazując na zamówieniu na testy zawierającym cele testów i trzymając się ram czasowych. To podejście okazuje się najpożyteczniejsze, gdy nie ma specyfikacji albo jest ona niekompletna, bądź przestarzała, również w sytuacjach bardzo krótkiego czasu na testy.
===================
Kandydat potrafi podzielić techniki projektowania testów według ich dopasowania do danego kontekstu, podstawy testowania, modeli oraz cech oprogramowania.
Wybór, która technika testowania powinna zostać użyta zależy od wielu czynników - są to czynniki tj. wybór systemu, regulacji prawnych, wymagań klienta lub kontraktu, poziom ryzyka, typu ryzyka, celu testów, dostępnej dokumentacji, wiedzy testerów, czasu i budżetu, cyklu rozwoju oprogramowania, modelu przypadków użycia oraz doświadczenia zwiazanego ze znajdowanymi typami usterek.
Niektóre z technik można z większą korzyścią zastosować tylko na niektórych poziomach testowania. Inne techniki można z równym powodzeniem stosować na wszystkich poziomach testów.
Podczas projektowania przypadków testowych testerzy zwykle stosują różne techniki projektowania testów - włącznie z technikami opartymi na procesie, regułach oraz danych, po to żeby zapewnić odpowiednie pokrycie testowanego obiektu.
==================
Dzięki za kolejną część przejścia przez ISTQB FL. Starałem się trzymać bardzo mocno sylabusa, jednak uzupełniłem wiedzę o materiały, które wg. mnie przedstawiają problem bardziej dostępnie i poglądowo.
Dzięki śliczne!
Na dzisiaj mam fajrant. Wracam jutro z rana ^_^
F.
Brak komentarzy:
Prześlij komentarz