Hva er testsele? (Eksempler)

Test sele i programvaretesting

Test sele i programvaretesting er en samling av stubber, drivere og andre støtteverktøy som kreves for å automatisere testkjøring. Testsele utfører tester ved å bruke et testbibliotek og genererer testrapporter. Testselen inneholder all informasjonen som trengs for å kompilere og kjøre en test som testtilfeller, måldistribusjonsport (TDP), kildefil under test, stubber, etc.

Enkelt sagt, en sele pakker komponenten du vil verifisere inn i et kontrollert miljø. Nærliggende moduler som mangler erstattes av små dummy-programmer, input kommer fra et fast datasett, og hvert resultat skrives til en logg i stedet for å leses fra en skjerm. Avsnittene som følger forklarer hvorfor team bygger en, hva den er laget av, hvordan den kjører og hvor den passer inn.

Hvorfor bruke testsele?

Det finnes en ledningsnett for å fjerne venting fra testsyklusen. Fordi den simulerer det som ikke er klart ennå, en programvaretesting Teamet kan begynne å verifisere atferd i den første sprinten i stedet for etter den endelige integrasjonen. Diagrammet nedenfor viser hvor en sele sitter mellom testskriptene og applikasjonen som testes.

• Automatiser testprosessen
• Utfør testserier med testtilfeller
• Generer tilknyttede testrapporter
• Støtte for feilsøking
• For å registrere testresultatene for hver av testene
• Hjelper utviklerne med å måle kodedekning på kodenivå
• Øk produktiviteten til systemet gjennom automatisering
• Forbedre kvaliteten på programvarekomponenter og applikasjoner
• For å håndtere den komplekse tilstanden som testere synes er vanskelig å simulere

Disse gevinstene er viktigst ved korte utgivelsessykluser. Når kode sendes flere ganger i uken, koster en feil som overlever til integrasjonsstadiet mye mer å trace enn én som blir tatt mot en stump den dagen den ble skrevet. Den belønningen kommer imidlertid bare når selen er satt sammen av de riktige delene.

Viktige komponenter i en testsele

En sele er ikke et enkelt program, men en samling av deler, der hver del fjerner én hindring som ellers ville hindret en test i å kjøre uten tilsyn.

• Testskript: Automatiserte instruksjoner som angir trinnene som skal utføres og resultatet som kan forventes, skrevet i henhold til testskript konvensjoner.
• Testutførelsesmotor: Løperen som leser skript i rekkefølge, løser avhengigheter og utløser sekvensiell eller parallell utførelse.
• Testdatalager: Inndataverdier som holdes utenfor skriptet i CSV, JSON, XML eller en seedet database, ofte fylt ut av teste datagenereringsverktøy.
• drivere: Dummy-kallende moduler som kaller komponenten som testes når det virkelige øvre laget, for eksempel et brukergrensesnitt, er uferdig.
• Stubber: Dummy kalte opp moduler som returnerte ferdigbehandlede svar, for eksempel en betalingstjeneste som svarte «Betaling vellykket» uten å kontakte en bank.
• Utdatavalidator: Påstandslogikk som sammenligner faktisk utgang med forventet verdi og markerer hvert tilfelle som bestått eller ikke bestått.
• Logging- og rapporteringslag: Tidsstempler, skjermbilder, konsollutdata og et kjøresammendrag som gjør alle feil tracmulig etterpå.

Fjern en hvilken som helst del, og selen slutter å være automatisk, fordi noe da må leveres for hånd på hver tur.

Hvordan fungerer en testsele?

En sele gjentar den samme løkken ved hver utførelse. Å vite at løkken forteller deg nøyaktig hvor din egen automatiseringstesting ressurser kobles til, og hvilket trinn som mislykkes når en kjøring blir rød.

1. Forbered miljøet: Selen løser miljøkonfigurasjonen, åpner tilkoblinger og laster inn inventar, slik at hver kjøring starter fra samme kjente tilstand.
2. Last inn testskriptene: Skript, parametere og forventede resultater leses fra depotet. Ingenting skrives inn under kjøring, noe som gjør en andre kjøring sammenlignbar med den første.
3. Erstatt de manglende modulene: Sjåfører vikarierer for innringere som ikke finnes ennå, og «stubber» vikarierer for tjenester som er uferdige, ustabile eller dyre å ringe til.
4. Kall applikasjonen som testes: Utførelsesmotoren utløser arbeidsflyten beskrevet av skriptet, enten det er et metodekall, en API forespørsel eller en nettleserinteraksjon.
5. Registrer den faktiske utgangen: Returverdier, responsnyttelaster, databaserader, logglinjer og skjermtilstand registreres alle etter hvert som de produseres.
6. Sammenlign med forventede resultater: Utdatavalidatoren bekrefter hver registrerte verdi. Enhver avvik markerer saken som mislykket og registrerer både den forventede og den observerte verdien.
7. Logg og rapporter: Selen skriver et tidsstemplet trace av kjøringen og genererer en bestått/ikke bestått-rapport som en utvikler kan lese uten å kjøre noe på nytt.
8. Riv ned: Midlertidige data, tilkoblinger og stub-tilstand slettes, slik at den neste saken ikke kan arve rester fra denne.

