Wat is testharnas? (Voorbeelden)

Testharnas bij het testen van software

Testharnas bij het testen van software is een verzameling stubs, stuurprogramma's en andere ondersteunende tools die nodig zijn om de testuitvoering te automatiseren. Testharnas voert tests uit met behulp van een testbibliotheek en genereert testrapporten. Testharnas bevat alle informatie die nodig is om een ​​test te compileren en uit te voeren, zoals testgevallen, doelimplementatiepoort (TDP), te testen bronbestand, stubs, enz.

Simpel gezegd, een testomgeving omhult het component dat je wilt verifiëren in een gecontroleerde omgeving. Ontbrekende modules in de buurt worden vervangen door kleine dummyprogramma's, de invoer komt uit een vaste dataset en elk resultaat wordt naar een logbestand geschreven in plaats van van een scherm te worden afgelezen. De volgende paragrafen leggen uit waarom teams er een bouwen, waaruit hij is opgebouwd, hoe hij werkt en waar hij thuishoort.

Waarom Testharnas gebruiken?

Er bestaat een testomgeving om wachttijden in de testcyclus te elimineren. Omdat deze alles simuleert wat nog niet gereed is, software testen Het team kan al in de eerste sprint beginnen met het verifiëren van het gedrag, in plaats van pas na de uiteindelijke integratie. Het onderstaande diagram laat zien waar een testomgeving zich bevindt tussen de testscripts en de te testen applicatie.

• Automatiseer het testproces
• Uitvoeren van testsuites van testgevallen
• Genereer bijbehorende testrapporten
• Ondersteuning voor foutopsporing
• Om de testresultaten voor elk van de tests vast te leggen
• Helpt ontwikkelaars bij het meten van de codedekking op codeniveau
• Verhoog de productiviteit van het systeem door automatisering
• Verbeter de kwaliteit van softwarecomponenten en applicaties
• Om de complexe omstandigheden te kunnen hanteren die testers moeilijk kunnen simuleren

Deze voordelen zijn vooral relevant bij korte releasecycli. Wanneer code meerdere keren per week wordt uitgebracht, kost een defect dat de integratiefase bereikt veel meer. trace dan een die op de dag van schrijven tegen een stompje aanliep. Die beloning komt echter pas als het harnas uit de juiste onderdelen is samengesteld.

Belangrijkste onderdelen van een testharnas

Een testharnas is geen op zichzelf staand programma, maar een samenstelling van onderdelen, waarbij elk onderdeel een obstakel wegneemt dat anders zou voorkomen dat een test onbeheerd kan worden uitgevoerd.

• Testscripts: Geautomatiseerde instructies met een beschrijving van de uit te voeren stappen en het te verwachten resultaat, geschreven volgens de testscript conventies.
• Testuitvoeringsengine: De runner die scripts in volgorde leest, afhankelijkheden oplost en sequentiële of parallelle uitvoering activeert.
• Testgegevensopslagplaats: Invoerwaarden die buiten het script worden bewaard in CSV-, JSON-, XML- of een vooraf ingevulde database, vaak gevuld door tools voor het genereren van gegevens testen.
• Drivers: Dummy-aanroepmodules die de te testen component aanroepen wanneer de echte bovenliggende laag, zoals een gebruikersinterface, nog niet af is.
• Stubs: Dummy-modules die vooraf ingestelde antwoorden retourneren, bijvoorbeeld een betaaldienst die "Betaling geslaagd" antwoordt zonder contact op te nemen met een bank.
• Uitvoervalidator: Assertielogica die de werkelijke uitvoer vergelijkt met de verwachte waarde en elk geval als geslaagd of mislukt markeert.
• Log- en rapportagelaag: Tijdstempels, schermafbeeldingen, console-uitvoer en een runoverzicht die elke mislukking inzichtelijk maken. tracdaarna beschikbaar.

Verwijder één onderdeel en de kabelboom werkt niet langer automatisch, omdat er dan bij elke run handmatig iets moet worden toegevoegd.

Hoe werkt een testharnas?

Een harnas herhaalt dezelfde lus bij elke uitvoering. Door die lus te kennen, weet je precies waar je eigen harnas zich bevindt. automatisering testen De assets worden aangesloten en er wordt aangegeven welke stap mislukt wanneer een run rood kleurt.

1. Bereid de omgeving voor: Het testsysteem regelt de omgevingsconfiguratie, opent verbindingen en laadt de benodigde bestanden, zodat elke run vanuit dezelfde bekende toestand start.
2. Laad de testscripts: Scripts, parameters en verwachte resultaten worden uit de repository gelezen. Er wordt tijdens de uitvoering niets handmatig ingevoerd, waardoor een tweede uitvoering vergelijkbaar is met de eerste.
3. Vervang de ontbrekende modules: Chauffeurs staan ​​voor bellers die nog niet bestaan, en stubs staan ​​voor diensten die onafgewerkt, instabiel of duur zijn om te bellen.
4. Start de te testen applicatie: De uitvoeringsengine activeert de workflow die in het script wordt beschreven, of dat nu een methodeaanroep is, of een API verzoek, of een browserinteractie.
5. Leg de daadwerkelijke uitvoer vast: Retourwaarden, antwoordgegevens, databaserijen, logregels en schermstatus worden allemaal vastgelegd zodra ze worden gegenereerd.
6. Vergelijk met de verwachte resultaten: De uitvoervalidator controleert elke vastgelegde waarde. Elke afwijking markeert de test als mislukt en registreert zowel de verwachte als de waargenomen waarde.
7. Logboek en rapportage: Het harnas schrijft een tijdgestempelde melding. tracHet programma beëindigt de uitvoering en genereert een rapport met de uitslag (geslaagd/mislukt) dat een ontwikkelaar kan lezen zonder iets opnieuw uit te voeren.
8. Afbreken: Tijdelijke gegevens, verbindingen en de status van de stub worden gewist, zodat de volgende case geen restanten van deze case kan overnemen.

