Hvad er loop test? Metode, eksempel

⚡ Smart opsummering

Looptestning validerer loopkonstruktionerne i et program og kontrollerer, hvad der sker, når et loop springes over, indtastes én gang, udføres ved dets grænse og skubbes én gennemgang ud over det maksimalt tilladte antal.

🔘 Definition: En white box-kontrolstrukturteknik rettet mod loopvaliditet, ikke mod skærme.
🔁 Fire klasser: Simple, indbyggede, sammenkædede og ustrukturerede løkker kræver hver deres egen strategi.
📍 Tre kontrolpunkter: Adgang til løkken, adfærd under udførelse og slutbetingelse.
🧪 Grænseovergange: Nul, en, to, et typisk antal, derefter b-1, b og b+1 iterationer.
🪜 Indlejret rækkefølge: Start ved den inderste løkke, hold de ydre mindst muligt, og arbejd dig derefter udad.
🐞 Fundne defekter: Off-by-one-grænser, uinitialiserede tællere, uendelige loops og kapacitetsflaskehalse.
⚠️ Begrænsning: Loop-fejl sidder i lavniveaukode og er sjældent subtile, når de først er nået.

Læs mere

Hvad er loop test?

Løkketest er en softwaretesttype, der udelukkende fokuserer på gyldigheden af loopkonstruktionerne i et program. Det er en del af test af kontrolstrukturer, sammen med stitestning, datavalideringstest og tilstandstest.

Loop test er en hvid boks test teknikken, så den anvendes af en person, der kan læse kildekoden og se loopbetingelsen, tælleren og exit-stien. Testeren gætter ikke på brugergrænsefladen; selve loopen er det objekt, der testes.

Diagrammet nedenfor viser, hvor looptestning er placeret inden for testfamilien af kontrolstrukturer.

Sløjfetyper Testet

Før du vælger en strategi, skal du identificere hvilken af de fire loopklasser du ser på. Eksempler på looptyper, der testes, er:

Enkel løkke — en enkelt løkke med én indgang og én udgang, såsom en almindelig forum, mens or gøre imens konstruere.
Indlejret sløjfe — en løkke placeret inden i en anden, så den indre løkke løber helt færdig ved hver passage af den ydre løkke.
Sammenkædet løkke — to eller flere løkker, der kører efter hinanden i rækkefølge.
Ustruktureret sløjfe — en uplanlagt kombination af indbyggede og sammenkædede løkker, normalt resultatet af hop ind i eller ud af en løkkekrop.

Klassen bestemmer indsatsen. En simpel løkke kræver et par iterationer; en ustruktureret løkke kræver normalt, at koden redesignes, før den overhovedet kan testes.

Hvorfor udføres loop-test?

Sløjfetest udføres af følgende årsager

Test kan løse problemer med loop-gentagelse
Looptestning kan afsløre flaskehalse i ydeevne og kapacitet
Ved at teste løkker kan de ikke-initialiserede variabler i løkken bestemmes
Det hjælper med at identificere problemer med loopinitialisering.

Der er også en kommerciel årsag. En løkke, der kører én iteration for meget, korrumperer en total; en løkke, der aldrig afsluttes, hænger en proces. Begge defekter er billige at finde, mens koden stadig er på en udviklermaskine, og dyre at finde i produktion.

Sådan laver du sløjfetestning: Komplet metode

Når man tester et loop, skal det kontrolleres på tre forskellige niveauer:

Når løkken er indtastet
Under dens udførelse, og
Når løkken er tilbage

Teststrategien for alle disse løkker er som følger.

Enkel løkke

En simpel løkke har en enkelt indgang og en enkelt udgang, som vist nedenfor.

En simpel sløjfe testes på følgende måde:

Spring hele løkken over
Lav 1 gennemløb gennem løkken
Lav 2 gennemløb gennem løkken
Lave a går gennem løkken hvor a < b, det er et typisk melleminterval-iterationsantal
Lave b, b-1 og b+1 går gennem løkken hvor b er det maksimale antal tilladte passager gennem løkken.

