Techniki projektowania testów

Ważnym elementem testowania jest przygotowanie dobrych testów. Mogą to być testy eksploracyjne, mogą równie dobrze być przypadki testowe. Dojrzali testerzy stosują w tym celu dobre praktyki opisane jako techniki, które pomagają definiować co i jak należy testować.

Identyfikowanie co należy przetestować i projektowanie testów

Procedura przygotowania testów może wyglądać następująco:

identyfikacja elementów do poddania testom,
projektowanie testów,
tworzenie scenariuszy lub procedur testowych.

Może być ona wykonana na różne sposoby, od bardziej nieformalnych z niewielką ilością dokumentacji po bardzo formalne z notacją w postaci przypadków testowych. Poziom formalizmu zależy od kontekstu organizacji samego testowania i uwzględnia firmę, dojrzałość procesów testowania i programowania, ramy czasowe, zaangażowanych ludzi, itd.

Podczas projektowania testów dokumenty specyfikujące oprogramowanie muszą zostać przeanalizowane w celu określenia co należy przetestować, np. zidentyfikowanie idei (warunków) testowych. Idee te definiuje się jako pojedyncze elementy lub zdarzenia, które mogą być weryfikowane przez jeden lub więcej testów. Możemy testować funkcje, transakcje, atrybuty jakości lub element struktury białoskrzynkowej (kodu lub architektury).

Powiązanie warunków testowych ze specyfikacją i wymaganiami umożliwia nam analizę wpływu zmiany wymagań na konieczność zmiany specyfikacji testów. Dzięki określeniu mapowania testów na wymagania możemy również sprawdzić poziom pokrycia obiektu testów przez zbiór testów. Podczas projektowania testów używamy konkretnych metod i technik testowych.

Gdy decydujemy się na specyfikowanie przypadków testowych wraz z danymi testowymi, to mogą one być tworzone i rozwijane poprzez stosowanie konkretnych technik projektowania testów. Przypadki testowe zawierają zestaw wartości wejściowych, warunki wykonania testów, oczekiwany rezultat i warunki po wykonaniu testu, stworzone dla pokrycia konkretnych warunków (idei) testowych. Normy IEE829 i ISO 29119 opisują zawartość specyfikacji testowej oraz specyfikacji przypadków testowych.

Oczekiwany rezultat powinien być częścią specyfikacji przypadku testowego i zawierać wyniki, zmiany danych lub stanów i/lub inne konsekwencje wykonania testu. W przypadku, gdy oczekiwany rezultat nie został zdefiniowany, pożądany, ale potencjalnie niosący błędy rezultat może być interpretowany jako poprawny. Oczekiwany rezultat powinien być zdefiniowany przed wykonaniem testu.

Przypadki testowe ułożone są w porządku ułatwiającym ich wykonanie, zgodnie z wyspecyfikowaną procedurą testową. Taka procedura (scenariusz lub manualny skrypt testowy) definiuje sekwencję akcji potrzebną do wykonania całego zbioru testów. W przypadku jeśli test wykonywany jest automatycznie, sekwencja akcji zostaje opisana w skrypcie testowym (który jest zautomatyzowaną procedurą testową).

Dla pojedynczej wersji oprogramowania różne procedury testowe i zautomatyzowane skrypty testowe są formowane w plan wykonania testów, definiujący kolejność ich wykonania. Określa on kiedy i przez kogo procedury testowe i ewentualnie zautomatyzowane skrypty testowe są uruchamiane. Plan wykonania testów rozważa różne czynniki takie jak testy regresyjne, priorytety oraz techniki i ich logiczne zależności.

Kategorie technik projektowania testów

Celem technik projektowania testów jest identyfikacja warunków i idei testowych, a docelowo przypadków testowych. Klasycznym rozróżnieniem znanym z ISTQB jest określenie technik testów jako czarnoskrzynkowych lub białoskrzynkowych. Czarnoskrzynkowe techniki (nazywane również technikami bazującymi na specyfikacji) są metodą definiowania i wybierania warunków testowych lub przypadków testowych odwołujących się do analizy podstawowych dokumentów opisujących funkcjonalność oraz atrybuty niefunkcjonalne, dla komponentu lub systemu. Cechą charakterystyczną tego zbioru metod jest nieodwoływanie się do wewnętrznej struktury oprogramowania. Nie wiemy więc co dzieje się „w środku”, a analizujemy jedynie zewnętrzne interfejsy. Białoskrzynkowe techniki (nazywane technikami strukturalnymi lub bazującymi na strukturze) oparte są na analizie wewnętrznej struktury komponentu lub systemu.