💡Tip: Vernieuw je stubs telkens wanneer de daadwerkelijke module verandert. Een stub die nog steeds de opmaak van het vorige kwartaal gebruikt, zal een groene run rapporteren, terwijl de live-integratie al niet meer werkt.

Een uitgewerkt voorbeeld maakt de lus concreet. Stel dat de afrekenpagina gereed is, maar de betalingsgateway nog niet. Een driver verstuurt het verzoek dat de interface normaal gesproken zou versturen, een stub antwoordt eerst met "Betaling geslaagd" en vervolgens met een time-out, en de validator bevestigt de bestelling in het ene geval en vraagt ​​in het andere geval om een ​​nieuwe poging. Beide paden worden gecontroleerd voordat het gateway-team ook maar één regel code schrijft.

Er zijn twee contexten waarin Testharnas wordt gebruikt

Datzelfde mechanisme dient twee verschillende doelen, en de woordenschat verandert enigszins afhankelijk van in welke situatie je je bevindt.

1. Automatisering testen: Het bevat de testscripts, parameters die nodig zijn om deze scripts uit te voeren en resultaten te verzamelen om deze te analyseren
2. Integratie testen: Het wordt gebruikt om twee code- of module-eenheden samen te stellen die met elkaar communiceren om te controleren of het gecombineerde gedrag al dan niet is zoals verwacht of niet

Stel je een inlogmodule en een profielmodule voor die een gebruikerstoken moeten uitwisselen. In de integratiecontext simuleert een driver een succesvolle login en geeft het token door aan de profiellogica, zodat de datamappingDe permissiecontrole en de schermweergave kunnen allemaal worden geverifieerd voordat de daadwerkelijke authenticatieservice is voltooid. In de automatiseringscontext wordt datzelfde paar testgevallen toegevoegd aan een testsuite en bij elke build opnieuw uitgevoerd zonder dat iemand er verder nog iets aan hoeft te doen.

Soorten testharnassen

Omdat software in lagen is opgebouwd, is een testharness meestal specifiek voor de laag die hij verifieert. Vier typen zijn geschikt voor vrijwel elk project.

A testharnas voor de unit Het voert de kleinste stukjes code uit, zoals een enkele functie of methode, waarbij elke afhankelijkheid wordt vervangen door een placeholder. Het is het snelst uit te voeren en het goedkoopst te onderhouden, en daarom testen van een eenheid Testomgevingen zijn meestal de eerste testomgeving die een team bouwt. Het testen van een belastingberekening zonder de factureringsmodule aan te raken, is een typisch gebruik.

An integratie testharnas Het controleert of twee of meer modules correct samenwerken en is de laag waar inconsistenties in de gegevens en mislukte aanroepen aan het licht komen. Het is het testplatform dat wordt beschreven in de integratie testen In de bovenstaande context wordt bijvoorbeeld gecontroleerd of een orderdienst de juiste gegevens aan een betalingsdienst doorgeeft.

A systeem testkabelboom zorgt voor een complete end-to-end workflow tussen interface, service en database, zodat systeem testen kan bevestigen dat de bedrijfsregels gelden zodra alle lagen aanwezig zijn. regressietest-harnas Vervolgens voert het na elke wijziging de verzamelde testsuite opnieuw uit, wat ervoor zorgt dat... regressietesten Praktisch wanneer honderden scenario's bij elke samenvoeging herhaald moeten worden.

Gereedschap voor testharnas

Elk van deze typen is doorgaans gebaseerd op een bestaande tool in plaats van volledig vanaf nul te worden ontwikkeld. De twee klassieke opties blijven de frameworks op unit-niveau:

• Juniet: Gereedschap gebruikt tijdens gebruik Java
• Nunit: Gereedschap gebruikt voor gebruik .Net-framework

Naast deze twee voegen de meeste teams tools toe die de functionaliteit uitbreiden naar de browser, de API-laag of het loadprofiel. De onderstaande tabel geeft een overzicht van de meest voorkomende opties en de rol die ze spelen.

Welke combinatie je ook kiest, de kabelboom verdient zichzelf pas terug als hij onbeheerd draait, dus sluit hem aan op een continue integratie baan vroegtijdig. Een uitgebreidere catalogus met opties is te vinden in de Guru99 testtools Samenvatting. Eén onderscheid zorgt nog steeds voor verwarring, en het is de moeite waard om dat op te helderen voordat je een keuze maakt.

Testharnas versus testframework

Een testharnas en een automatiseringsframework worden vaak als hetzelfde beschouwd, maar ze beantwoorden verschillende vragen: het testharnas voert een test uit, terwijl het framework de structuur vormt waarbinnen tests worden ontworpen. De onderstaande tabel zet ze naast elkaar.

Veelgestelde vragen