Vad är looptestning? Metodik, exempel
Thomas Hamilton
⚡ Smart sammanfattning
Looptestning validerar loopkonstruktionerna inuti ett program och kontrollerar vad som händer när en loop hoppas över, startas en gång, körs vid dess gräns och skickas ett svep bortom det maximalt tillåtna antalet.
Vad är looptestning?
Slingtestning är en typ av mjukvarutestning som helt fokuserar på giltigheten av loopkonstruktionerna i ett program. Det är en del av testning av kontrollstrukturer, tillsammans med sökvägstestning, datavalideringstestning och tillståndstestning.
Slingtestning är en vit box testning tekniken, så den tillämpas av någon som kan läsa källkoden och se loopens villkor, räknaren och utgångsvägen. Testaren gissar inte beteendet från användargränssnittet; loopen i sig är objektet som testas.
Diagrammet nedan visar var looptestning finns inom testfamiljen för kontrollstrukturer.
Typer av slingor Testade
Innan du väljer en strategi, identifiera vilken av de fyra loopklasserna du tittar på. Exempel på looptyper som testas är:
- Enkel slinga — en enda slinga med en ingång och en utgång, såsom en slätt för, medan or göra medan konstruera.
- Kapslad slinga — en slinga placerad inuti en annan, så att den inre slingan löper till fullbordan vid varje pass av den yttre slingan.
- Sammanfogad slinga — två eller flera loopar som löper efter varandra i sekvens.
- Ostrukturerad slinga — en oplanerad kombination av kapslade och sammanfogade loopar, vanligtvis resultatet av hopp in i eller ut ur en loopkropp.
Klassen bestämmer ansträngningen. En enkel loop behöver ett fåtal iterationer; en ostrukturerad loop behöver vanligtvis koden omdesignas innan den kan testas överhuvudtaget.
Varför gör looptestning?
Slingtestning görs av följande skäl
- Testning kan fixa problem med loopupprepning
- Looptestning kan avslöja flaskhalsar i prestanda och kapacitet
- Genom att testa loopar kan de oinitierade variablerna i loopen bestämmas
- Det hjälper till att identifiera problem med loopinitialisering.
Det finns också en kommersiell anledning. En loop som kör en iteration för mycket korrumperar en totalsumma; en loop som aldrig avslutas får en process att låsa sig. Båda defekterna är billiga att hitta medan koden fortfarande finns på en utvecklarmaskin och dyra att hitta i produktion.
Hur man gör looptestning: Komplett metodik
När man testar en loop måste den kontrolleras på tre olika nivåer:
- När loopen är inmatad
- Under dess utförande, och
- När slingan är kvar
Teststrategin för alla dessa loopar är följande.
Enkel slinga
En enkel loop har en enda ingång och en enda utgång, som visas nedan.
En enkel slinga testas på följande sätt:
- Hoppa över hela slingan
- Gör 1 pass genom slingan
- Gör 2 pass genom öglan
- Fabrikat a passerar genom slingan där a < b, det är ett typiskt iterationsantal i mellanintervallet
- Fabrikat b, b-1 och b+1 passerar genom slingan där b är det maximala antalet tillåtna passager genom slingan.
De två sista fallen har det största värdet. Hoppa överping Loopen bevisar att utgångsvillkoret utvärderas innan kroppen körs, och b+1-fallet bevisar att loopen vägrar arbete bortom sin deklarerade gräns istället för att överköra en array.
Nestad slinga
En kapslad loop multiplicerar antalet möjliga iterationskombinationer, så den testas inifrån och ut snarare än allt på en gång.
För en kapslad loop måste du följa följande steg.
- Ställ in alla andra loopar på deras minimivärde och börja vid den innersta loopen
- För den innersta slingan, utför ett enkelt slingtest och håll de yttre slingorna vid deras lägsta iterationsparametervärde
- Utför testet för nästa loop och arbeta utåt
- Fortsätt tills den yttersta öglan har testats.
Sammanfogade loopar
Sammanfogade loopar sitter en efter en i samma exekveringsväg, som diagrammet visar.
I sammanfogade loopar, om två loopar är oberoende av varandra, testas de med den enkla loopmetoden, annars testas de som kapslade loopar.
Om däremot loopräknaren för en loop används som initialvärde för den andra, betraktas de två looparna inte som oberoende.
Ostrukturerade loopar
Ostrukturerade loopar är det svåraste fallet, eftersom kontrollen hoppar in och ut ur loopkroppen vid godtyckliga punkter.
För ostrukturerade loopar måste designen omstruktureras för att återspegla användningen av strukturerade programmeringskonstruktioner. När koden har reducerats till enkla, kapslade eller sammanfogade former gäller matchningsstrategin ovan.
Exempel på looptestning med testfall
Ett fungerande exempel gör iterationsräkningarna konkreta. Betrakta en rutin som multiplicerar ett löpande resultat med varje heltal från 1 till n, en faktorberäkning. Loopräknaren börjar vid 1, utgångsvillkoret är motverka > n, och loopen deklareras att acceptera maximalt 12 passeringar innan resultatet överflödar den deklarerade heltalstypen.
Om man behandlar detta som en enkel loop, översätts de ovan rekommenderade iterationsantalen till följande testfall.
| Testfall | Värde av n | Utförda passningar | Vad det bevisar |
| TC01 | 0 | 0 (slinga hoppad över) | Avslutningsvillkoret utvärderas innan kroppen körs, och resultatet behåller sitt initialiserade värde på 1. |
| TC02 | 1 | 1 | En enda omgång ger rätt resultat och räknaren ökar en gång. |
| TC03 | 2 | 2 | Ackumulatorn överför ett värde framåt mellan två på varandra följande omgångar. |
| TC04 | 5 | 5 | Ett typiskt mellanregistervärde returnerar det förväntade värdet 120, vilket bekräftar normalt beteende. |
| TC05 | 11 | 11 | Ett pass under maximum slutförs fortfarande normalt (b-ett). |
| TC06 | 12 | 12 | Det deklarerade maximumet accepteras och loopen avslutas (b). |
| TC07 | 13 | förkastas | Ett pass utöver maximum nekas snarare än att ljudlöst översvämmas (b+ 1). |
Observera att TC01 och TC07 är de två fall som utvecklare oftast utelämnar, och det är de två som exponerar misslyckad initialisering och överflödesfel. Ett negativt värde på n hör hemma i samma uppsättning om specifikationen tillåter att den anges, vilket länkar looptestning till negativa tester.
Vanliga defekter som upptäcks vid looptestning
Looptestning hittar hela tiden samma lilla familj av fel, vilket är det som gör de fasta iterationsräkningarna värda att köra varje gång.
- Avgränsningar — ett villkor skrivet som < var <= var avsett, så loopen körs ett pass för få eller ett för mycket.
- Oinitierade räknare eller ackumulatorer — en summa som innehåller ett värde kvar från ett tidigare samtal.
- Oändliga loopar — ett utgångsvillkor som loopkroppen aldrig kan uppfylla eftersom räknaren bara uppdateras på vissa grenar.
- Antaganden om hoppade loopar — kod efter loopen som läser en variabel som loopkroppen förväntades sätta, vilket misslyckas när loopen körs noll gånger.
- Kapacitets- och prestandafel — en loop som är korrekt men läser om databasen vid varje pass, så kostnaden växer med antalet iterationer.
- Kapslad loop-interferens — en inre loop som återanvänder den yttre loopräknaren och tyst ändrar det yttre iterationsräknaren.
Eftersom varje fel mappas till ett specifikt iterationsantal är de fel som uppstår här enkla att reproducera och snabba att åtgärda jämfört med fel som hittas vid högre testnivåer.
Looptestning jämfört med andra testtekniker för kontrollstrukturer
Looptestning är en medlem i kontrollstrukturfamiljen och är lätt att förväxla med angränsande tekniker. Tabellen nedan skiljer dem åt.
| Teknik | Vad den riktar sig till | Typiskt täckningsmål |
| Slingtestning | Loopkonstruktioner: ingång, iterationsantal och utgång | Noll-, ett-, typisk- och gräns-iterationsräkningar för varje loop |
| Tillståndstestning | Booleska uttryck i beslut | Varje villkor utvärderades både sant och falskt |
| Dataflödestestning | Definition och användning av varje variabel | Varje definition-att-använda-par utförs minst en gång |
| Testning av grundväg | Oberoende vägar genom kontrollflödesgrafen | Ett antal vägar lika med den cyklomatiska komplexiteten |
I praktiken kompletterar dessa tekniker snarare än konkurrerar. Cyklomatisk komplexitet visar hur många oberoende vägar som finns, basvägstestning täcker dem, och looptestning lägger sedan till de iterationsantal som vägtäckning ensam inte skulle tvinga fram. Alla är dynamisk testning aktiviteter, eftersom koden måste köras för att resultaten ska kunna observeras.
Begränsning i looptestning
Tekniken har verkliga gränser, och att känna till dem förhindrar överinvestering.
- Slingbuggar dyker mest upp i mjukvara på låg nivå
- De buggar som identifieras under looptestning är inte särskilt subtila
- Många av buggarna kan upptäckas av operativsystemet, eftersom de orsakar minnesgränsöverträdelser, detekterbara pekarfel och liknande fel.
- Att identifiera klassen för varje loop och testa den därefter kostar tid, vilket är svårt att rättfärdiga på kodvägar som medför liten risk.
