what is test harness
Jeg er ikke en stor fan af etiketter. Her er hvad jeg mener med det.
Hvis jeg er nødt til at kontrollere nogle få aspekter, før jeg bestemmer, om QA kan startes eller ej, opretter jeg simpelthen en liste og udfører handlingen. Efter min mening betyder det ikke noget, om jeg officielt kalder det en 'Test readiness review' -operation eller ej - så længe jeg gør, hvad jeg skal gøre, tror jeg, at der ikke er behov for at kalde det et specifikt navn eller etiket .
Men jeg står korrigeret. For nylig underviste jeg i min klasse i Agile-scrum-model til softwareudvikling. Der var en spørgsmål ' hvordan udføres test i en Agile metode? ”Jeg forklarede to metoder - den ene er, hvor vi forsøger at inkludere den inden for hver sprint, og den anden er en bedste praksis, som jeg har lært fra førstehåndsimplementeringen - det vil sige at forsinke en QA-sprint med hensyn til udviklingen.
En af mine elever spurgte mig, om der er et navn til den anden, og det gjorde jeg ikke, fordi jeg aldrig lagde vægt på navnene selv.
Men i det øjeblik følte jeg, hvor vigtigt det var at mærke en proces passende for at sikre, at vi har et udtryk til at henvise til den proces, vi taler om.
Derfor vil vi i dag gøre netop det: Lær processen bag udtrykket “Test Harness”.
Som jeg nævnte før i nogle af mine tidligere artikler: meget kan forstås ud fra den bogstavelige betydning af navnet. Så tjek din ordbog for, hvad 'sele' betyder, og den store afsløring af, om det gælder, i dette tilfælde, er noget, vi vil se i slutningen.
Der er to sammenhænge, hvor testsele bruges:
- Automatiseringstest
- Integrationstest
Lad os begynde med den første:
Hvad du vil lære:
- Kontekst nr. 1: Test seletøj i testautomatisering
- Kontekst # 2: Test sele i integrationstest
- Afslutningsvis:
- Anbefalet læsning
Kontekst # 1: Test seletøj i testautomatisering
I det automatiseringstest verden, Test sele refererer til rammen og de softwaresystemer, der indeholder test-scripts, nødvendige parametre (med andre ord data) til at køre disse scripts, indsamle testresultater, sammenligne dem (om nødvendigt) og overvåge resultaterne.
Jeg vil prøve at gøre dette enklere ved hjælp af et eksempel.
Eksempel:
Hvis jeg talte om et projekt, der bruger HP Quick Test Professional (nu UFT) til funktionel test, HP ALM er knyttet til at organisere og administrere alle scripts, kørsler og resultater, og dataene er plukket fra en MS Access DB - Følgende ville være testens ledning til dette projekt:
den bedste gratis mp3 downloader til android
- QTP (UFT) -softwaren i sig selv
- Scripts og den fysiske placering, hvor de er gemt
- Testen sætter
- MS Access DB for at levere parametre, data eller de forskellige betingelser, der skal leveres til testskripterne
- HP ALM
- Testresultaterne og de sammenlignende overvågningsattributter
Som du kan se, bliver softwaresystemer (automatisering, testadministration osv.), Data, betingelser, resultater - alle en integreret del af testens ledningsnet - den eneste udelukkelse er selve AUT.
Kontekst # 2: Test sele i integrationstest
Nu er det tid til at undersøge, hvad testsele betyder i sammenhæng med “Integrationstest” .
Integrationstestning er at sammensætte to eller moduler (eller enheder) kode, der interagerer med hinanden og kontrollere, om den kombinerede adfærd er som forventet eller ej.
Ideelt set bør og ville integrationstest af to moduler være muligt, når begge er 100% klar, enhedstestet og klar til brug.
Vi lever dog ikke i en perfekt verden - hvilket betyder, at et eller flere moduler / enheder af kode, der skal være de bestanddele af integrationstesten, muligvis ikke er tilgængelige. For at løse denne situation har vi stubbe og drivere.
Stud er normalt et stykke kode, der er begrænset i sin funktion og vil erstatte eller proxy for det faktiske kodemodul, der skal træde i stedet.
Eksempel: For at forklare dette yderligere, lad mig bruge et scenario
Hvis der er en enhed A og enhed B, der skal integreres. Også, at enhed A sender data til enhed B eller med andre ord, enhed A kalder enhed B.
Enhed A, hvis 100% er tilgængelig, og enhed B ikke er, kan udvikleren skrive et stykke kode, der er begrænset i dets kapacitet (hvad dette betyder, er enhed B, hvis den har 10 funktioner, kun 2 eller 3, der er vigtige for integration med A) vil blive udviklet og bruges til integration. Dette kaldes en STUB.
Integrationen ville nu være: Enhed A-> Stub (erstatter B)
På den anden side, hvis enhed A er 0% tilgængelig og enhed B er 100% tilgængelig, skal simuleringen eller proxyen være enhed A her. Derfor når en opkaldsfunktion erstattes af en hjælpekode, kaldes den derfor CHAUFFØR .
Integrationen, i dette tilfælde, ville være : DRIVER (erstatter A) -> Enhed B
Hele rammen: Processen med planlægning, oprettelse og brug af stubber og / eller drivere til at udføre integrationstesten kaldes Test Harness.
Bemærk : ovenstående eksempel er begrænset, og realtidsscenariet er muligvis ikke så simpelt eller så ligetil som dette. Realtidsapplikationer har komplekse og sammensatte integrationspunkter.
Afslutningsvis:
Som altid mener STH, at selv de mest tekniske definitioner kan stamme fra udtrykets enkle, bogstavelige betydning.
Ordbogen på min smartphone fortæller mig, at en 'sele' er (se under verbsammenhæng):
”At bringe under betingelser for effektiv brug; få kontrol over for en bestemt ende “
Efter dette og tilpasning til test:
”En testsele er simpelthen at skabe den korrekte ramme og bruge den (og alle dens bestanddele) til at kontrollere hele aktiviteten for at få mest muligt ud af situationen - hvad enten det er automatisering eller integration. “
Der hviler vi på vores sag.
Et par ting til, før vi er færdige:
Spørgsmål: Hvad er fordelene ved en testsele?
Vil du nu spørge, hvad vejrtrækningens betydning for menneskelivet er - det er iboende, er det ikke? Tilsvarende er en ramme til effektiv test som en given. Fordelen, hvis vi er nødt til at stave det med så mange ord - jeg vil sige, hver testproces har en testsele, uanset om vi bevidst siger, at det er 'The Test sele' eller ej. Det er som at rejse at kende ruten, destinationen og alle de andre dynamikker på rejsen.
Q. Hvad er forskellen mellem testbælte og testramme ?
Jeg synes personligt, at sammenligning og kontrast ikke ofte er den rigtige tilgang, når man forstår relaterede begreber, fordi linjerne ofte er slørede. Som svar på dette spørgsmål vil jeg sige, at testselet er specifikt, og testrammen er generisk. For eksempel vil en testsele omfatte de nøjagtige oplysninger om testadministrationsværktøjet ned til de login-id'er, der skal bruges. En testramme vil derimod blot sige, at et teststyringsværktøj vil udføre de respektive aktiviteter.
Q. Er der testværktøjsværktøjer ?
Test seletøj inkluderer værktøjer - som automatiseringssoftware, testadministrationssoftware osv. Der er dog ingen specifikke værktøjer til at implementere en testsele. Alle eller ethvert værktøj kan være en del af testbælte: QTP, JUnit, HP ALM - alle kan udgøre værktøj til enhver testbælte.
Om forfatteren: Denne artikel er skrevet af STH-teammedlem Swati S.
Og altid med definitioner er der altid forskelle i meninger. Vi glæder os over dine meninger og elsker at høre, hvad du synes. Du er velkommen til at efterlade en kommentar, spørgsmål eller forslag nedenfor.
Anbefalet læsning
- Load Testing med HP LoadRunner-vejledninger
- Råd om softwaretest til nybegyndere
- Bedste softwaretestværktøjer 2021 (QA Test Automation Tools)
- Forskellene mellem enhedstest, integrationstest og funktionstest
- Mister testere deres greb over test på grund af automatisering?
- Global softwaretestvirksomhed når snart $ 28,8 milliarder
- Hvordan holder jeg motivationen levende i softwaretestere?
- Test af Primer eBook Download