Techniki czarnoskrzynkowe i oparte na specyfikacji bazują na modelu oprogramowania lub jego komponentach, zarówno formalnych jak i nieformalnych. Są używane do specyfikowania zagadnienia, które musi zostać rozwiązane poprzez testy. Dzięki modelom testy mogą być tworzone systematycznie, co oznacza, że możemy uzyskać 100% pokrycie dla modelu.

W technikach białoskrzynkowych i opartych na strukturze informacja o tym jak oprogramowanie jest skonstruowane (kod, architektura) używana jest do tworzenia testów. Poziom pokrycia oprogramowania może zostać zmierzony dla już zdefiniowanych testów, a jeśli nie osiąga 100%, testy można projektować dalej. Dzięki dalszemu tworzeniu można systematycznie zwiększać pokrycie kodu lub architektury.

Do tak zdefiniowanych kategorii nie da się łatwo przypisać technik. Często pojedyncza technika może być stosowana do wielu „skrzynek”. Czasami więc pojawia się dodatkowa kategoria technik szaroskrzynkowych, czyli czegoś pomiędzy białą a czarną skrzynką.

Do wcześniej zdefiniowanych technik możemy jeszcze dopisać techniki bazujące na doświadczeniu i wiedzy ludzi. Używamy ich do tworzenia testów, które nie są oczywiste przy użyciu powyżej opisanych technik. Wiedza testerów, programistów, użytkowników lub innych uczestników procesu dostarczania oprogramowania może pomagać definiować nieoczywiste testy. Znajomość tego jak używa się oprogramowania i w jakim środowisku pracy oraz wiedza o możliwych defektach i ich efektach pozwalają wyjść poza ścisłe ramy podstawowych technik.

Przypadki testowe oparte na specyfikacji lub czarnoskrzynkowe

Partycje (klasy) równoważne

Dane wejściowe do oprogramowania lub systemu są podzielone na grupy, dla których można zdefiniować oczekiwane, podobne zachowanie systemu. Równoważne partycje (lub klasy) mogą być określone dla poprawnych i niepoprawnych danych np. danych, które powinny być odrzucone. Partycje mogą zostać zidentyfikowane dla danych wyjściowych, wewnętrznych wartości, wartości powiązanych z czasem (np. przed lub po zdarzeniu) i dla parametrów interfejsu (np. podczas testów integracji). Testy są zaprojektowane w celu jak najpełniejszego pokrycia partycji. Równoważne partycje mogą występować na wszystkich poziomach testowania.

Równoważna partycja jako technika może być użyta w celu osiągnięcia pokrycia wejść i wyjść. Może zostać zastosowana dla danych wprowadzanych przez użytkownika, danych wejściowych podawanych poprzez interfejsy do systemu lub dla parametrów interfejsów podczas testowania integracji.

Więcej o klasach równoważności:

http://testerzy.pl/baza-wiedzy/klasy-rownowaznosci-1

Analiza wartości granicznych

Zachowanie na każdej z krawędzi partycji w wielu przypadkach jest niepoprawne, więc granice są obszarami, gdzie testowanie może wykryć defekty. Wartości minimalna i maksymalna partycji są jego wartościami granicznymi. Wartość graniczna dla poprawnej partycji jest poprawną wartością graniczną i, odpowiednio dla niepoprawnej, jest niepoprawną wartością graniczną. Testy mogą być zaprojektowane dla pokrycia obu wartości.

Podczas tworzenia przypadku testowego wybierana jest wartość dla każdej granicy.

Analiza tego rodzaju może pojawić się na wszystkich poziomach testowych. Jest relatywnie prosta do zastosowania, a jej zdolność do znajdywania defektów jest bardzo wysoka. Pomaga w tym szczegółowa specyfikacja.

Technika ta jest często postrzegana jako rozszerzenie równoważnych partycji i może zostać użyta w celu zarówno zdefiniowana danych wprowadzanych przez człowieka, jak i dla czasów odpowiedzi czy granicznych wartości tabeli. Pogłębiona analiza specyfikacji pomaga dobierać dane testowe.

Czasami technikę rozszerza się jeszcze dodatkowo o weryfikację danych po obu stronach granicy. W takim przypadku mówimy o analizie trójwartościowej.

Więcej o analizie wartości granicznych:

Analiza tablicy decyzji

