Zmodyfikowane pokrycie warunków decyzji (ZPWD). Jak to określać?

Zmodyfikowane pokrycie warunków decyzji (ZPWD). Jak to określać?
Jedną z trudniejszych technik projektowania przypadków testowych dla kodu źródłowego omawianych w sylabusie ISTQB Techniczny Analityk Testów jest ZPWD.
 

Zmodyfikowane pokrycie warunków decyzji (ZPWD) to dość karkołomne tłumaczenie modified condition / decision coverage (MC/DC). Technika ta zapewnia bardzo silne pokrycie warunków decyzyjnych w kodzie źródłowym i przy 100% uruchomieniu gwarantuje uruchomienie wszystkich ścieżek w kodzie w ramach przepływu sterowania. Jej podstawowym założeniem jest to, że w punkcie decyzyjnym w kodzie znajdują się warunki atomowe, czyli takie, których nie można rozłożyć na elementy prostsze (zdekomponować).

 

PRZYKŁAD

Stosując tę technikę i zakładając, że w punkcie decyzyjnym istnieje N unikalnych warunków atomowych, ZPWD zazwyczaj osiągnie pełne pokrycie w N+1 unikalnych przypadkach testowych.

 

PRZYKŁAD

Decyzja podejmowana jest w oparciu o następujące warunki logiczne „(A or B) and C”, gdzie A, B i C to warunki atomowe przyjmujące wartość PRAWDA / FAŁSZ. Ponieważ mamy 3 warunki, to N=3, a 100% pokrycia będzie możliwe do uzyskania w N+1 testach, czyli w czterech (4).

Dzięki ZPWD osiągamy pokrycie warunków w decyzjach, ale wymagane jest również by: 

  1. zaprojektować przynajmniej jeden test dla każdego przypadku, gdzie zmiana atomowego warunku X na PRAWDA wpływa na zmianę całej decyzji;
  2. zaprojektować przynajmniej jeden test dla każdego przypadku, gdzie zmiana atomowego warunku X na FAŁSZ wpływa na zmianę całej decyzji;
  3. każdy atomowy warunek musi być zweryfikowany dla wymagania 1 i 2.

 

PRZYKŁAD

Załóżmy, że decyzja zależy od opisanego wcześniej „(A or B) and C”.

Zgodnie z regułą przedstawioną powyżej wiemy, że potrzebuje 4 testów dla uzyskania pełnego pokrycia kodu w ramach zmodyfikowanego testowania warunków decyzji.

Przykładowe testy

Pogrubione zaznaczenie pokazuje warunki znaczące. 

Dzięki zaprezentowanym testom uzyskujemy pełne pokrycie decyzji zarówno naprawdę, jak i na FAŁSZ. Uzyskujemy również pokrycie warunków A, B i C, które zostają zweryfikowane na PRAWDĘ oraz na FAŁSZ.

  • Test 1, A jest PRAWDA i wynik jest PRAWDA. Jeśli A zmieni się na FAŁSZ (jak w teście Test 3, gdy pozostałe wartości pozostają bez zmian) rezultat zmieni się FAŁSZ.

  • Test 2, B jest PRAWDA i wynik jest PRAWDA. Jeśli B zmieni się na FAŁSZ (jak w teście Test 3, gdy pozostałe wartości pozostają bez zmian) rezultat zmieni się w FAŁSZ.

  • Test 1, C jest PRAWDA i wynik jest PRAWDA. Jeśli C zmieni się na FAŁSZ (jak w teście Test 4, gdy pozostałe wartości pozostają bez zmian) rezultat zmienia się w FAŁSZ.

Taką samą analizę możemy przeprowadzić dla A, B i C jako FAŁSZ.

 

Aby jeszcze trochę zagmatwać sama technika ma również dwie dodatkowe trudności.

  1. Osiągnięcie pokrycia dla zmodyfikowanego testowania warunków decyzji może być trudne, gdy pojedynczy argument występuję wielokrotnie w wyrażeniu. Mówimy wtedy, że argument jest „sprzężony”. Czasami, w zależności od zdefiniowania decyzji w kodzie, może nie być możliwe rozróżnienie, czy argument jest sprzężony czy też nie i czy może atomowo spowodować zmianę wyniku decyzji. Rozwiązaniem tego problemu jest założenie, że jedynie niesprzężone warunki atomowe muszą być przetestowane. Innym podejściem jest dokładne przeanalizowanie każdej decyzji, w której sprzężone argumenty występują.

  2. Niektóre języki programowania i interpretatory są zaprojektowane w taki sposób, że wykonują „zwarcie” (ang. short-circuiting) podczas oceny złożonych decyzji w kodzie. W wykonywanym kodzie może nie zostać zweryfikowane całe wyrażenie jeśli końcowy wynik może zostać określony po sprawdzeniu tylko części wyrażenia.

Przykład: Jeśli weryfikujemy decyzję “A and B”, nie ma potrzeby sprawdzać B jeśli A zostało określone jako FAŁSZ. Żadna wartość B nie wpłynie na końcową wartość. Kod można wykonać szybciej poprzez niesprawdzanie B. Zwarcie może powodować, że nie da się osiągnąć pełnego pokrycia ZPWD, ponieważ wymagane testy nie będą możliwe do uruchomienia dynamicznego.

 

Więcej przykładów rozwiązujemy i omawiamy w ramach naszego szkolenia ISTQB Poziom Zaawansowany - Techniczny Analityk Testów. Uczestnikom naszych egzaminów udostępniamy również generator pseudokodu z możliwością generowania zadań w formacie egzaminu ISTQB. Przykładowe zadania umożliwiają uczenie się kalkulowania pokrycia instrukcji, decyzji, warunków, warunków wielokrotnych oraz zmodyfikowanego pokrycia warunków decyzji (ZPWD). Kod można generować w strukturze zbliżonej do języków C++/C/C#/Java/JavaScript; PHP; BASIC oraz Delphi/Pascal.

 

 

Dostęp do narzędzia można również wykupić na platformie EDU.

Narzędzie można znaleźć pod adresem http://edu.ittraining.pl/material/white-box-pl

 

Najbliższe szkolenie z ISTQB Techniczny Analityk Testów odbędzie się 9-11 maja w Warszawie.

 

Bibliografia:

  1. Sylabus ISTQB Poziom Zaawansowany - Techniczny Analityk Testów [PL]
  2. Słownik terminów testowych ISTQB
 
 
 
 

To powinno Cię zainteresować