Menu

Soorten automatiseringstests en enkele misvattingen

types automation testing

Probeer Ons Instrument Voor Het Oplossen Van Problemen

Leer de verschillende soorten automatiseringstests met enkele misvattingen over testautomatisering:

In dit tweede deel van test automatisering tutorials serie , Zal ik in het kort de soorten geautomatiseerde tests beschrijven en dan, nog belangrijker, ik zal enkele misvattingen over testautomatisering uit de wereld helpen.

Wat is automatiseringstesten?

Automatiseringstests kunnen worden gedefinieerd als een manier om een ​​reeks tests keer op keer uit te voeren zonder ze handmatig uit te hoeven voeren. Door automatiseringstests in uw teststrategie te introduceren, bespaart u tijd en geld.

soorten automatiseringstests

Wat je leert:

Soorten automatiseringstests

Typen automatiseringstests bepalen wat voor soort testsuites kunnen worden geautomatiseerd. Veel testers verwarren dit onderwerp met de soorten automatiseringsframeworks die bepalen hoe u uw testsuite in een automatiseringspakket gaat ontwerpen dat gemakkelijk kan worden uitgevoerd.

In dit artikel gaan we dieper in op de Automation-testtypen en zullen we uiteindelijk kort kijken naar de automatiseringsframeworks.

Soorten automatisering

Laten we de bovenstaande classificaties in detail begrijpen:

Automatisering op basis van het type testen

Automatisering van functionele tests:

help desk vragen om gebruikers te stellen

Functionele tests worden geschreven om de bedrijfslogica achter een applicatie te testen. Het automatiseren van deze gemiddelde schrijfscripts om de bedrijfslogica en de functionaliteit die van de applicatie wordt verwacht, te valideren.

Automatisering van niet-functionele tests:

Niet-functionele tests definiëren de niet-zakelijke vereisten van de applicatie. Dit zijn de vereisten met betrekking tot prestaties, beveiliging, databases, enz. Deze vereisten kunnen constant blijven of kunnen worden geschaald op basis van de grootte van de software.

Automatisering op basis van de testfase

Automatisering van unit-tests:

Deze tests worden tijdens de ontwikkelingsfase zelf uitgevoerd, idealiter door de dev na voltooiing van de ontwikkeling en voordat het systeem ter test aan de testers wordt overgedragen.

Automatisering van API-tests:

API-tests worden uitgevoerd tijdens de integratiefase. Deze kunnen worden uitgevoerd door het ontwikkeling- of testteam en kunnen worden uitgevoerd voor of nadat de UI-laag voor de applicatie is gebouwd. Deze tests zijn gericht op het testen op basis van het verzoek en de reactie waarop de applicatie is gebouwd.

Automatisering van op UI gebaseerde tests:

UI-gebaseerde tests worden uitgevoerd tijdens de testuitvoeringsfase. Deze worden specifiek uitgevoerd door de testers en worden slechts één keer uitgevoerd voordat de gebruikersinterface van de applicatie aan hen wordt overgedragen. Deze testen de functionaliteit en bedrijfslogica van de applicatie vanaf de voorkant van de applicatie.

Automatisering op basis van het type tests

Eenheidstests:

Unit Tests zijn de tests die zijn gebouwd om de code van een applicatie te testen en die meestal in de code zelf zijn ingebouwd. Ze richten zich op de coderingsstandaarden, zoals hoe de methoden en functies worden geschreven.

Deze tests worden vaker door de ontwikkelaars zelf geschreven, maar in de huidige wereld kan ook aan automatiseringstesters worden gevraagd om ze te schrijven.

Als u deze tests uitvoert en er geen bugs van krijgt, betekent dit dat uw code zonder codeproblemen zal worden gecompileerd en uitgevoerd. Deze tests zijn meestal niet gericht op de functionele aspecten van de applicatie en aangezien ze gericht zijn op code, is het geschikter om ze te automatiseren, zodat ze kunnen worden uitgevoerd als en wanneer de ontwikkelaar dit vereist.

Rookproeven:

De rooktest is een beroemde test die tijdens de testlevenscyclus wordt uitgevoerd. Dit zijn post-build tests, ze worden onmiddellijk uitgevoerd nadat een build uit de applicatie is gegeven om er zeker van te zijn dat de applicatie nog steeds functioneert nadat de build is voltooid.

Dit is een kleine testsuite en is iets dat meerdere keren zal worden uitgevoerd en daarom is het logisch om het te automatiseren. Deze tests zijn meestal functioneel van aard en afhankelijk van het type toepassing kan er een tool voor worden gekozen.

API-tests:

API-testen zijn de afgelopen jaren erg beroemd geworden. Toepassingen die zijn gebouwd op de API-architectuur kunnen deze tests uitvoeren.

