Wat is threadtesten bij het testen van software?

Wat is threadtesten?

Draadtesten Dit is een type softwaretest dat de belangrijkste functionele mogelijkheden van een specifieke taak, een zogenaamde thread, verifieert. Het wordt meestal in een vroeg stadium van de ontwikkeling uitgevoerd. integratie testen fase. Testen op basis van threads is een van de incrementele strategieën die worden toegepast tijdens systeemintegratietesten. Om die reden kan een threadtest beter worden omschreven als een test voor interactie tussen threads.

Een thread is hier niet alleen een thread van het besturingssysteem. software engineering In deze terminologie is een thread één complete zakelijke transactie — bijvoorbeeld "klant plaatst een bestelling" — tracHet pad wordt door elke module die het aanraakt heen geleid. Bij threadtesten wordt nagegaan of dat ene pad zich nog steeds correct gedraagt ​​nadat de modules met elkaar zijn verbonden.

Het onderstaande diagram laat zien hoe individuele threads worden geïntegreerd en als subsysteem worden getest voordat het volledige systeem wordt samengesteld.

Soorten draadtesten

Testen op basis van threads wordt onderverdeeld in twee categorieën, en het onderscheid daartussen bepaalt zowel de testgegevens als de defecten die je waarschijnlijk zult vinden.

• Testen met één thread: Een single-thread test omvat één applicatietransactie tegelijk. Er wordt slechts één verzoek verwerkt, waardoor het responsgedrag voorspelbaar is en de test eenvoudig te scripten en te herhalen is.
• Testen met meerdere threads: Een multithread-test omvat meerdere gelijktijdig actieve transacties. Er worden aparte threads voorbereid voor dezelfde service, zodat de responsiviteit en de afhandeling van gedeelde status onder gelijktijdige belasting kunnen worden geobserveerd.

Een transactie die in een test met één thread probleemloos verloopt, kan in een test met meerdere threads alsnog mislukken, omdat de tweede testrun extra concurrentie creëert voor dezelfde records, verbindingen en geheugen.

Hoe u een draadtest uitvoert

Het threadproces richt zich op de integratieactiviteiten in plaats van op de volledige ontwikkelingscyclus. In de praktijk werkt de aanpak als volgt.

• Thread-gebaseerd testen is een algemene vorm van sessie-gebaseerd testen, in die zin dat sessies een vorm van thread zijn, maar een thread niet noodzakelijkerwijs een sessie is.
• De thread of het programma (kleine functionaliteit) wordt stapsgewijs geïntegreerd en getest als een subsysteem, en vervolgens uitgevoerd voor het hele systeem.
• In de meest basale vorm biedt het integrators een beter inzicht in de reikwijdte van wat er getest moet worden.
• In plaats van softwarecomponenten direct te testen, moeten integrators zich concentreren op het testen van logische uitvoeringspaden in de context van het gehele systeem.

Omdat de werkeenheid een bedrijfsproces is in plaats van een component, past threadtesten daar van nature tussenin. moduletesten en vol systeem testen.

Tips voor multithread-testen

Defecten die door meerdere threads worden veroorzaakt, zijn afhankelijk van de timing, dus een enkele foutloze run zegt weinig. De onderstaande tips vergroten de kans om ze aan het licht te brengen.

• Test je multithreaded programma door het herhaaldelijk uit te voeren met een andere combinatie van actieve applicaties.
• Test je multithreaded programma door meerdere instanties van het programma tegelijkertijd actief te hebben.
• Voer uw multithreaded programma uit op verschillende hardwaremodellen met uiteenlopende belastingniveaus en werklasten.
• Gebruik code-inspectie, aangezien sommige synchronisatiefouten gemakkelijker te lezen dan te reproduceren zijn.
• Verzamel alleen fouten en mislukkingen die zich hebben voorgedaan in andere threads dan de hoofdthread.

Veelvoorkomende defecten die tijdens draadtesten worden aangetroffen

