Hvad er Test Sele? (Eksempler)

Test sele i softwaretest

Test sele i softwaretest er en samling af stubber, drivere og andre understøttende værktøjer, der kræves for at automatisere testudførelsen. Testsele udfører test ved at bruge et testbibliotek og genererer testrapporter. Testsele indeholder al den information, der er nødvendig for at kompilere og køre en test som testcases, target deployment port (TDP), kildefil under test, stubs osv.

Kort sagt, en kabelholder omslutter den komponent, du vil verificere, i et kontrolleret miljø. Manglende tilstødende moduler erstattes af små dummy-programmer, input kommer fra et fast datasæt, og hvert resultat skrives til en log i stedet for at blive aflæst fra en skærm. De følgende afsnit forklarer, hvorfor teams bygger en, hvad den er lavet af, hvordan den kører, og hvor den passer ind.

Hvorfor bruge testsele?

Der findes en ledningsnet, der fjerner ventetiden fra testcyklussen. Fordi den simulerer det, der endnu ikke er klar, en software test Teamet kan begynde at verificere adfærd i den første sprint i stedet for efter den endelige integration. Diagrammet nedenfor viser, hvor en sele sidder mellem testscriptene og den applikation, der testes.

• Automatiser testprocessen
• Udfør testpakker af testcases
• Generer tilknyttede testrapporter
• Support til debugging
• At registrere testresultaterne for hver af testene
• Hjælper udviklerne med at måle kodedækning på kodeniveau
• Øg systemets produktivitet gennem automatisering
• Forbedre kvaliteten af ​​softwarekomponenter og applikationer
• At håndtere den komplekse tilstand, som testere har svært ved at simulere

Disse gevinster betyder mest ved korte udgivelsescyklusser. Når kode sendes flere gange om ugen, koster en fejl, der overlever til integrationsfasen, langt mere at trace end én, der bliver fanget mod en stump på den dag, den blev skrevet. Den gevinst kommer dog først, når selen er samlet af de rigtige dele.

Nøglekomponenter i en testsele

En sele er ikke et enkelt program, men en samling af dele, der hver især fjerner én forhindring, som ellers ville forhindre en test i at køre uovervåget.

• Testscripts: Automatiserede instruktioner, der angiver de trin, der skal udføres, og det forventede resultat, skrevet i henhold til test script konventioner.
• Testudførelsesmotor: Den løber, der læser scripts i rækkefølge, løser afhængigheder og udløser sekventiel eller parallel udførelse.
• Testdatalager: Inputværdier, der holdes uden for scriptet i CSV, JSON, XML eller en seedet database, ofte udfyldt af test værktøjer til datagenerering.
• chauffører: Dummy-kaldende moduler, der kalder den komponent, der testes, når det virkelige øvre lag, såsom en brugergrænseflade, er ufærdigt.
• Stubbe: Dummy kaldte moduler, der returnerede standardsvar, for eksempel en betalingstjeneste, der svarede "Betaling gennemført" uden at kontakte en bank.
• Outputvalidator: Påstandslogik, der sammenligner det faktiske output med den forventede værdi og markerer hvert tilfælde som bestået eller ikke bestået.
• Logførings- og rapporteringslag: Tidsstempler, skærmbilleder, konsoloutput og et kørselsresumé, der afslører enhver fejl tracmulig bagefter.

Fjern en hvilken som helst del, og selen holder op med at være automatisk, fordi der så skal leveres noget manuelt på hver tur.

Hvordan fungerer en testsele?

En sele gentager den samme løkke ved hver udførelse. At kende den løkke fortæller dig præcis, hvor din egen automatiseringstest aktiver tilsluttes, og hvilket trin der fejler, når en kørsel bliver rød.

1. Forbered miljøet: Harnesset løser miljøkonfigurationen, åbner forbindelser og indlæser fixtures, så hver kørsel starter fra den samme kendte tilstand.
2. Indlæs testscripts: Scripts, parametre og forventede resultater læses fra arkivet. Der indtastes intet under kørsel, hvilket gør en anden kørsel sammenlignelig med den første.
3. Erstat de manglende moduler: Chauffører træder i stedet for opkaldere, der endnu ikke findes, og stubber træder i stedet for tjenester, der er ufærdige, ustabile eller dyre at ringe til.
4. Aktivér den applikation, der testes: Udførelsesmotoren udløser den arbejdsgang, der er beskrevet af scriptet, uanset om det er et metodekald eller et API anmodning eller en browserinteraktion.
5. Registrer det faktiske output: Returværdier, svarnyttelast, databaserækker, loglinjer og skærmtilstand registreres alle, efterhånden som de produceres.
6. Sammenlign med forventede resultater: Outputvalidatoren foretager en assert på hver registreret værdi. Enhver uoverensstemmelse markerer sagen som mislykket og registrerer både den forventede og den observerede værdi.
7. Log og rapportér: Selen skriver et tidsstemplet trace af kørslen og genererer en bestået/ikke bestået-rapport, som en udvikler kan læse uden at køre noget igen.
8. Riv ned: Midlertidige data, forbindelser og stub-tilstand ryddes, så den næste sag ikke kan arve rester fra denne.