Bij API-testen valideren de testers de bedrijfslaag van de applicatie door de verzoek-antwoordcombinaties te controleren voor de verschillende API's waarop de applicatie is gebouwd. API-tests kunnen ook worden uitgevoerd als onderdeel van de onderstaande integratietests.

Integratietests:

Integratietest zoals de naam zelf suggereert, betekent het testen van de applicatie door alle modules te integreren en de functionaliteit van de applicatie te controleren.

Integratietesten kunnen worden gedaan door middel van API-testen of kunnen worden gedaan via de UI-laag van de applicatie.

UI-tests:

UI-tests worden gedaan vanuit de UI-laag of de frontend van de applicatie. Deze kunnen gericht zijn op het testen van de functionaliteit of gewoon op het testen van de UI-elementen van een applicatie.

Het automatiseren van de gebruikersinterface om de functionaliteit te testen is een gangbare praktijk. Het automatiseren van de GUI-functies is echter een van de meer gecompliceerde automatiseringen.

Regressietests:

Een van de meest geautomatiseerde testsuites is de regressietestsuite. Regressie, zoals u wellicht al weet, is de test die wordt uitgevoerd aan het einde van het testen van een nieuwe module om er zeker van te zijn dat geen van de bestaande modules erdoor is beïnvloed.

Het wordt herhaald na elke nieuwe iteratie van testen en de belangrijkste testcases blijven opgelost met meestal een paar nieuwe toevoegingen na een nieuwe iteratie. Omdat het vaak wordt uitgevoerd, proberen bijna alle testteams dit pakket te automatiseren.

Automatisering als continue integratie:

Mogelijk wordt opnieuw continue integratie uitgevoerd op de geautomatiseerde regressietests zelf, maar om CI te bereiken, zorgen we ervoor dat de regressie of geïdentificeerde testsuite elke keer kan worden uitgevoerd wanneer een nieuwe implementatie wordt uitgevoerd.

Beveiligingstests:

Beveiligingstests kunnen zowel functioneel als niet-functioneel zijn, waarbij de applicatie op kwetsbaarheden wordt getest. Functionele tests zullen bestaan ​​uit tests met betrekking tot autorisatie enz., Terwijl niet-functionele vereisten kunnen testen op SQL-injectie, cross-site scripting, enz.

Prestatietests en kwaliteitscontrole:

Prestatietests zijn niet-functionele tests die zich richten op vereisten zoals het testen van belasting, spanning, schaalbaarheid van de applicatie.

Acceptatietests:

Acceptatietests vallen weer onder functionele tests die meestal worden gedaan om te controleren of aan de acceptatiecriteria van de opdrachtgever is voldaan.

Tot dusverre hebben we het type tests beschreven dat kan worden geautomatiseerd en verschillende classificaties daarvan, alle classificaties zullen uiteindelijk leiden tot dezelfde eindresultaten van een testsuite die wordt geautomatiseerd. Zoals we eerder zeiden, is een beetje begrip vereist over hoe deze verschillen van frameworks.

Als u eenmaal de tests heeft geïdentificeerd die u wilt automatiseren op basis van de bovenstaande classificatie, moet u uw logica zo ontwerpen dat deze tests soepel kunnen worden uitgevoerd, zonder veel handmatige tussenkomst. Dit ontwerp van een handmatige testsuite naar een geautomatiseerde testsuite is waar de frameworks binnenkomen.

Nu zullen we de 3 beste soorten automatiseringstests onderzoeken

  1. Testen van een eenheid
  2. API-testen
  3. GUI-testen

# 1) Geautomatiseerde unit-tests

Geautomatiseerde unit-tests zijn geschreven om het codeniveau te testen. Bugs worden geïdentificeerd in de functies, methoden en routines die door de ontwikkelaars zijn geschreven.

Sommige bedrijven vragen de ontwikkelaars om de unit-tests zelf uit te voeren en sommige huren gespecialiseerde testautomatiseringshulpmiddelen in. Deze bronnen hebben toegang tot de broncode en schrijven eenheidstests om de productiecode te kraken.

Vanwege de aanwezigheid van unit-tests worden, telkens wanneer de code compileert, alle unit-tests uitgevoerd en vertellen ons het resultaat dat als alle functionaliteit werkt. Als een unit-test mislukt, betekent dit dat er nu een bug aanwezig is in de productiecode.

Enkele van de meest populaire tools die op de markt aanwezig zijn, zijn onder meer NUnit en JUnit ​Microsoft biedt ook zijn eigen framework voor unit testing genaamd MSTest ​Ga door de websites van deze tools en ze zullen u meer voorbeelden en tutorials geven over het schrijven van unit-tests.

#twee) Geautomatiseerde webservice- / API-tests

