Hva er looptesting? Metodikk, eksempel

by: Thomas Hamilton Thomas Hamilton
Hours oppdatert

⚡ Smart oppsummering

Loop Testing validerer løkkekonstruksjonene i et program, og sjekker hva som skjer når en løkke hoppes over, startes én gang, kjøres ved grensen og skyves ett pass utover det maksimalt tillatte antallet.

  • 🔘 Definisjon: En hvitboks-kontrollstrukturteknikk rettet mot løkkevaliditet, ikke mot skjermer.
  • 🔁 Fire klasser: Enkle, nestede, sammenkoblede og ustrukturerte løkker trenger hver sin egen strategi.
  • 📍 Tre kontrollpunkter: Inngang i løkken, oppførsel under utførelse og utgangsbetingelse.
  • 🧪 Grensepasseringer: Null, en, to, en typisk telling, deretter b-1, b og b+1 iterasjoner.
  • 🪜 Nestet rekkefølge: Start ved den innerste løkken, hold de ytre minst mulig, og arbeid deg deretter utover.
  • 🐞 Funnede feil: Av-for-én-grenser, uinitialiserte tellere, uendelige løkker og kapasitetsflaskehalser.
  • ⚠️ Begrensning: Loop-feil sitter i lavnivåkode og er sjelden subtile når de først er nådd.
Les mer

Metodikk for løkketesting, typer løkker og eksempler på testtilfeller

Hva er looptesting?

Sløyfetesting er en type programvaretesting som fokuserer utelukkende på gyldigheten av løkkekonstruksjonene i et program. Det er en del av testing av kontrollstrukturer, ved siden av stitesting, datavalideringstesting og tilstandstesting.

Sløyfetesting er en testing av hvit boks teknikken, slik at den brukes av noen som kan lese kildekoden og se løkkebetingelsen, telleren og utgangsveien. Testeren gjetter ikke på oppførselen fra brukergrensesnittet; selve løkken er objektet som testes.

Diagrammet nedenfor viser hvor løkketesting befinner seg innenfor testfamilien for kontrollstrukturer.

Looptesting vist som en gren av testing av kontrollstrukturer

Typer sløyfe Testet

Før du velger en strategi, identifiser hvilken av de fire løkkeklassene du ser på. Eksempler på løkketyper som testes er:

  • Enkel løkke — en enkelt sløyfe med én inngang og én utgang, for eksempel en vanlig forum, mens or gjør mens konstruere.
  • Nestet løkke — én løkke plassert inni en annen, slik at den indre løkken fullføres for hver passering av den ytre løkken.
  • Sammenhengende løkke — to eller flere løkker som går etter hverandre i rekkefølge.
  • Ustrukturert sløyfe — en uplanlagt kombinasjon av nestede og sammenkoblede løkker, vanligvis et resultat av hopp inn i eller ut av en løkkekropp.

Klassen bestemmer innsatsen. En enkel løkke trenger en håndfull iterasjonsantall; en ustrukturert løkke trenger vanligvis at koden redesignes før den i det hele tatt kan testes.

Hvorfor utføre sløyfetesting?

Sløyfetesting utføres av følgende årsaker

  • Testing kan fikse problemene med loop-repetisjon
  • Looptesting kan avdekke flaskehalser i ytelse og kapasitet
  • Ved å teste løkker kan de uinitialiserte variablene i løkken bestemmes
  • Det hjelper med å identifisere problemer med løkkeinitialisering.

Det finnes også en kommersiell grunn. En løkke som kjører én iterasjon for mye, ødelegger en total; en løkke som aldri avsluttes, henger en prosess. Begge feilene er billige å finne mens koden fortsatt er på en utviklermaskin, og dyre å finne i produksjon.

Slik utfører du sløyfetesting: Komplett metodikk

Når man tester en løkke, må den kontrolleres på tre forskjellige nivåer:

  • Når løkken er inngått
  • Under utførelsen, og
  • Når løkken er igjen

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

Enkel løkke

En enkel løkke har én inngang og én utgang, som vist nedenfor.

Enkelt løkkeflytskjema med ett inngangspunkt og én utgangspunkt

En enkel sløyfe testes på følgende måte:

  1. Hopp over hele løkken
  2. Gjør 1 pass gjennom løkken
  3. Gjør 2 passeringer gjennom løkken
  4. Lage a går gjennom løkken der a < b, det er et typisk iterasjonstall i mellomklassen
  5. Lage b, b-1 og b+1 går gjennom løkken der b er det maksimale antallet tillatte passeringer gjennom løkken.

