Hvad er trådtest i softwaretest?
Redaktionelle team
⚡ Smart opsummering
Trådtestning verificerer den centrale funktionelle kapacitet for en enkelt forretningsopgave, mens den bevæger sig gennem et integreret system, og den kører tidligt i integrationstesten i stedet for efter at hver komponent er færdig.
Hvad er trådtestning?
Trådtestning er en softwaretesttype, der verificerer den vigtigste funktionelle kapacitet i en specifik opgave, kaldet en tråd. Det udføres normalt i den tidlige fase af integrationstest fase. Trådbaseret testning er en af de trinvise strategier, der anvendes under systemintegrationstestning. Af den grund beskrives en trådtest mere korrekt som en trådinteraktionstest.
En tråd her er ikke kun en tråd om operativsystemet. software Engineering I praksis er en tråd én komplet forretningstransaktion — for eksempel "kunde afgiver en ordre" — tracgår gennem hvert modul, den berører. Trådtestning spørger, om den enkelte sti stadig opfører sig korrekt, når modulerne er forbundet.
Diagrammet nedenfor viser, hvordan individuelle tråde integreres og øves som et delsystem, før det fulde system samles.
Typer af trådtestning
Trådbaseret testning er klassificeret i to kategorier, og sondringen bestemmer både testdataene og de defekter, du sandsynligvis vil finde.
- Test af enkelttråd: En test med én tråd involverer én applikationstransaktion ad gangen. Kun én anmodning behandles, så responsadfærden er forudsigelig, og testen er nem at scripte og gentage.
- Multitrådstestning: En flertrådstest involverer flere samtidig aktive transaktioner ad gangen. Separate tråde forberedes til den samme tjeneste, så responsivitet og håndtering af delte tilstande kan observeres under samtidig belastning.
En transaktion, der består problemfrit i en enkelttrådstest, kan stadig mislykkes i en kørsel med flere tråde, fordi den anden kørsel tilføjer konkurrence om de samme poster, forbindelser og hukommelse.
Sådan laver du trådtest
Trådprocessen fokuserer på integrationsaktiviteterne snarere end hele udviklingslivscyklussen. I praksis fungerer fremgangsmåden som følger.
- Trådbaseret test er en generaliseret form for sessionsbaseret test, idet sessioner er en form for tråd, men en tråd er ikke nødvendigvis en session.
- Tråden eller programmet (lille funktionalitet) integreres og testes trinvist som et delsystem og udføres derefter for hele systemet.
- På det laveste niveau giver det integratorer bedre viden om omfanget af, hvad der skal testes.
- I stedet for at teste softwarekomponenter direkte kræver det, at integratorer koncentrerer sig om at teste logiske udførelsesstier i hele systemets kontekst.
Da arbejdsenheden er en forretningssti snarere end en komponent, ligger trådtestning naturligt mellem modultestning og fuld system test.
Tips til test af flere tråde
Flertrådede defekter afhænger af timing, så en enkelt ren kørsel beviser meget lidt. Tipsene nedenfor øger chancen for at opdage dem.
- Test dit multithreaded-program ved at udføre det gentagne gange med en forskellig blanding af kørende applikationer.
- Test dit multithreaded-program ved at have flere instanser af programmet aktive på samme tid.
- Udfør dit multithreaded-program på forskellige hardwaremodeller med varierende stressniveauer og arbejdsbelastninger.
- Brug kodeinspektion, da nogle synkroniseringsfejl er lettere at læse end at reproducere.
- Indsaml kun fejl og mangler, der opstod i andre tråde end den primære.
Almindelige defekter fundet under gevindtestning
Samtidighedsfejl annoncerer sig sjældent med en ren stak trace. Kategorierne nedenfor tegner sig for det meste af, hvad en flertrådskørsel afslører, og hver enkelt har et særskilt symptom, der er værd at anerkende.
- Løbsbetingelser: To tråde læser og skriver den samme værdi uden rækkefølge, så det endelige resultat afhænger af, hvilken tråd der sluttede først. Symptom: totaler, der er korrekte i nogle kørsler og forkerte i andre.
- Dødlåsning: To tråde har hver en lås, som den anden har brug for, og ingen af dem fortsætter. Symptom: transaktionen hænger på ubestemt tid i stedet for at fejle.
- Ressourcestrid: Tråde i kø for den samme forbindelse, filhandle eller post, og gennemløbet kollapser længe før hardwaregrænsen er nået.
- Datakorruption: Delvist skrevne delte strukturer efterlader poster i en tilstand, som ingen gyldig transaktion kunne producere.
- Sult: En tråd med lav prioritet får aldrig den ressource, den har brug for, så én brugersti får timeout, mens resten af systemet ser ud til at være i orden.
Hver af disse kræver, at den fejlende kørsel registreres i logfiler, fordi en fejl, der reproduceres én gang ud af halvtreds forsøg, ellers er umulig at identificere via proces til håndtering af fejl.
Trådtest vs. samtidighedstest vs. integrationstest
De tre begreber overlapper hinanden og blandes ofte sammen i testplaner. Tabellen adskiller dem efter hensigt.
| Aspect | Trådtestning | Samtidighedstestning | Integrationstest |
| Enhed under test | Én forretningstransaktion på tværs af moduler | Flere brugere eller tråde, der agerer på én gang | Grænseflader mellem to eller flere komponenter |
| Primært spørgsmål | Fungerer denne nøglevej fra start til slut? | Hvad går i stykker, når adgangen er samtidig? | Kommunikerer modulerne korrekt med hinanden? |
| Typisk stadie | Tidlig integrationstest | System- eller ydeevnetest | Efter enhedstestning |
| Målrettede defekter | Ødelagte udførelsesstier, manglende overdragelser | Dødlåse, løbsbetingelser, låsekamp | Uoverensstemmelser i grænsefladen, forkerte datatracts |
| Relationship | Overlap mellem flertrådsvarianter og samtidighedstest | Bredere end flertrådsudsnittet af trådtestning | Trådtestning er en trinvis strategi indeni |
Kort fortalt, samtidighedstestning spørger, hvad samtidig adgang gør ved systemet, mens trådtest spørger, om én vigtig sti overhovedet overlever integration. Teams, der kører begge, planlægger normalt trådtest først.
Fordele ved gevindtestning
Teknikken fortjener sin plads i en integrationsplan af flere praktiske årsager.
- Vigtige forretningsstier valideres tidligt, så en ødelagt overdragelse findes, før hele systemet er samlet.
- Integratorer får et klart billede af omfanget, fordi testenheden er en genkendelig transaktion snarere end en abs.tract-komponentgrænse.
- Test af logiske udførelsesstier i systemkontekst afslører fejl, der isolerede komponenttest kan ikke se.
- Multitrådskørsel afslører samtidighedsfejl — fastlåste situationer, kapløbsbetingelser og ressourcekonflikter — som ellers ville nå produktion.
- Inkrementel integration holder fejlfindingsoverfladen lille, da kun én tråd tilføjes ad gangen.
- Resultaterne går direkte ind i regressionstest, fordi en forbipasserende tråd er en oplagt kandidat til regressionssuiten.
Ulemper ved trådtestning
- Ved multithreading-testning er den største udfordring at kunne programmere en reproducerbar test til en enhedstest.
- Det er en udfordrende opgave at skrive enhedstests til multitrådet kode.
- Testkriterier for multitrådstest adskiller sig fra single-thread-test. For multitrådstest varierer faktorer som hukommelsesstørrelse, lagerkapacitet og timingproblemer, når koden kaldes på forskellig hardware.
- Tråde kan ikke testes, før de moduler, de krydser, er tilgængelige, så planlægningen afhænger af integrationsrækkefølgen.
- Periodiske fejl er lette at afvise som miljøstøj, hvilket gør disciplineret logning afgørende.