Een Application Programming Interface (API) maakt het mogelijk dat de software met andere softwareapplicaties communiceert. Net als alle andere software, moeten API's worden getest. Bij dit type testen is GUI meestal niet betrokken.

Wat we hier testen, zijn meestal de functionaliteit, compliance en beveiligingsproblemen. In webapplicaties kunnen we het verzoek en de reactie van onze applicatie testen of ze al dan niet veilig en gecodeerd zijn.

Dit is een van de voorbeelden waarin we API-testen kunnen gebruiken. De meest populaire tool voor API-testen is ZEEP die zowel gratis als betaalde versies heeft. Er zijn ook andere tools die u naar behoefte kunt gebruiken.

# 3) Geautomatiseerde GUI-tests.

Dit type geautomatiseerd testen is de moeilijkste vorm van automatisering, aangezien het gaat om het testen van een gebruikersinterface van de applicatie.

Het is moeilijk omdat de GUI's sterk aan verandering onderhevig zijn. Maar dit type testen komt ook het dichtst in de buurt van wat de gebruikers zullen doen met onze applicatie. Aangezien de gebruiker de muis en het toetsenbord zal gebruiken, bootsen geautomatiseerde GUI-tests hetzelfde gedrag na door muis en toetsenbord te gebruiken om te klikken of schrijven naar objecten op de gebruikersinterface.

Hierdoor kunnen we bugs vroeg vinden en kan het in veel scenario's worden gebruikt, zoals regressietesten of het invullen van formulieren, wat te veel tijd kost.

De meest populaire GUI-testtools zijn onder meer Micro Focus Unified Functional Testing (UFT) ​ Selenium ​ Test voltooid en Microsoft gecodeerde gebruikersinterface (dat deel uitmaakt van de ultieme en premium-edities van Visual Studio).

Net als de soorten automatiseringstests, zijn er ook meerdere soorten frameworks.

Automation Frameworks

Enkele veelgebruikte automatiseringsframeworks zijn:

  • Lineair (opnemen en afspelen)
  • Zoekwoordgestuurd
  • Gegevensgestuurd
  • Pagina-objectmodel
  • Modulair

Verder lezen => Automation Frameworks

Typen, framework en tools

Zoals u kunt zien, is de eerste stap in het automatiseringsproces het identificeren van het type automatisering. Vervolgens kunt u het raamwerk bepalen dat u wilt ontwerpen en met deze in gedachten kunt u de tools selecteren die aan uw behoeften voldoen.

Automatiseringstools

Op basis van het type testen waarop u zich richt en het type framework dat u er mogelijk omheen wilt bouwen, zijn de volgende tools beschikbaar om te gebruiken:

  • Selenium ​ Zeer krachtige tool voor het testen van webapplicaties. Biedt ondersteuning voor meerdere browsers.
  • Junit en Nunit: Tools die voornamelijk door de ontwikkelaars worden gebruikt voor het testen van eenheden.
  • QTP ​ Geweldig hulpmiddel voor niet-webtoepassingen en wordt geleverd met een ingebouwde objectrepository.
  • Sikuli: Open source-tool voor GUI-testen.
  • Zeep UI: Tool voor API-testen.
  • Wees gerustgesteld: Bibliotheek om een ​​API-testraamwerk te maken.
  • appium ​ Tool die mobiel testen, testen van native apps, hybride en mobiele webapplicaties ondersteunt.
  • Jmeter ​ Een tool die wordt gebruikt voor prestatietests.
  • TestNG: TestNG is op zichzelf geen automatiseringstool, maar het biedt geweldige ondersteuning voor automatiseringsraamwerken die zijn gebouwd met selenium, appium, wees gerust, enz.

Verder lezen => Test automatiseringstools

Misvattingen over automatiseringstests

In de loop der jaren heb ik enkele misvattingen gehoord over testautomatisering. Ik denk dat ik ze ook in dit artikel moet ophelderen.

Misvatting # 1​ Automatisering is hier om handmatige testers te vervangen.

Testautomatisering is bedoeld om de testers te helpen het testen sneller en op een veel betrouwbaardere manier uit te voeren. Het kan nooit mensen vervangen.

Beschouw testautomatisering als een auto. Als u loopt, duurt het ongeveer 20 minuten om uw huis te bereiken. Maar als u een auto gebruikt, bent u er in twee minuten. De bestuurder van de auto ben jij nog steeds, een mens, maar .. de auto helpt de mens om zijn / haar doel sneller te bereiken. Bovendien wordt de meeste van uw energie bespaard, omdat u niet liep. Zo kun je deze energie gebruiken om belangrijkere dingen uit te voeren.

Hetzelfde geldt voor automatiseringstests. Je gebruikt het om snel de meeste van je herhaalde, lange en saaie tests te testen en je tijd en energie te besparen om je te concentreren en nieuwe en belangrijke functionaliteit te testen.

