Liniowa sekwencja kodu i skok

Liniowa sekwencja kodu i skok ( LCSAJ ), w szerokim znaczeniu, to metoda analizy oprogramowania używana do identyfikacji jednostek strukturalnych w testowanym kodzie. Jego głównym zastosowaniem jest dynamiczna analiza oprogramowania, która pomaga odpowiedzieć na pytanie „Ile testów wystarczy?”. Dynamiczna analiza oprogramowania służy do pomiaru jakości i skuteczności danych testowych oprogramowania, gdzie kwantyfikację przeprowadza się w kategoriach jednostek strukturalnych testowanego kodu. W przypadku użycia do ilościowego określenia jednostek strukturalnych wykonywanych przez dany zestaw danych testowych analiza dynamiczna jest również nazywana analizą pokrycia strukturalnego .

W węższym sensie LCSAJ to dobrze zdefiniowany liniowy region kodu programu. Używany w tym sensie, LCSAJ jest również nazywany JJ-path , co oznacza ścieżkę skoku do skoku.

Historia

Metoda analizy LCSAJ została opracowana przez profesora Michaela Hennella w celu przeprowadzenia oceny jakości bibliotek matematycznych, na których opierały się jego badania w dziedzinie fizyki jądrowej na Uniwersytecie w Liverpoolu . Profesor Hennell założył później Liverpool Data Research Associates (LDRA) w celu skomercjalizowania stanowiska testowego oprogramowania wyprodukowanego na potrzeby tej pracy, w wyniku czego powstał produkt LDRA Testbed .

Wprowadzony w 1976 r. LCSAJ jest obecnie określany jako ścieżka skoku do skoku (ścieżka JJ). Został również nazwany wkładem Liverpoolu w głupie akronimy i żarty. ^{[ potrzebne źródło ]}

Definicja i charakterystyka LCSAJ jako regionu kodowego

LCSAJ to fragment ścieżki kodu oprogramowania składający się z sekwencji kodu (liniowej sekwencji kodu), po której następuje skok sterowania, i składa się z następujących trzech elementów:

początek liniowej sekwencji instrukcji wykonywalnych
koniec ciągu liniowego
linia docelowa, do której przekazywany jest przepływ sterowania na końcu sekwencji liniowej.

W przeciwieństwie do (maksymalnych) bloków podstawowych , LCSAJ mogą nakładać się na siebie, ponieważ wyskok (out) może wystąpić w środku LCSAJ, podczas gdy nie jest to dozwolone w środku bloku podstawowego. W szczególności skoki warunkowe generują nakładające się LCSAJ: jeden, który przechodzi do miejsca, w którym warunek ma wartość fałsz, a drugi kończy się w momencie, gdy warunek ma wartość prawda (przykład podany poniżej w tym artykule ilustruje takie zdarzenie). Według monografii z 1986 roku LCSAJ były zazwyczaj cztery razy większe niż podstawowe bloki.

Formalną definicję LCSAJ można przedstawić w kategoriach podstawowych bloków w następujący sposób:

sekwencja jednego lub więcej kolejno ponumerowanych bloków podstawowych, p , ( p +1), ..., q jednostki kodu, po której następuje skok sterowania z kodu [jednostka] lub do bloku podstawowego o numerze r , gdzie r ≠( q +1), i albo p = 1, albo istnieje przeskok przepływu sterowania do bloku p z innego bloku w jednostce. (Podstawowy blok, do którego można wykonać taki skok w przepływie sterowania, jest określany jako cel skoku [LCSAJ].)

Według podręcznika Jorgensena z 2013 roku, poza Wielką Brytanią i literaturą ISTQB , to samo pojęcie nazywa się DD-path . ^{[ wątpliwe – dyskutuj ]}

Współczynnik skuteczności testu

Metryki analizy pokrycia służą do oceny, ile testów zostało osiągniętych. Najbardziej podstawową metryką jest proporcja wykonanych instrukcji, Współczynnik efektywności testu 1 (TER1):

${\ Displaystyle TER _ {\ tekst {1}} = {\ Frac {\ tekst {liczba instrukcji wykonywanych przez dane testowe}}} {\ tekst {całkowita liczba instrukcji wykonywalnych}}}}$

Można również wygenerować wskaźniki pokrycia wyższego poziomu, w szczególności:

${\ Displaystyle TER _ {\ tekst {2}} = {\ Frac {\ tekst {liczba rozgałęzień przepływu sterowania wykonanych przez dane testowe}}{\text{całkowita liczba rozgałęzień przepływu sterowania}}}}$

${\ Displaystyle TER _ {\ tekst {3}} = {\ Frac {\ tekst {liczba LCSAJ wykonanych przez dane testowe}}} {\ text { łączna liczba LCSAJ}}}}$

Metryki te odpowiadają czystej hierarchii, zgodnie z którą po osiągnięciu TER3 = 100% oznacza to, że osiągnięto również TER2 = 100% i TER1 = 100%.

Zarówno metryki TER1, jak i TER2 były używane we wczesnych latach siedemdziesiątych, a trzecia z późnych lat siedemdziesiątych. Wymóg osiągnięcia TER1 = 100% był poziomem pierwotnie wybranym dla standardu awioniki DO-178, dopóki nie został on uzupełniony dodatkowym wymaganiem MCDC ( zmodyfikowany warunek/pokrycie decyzji ) w 1992 r. Wyższe poziomy TER3 = 100% były wymagane dla wielu inne projekty, w tym lotnictwo, telefonię i bankowość. ^{[ potrzebne źródło ]} Jednym z praktycznych problemów związanych z używaniem TER3 jest to, że wielu LCSAJ nigdy nie można wykonać z powodu zawartych w nich sprzecznych warunków.

przeczytaj x, y jeśli x > 5 jeśli y > 3 wypisz "testowanie" endif endif wypisz " oprogramowanie"

Z tego przykładu widać, że podstawowy blok identyfikowany przez potrójną sekwencję LCSAJ może obejmować punkt decyzyjny, odzwierciedlający warunki, które muszą być spełnione, aby LCSAJ mógł zostać wykonany. Na przykład LCSAJ 2 dla powyższego przykładu zawiera while , w której warunek (liczba < ITERACJE) ma wartość true.

Każda linia kodu ma przypisaną „gęstość” LCSAJ; na przykład linia 17 pojawia się w obrębie 6 unikalnych LCSAJ - tj. ma gęstość LCSAJ równą 6. Jest to pomocne przy ocenie łatwości utrzymania kodu; Jeśli linia kodu ma zostać zmieniona, gęstość wskazuje, ile LCSAJ zostanie dotkniętych tą zmianą.

Poziom pokrycia TER3 = 100% zostałby osiągnięty, gdyby użyte dane testowe spowodowały wykonanie każdego z tych LCSAJ przynajmniej raz.