De sidste to tilfælde bærer det meste af værdien. Spring overping Løkken beviser, at udgangsbetingelsen evalueres, før kroppen kører, og b+1 tilfælde beviser, at løkken nægter at arbejde ud over dens deklarerede grænse i stedet for at overskrive et array.

Indlejret løkke

En indbygget løkke multiplicerer antallet af mulige iterationskombinationer, så den testes indefra og ud i stedet for alt på én gang.

For en indlejret løkke skal du følge følgende trin.

Indstil alle de andre løkker til deres minimumsværdi og start ved den inderste løkke
For den inderste sløjfe skal du udføre en simpel sløjfetest og holde de ydre sløjfer ved deres minimum iterationsparameterværdi
Udfør testen for den næste løkke og arbejd dig udad
Fortsæt indtil den yderste løkke er blevet testet.

Sammenkædede løkker

Sammenkædede løkker sidder efter hinanden i den samme udførelsessti, som diagrammet viser.

I sammenkædede løkker, hvis to løkker er uafhængige af hinanden, testes de ved hjælp af den simple løkketilgang, ellers testes de som indbyggede løkker.

Hvis loop-tælleren for den ene løkke imidlertid bruges som startværdi for den anden, betragtes de to løkker ikke som uafhængige.

Ustrukturerede løkker

Ustrukturerede løkker er det sværeste tilfælde, fordi kontrollen hopper ind og ud af løkkekroppen på vilkårlige punkter.

For ustrukturerede loops skal designet omstruktureres for at afspejle brugen af strukturerede programmeringskonstruktioner. Når koden er reduceret til simple, indbyggede eller sammenkædede former, gælder ovenstående matchingstrategi.

Eksempel på looptest med testcases

Et bearbejdet eksempel gør iterationsoptællingerne konkrete. Overvej en rutine, der ganger et løbende resultat med hvert heltal fra 1 til n, en faktorberegning. Løkketælleren starter ved 1, udgangsbetingelsen er imødegå > n, og løkken erklæres til at acceptere maksimalt 12 gennemløb, før resultatet overløber den deklarerede heltalstype.

Hvis dette behandles som et simpelt loop, oversættes de ovenfor anbefalede iterationsantal til følgende test tilfælde.

Test tilfælde	Værdi af n	Eksekverede afleveringer	Hvad det beviser
TC01	0	0 (løkke sprunget over)	Udgangsbetingelsen evalueres, før kroppen kører, og resultatet forbliver på dens initialiserede værdi på 1.
TC02	1	1	En enkelt gennemgang giver det korrekte resultat, og tælleren øges én gang.
TC03	2	2	Akkumulatoren overfører en værdi fremad mellem to på hinanden følgende gennemløb.
TC04	5	5	En typisk optælling i mellemområdet returnerer de forventede 120, hvilket bekræfter normal adfærd.
TC05	11	11	Én gennemgang under maksimumniveauet fuldføres stadig normalt (b1).
TC06	12	12	Det deklarerede maksimum accepteres, og løkken afsluttes (b).
TC07	13	afvist	Én gennemgang ud over det maksimale afvises i stedet for lydløst at løbe over (b+ 1).

Bemærk, at TC01 og TC07 er de to tilfælde, som udviklere oftest udelader, og det er de to, der eksponerer fejl i sprunget initialisering og overflow. En negativ værdi af n hører hjemme i det samme sæt, hvis specifikationen tillader det, hvilket forbinder looptestning med negativ test.

Almindelige defekter fundet ved looptestning

Looptestning finder hele tiden den samme lille familie af fejl, hvilket er det, der gør de faste iterationstællinger værd at køre hver gang.

Grænser lige for sig — en betingelse skrevet som < hvor <= var tiltænkt, så løkken kører én gennemgang for få eller én for mange.
Uinitialiserede tællere eller akkumulatorer — en total, der indeholder en værdi tilbage fra et tidligere opkald.
Uendelige løkker — en exit-betingelse som loop-kroppen aldrig kan opfylde, fordi tælleren kun opdateres på nogle grene.
Antagelser om oversprungne loops — kode efter løkken, der læser en variabel, som løkkens brødtekst forventedes at sætte, hvilket fejler, når løkken kører nul gange.
Kapacitets- og ydeevnefejl — en løkke, der er korrekt, men genlæser databasen ved hver gennemgang, så omkostningerne vokser med antallet af iterationer.
Indlejret loop-interferens — en indre løkke, der genbruger den ydre løkketæller og stille og roligt ændrer antallet af ydre iterationer.