De to siste sakene har mest verdi. Hopp overping løkken beviser at utgangsbetingelsen evalueres før kroppen kjører, og b+1 tilfelle beviser at løkken nekter arbeid utover den deklarerte grensen i stedet for å overkjøre en array.

Nestet løkke

En nestet løkke multipliserer antallet mulige iterasjonskombinasjoner, slik at den testes fra innsiden og ut i stedet for alt på en gang.

Flytskjema for nestet løkke med en indre løkke omsluttet av en ytre løkke

For en nestet løkke må du følge følgende trinn.

  1. Sett alle de andre løkkene til minimumsverdien og start ved den innerste løkken
  2. For den innerste sløyfen, utfør en enkel sløyfetest og hold de ytre løkkene ved deres minste iterasjonsparameterverdi
  3. Utfør testen for neste løkke og arbeid deg utover
  4. Fortsett til den ytterste løkken er testet.

Sammenhengte løkker

Sammenkoblede løkker sitter etter hverandre i samme utførelsesbane, som diagrammet viser.

Flytskjema for sammenkoblede løkker som viser to løkker som kjører i rekkefølge

I sammenkoblede løkker, hvis to løkker er uavhengige av hverandre, testes de ved hjelp av den enkle løkketilnærmingen, ellers testes de som nestede løkker.

Men hvis løkketelleren for én løkke brukes som startverdi for den andre, regnes ikke de to løkkene som uavhengige.

Ustrukturerte løkker

Ustrukturerte løkker er det vanskeligste tilfellet, fordi kontroll hopper inn og ut av løkkekroppen på vilkårlige punkter.

Ustrukturert løkkeflytskjema med kontrollhoppping inn og ut av løkkekroppen

For ustrukturerte løkker må designet omstruktureres for å gjenspeile bruken av strukturerte programmeringskonstruksjoner. Når koden er redusert til enkle, nestede eller sammenkoblede former, gjelder matchingstrategien ovenfor.

RELATERTE ARTIKLER

Eksempel på løkketesting med testtilfeller

Et utarbeidet eksempel gjør iterasjonstellingene konkrete. Tenk deg en rutine som multipliserer et løpende resultat med hvert heltall fra 1 til n, en faktorberegning. Løkketelleren starter på 1, utgangsbetingelsen er disk > n, og løkken er deklarert til å godta maksimalt 12 passeringer før resultatet overflyter den deklarerte heltallstypen.

Hvis vi behandler dette som en enkel løkke, oversettes iterasjonstallene som er anbefalt ovenfor til følgende test tilfeller.

Test tilfelle Verdien av n Utførte pasninger Hva det beviser
TC01 0 0 (løkke hoppet over) Utgangsbetingelsen evalueres før kroppen kjører, og resultatet forblir på den initialiserte verdien på 1.
TC02 1 1 Én enkelt omgang gir riktig resultat, og telleren øker én gang.
TC03 2 2 Akkumulatoren overfører en verdi fremover mellom to påfølgende omganger.
TC04 5 5 En typisk telling i mellomområdet returnerer forventede 120, noe som bekrefter vanlig oppførsel.
TC05 11 11 Én omgang under maksimumet fullføres fortsatt normalt (b-1.).
TC06 12 12 Det deklarerte maksimumet aksepteres, og løkken avsluttes (b).
TC07 13 avvist Én passering utover maksimumet blir nektet i stedet for å overløpe stille (b+ 1).

Legg merke til at TC01 og TC07 er de to tilfellene utviklere oftest utelater, og det er de to som eksponerer feil ved hoppet initialisering og overløp. En negativ verdi på n hører hjemme i samme sett hvis spesifikasjonen tillater det, som kobler løkketesting til negativ testing.

Vanlige feil funnet ved løkketesting

Looptesting finner stadig den samme lille familien av feil, og det er det som gjør de faste iterasjonstellingene verdt å kjøre hver gang.

  • Avgrensninger — en betingelse skrevet som < hvor <= var ment, så løkken kjører én omgang for få eller én for mange.
  • Uinitialiserte tellere eller akkumulatorer — en totalsum som inneholder en verdi som er igjen fra et tidligere anrop.
  • Uendelige løkker — en utgangsbetingelse som løkkekroppen aldri kan oppfylle fordi telleren bare oppdateres på noen grener.
  • Forutsetninger om hoppet over sløyfer — kode etter løkken som leser en variabel som løkkeinnholdet var forventet å sette, som mislykkes når løkken kjøres null ganger.
  • Kapasitets- og ytelsesfeil — en løkke som er korrekt, men som leser databasen på nytt ved hver passering, slik at kostnaden vokser med iterasjonsantallet.
  • Nestet sløyfeinterferens — en indre løkke som gjenbruker den ytre løkketelleren og stille endrer den ytre iterasjonstelleren.