Tablice decyzyjne są stosowane w definiowaniu wymagań systemowych, gdzie opisane są warunki logiczne i udokumentowana jest wewnętrzna struktura systemu. Mogą one zostać użyte do zapisu skomplikowanych zasad biznesowych produkowanego systemu. Specyfikacja jest analizowana, a warunki i akcje systemu są identyfikowane. Warunki wejściowe i akcje są często deklarowane jako "prawda" lub "fałsz". Tablica decyzyjna zawiera warunki rozpoczęcia (często kombinację "prawdy" i "fałszu") dla konkretnych danych wejściowych i reakcję dla każdej kombinacji warunków. Każda kolumna tabeli związana jest z zasadą biznesową, definiującą unikalną kombinację warunków jakie wynikają z wykonania akcji powiązanej z zasadą. Standardowym pokryciem używanym w testowaniu za pomocą tabeli decyzji jest osiągnąć przynajmniej jeden test w kolumnie, co zasadniczo zawiera pokrycie wszystkich kombinacji dla warunków uruchomienia.

Zaletą testowania z użyciem tabeli decyzji jest to, że tworzy ona kombinację warunków, które nie mogą w inny sposób zostać wykonane podczas testów. Tabela decyzji może być zastosowana we wszystkich sytuacjach kiedy akcja oprogramowania zależy od wielu logicznych decyzji.

Więcej o tablicach decyzyjnych:

http://testerzy.pl/baza-wiedzy/optymalizowanie-tablic-decyzyjnych

Analiza przejścia stanów

System może przedstawiać różne odpowiedzi w zależności od aktualnych warunków oraz wcześniejszych zdarzeń. W tym przypadku aspekty systemu mogą zostać pokazane jako diagram przejścia stanów. Umożliwia to testerowi zobaczenie oprogramowania z perspektywy jego stanów, przejść między stanami, danych wejściowych zdarzenia powodującego wykonanie zmiany stanu i akcji, które mogą być skutkiem tych zmian. Stany oprogramowania lub obiektu poddawanego testom są oddzielane, identyfikowane i grupowane. Tablica przejść pokazuje relacje pomiędzy stanami i danymi wejściowymi i może określać możliwe niepoprawne przejścia. Testy mogą być projektowane dla pokrycia typowych sekwencji stanów, dla pokrycia wszystkich stanów, dla sprawdzenia każdego przejścia, dla przetestowania specyficznych sekwencji przejść lub do testowania nieprawidłowych przejść.

Testowanie zmiany stanów jest bardziej użyteczne w testach z wbudowanym oprogramowaniem i automatyzacją. Technika ta jest również wartościowa dla testowania procesów biznesowych określonych poprzez stany. Podobnie możemy stosować ją w aplikacjach internetowych.

Przypadki testowe strukturalne lub białoskrzynkowe

Testowanie białoskrzynkowe bazuje na identyfikowalnych elementach struktury oprogramowania i systemu, jak w poniższych przykładach:

poziom komponentów - struktura będąca kodem np. deklaracje, decyzje i gałęzie
poziom integracji - struktura, która może być nazwana drzewkiem (diagram, w którym moduły wywołują inne moduły)
poziom systemu - struktura będąca strukturą menu, procesów biznesowych lub struktury strony internetowej.

Przedyskutujemy dwie powiązane z kodem techniki strukturalne, używane do osiągnięcia pokrycia kodu, które oparte są na analizie instrukcji i decyzji. W testowaniu decyzji diagram kontroli stanów może być użyty do lepszej wizualizacji alternatyw dla każdej decyzji.

Analiza pokrycia instrukcji kodu źródłowego

W testowaniu komponentów pokrywamy instrukcje, czyli oceniamy w jakim procencie zostały one wykonane/sprawdzone przez zbiór testów.

Analiza pokrycia decyzji w kodzie źródłowym

Testowanie decyzji tworzy przypadki testowe do wykonania konkretnych decyzji.

Pokrycie decyzji, powiązane z testowaniem gałęzi, jest ocenianiem procentu wyników decyzji (np. opcje "prawda"/"fałsz" dla instrukcji IF), które zostały wykonane przez zbiory przypadków testowych. Testowanie decyzji tworzy przypadki testowe do wykonania konkretnych wyników decyzji, do zwiększenia pokrycia decyzji. 100% pokrycia decyzji gwarantuje 100% pokrycia instrukcji, ale nie odwrotnie.

Inne

Możemy wyróżnić również inne techniki, takie jak pokrycie warunków i pokrycie warunków wielokrotnych. Koncepcja pokrycia może zostać zastosowana do innych poziomów testowych (np. poziomu integracji) jako procent modułów, komponentów lub klas, które zostały sprawdzone przez zbiory przypadków testowych. Wsparcie narzędziowe automatyzacji testowania kodu jest konieczne.