Zoals James Bach zei een prachtig citaat:

'Tools testen niet. Alleen mensen testen. Tools voeren alleen acties uit die mensen 'helpen' testen.​

Tools kunnen op objecten klikken. Maar waar u moet klikken, wordt altijd verteld door een handmatige tester. Ik denk dat je mijn punt nu begrijpt.

Misvatting 2 ​ Alles onder de zon kan worden geautomatiseerd

Als u 100% van uw testcases probeert te automatiseren, kunt u dit misschien doen, maar als u dat zou kunnen doen, wordt ons eerste punt onjuist. Als alles is geautomatiseerd, wat doet een handmatige tester dan?

Verward? Rechtsaf?

Het punt is eigenlijk dat je niet 100% van je testcases kunt automatiseren. Omdat wij, als testers, van mening zijn dat geen enkele applicatie 100% getest kan worden. Er zullen altijd enkele scenario's zijn die we zullen missen. Er zullen altijd bugs zijn die alleen optreden als uw applicatie door de klanten wordt gebruikt.

Als de applicatie niet 100% kan worden getest, hoe kunt u dan 100% automatisering beloven?

Er is ook een zeer kleine kans dat u al uw bestaande testgevallen kunt automatiseren. Er zijn altijd scenario's die moeilijk te automatiseren zijn en gemakkelijker handmatig kunnen worden uitgevoerd.

Bijvoorbeeld Eén gebruiker voert de gegevens in, de tweede gebruiker keurt de gegevens goed, de derde gebruiker ziet de gegevens en de vierde gebruiker mag de gegevens niet inzien. Deze scenario's kunnen worden geautomatiseerd, maar ze zullen veel tijd en moeite kosten. Het wordt dus gemakkelijker als u dat gewoon handmatig doet.

Onthoud dat we auto's gebruiken om afstanden af ​​te leggen, maar er kunnen onderweg lange signalen zijn, er zal brandstofverbruik zijn, er zullen problemen met de parkeerruimte zijn, parkeerkosten en nog veel meer hoofdpijn. In sommige scenario's lopen we gewoon en bereiken we onze bestemming :) ​

U moet dus niet proberen alles te automatiseren. Automatiseer alleen die scenario's die belangrijk zijn en die veel tijd kosten om handmatig uit te voeren.

Misvatting # 3 ​ Automatisering omvat alleen opnemen en afspelen.

Leef alsjeblieft niet in een fantasiewereld. Deze fantasie is eigenlijk gecreëerd door valse advertenties van verschillende leveranciers van automatiseringstools. Ze zeggen dat je gewoon je stappen opneemt en afspeelt en dat je testcases worden geautomatiseerd. Nou, dat is een grote leugen!

Automatisering is alles en niet alleen opnemen en afspelen. Pure automatiseringstechnici gebruiken normaal gesproken helemaal geen opname- en afspeelfunctie. Opnemen en afspelen worden over het algemeen gebruikt om een ​​idee te krijgen van hoe de tool een script voor onze stappen genereert.

Zodra we de scripting leren kennen, gebruiken we altijd scripting om geautomatiseerde tests te maken. Onthouden, u moet programmeren kennen als u testautomatisering wilt doen ​ Aan de andere kant, wees niet ontmoedigd als u niet weet wat programmeren is. Net als elke andere taak, kan programmeren ook met oefening en toewijding worden geleerd.

Ik ken mensen die niet eens een computerwetenschappelijke achtergrond hebben, maar ze leren programmeren en nu zijn het geweldige automatiseringsingenieurs. Bij Microsoft huren ze testers in die kunnen programmeren. Ze worden genoemd SDET (Software development engineers voor test). De eerste regel van de taakomschrijving zegt 'SDET's schrijven veel code….'.

Leer programmeren, loop er niet voor weg. Het zal je een geweldige tester ​

Gevolgtrekking

Ik hoop dat dit artikel je zou hebben geholpen om enkele concepten met betrekking tot testautomatisering te verduidelijken.

We hebben een hoog niveau van verschillende soorten automatiseringstests behandeld, met verschillende manieren om te classificeren.

De belangrijkste classificaties zijn:

  • Automatisering op basis van type testen (functioneel of niet-functioneel).
  • Automatisering op basis van de testfase (Unit, API of UI).
  • Automatisering op basis van de verschillende soorten testen (Meerdere soorten testen).

Ook hebben we de verschillende tools op een rijtje gezet die voor dit soort geautomatiseerd testen kunnen worden gebruikt.

In ons aanstaande artikel zullen we de stap voor stap procedure van hoe u testautomatisering start in uw organisatie ​

PREV Tutorial # 1 ​ VOLGENDE Tutorial # 3

Aanbevolen literatuur

^