Fordi hver feil er knyttet til et spesifikt antall iterasjoner, er feilene som dukker opp her enkle å reprodusere og raske å fikse sammenlignet med feil som finnes ved høyere testnivåer.

Looptesting vs. andre testteknikker for kontrollstrukturer

Looptesting er et medlem av kontrollstrukturfamilien, og det er lett å forveksle med de nærliggende teknikkene. Tabellen nedenfor skiller dem.

Teknikk Hva den retter seg mot Typisk dekningsmål
Sløyfetesting Loopkonstruksjoner: inngang, iterasjonstelling og utgang Null-, én-, typisk- og grenseiterasjonstellinger for hver løkke
Tilstandstesting Boolske uttrykk i beslutninger Hver betingelse evaluerte både sant og usant
Dataflyttesting Definisjon og bruk av hver variabel Hvert definisjonspar som skal brukes, utøves minst én gang
Basissti-testing Uavhengige baner gjennom kontrollflytgrafen Et antall stier lik den syklomatiske kompleksiteten

I praksis er disse teknikkene komplementære snarere enn konkurrerende. Syklomatisk kompleksitet forteller deg hvor mange uavhengige stier som finnes, basisstitesting dekker dem, og løkketesting legger deretter til iterasjonstallene som stidekning alene ikke ville tvinge frem. Alle er dynamisk testing aktiviteter, siden koden må kjøres for at resultatene skal kunne observeres.

Begrensning i sløyfetesting

Teknikken har reelle grenser, og det å kjenne dem forhindrer overinvestering.

  • Sløyfefeil vises for det meste i programvare på lavt nivå
  • Feilene som er identifisert under loop-testing er ikke veldig subtile
  • Mange av feilene kan oppdages av operativsystemet, ettersom de forårsaker brudd på minnegrenser, oppdagelige pekerfeil og lignende feil.
  • Det koster tid å identifisere klassen til hver løkke og teste den deretter, noe som er vanskelig å rettferdiggjøre på kodestier som medfører liten risiko.

Spørsmål og svar

Utviklere og tekniske testere med tilgang til kildekode, vanligvis under enhetstesting eller kodegjennomgang. Forretningstestere kan ikke bruke den, fordi løkkebetingelsen er usynlig fra brukergrensesnittet.

En modell leser løkkebetingelsen og foreslår automatisk null-, én-, typisk- og grenseiterasjonstellinger, inkludert overløpstilfellet. En anmelder bekrefter likevel at hvert forventede resultat samsvarer med spesifikasjonen.

Den utarbeider dem raskt, siden iterasjonsmønsteret er formelbasert. Agentassistenter kan også kjøre suiten og rapportere hvilke antall feil, men å bestemme maksimalt antall tillatte passeringer er fortsatt en designbeslutning som et menneske eier.

Kjør saken under en timeout eller en iterasjonsbeskyttelse slik at testen feiler raskt i stedet for å henge opp pakken. Vær sikker på antall registrerte passeringer, ikke bare den endelige utdataverdien.

Langt færre enn alle kombinasjoner. Testing på vrangen holder tellingen omtrent additiv på tvers av nivåer i stedet for multiplikativ, fordi de ytre løkkene er festet til sin minimumsverdi mens den indre løkken trenes.

Det finnes ikke noe verktøy dedikert til det. Team kombinerer et enhetstestrammeverk som f.eks. JUnit eller pytest med et dekningsverktøy som rapporterer grendekning, og les deretter rapporten for å bekrefte at null-iterasjonsbanen ble nådd.

Nei. Grendekningen er oppfylt når en løkke er inngått og utgått én gang. Looptesting krever i tillegg antall overspurte passeringer og grenser, noe grendekningen alene aldri tvinger frem.

Når det er ustrukturert — kontrollhoppping inn i eller ut av kroppen. Omstrukturering til enkle, nestede eller sammenkoblede former koster mindre enn å designe tester for hvert uregelmessige inngangspunkt.

Oppsummer dette innlegget med: