Linjär kodsekvens och hopp

Linjär kodsekvens och hopp ( LCSAJ ), i vid mening, är en mjukvaruanalysmetod som används för att identifiera strukturella enheter i kod som testas. Dess primära användning är med dynamisk mjukvaruanalys för att hjälpa till att svara på frågan "Hur mycket testning räcker?". Dynamisk mjukvaruanalys används för att mäta kvaliteten och effektiviteten hos mjukvarutestdata, där kvantifieringen utförs i termer av strukturella enheter av koden som testas. När den används för att kvantifiera de strukturella enheterna som utövas av en given uppsättning testdata, kallas dynamisk analys också för strukturell täckningsanalys .

I en snävare mening är en LCSAJ en väldefinierad linjär region av ett programs kod. När det används i denna mening kallas LCSAJ även JJ-path , vilket står för jump-to-jump path.

Historia

LCSAJ-analysmetoden utarbetades av professor Michael Hennell för att utföra kvalitetsbedömningar av de matematiska bibliotek som hans kärnfysikforskning vid University of Liverpool var beroende av. Professor Hennell grundade senare Liverpool Data Research Associates (LDRA) för att kommersialisera den mjukvarutestbädd som tagits fram för detta arbete, vilket resulterade i LDRA Testbed- produkten.

LCSAJ, som introducerades 1976, kallas nu också för hopp-till-hopp-banan (JJ-banan). Den har också kallats Liverpools bidrag till fåniga akronymer och skämt. ^{[ citat behövs ]}

Definition och egenskaper för LCSAJ som en kodregion

En LCSAJ är ett programvarukodsvägsfragment som består av en kodsekvens (en linjär kodsekvens) följt av ett kontrollflödeshopp, och består av följande tre poster:

början av den linjära sekvensen av körbara satser
slutet av den linjära sekvensen
mållinjen till vilken kontrollflödet överförs i slutet av den linjära sekvensen.

Till skillnad från (maximala) grundblock kan LCSAJs överlappa varandra eftersom ett hopp (ut) kan inträffa mitt i en LCSAJ, medan det inte är tillåtet i mitten av ett grundblock. I synnerhet genererar villkorliga hopp överlappande LCSAJ:er: en som löper fram till där villkoret utvärderas till falskt och ett annat som slutar vid hoppet när villkoret utvärderas till sant (exemplet som ges längre ner i den här artikeln illustrerar en sådan händelse). Enligt en monografi från 1986 var LCSAJ vanligtvis fyra gånger större än basblock.

Den formella definitionen av en LCSAJ kan ges i termer av grundläggande block enligt följande:

en sekvens av ett eller flera i följd numrerade grundblock, p , ( p +1), ..., q , av en kodenhet, följt av ett kontrollflödeshopp antingen ut ur koden [enhet] eller till ett grundblock numrerat r , där r ≠( q +1), och antingen p =1 eller så finns det ett kontrollflödeshopp till block p från något annat block i enheten. (Ett grundläggande block till vilket ett sådant kontrollflödeshopp kan göras hänvisas till som ett mål för [LCSAJ]-hoppet.)

Enligt Jorgensens lärobok från 2013, utanför Storbritannien och ISTQB- litteraturen, kallas samma föreställning DD-path . ^{[ tveksamt – diskutera ]}

Testeffektivitetsförhållande

Täckningsanalysmått används för att mäta hur mycket testning som har uppnåtts. Det mest grundläggande måttet är andelen exekverade uttalanden, Test Effectiveness Ratio 1 (TER1):

$TER_{\text{1}}={\frac {\text{antal satser som exekveras av testdata}}{\text {totalt antal körbara satser}}}$

Täckningsstatistik på högre nivå kan också genereras, särskilt:

$TER_{\text{2}}={\frac {\text{antal kontrollflödesgrenar exekveras av testdata}}{\text{totalt antal kontrollflödesgrenar}}}$

$TER_{\text{3}}={\frac {\text{antal LCSAJs exekverade av testdata}}{\text{ totalt antal LCSAJs}}}$

Dessa mått uppfyller en ren hierarki, där när TER3 = 100 % har uppnåtts följer att TER2 = 100 % och TER1 = 100 % också har uppnåtts.

Både TER1- och TER2-måtten användes i början av 1970-talet och den tredje är från slutet av 1970-talet. Kravet för att uppnå TER1 = 100 % var den nivå som ursprungligen valdes för flygelektronikstandarden DO-178 tills den kompletterades av MCDC ( modified condition/decision coverage ) ytterligare krav 1992. Högre nivåer TER3 = 100 % har varit obligatoriska för många andra projekt, inklusive flyg, telefoni och bankverksamhet. ^{[ citat behövs ]} Ett praktiskt problem med att använda TER3 är att många LCSAJs aldrig kan köras på grund av de motstridiga villkoren de innehåller.

läs x, y om x > 5 om y > 3 skriv ut "testning" endif endif skriv ut "mjukvara"

Från det här exemplet kan det ses att det grundläggande blocket som identifieras av en LCSAJ-trippel kan sträcka sig över en beslutspunkt, vilket återspeglar de villkor som måste vara på plats för att LCSAJ ska kunna exekveras. Till exempel inkluderar LCSAJ 2 för exemplet ovan satsen while där villkoret (antal < ITERATIONER) utvärderas till sant.

Varje kodrad har en LCSAJ 'densitet' associerad med sig; rad 17, till exempel, visas inom 6 unika LCSAJs - dvs den har en LCSAJ-densitet på 6. Detta är användbart när man utvärderar kodens underhållbarhet; Om en kodrad ska ändras så är densiteten en indikation på hur många LCSAJ som kommer att påverkas av den förändringen.

En täckningsnivå på TER3 = 100 % skulle uppnås när testdata som används orsakar exekvering av var och en av dessa LCSAJs minst en gång.