what is test harness
Jag är inte ett stort fan av etiketter. Här är vad jag menar med det.
Om jag måste kontrollera några aspekter innan jag avgör om QA kan startas eller inte, kommer jag helt enkelt att göra en lista och utföra åtgärden. Enligt min mening spelar det ingen roll om jag officiellt kallar det för en 'Test readiness review' -operation eller inte - så länge jag gör vad jag ska göra, tror jag att det inte finns något behov av att kalla det ett specifikt namn eller etikett .
Men jag står rättad. Nyligen undervisade jag i min klass Agile-scrum-modell för programvaruutveckling. Det var en fråga ” hur utförs testning i en Agile-metod? ”Jag förklarade två metoder - den ena är där vi försöker inkludera den i varje sprint och den andra är en bästa praxis som jag har lärt mig från förstahandsimplementeringen - vilket är att fördröja en QA-sprint med avseende på utvecklingen.
En av mina elever frågade mig om det finns ett namn på den andra och det gjorde jag inte för jag lade aldrig tonvikten på själva namnen.
Men just nu kände jag hur viktigt det var att märka en process på lämpligt sätt för att se till att vi har en term att referera till den process vi pratar om.
Därför kommer vi idag att göra just det: Lär dig processen bakom termen 'Test Harness'.
Som jag nämnde tidigare i några av mina tidigare artiklar: mycket kan förstås från den bokstavliga betydelsen av namnet. Så kolla din ordbok för vad ”sele” betyder och den stora avslöjandet av om det gäller, i det här fallet, är något vi kommer att se i slutet.
Det finns två sammanhang där testsele används:
- Automationstestning
- Integrationstestning
Låt oss börja med den första:
Vad du kommer att lära dig:
- Kontext nr 1: Testa sele i testautomation
- Kontext # 2: Testa sele vid integrationstestning
- Sammanfattningsvis:
- Rekommenderad läsning
Kontext # 1: Testa sele i testautomation
I de automatiseringstestning värld, Testkabel refererar till ramverket och mjukvarusystemen som innehåller testskript, nödvändiga parametrar (med andra ord data) för att köra dessa skript, samla testresultat, jämföra dem (om nödvändigt) och övervaka resultaten.
Jag ska försöka göra det enklare med hjälp av ett exempel.
Exempel:
Om jag pratade om ett projekt som använder HP Quick Test Professional (nu UFT) för funktionstestning, HP ALM är länkad för att organisera och hantera alla skript, körningar och resultat och data plockas från en MS Access DB - Följande skulle vara teststammen för detta projekt:
bästa gratis video till DVD-omvandlare
- Själva programvaran QTP (UFT)
- Skripten och den fysiska platsen där de lagras
- Testet sätter
- MS Access DB för att leverera parametrar, data eller de olika förhållandena som ska levereras till testskripten
- HP ALM
- Testresultaten och de jämförande övervakningsattributen
Som du kan se blir mjukvarusystem (automatisering, testhantering, etc.), data, villkor, resultat - alla en integrerad del av testkabeln - enda undantaget är AUT själv.
Kontext # 2: Testa sele vid integrationstestning
Nu är det dags att utforska vad testsele betyder i sammanhang av “Integrationstestning” .
Integrationstestning är att sätta ihop två eller moduler (eller enheter) kod som interagerar med varandra och kontrollera om det kombinerade beteendet är som förväntat eller inte.
Helst skulle och skulle det vara möjligt att utföra integreringstestning av två moduler när båda är 100% färdiga, enhetstestade och bra att gå.
Vi lever dock inte i en perfekt värld - vilket innebär att en eller flera moduler / kodenheter som ska vara de ingående delarna av integrationstestet kanske inte är tillgängliga. För att lösa denna situation har vi stubbar och förare.
Stud är vanligtvis en kodkod som är begränsad i dess funktion och kommer att ersätta eller proxy för den faktiska kodmodulen som måste ta plats.
Exempel: För att ytterligare förklara detta, låt mig använda ett scenario
Om det finns en enhet A och enhet B som ska integreras. Även att enhet A skickar data till enhet B eller med andra ord, enhet A anropar enhet B.
Enhet A om 100% tillgänglig och enhet B inte, då kan utvecklaren skriva en kodkod som är begränsad i dess kapacitet (vad detta betyder är Enhet B om den har 10 funktioner, bara 2 eller 3 som är viktiga för integration med A) kommer att utvecklas och används för integration. Detta kallas a STUMP.
Integrationen skulle nu vara: Enhet A-> Stub (ersätter B)
Å andra sidan, om enhet A är 0% tillgänglig och enhet B är 100% tillgänglig, måste simuleringen eller proxyn vara enhet A här. Därför när en anropsfunktion ersätts av en hjälpkod kallas den FÖRARE .
Integrationen, i detta fall, skulle vara : DRIVER (ersätter A) -> Unit B
Hela ramen: Processen att planera, skapa och använda stubbar och / eller drivrutiner för att utföra integrationstestningen kallas Test Harness.
Notera : exemplet ovan är begränsat och realtidsscenariet kanske inte är så enkelt eller så enkelt som detta. Realtidsapplikationer har komplexa och sammansatta integrationspunkter.
Sammanfattningsvis:
Som alltid tror STH att även de mest tekniska definitionerna kan härledas från termens enkla, bokstavliga betydelse.
Ordboken på min smartphone berättar för mig att en 'sele' är (se under verbkontext):
”Att få under förutsättningar för effektiv användning; få kontroll över för ett visst ändamål; “
Efter detta och anpassa detta till testning:
”En testsele är helt enkelt att skapa rätt ram och använda den (och alla dess beståndsdelar) för att styra hela aktiviteten för att få ut det mesta av situationen - oavsett automatisering eller integration. “
Där vilar vi vårt fall.
Några saker till innan vi är klara:
Fråga: Vilka är fördelarna med en testkabel?
Skulle du fråga vilken betydelse andningen har för människolivet - det är inneboende, eller hur? På samma sätt är ett ramverk för att testa effektivt som en given. Fördelen, om vi måste stava det med så många ord - jag skulle säga, varje testprocess har en testkabel, oavsett om vi medvetet säger att det är 'Testkabeln' eller inte. Det är som att känna till rutten, destinationen och alla andra dynamiker på resan.
Fråga: Vad är skillnaden mellan testbälte och testramverk ?
Jag tycker personligen att jämförelse och kontrast inte ofta är rätt tillvägagångssätt när man förstår relaterade begrepp eftersom linjerna ofta är suddiga. Som svar på den frågan skulle jag säga att teststammen är specifik och testramverket är generiskt. Till exempel kommer en testkabel att innehålla den exakta informationen om testhanteringsverktyget ner till inloggnings-ID: n som ska användas. Ett testramverk, å andra sidan, säger helt enkelt att ett testhanteringsverktyg kommer att göra respektive aktiviteter.
Q. Finns det några testkablar ?
Testkablage innehåller verktyg - som automatiseringsprogramvara, programvara för testhantering etc. Det finns dock inga specifika verktyg för att implementera en testkabel. Alla eller vilket verktyg som helst kan vara en del av testkabeln: QTP, JUnit, HP ALM - alla kan vara ingående verktyg i alla testkablar.
Om författaren: Den här artikeln är skriven av STH-teammedlem Swati S.
Och alltid med definitioner, det finns alltid skillnader i åsikter. Vi välkomnar dina åsikter och älskar att höra vad du tycker. Lämna gärna en kommentar, frågor eller förslag nedan.
Rekommenderad läsning
- Lasttestning med HP LoadRunner-handledning
- Råd om programvarutestning för nybörjare
- Bästa verktyg för testning av programvara 2021 (QA Test Automation Tools)
- Skillnaderna mellan enhetstestning, integrationstestning och funktionstestning
- Förlorar testare greppet över testning på grund av automatisering?
- Global mjukvarutestning kommer snart att nå 28,8 miljarder dollar
- Hur håller jag motivationen levande i programvarutestare?
- Testing Primer eBook Download