Gelijktijdigheidsfouten kondigen zich zelden aan met een schone stack. trace. De onderstaande categorieën omvatten het grootste deel van wat een multithread-uitvoering aan het licht brengt, en elke categorie heeft een specifiek symptoom dat het herkennen waard is.

• Wedstrijdomstandigheden: Twee threads lezen en schrijven dezelfde waarde zonder volgorde, waardoor het eindresultaat afhangt van welke thread als eerste klaar is. Symptoom: totalen die bij sommige uitvoeringen correct zijn en bij andere onjuist.
• Impasse: Twee threads houden elk een vergrendeling vast die de ander nodig heeft, en geen van beide kan verder. Symptoom: de transactie blijft oneindig hangen in plaats van met een foutmelding te mislukken.
• Conflict over hulpbronnen: Threads staan ​​in de wachtrij voor dezelfde verbinding, bestandsdescriptor of record, en de doorvoer stort in ruim voordat de hardwarelimiet is bereikt.
• Data corruptie: Gedeeltelijk geschreven gedeelde structuren laten records achter in een staat die geen geldige transactie zou kunnen opleveren.
• honger: Een thread met lage prioriteit krijgt nooit de benodigde bron, waardoor één gebruikerspad een time-out krijgt terwijl de rest van het systeem er goed uitziet.

Voor elk van deze gevallen is het nodig dat de mislukte uitvoering in de logbestanden wordt vastgelegd, omdat een defect dat slechts eens in de vijftig pogingen optreedt anders onmogelijk via de logbestanden kan worden gemeld. defectbeheerproces.

Threadtesten versus gelijktijdigheidstesten versus integratietesten

De drie termen overlappen elkaar en worden vaak door elkaar gebruikt in testplannen. De tabel scheidt ze op basis van hun bedoeling.

In het kort, gelijktijdigheidstesten De vraag is wat gelijktijdige toegang met het systeem doet, terwijl threadtesten nagaan of een belangrijk pad de integratie überhaupt overleeft. Teams die beide testen uitvoeren, plannen doorgaans eerst de threadtesten in.

Voordelen van draadtesten

Deze techniek verdient om verschillende praktische redenen een plaats in een integratieplan.

• Belangrijke bedrijfsprocessen worden vroegtijdig gevalideerd, zodat eventuele problemen bij de overdracht worden opgespoord voordat het volledige systeem is samengesteld.
• Integrators krijgen een duidelijk beeld van de reikwijdte, omdat de testeenheid een herkenbare transactie is in plaats van een abstracte eenheid.tract componentgrens.
• Het testen van logische uitvoeringspaden in de systeemcontext legt fouten bloot die anders geïsoleerd zouden blijven. testen van componenten Kan niet zien.
• Bij het uitvoeren van meerdere threads komen gelijktijdigheidsproblemen aan het licht, zoals deadlocks, raceomstandigheden en conflicten met resources, die anders in de productieomgeving terecht zouden komen.
• Door stapsgewijze integratie blijft het debugoppervlak klein, omdat er telkens maar één thread wordt toegevoegd.
• De resultaten worden direct ingevoerd in regressietesten, omdat een passerende thread een voor de hand liggende kandidaat is voor de regressietestsuite.

Nadelen van draadtesten

• Bij het testen met multithreading is de grootste uitdaging het programmeren van een reproduceerbare unit-test.
• Het schrijven van unit tests voor multithreaded code is een uitdagende taak.
• De testcriteria voor multithreading verschillen van die voor single-threading. Bij multithreading variëren factoren zoals geheugengrootte, opslagcapaciteit en timingproblemen wanneer de code op verschillende hardware wordt uitgevoerd.
• Threads kunnen pas getest worden nadat de modules die ze kruisen beschikbaar zijn, dus de planning is afhankelijk van de integratievolgorde.
• Intermitterende storingen worden gemakkelijk afgedaan als omgevingsruis, waardoor nauwkeurige registratie essentieel is.

Veelgestelde vragen