💡 Tip: Opdater dine stubber, når det rigtige modul ændres. En stubber, der stadig svarer med sidste kvartals format, vil rapportere en grøn kørsel, mens liveintegrationen allerede er brudt.

Et bearbejdet eksempel gør løkken konkret. Antag, at betalingssiden er klar, men betalingsgatewayen ikke er. En chauffør afsender den anmodning, som grænsefladen normalt ville sende, en stub svarer først med "Betaling gennemført" og derefter med en timeout, og validatoren bekræfter ordren i det ene tilfælde og en gentagelsesprompt i det andet. Begge stier verificeres, før gateway-teamet skriver en linje kode.

Der er to sammenhænge, ​​hvor Test Sele bruges

Den samme mekanisme tjener to forskellige formål, og ordforrådet ændrer sig en smule afhængigt af hvilket man er i.

1. Automatiseringstest: Den indeholder test scriptsparametre, der er nødvendige for at køre disse scripts og indsamle resultater for at analysere det
2. Integrationstest: Det bruges til at sammensætte to enheder kode eller modul, der interagerer med hinanden for at kontrollere, om den kombinerede adfærd er som forventet eller ej

Overvej et loginmodul og et profilmodul, der skal udveksle et brugertoken. I integrationskonteksten simulerer en driver et vellykket login og overfører tokenet til profillogikken, så datakortetping, tilladelseskontrollen og skærmgengivelsen kan alle verificeres, før den rigtige godkendelsestjeneste er færdig. I automatiseringskonteksten tilføjes det samme par af cases til en suite og køres igen på hvert build uden at nogen rører det igen.

Typer af testseler

Fordi software er bygget i lag, er en harness normalt specialiseret til det lag, den verificerer. Fire typer dækker næsten ethvert projekt.

A enhedstestledning udfører de mindste stykker kode, såsom en enkelt funktion eller metode, hvor hver afhængighed erstattes af en stub. Den er den hurtigste at køre og den billigste at vedligeholde, hvilket er grunden enhedstest Suiter er normalt den første ledning, et team bygger. Test af en skatteberegning uden at røre faktureringsmodulet er en typisk anvendelse.

An integrationstestsele kontrollerer, at to eller flere moduler samarbejder korrekt, og er det lag, hvor dataafvigelser og mislykkede opkald dukker op. Det er den harness, der er beskrevet i integrationstest konteksten ovenfor, for eksempel verifikation af, at en ordretjeneste overleverer den korrekte nyttelast til en betalingstjeneste.

A systemtestledning driver et komplet end-to-end flow på tværs af grænseflade, service og database, så system test kan bekræfte, at forretningsreglerne gælder, når alle lag er til stede. regressionstestudstyr kører derefter den akkumulerede suite igen efter hver ændring, hvilket er det, der gør regressionstest praktisk, når flere hundrede scenarier skal gentages ved hver sammenlægning.

Test seleværktøjer

Hver af disse typer er normalt bygget på et eksisterende værktøj i stedet for fra bunden. De to klassiske valgmuligheder er fortsat enhedsniveau-frameworks:

• Junit: Værktøj brugt under brug Java
• Nunit: Værktøj brugt til brug .Net framework

Ud over disse to tilføjer de fleste teams værktøjer, der udvider kapaciteten til browseren, API-laget eller belastningsprofilen. Tabellen nedenfor viser de almindelige muligheder i forhold til den rolle, hver enkelt spiller.

Uanset hvilken kombination du vælger, tjener ledningsnettet sig først ind, når det kører uden opsyn, så tilslut det til en kontinuerlig integration job tidligt. Et bredere katalog af muligheder er angivet i Guru99 testværktøjer opsummering. Én sondring skaber stadig forvirring, og det er værd at afklare, før du vælger noget.

Testsele vs testramme

En harness og et automatiseringsframework behandles ofte som det samme, men de besvarer forskellige spørgsmål: harnessen er det, der udfører en test, mens frameworket er den struktur, som tests designes inden for. Tabellen nedenfor viser dem side om side.

Ofte Stillede Spørgsmål