what is test harness
Jeg er ikke en stor fan av etiketter. Her er hva jeg mener med det.
Hvis jeg må sjekke noen få aspekter før jeg avgjør om QA kan startes eller ikke, vil jeg bare lage en liste og utføre handlingen. Etter min mening spiller det ingen rolle om jeg offisielt kaller det en 'Test readiness review' -operasjon eller ikke - så lenge jeg gjør det jeg skal gjøre, tror jeg det ikke er behov for å kalle det et spesifikt navn eller etikett. .
Men jeg står korrigert. Nylig lærte jeg Agile-scrum-modellen for programvareutvikling i klassen min. Det var en spørsmål ' hvordan utføres testing i en Agile-metode? ”Jeg forklarte to metoder - den ene er hvor vi prøver å inkludere den i hver sprint, og den andre er en beste praksis jeg har lært fra førstehånds implementering - som er å forsinke en QA sprint med hensyn til utviklingen.
En av studentene mine spurte meg om det finnes et navn på den andre, og det gjorde jeg ikke fordi jeg aldri la vekt på navnene selv.
Men i det øyeblikket følte jeg hvor viktig det var å merke en prosess på riktig måte for å sikre at vi har et begrep å referere til prosessen vi snakker om.
Derfor skal vi i dag gjøre nettopp det: Lær prosessen bak begrepet “Test Harness”.
Som jeg nevnte tidligere i noen av mine tidligere artikler: mye kan forstås fra den bokstavelige betydningen av navnet. Så sjekk ordboken din for hva 'sele' betyr, og den store avsløringen av om det gjelder, i dette tilfellet, er noe vi vil se på slutten.
Det er to sammenhenger hvor testsele brukes:
- Automatiseringstesting
- Integrasjonstesting
La oss begynne med den første:
Hva du vil lære:
- Kontekst 1: Test sele i testautomatisering
- Kontekst 2: Test sele i integrasjonstesting
- For å konkludere:
- Anbefalt lesing
Kontekst 1: Test sele i testautomatisering
I de automatiseringstesting verden, Test sele refererer til rammeverket og programvaresystemene som inneholder testskriptene, nødvendige parametere (med andre ord data) for å kjøre disse skriptene, samle testresultater, sammenligne dem (om nødvendig) og overvåke resultatene.
Jeg skal prøve å gjøre dette enklere ved hjelp av et eksempel.
Eksempel:
Hvis jeg snakket om et prosjekt som bruker HP Quick Test Professional (nå UFT) for funksjonstesting, HP ALM er koblet til å organisere og administrere alle skriptene, løpene og resultatene, og dataene plukkes fra en MS Access DB - Følgende vil være testselen for dette prosjektet:
dobbeltkoblet liste c ++ kode
- Selve QTP (UFT) -programvaren
- Skriptene og den fysiske plasseringen der de er lagret
- Testen setter
- MS Access DB for å levere parametere, data eller de forskjellige forholdene som skal leveres til testskriptene
- HP ALM
- Testresultatene og de sammenlignende overvåkingsattributtene
Som du kan se, blir programvaresystemer (automatisering, testadministrasjon osv.), Data, forhold, resultater - alle sammen en integrert del av testselen - den eneste utelukkelsen er AUT selv.
Kontekst 2: Test sele i integrasjonstesting
Nå er det på tide å utforske hva testsele betyr i kontekst av “Integrasjonstesting” .
Integrasjonstesting er å sette sammen to eller moduler (eller enheter) kode som samhandler med hverandre og å sjekke om den kombinerte oppførselen er som forventet eller ikke.
Ideelt sett bør integrasjonstesting av to moduler og være mulig å utføre når begge er 100% klare, enhetstestede og godt i bruk.
Imidlertid lever vi ikke i en perfekt verden - noe som betyr at en eller flere moduler / enheter av kode som skal være de inngående elementene i integrasjonstesten, kanskje ikke er tilgjengelige. For å løse denne situasjonen har vi stubber og drivere.
Stud er vanligvis et stykke kode som har begrenset funksjon og vil erstatte eller proxy for den faktiske kodemodulen som må ta plass.
Eksempel: For å forklare dette nærmere, la meg bruke et scenario
Hvis det er en enhet A og enhet B som skal integreres. Også at Enhet A sender data til Enhet B eller med andre ord, Enhet A kaller Enhet B.
Enhet A hvis 100% tilgjengelig og enhet B ikke er, kan utvikleren skrive et stykke kode som er begrenset i sin evne (hva dette betyr er enhet B hvis den har 10 funksjoner, bare 2 eller 3 som er viktige for integrering med A) vil bli utviklet og brukes til integrering. Dette kalles a STUB.
Integrasjonen ville nå være: Enhet A-> Stub (erstatter B)
På den annen side, hvis enhet A er 0% tilgjengelig og enhet B er 100% tilgjengelig, må simuleringen eller proxyen være enhet A her. Derfor når en anropsfunksjon erstattes av en hjelpekode, kalles den SJÅFØR .
Integrasjonen, i dette tilfellet, ville være det : DRIVER (erstatter A) -> Unit B
Hele rammeverket: Prosessen med å planlegge, lage og bruke stubber og / eller drivere for å utføre integrasjonstesten kalles Test Harness.
Merk : eksemplet ovenfor er begrenset, og sanntidsscenariet er kanskje ikke så enkelt eller så greit som dette. Sanntidsapplikasjoner har komplekse og sammensatte integreringspunkter.
For å konkludere:
Som alltid mener STH at den selv mest tekniske definisjonen kan stamme fra begrepets enkle, bokstavelige betydning.
Ordboken på smarttelefonen min forteller meg at en 'sele' er (se under verbsammenheng):
“Å bringe under betingelser for effektiv bruk; få kontroll over for en bestemt slutt; “
Etter dette og tilpasse dette til testing:
“En testsele er ganske enkelt å lage riktig rammeverk og bruke den (og alle dens bestanddeler) til å kontrollere hele aktiviteten for å få mest mulig ut av situasjonen - enten det er automatisering eller integrering. “
Der hviler vi saken vår.
Noen få ting til før vi er ferdige:
Spørsmål: Hva er fordelene med en testsele?
Nå, vil du spørre hvilken betydning pusten har for menneskelivet - det er iboende, ikke sant? Tilsvarende er et rammeverk for å teste effektivt som et gitt. Fordelen, hvis vi må stave det med så mange ord - jeg vil si, hver testprosess har en testsele, enten vi bevisst sier at det er 'Test-selen' eller ikke. Det er som å reise og kjenne ruten, destinasjonen og all den andre dynamikken på reisen.
Spørsmål: Hva er forskjellen mellom testsele og testramme ?
Jeg personlig synes at sammenligning og kontrast ikke ofte er den rette tilnærmingen når jeg forstår relaterte begreper fordi linjene ofte er uskarpe. Som et svar på det spørsmålet, vil jeg si at testselen er spesifikk og testrammen er generisk. For eksempel vil en testsele inkludere den nøyaktige informasjonen om testadministrasjonsverktøyet ned til påloggings-ID-ene som skal brukes. Et testrammeverk vil derimot ganske enkelt si at et testadministrasjonsverktøy vil gjøre de respektive aktivitetene.
Q. Er det noen testseleverktøy ?
Test sele inkluderer verktøy - som automatiseringsprogramvare, programvare for testadministrasjon osv. Det er imidlertid ingen spesifikke verktøy for å implementere en test sele. Alle eller hvilket som helst verktøy kan være en del av Test Harness: QTP, JUnit, HP ALM - alle kan være inngående verktøy for en hvilken som helst Test Harness.
Om forfatteren: Denne artikkelen er skrevet av STH-teammedlem Swati S.
Og alltid med definisjoner, det er alltid forskjeller i meninger. Vi ønsker dine meninger velkommen og elsker å høre hva du synes. Du er velkommen til å legge igjen en kommentar, spørsmål eller forslag nedenfor.
Anbefalt lesing
- Lastetesting med HP LoadRunner-opplæringsprogrammer
- Råd om programvaretesting for nybegynnere
- Beste verktøy for testing av programvare 2021 (QA Test Automation Tools)
- Forskjellene mellom enhetstesting, integrasjonstesting og funksjonstesting
- Mister testere grepet over testing på grunn av automatisering?
- Global programvaretestingsvirksomhet når snart 28,8 milliarder dollar
- Hvordan holder jeg motivasjonen levende i programvaretestere?
- Testing Primer eBook Download