💡 Tips: Oppdater stubbene dine når den virkelige modulen endres. En stubb som fortsatt svarer med formatet fra forrige kvartal vil rapportere en grønn løp mens live-integrasjonen allerede er ødelagt.

Et utarbeidet eksempel konkretiserer løkken. Anta at betalingssiden er klar, men ikke betalingsgatewayen. En sjåfør sender forespørselen som grensesnittet normalt ville sendt, en stub svarer først med «Betaling vellykket» og deretter med en tidsavbrudd, og validatoren bekrefter bestillingen i det ene tilfellet og en ny prøveforespørsel i det andre. Begge banene verifiseres før gateway-teamet skriver en linje med kode.

Det er to sammenhenger hvor Test Sele brukes

Den samme mekanismen tjener to forskjellige formål, og vokabularet endres litt avhengig av hvilket du er i.

1. Automatiseringstesting: Den inneholder testskript, parametere som er nødvendige for å kjøre disse skriptene og samle resultater for å analysere det
2. Integrasjonstesting: Den brukes til å sette sammen to enheter med kode eller modul som samhandler med hverandre for å sjekke om den kombinerte oppførselen er som forventet eller ikke

Tenk deg en innloggingsmodul og en profilmodul som må utveksle et brukertoken. I integrasjonskonteksten simulerer en driver en vellykket innlogging og overfører tokenet til profillogikken, slik at datakartetping, tillatelsessjekken og skjermgjengivelsen kan alle verifiseres før den virkelige autentiseringstjenesten er fullført. I automatiseringskonteksten legges det samme paret med saker til en suite og kjøres på nytt på hver build uten at noen berører det igjen.

Typer testseler

Fordi programvare er bygget i lag, er en sele vanligvis spesialisert til laget den verifiserer. Fire typer dekker nesten alle prosjekter.

A enhetstestledning kjører de minste kodebitene, som en enkelt funksjon eller metode, der hver avhengighet erstattes av en stub. Den er raskest å kjøre og billigst å vedlikeholde, og det er derfor enhetstesting Suiter er vanligvis den første selen et team bygger. Testing av en skatteberegning uten å berøre faktureringsmodulen er en typisk bruk.

An integrasjonstestsele kontrollerer at to eller flere moduler samarbeider riktig, og er laget der dataavvik og mislykkede anrop dukker opp. Det er ledningsnettet som er beskrevet i integrasjonstesting konteksten ovenfor, for eksempel å bekrefte at en bestillingstjeneste overleverer riktig nyttelast til en betalingstjeneste.

A systemtestsele driver en komplett ende-til-ende-flyt på tvers av grensesnitt, tjeneste og database, slik at systemtesting kan bekrefte at forretningsreglene gjelder når alle lag er til stede. regresjonstestsele kjører deretter den akkumulerte pakken på nytt etter hver endring, noe som gjør Regresjonstesting praktisk når flere hundre scenarier må gjentas ved hver sammenslåing.

Test seleverktøy

Hver av disse typene er vanligvis bygget på et eksisterende verktøy i stedet for fra bunnen av. De to klassiske valgene er fortsatt enhetsnivårammeverk:

• Junite: Verktøy som brukes under bruk Java
• Nunit: Verktøy som brukes til bruk .Net rammeverk

Utover disse to legger de fleste team til verktøy som utvider verktøyene til nettleseren, API-laget eller lastprofilen. Tabellen nedenfor kartlegger de vanlige alternativene i forhold til rollen hver av dem spiller.

Uansett hvilken kombinasjon du velger, betaler ledningsnettet seg bare tilbake når det kjører uten tilsyn, så koble det til en kontinuerlig integrering jobb tidlig. En bredere katalog med alternativer er oppført i Guru99 testverktøy oppsummering. Én distinksjon forårsaker fortsatt forvirring, og det er verdt å avgjøre før du velger noe.

Testsele vs testrammeverk

En sele og et automatiseringsrammeverk blir ofte behandlet som det samme, men de svarer på forskjellige spørsmål: selen er det som utfører en test, mens rammeverket er strukturen som tester utformes innenfor. Tabellen nedenfor setter dem side om side.

Spørsmål og svar