Więcej o technikach białoskrzynkowych:

Przypadki testowe oparte na doświadczeniu

Prawdopodobnie najszerzej używane podejście do testowania to testowanie eksploracyjne. Testy tworzone są podczas ich uruchamiania przy pomocy umiejętności testera, jego intuicji i doświadczenia z podobnymi aplikacjami i technologiami. ISTQB uważa, że technika ta zazwyczaj stosowana jest jako uzupełnienie wcześniej opisanych technik systematycznych. Testowanie intuicyjne może być użyteczne do identyfikacji specjalnych testów nieuchwytnych w formalnych technikach. Technika ta jest głównie używana po metodach bardziej formalnych. Może mieć różne poziomy efektywności w zależności od doświadczenia testera. Przykładową metodą systematyczną dla techniki zgadywania błędów (jedna z technik opartych na doświadczeniu) jest wypisanie możliwych błędów i zaprojektowanie testów w taki sposób, by sprawdzały one te błędy. Defekty oraz lista powodowanych przez nie problemów mogą być zbudowane w oparciu o doświadczenie, dostępne dane na temat defektów oraz z ogólnie dostępnej wiedzy na temat problemów oprogramowania.

Testowanie eksploracyjne jest równoległym projektowaniem, wykonaniem i zapisywaniem testów, opartym na opisie celów testów i prowadzonym w zdefiniowanych ramach czasowych. Jest to najbardziej przydatna metoda, gdy mamy niedostateczną lub nieadekwatną dokumentację i presję czasu. Może służyć jako sprawdzenie procesu testowego jako argument, że najważniejsze błędy zostały znalezione.

Dobór technik

Wybór techniki zależy od wielu czynników. Mogą to być:

typ systemu
standardy dla systemu
wymagania kontraktu lub klienta
poziom ryzyka
cele testów
dostępna dokumentacja
wiedza testerów
czas i budżet
typ cyklu tworzenia oprogramowania
model przypadków użycia
poprzednie doświadczenia
typy znalezionych defektów.

Różne techniki stają się bardziej odpowiednie w konkretnej sytuacji i dla konkretnego poziomu testów.

Źródła

Nazwa	Opis
PHPSESSID	Ciasteczko pozwalające na zapamiętywanie danych dotyczących stanu sesji.
_GRECAPTCHA	Ciasteczko pomagające zabezpieczyć formularze na stronie.
cookie_law_confirmed	Ciasteczko służące do wyświetlania tego okienka.
cookie_law_google_analytics	Ciasteczko zapamiętujące stan zgody użytkownika dotyczącej Google Analytics.
cookie_law_disqus	Ciasteczko zapamiętujące stan zgody użytkownika dotyczącej Disqus.
cookie_law_share_this	Ciasteczko zapamiętujące stan zgody użytkownika dotyczącej ShareThis.
article_visited	Ciasteczko pomagające ustalić, które artykuły są najbardziej popularne.
service_visited	Ciasteczko pomagające ustalić, które usługi są najbardziej popularne.
event_visited	Ciasteczko pomagające ustalić, które wydarzenia są najbardziej popularne.
training_visited	Ciasteczko pomagające ustalić, które szkolenia są najbardziej popularne.
external_training_visited	Ciasteczko pomagające ustalić, które zewnętrzne szkolenia są najbardziej popularne.

Nazwy	Opis
_utma	Unikalny użytkownik. Ciasteczko to zawiera unikalny numer identyfikacyjny, dzięki któremu narzędzie potrafi określić unikalnego i nowego użytkownika. Żywotność tego ciasteczka wynosi 2 lata i zapisywane jest w przeglądarce.
_utmb	Śledzenie odwiedzin. Ciasteczko przechowuje informację na temat danej odwiedziny.
_utmc	Śledzenie odwiedzin. Jego zadaniem jest ustalenie czy rozpocząć śledzenie nowej odwiedziny, czy też zbierane dane powinny zostać zaliczone do starej. Ciasteczko wygasa po zamknięciu przeglądarki.
_utmz	Źródła odwiedzin. Ciasteczko zawiera informację na temat źródeł odwiedzin. Dzięki niemu możliwe jest policzenie odwiedzin z wyszukiwarek oraz danych z kampanii marketingowych. Jego żywotność wynosi 6 miesięcy.
_utmv	Zmienne niestandardowe. Ciasteczko pojawia się tylko wtedy kiedy na witrynie zastosujemy śledzenie niestandardowych zmiennych. Jego żywotność to 2 lata.