Fordi hver fejl er knyttet til et specifikt iterationsantal, er de fejl, der opstår her, nemme at reproducere og hurtige at udbedre sammenlignet med fejl, der findes ved højere testniveauer.

Looptestning vs. andre testteknikker til kontrolstrukturer

Looptestning er et medlem af kontrolstrukturfamilien, og den er let at forveksle med de tilstødende teknikker. Tabellen nedenfor adskiller dem.

Teknik	Hvad den er rettet mod	Typisk dækningsmål
Loop test	Loopkonstruktioner: indgang, iterationsantal og udgang	Nul-, en-, typisk- og grænseiterationstællinger for hver løkke
Tilstandstest	Boolske udtryk i beslutninger	Hver betingelse evaluerede både sand og falsk
Test af dataflow	Definition og brug af hver variabel	Hvert definition-til-brug-par udøves mindst én gang
Basissti-testning	Uafhængige stier gennem kontrolflowgrafen	Et antal stier lig med den cyklomatiske kompleksitet

I praksis er disse teknikker snarere komplementære end konkurrerende. Cyklomatisk kompleksitet fortæller dig, hvor mange uafhængige stier der findes, basisstitestning dækker dem, og looptestning tilføjer derefter iterationsantallet, som stidækning alene ikke ville fremtvinge. De er alle dynamisk test aktiviteter, da koden skal udføres for at resultaterne kan observeres.

Begrænsning i loop test

Teknikken har reelle grænser, og kendskab til dem forhindrer overinvestering.

Loop-fejl dukker for det meste op i software på lavt niveau
De fejl, der identificeres under loop-test, er ikke særlig subtile
Mange af fejlene kan muligvis opdages af operativsystemet, da de forårsager overtrædelser af hukommelsesgrænser, detekterbare pointerfejl og lignende fejl.
Det koster tid at identificere klassen for hvert loop og teste det i overensstemmelse hermed, hvilket er svært at retfærdiggøre på kodestier, der indebærer lav risiko.

Ofte Stillede Spørgsmål

Udviklere og tekniske testere med adgang til kildekode, normalt under enhedstest eller kodegennemgang. Forretningstestere kan ikke anvende det, fordi loopbetingelsen er usynlig fra brugergrænsefladen.

En model læser løkkebetingelsen og foreslår automatisk nul-, en-, typisk- og grænseiterationstællinger, inklusive overløbstilfældet. En anmelder bekræfter stadig, at hvert forventet resultat matcher specifikationen.

Den udarbejder dem hurtigt, da iterationsmønsteret er formelbaseret. Agentassistenter kan også køre pakken og rapportere, hvilke antal fejl, men at bestemme det maksimalt tilladte antal gennemløb forbliver en designbeslutning, som et menneske ejer.

Kør casen under en timeout eller en iterationsbeskyttelse, så testen fejler hurtigt i stedet for at hænge pakken. Vær sikker på antallet af registrerede gennemløb, ikke kun på den endelige outputværdi.

Langt færre end alle kombinationer. Testning på vrangen holder antallet nogenlunde additivt på tværs af niveauer snarere end multiplikativt, fordi de ydre løkker er fastgjort til deres minimumsværdi, mens det indre løkke trænes.

Der er ikke dedikeret noget værktøj til det. Teams kombinerer et enhedstestframework som f.eks. JUnit eller pytest med et dækningsværktøj, der rapporterer grendækning, og læs derefter rapporten for at bekræfte, at nul-iterationsstien blev nået.

Nej. Grendækningen er opfyldt, når en løkke er gået ind i og ud af én løkke. Looptestning kræver desuden det oversprungne gennemløb og grænseantal, hvilket grendækningen alene aldrig fremtvinger.

Når det er ustruktureret — kontroljumpping ind i eller ud af kroppen. Omstrukturering til simple, indbyggede eller sammenkædede former koster mindre end at designe tests for hvert uregelmæssigt indgangspunkt.