Wat is Automatiseringstesten (Ultimate Guide to Start Test Automation)

Een complete gids voor het starten van Automatiseringstesten op uw project:

Wat is automatiseringstesten?

Automatiseringstesten is een techniek om software te testen en de werkelijke uitkomst te vergelijken met de verwachte uitkomst. Dit kan worden bereikt door het schrijven van testscripts of met behulp van een automatiseringstest tool. Testautomatisering wordt gebruikt voor het automatiseren van repetitieve taken en andere testtaken die moeilijk handmatig kunnen worden uitgevoerd.

gids voor automatiseringstesten

Wilt u beginnen met de automatiseringstest voor uw project, maar worstelt u met de meest elementaire stappen zoals hieronder vermeld:

  • Hoe introduceert u automatisering in uw project?
  • Hoe selecteert u de beste en juiste automatiseringstool?
  • Hoe ontwikkelt u effectief scripts?
  • Hoe voert u testscripts uit en onderhoudt u ze?
  • En tenslotte wat zijn de best practices die u moet volgen voor succesvol automatiseringstesten?

Vandaag hebben we gepland om uw kennis te verrijken met een serie tutorials over “Aan de slag met Automatiseringstesten”. Deze serie van automatisering tutorials zal antwoord geven op alle bovenstaande vragen op een stap voor stap manier met eenvoudige voorbeelden.

Laten we eens een kijkje nemen op de serie van tutorials over het starten van automatisering op uw project!

Automatisering End-to-end Proces:

Tutorial #1: Beste Gids om Automatisering op Uw Project te Starten
Tutorial #2: Soorten Geautomatiseerde Tests en Enkele Misvattingen
Tutorial #3: 10 Stappen om Automatisering op Uw Project te Introduceren
Tutorial #4: De A tot Z Gids voor het Selecteren van de Beste Automatiseringstool
Tutorial #5: Script Ontwikkeling en Automatiseringsframeworks
Tutorial #6: Uitvoering en rapportage van Automatisering
Tutorial #7: Best Practices en Strategieën van Test Automatisering

Automatiseringstips:

Tutorial #8: 10 Tips die u moet lezen voordat u uw testwerk automatiseert
Tutorial #9: Hoe verschilt testplanning voor handmatige en automatiseringsprojecten
Tutorial #10: Wanneer kiest u voor automatisering?
Tutorial #11: Uitdagingen voor Automatiseringstesten
Tutorial #12: Gids om Proof of Concept (POC) in Automatisering te implementeren
Tutorial #13: Hoe de juiste testgevallen voor Automatisering te selecteren
Tutorial #14: Hoe Handmatige Testgevallen in Automatiseringsscripts te vertalen

Automatisering Carrière:

Tutorial #15: Tips om een betere Automatiseringstester te worden
Tutorial #16: Test Automatisering – Is het een Gespecialiseerde Carrière? Kunnen normale testers ook automatiseren?

Populaire Automatiseringstools:

Tutorial #17: Selenium Tutorials 31+ Beste Gratis Selenium Training Tutorials
Tutorial #18: QTP Tutorials
Tutorial #19: SoapUI Web Services Testing Tool
Tutorial #20: HP LoadRunner for Performance Testing

Automation Frameworks:

Tutorial #21: Why Do We Need Frameworks for Automation
Tutorial #22: Most Popular Automation Frameworks

Automation in Agile:

Tutorial #23: How to Implement Efficient Automation in the Agile World

Other Automation Tools:

Tutorial #24: Best Automation Test Tools
Tutorial #25: Sikuli GUI Automation Tool
Tutorial #26: PowerShell: Desktop Applicatie UI Automatisering Met PowerShell
Tutorial #27: Katalon Automation Recorder (Selenium IDE Alternatief)
Tutorial #28: Geb Tool: Browser Automatisering Met behulp van Geb Tool
Tutorial #29: AutoIt: How to Handle Windows Pop-up Using AutoIt
Tutorial #30: Cucumber: Automation Using Cucumber Tool and Selenium
Tutorial #31: Protractor Testing Tool for End-to-end Testing of AngularJS Applications

Mobile Automation Testing:

Tutorial #32: Appium Studio Hands-on Tutorial
Tutorial #33: Appium Tutorial voor Beginners
Tutorial #34: Selendroid Tutorial: Android Mobile Automation Framework
Tutorial #35: Ranorex Tutorial: A Powerful Desktop, Web, and Mobile Testing Tool

Domain Specific Automation Examples:

Tutorial #36: Automation of JAVA/J2EE Applications

Interview Preparation for Automation Jobs:

Tutorial #37: Automation Testing Interview Questions
Tutorial #38: Selenium Interview Questions

Laten we eens kijken naar de eerste tutorial uit de “The Ultimate Guide to Automation Testing” serie!

Wat is Automation Testing?

Als een software alles kan, waarom kan een software dan geen software testen?

Klinkt deze uitspraak je logisch in de oren?

Indien ja, dan gefeliciteerd, u denkt nu aan Test Automatisering, en dat is het centrale punt dat we in deze serie informatieve tutorials gaan bespreken.

Stel jezelf n de eerste dag op je werk als SQA voor. Je krijgt een applicatie voorgeschoteld die getest moet worden. Het is een ERP-applicatie met honderden formulieren en duizenden rapporten. Je begint je verkennende tests met het openen van een formulier dat zo’n 50 verschillende velden bevat.

Je probeert willekeurige gegevens in dit formulier in te voeren, wat zo’n 20 minuten duurt. Dan drukt u op submit. Wolla!!! Een foutmelding wordt getoond die lijkt op een unhandled exception. U wordt erg blij. U noteert trots de stappen en rapporteert de bug in uw bug management systeem. Grote inspanning, je voelt je echt zelfverzekerd en energiek. Je gaat door met testen tot het einde van de dag en vindt nog een aantal bugs. “Geweldige eerste dag”, dacht je.

Nu komt de volgende dag, de ontwikkelaar heeft het probleem opgelost en brengt een nieuwe versie van de build uit. Je test hetzelfde formulier met dezelfde stappen en je ontdekt dat de bug is verholpen. U markeert het opgelost. Grote inspanning. Je hebt bijgedragen aan de kwaliteit van het product door die bug te identificeren en omdat deze bug is verholpen, is de kwaliteit verbeterd.

Nu komt de derde dag, een ontwikkelaar heeft weer een nieuwere versie uitgebracht. Nu moet je weer dat formulier testen om er zeker van te zijn dat er geen regressie probleem wordt gevonden. Dezelfde 20 minuten. Nu voel je je een beetje verveeld.

Nu stel je voor dat er vanaf nu 1 maand lang steeds nieuwere versies uitkomen en dat je bij elke release dit lange formulier plus 100 van dit soort andere formulieren moet testen, alleen maar om er zeker van te zijn dat er geen regressie is.

Nu voel je je boos. Je voelt je moe. Je begint stappen over te slaan. U vult slechts ongeveer 50% van de totale velden in. Uw nauwkeurigheid is niet hetzelfde, uw energie is niet hetzelfde en zeker, uw stappen zijn niet hetzelfde.

En op een dag meldt de klant dezelfde bug in hetzelfde formulier. Je voelt je zielig. Je voelt je nu niet zelfverzekerd. Je denkt dat je niet competent genoeg bent. Managers twijfelen aan je capaciteiten.

Ik heb nieuws voor je; dit is het verhaal van 90% van de handmatige testers die er zijn. U bent niet anders.

Regressieproblemen zijn de pijnlijkste problemen. Wij zijn mensen. En we kunnen niet elke dag hetzelfde doen met dezelfde energie, snelheid en nauwkeurigheid. Dat is wat machines doen. Dit is waar automatisering voor nodig is, om dezelfde stappen te herhalen met dezelfde snelheid, nauwkeurigheid en energie als waarmee ze de eerste keer werden herhaald.

Ik hoop dat je begrijpt wat ik bedoel!!

automatisch testen een vriend

Wanneer een dergelijke situatie zich voordoet, moet je je testcase automatiseren. Testautomatisering is je vriend. Het zal je helpen om je te concentreren op nieuwe functionaliteit terwijl je de regressies voor je rekening neemt. Met automatisering kunt u dat formulier in minder dan 3 minuten invullen.

Het script vult alle velden in en vertelt u het resultaat samen met screenshots. In het geval van een mislukking, kan het de plaats aanwijzen waar de test case mislukte, waardoor u het met gemak kunt reproduceren.

Automation – A Cost-effective Method for Regression Testing

Automation kosten zijn echt hoger in het begin. Het omvat de kosten van de tool, dan de kosten van de automatisering test resource en zijn / haar training.

Maar als de scripts klaar zijn, kunnen ze honderden keren herhaald worden uitgevoerd met dezelfde nauwkeurigheid en vrij snel. Dit bespaart vele uren handmatig testen. Dus de kosten nemen geleidelijk af, en uiteindelijk wordt het een kosteneffectieve methode voor Regressie testen.

Scenario’s die Automatisering vereisen

Het bovenstaande scenario is niet het enige geval waarin je automatisering testen nodig hebt. Er zijn verschillende situaties, die niet handmatig kunnen worden getest.

Voorbeeld,

  1. Vergelijken van twee afbeeldingen pixel voor pixel.
  2. Vergelijken van twee spreadsheets met duizenden rijen en kolommen.
  3. Het testen van een applicatie onder de belasting van 100.000 gebruikers.
  4. Prestatiebenchmarks.
  5. Het testen van de applicatie op verschillende browsers en op verschillende besturingssystemen parallel.

Deze situaties vereisen en moeten worden, getest door tools.

Dus, wanneer automatiseren?

Dit is een tijdperk van agile methodologie in SDLC, waar de ontwikkeling en het testen bijna parallel zullen verlopen en het erg moeilijk is om te beslissen wanneer te automatiseren.

Overweeg de volgende situaties voordat je in automatisering stapt

  • Het product kan zich in zijn primitieve stadia bevinden, wanneer het product nog niet eens een UI heeft, in deze stadia moeten we een duidelijk idee hebben over wat we willen automatiseren. De volgende punten moeten worden onthouden.
    • Tests mogen niet verouderd zijn.
    • Als het product evolueert, moet het gemakkelijk zijn om de scripts op te pikken en aan te vullen.
    • Het is erg belangrijk om je niet te laten meeslepen en ervoor te zorgen dat de scripts gemakkelijk te debuggen zijn.
  • Probeer in de allereerste stadia geen UI-automatisering omdat de UI onderhevig is aan frequente wijzigingen, waardoor scripts zullen falen. Kies zoveel mogelijk voor automatisering op API-niveau/niet UI-niveau totdat het product is gestabiliseerd. API automatisering is eenvoudig te repareren en te debuggen.

Hoe bepaal je de beste automatiseringsgevallen:

Automatisering is een integraal onderdeel van een testcyclus en het is erg belangrijk om te beslissen wat we willen bereiken met automatisering voordat we besluiten te automatiseren.

De voordelen die automatisering lijkt te bieden zijn zeer aantrekkelijk, maar tegelijkertijd kan een slecht georganiseerde automatiseringssuite het hele spel bederven. Testers kunnen het grootste deel van de tijd bezig zijn met het debuggen en repareren van de scripts, waardoor ze testtijd verliezen.

Efficiënte testautomatisering

In deze serie wordt uitgelegd hoe een automatiseringssuite efficiënt genoeg kan worden gemaakt om de juiste testgevallen op te pikken en de juiste resultaten te behalen met de automatiseringsscripts die we hebben.

Ook heb ik antwoorden gegeven op vragen als Wanneer automatiseren, Wat automatiseren, Wat niet automatiseren en Hoe automatiseren te strategeren.

De juiste tests voor automatisering

De beste manier om dit probleem aan te pakken is door snel een “Automatiseringsstrategie” te bedenken die bij ons product past.

Het idee is om de testgevallen zo te groeperen dat elke groep een ander resultaat oplevert. De onderstaande illustratie laat zien hoe we gelijksoortige testgevallen kunnen groeperen, afhankelijk van het product/oplossing dat we testen.

Grouping Test Cases

Laten we nu diep duiken en begrijpen wat elke groep ons kan helpen om te bereiken:

1) Maak een testsuite van alle basisfunctionaliteit Positieve tests. Deze suite moet worden geautomatiseerd, en wanneer deze suite wordt uitgevoerd tegen een build, worden de resultaten onmiddellijk getoond. Elk script dat faalt in deze suite leidt tot een S1 of S2 defect, en die specifieke build kan worden gediskwalificeerd.

Als extra stap kunnen we deze geautomatiseerde testsuite toevoegen als onderdeel van BVT (Build verification tests) en de QA automation scripts controleren in het product bouwproces. Dus als de build klaar is, kunnen testers de resultaten van de automatiseringstests controleren en besluiten of de build geschikt is voor installatie en verder testproces.

Dit bereikt duidelijk de doelen van automatisering, die zijn:

  • Verlaag de testinspanning.
  • Ontdekken van fouten in eerdere stadia.

2) Vervolgens hebben we een groep van end-to-end tests.

Bij grote oplossingen is het testen van een end-to-end functionaliteit de sleutel, vooral tijdens de kritieke stadia van het project. We moeten een paar automatiseringsscripts hebben die ook betrekking hebben op de end-to-end oplossingstesten. Wanneer deze suite wordt uitgevoerd, moet het resultaat aangeven of het product in zijn geheel werkt zoals verwacht of niet.

De Automation test suite moet aangeven of een van de integratie onderdelen kapot is. Deze suite hoeft niet te dekken elke kleine functie / functionaliteit van de oplossing, maar het moet betrekking hebben op de werking van het product als geheel. Wanneer we een alpha of een beta of een andere tussentijdse releases, dan is dit soort scripts van pas komen en geven een zekere mate van vertrouwen aan de klant.

Om beter te begrijpen laten we aannemen dat we het testen van een online shopping portal, als onderdeel van de end-to-end tests moeten we worden die alleen de belangrijkste stappen betrokken.

Zoals hieronder gegeven:

  • Gebruiker login.
  • Browse en selecteer items.
  • Betaling optie – dit omvat de front-end tests.
  • Backend order management (omvat het communiceren met meerdere geïntegreerde partners, het controleren van de voorraad, het e-mailen van de gebruiker etc) – dit zal helpen bij het testen van de integratie van individuele stukken en ook de crux van product.

Dus wanneer een dergelijk script wordt uitgevoerd geeft het een vertrouwen dat de oplossing als geheel goed werkt.

3) De derde set is de Feature/Functionaliteit gebaseerde tests.

Bijv. We kunnen de functionaliteit hebben om te browsen en een bestand te selecteren, dus wanneer we dit automatiseren kunnen we cases automatiseren om de selectie van verschillende soorten bestanden, de grootte van bestanden, etc. op te nemen, zodat feature testing wordt gedaan. Wanneer er veranderingen/toevoegingen zijn aan die functionaliteit kan deze suite dienen als Regressie suite.

#4) De volgende op de lijst zouden UI gebaseerde tests zijn. We kunnen nog een suite hebben die puur UI-gebaseerde functionaliteiten test, zoals paginering, karakterbeperking in tekstvakken, kalenderknop, dropdowns, grafieken, afbeeldingen en veel van dit soort UI-gerichte functies. Het falen van deze scripts is meestal niet erg kritisch, tenzij de UI volledig down is of bepaalde pagina’s niet verschijnen zoals verwacht!

5) We kunnen nog een andere set tests hebben die eenvoudig zijn, maar erg bewerkelijk om handmatig uit te voeren. Vervelende maar eenvoudige tests zijn de ideale automatiseringskandidaten, bijvoorbeeld het invoeren van de gegevens van 1000 klanten in de database heeft een eenvoudige functionaliteit, maar uiterst moeizaam om handmatig te worden uitgevoerd, dergelijke tests moeten worden geautomatiseerd. Zo niet, dan worden ze meestal genegeerd en niet getest.

Wat NIET te automatiseren?

Hieronder staan enkele tests die niet geautomatiseerd moeten worden.

#1) Negatieve tests/Failover tests

We moeten niet proberen om negatieve of failover tests te automatiseren, omdat voor deze tests de testers analytisch moeten denken en negatieve tests zijn niet echt eenvoudig om een pass of fail resultaat te geven dat ons kan helpen.

Negatieve tests zullen veel handmatige interventie nodig hebben om een werkelijk disaster recovery soort scenario te simuleren. Om een voorbeeld te geven: we testen functies zoals de betrouwbaarheid van webservices – om het hier te veralgemenen: het belangrijkste doel van dergelijke tests zou zijn om opzettelijke fouten te veroorzaken en te zien hoe goed het product erin slaagt om betrouwbaar te zijn.

Het nabootsen van de bovengenoemde fouten is niet eenvoudig, het kan het injecteren van enkele stubs inhouden of het gebruik van enkele tools tussendoor en automatisering is niet de beste manier om hier te gaan.

#2) Ad-hoc tests

Deze tests zijn misschien niet altijd echt relevant voor een product en dit kan zelfs iets zijn waar de tester aan zou kunnen denken in dat stadium van project initiatie, en ook de inspanning om een ad-hoc test te automatiseren moet worden gevalideerd tegen de kriticiteit van de feature waar de tests betrekking op hebben.

Bijv. een tester die een functie test die zich bezighoudt met compressie/encryptie van gegevens, heeft misschien intensieve ad-hoc tests gedaan met de verscheidenheid aan gegevens, bestandstypen, bestandsgroottes, corrupte gegevens, een combinatie van gegevens, met behulp van verschillende algoritmen, op verschillende platforms, enz.

Wanneer we automatisering plannen, willen we misschien prioriteiten stellen en niet alleen alle ad-hoc tests voor die functie automatiseren, en uiteindelijk wat tijd overhouden voor het automatiseren van de andere belangrijke functies.

#3) Tests met enorme voorinstellingen

Er zijn tests die een aantal enorme voorvereisten vereisen.

Bijv. We hebben een product dat integreert met software van derden voor sommige functies, zoals een product dat integreert met een wachtrijsysteem voor berichtenverkeer, waarvoor installatie op een systeem nodig is, het instellen van wachtrijen, het maken van wachtrijen, enz.

De 3rd party software kan van alles zijn en de setup kan complex van aard zijn en als dergelijke scripts zijn geautomatiseerd dan zullen deze voor altijd afhankelijk zijn van de functie/setup van die 3rd party software.

Voorvereiste zijn:

Op dit moment ziet het er misschien eenvoudig en schoon uit als beide kanten setups worden gedaan en alles is in orde. We hebben vaak gezien dat wanneer een project in de onderhoudsfase komt, het project wordt overgeheveld naar een ander team, en zij uiteindelijk dergelijke scripts moeten debuggen waarbij de eigenlijke test heel eenvoudig is, maar het script mislukt als gevolg van een probleem met de software van een derde partij.

Het bovenstaande is slechts een voorbeeld, in het algemeen, houd tests in de gaten die omslachtige pre setups hebben voor een eenvoudige test die volgt.

Eenvoudig voorbeeld van test automatisering

Wanneer je een software test (op het web of desktop), gebruik je normaal gesproken een muis en toetsenbord om je stappen uit te voeren. Een automatiseringstool bootst diezelfde stappen na door gebruik te maken van scripting of een programmeertaal.

Bijv. als je een rekenmachine test en de testcase is dat je twee getallen moet optellen en het resultaat moet zien. The script will perform the same steps by making use of your mouse and keyboard.

The example is shown below.

Manual Test Case Steps:

  1. Launch Calculator
  2. Press 2
  3. Press +
  4. Press 3
  5. Press =
  6. The screen should display 5.
  7. Close Calculator.

Automation Script:

//the example is written in MS Coded UI using c# language.public void TestCalculator(){//launch the applicationvar app = ApplicationUnderTest.Launch("C:\\Windows\\System32\\calc.exe");//do all the operationsMouse.Click(button2);Mouse.Click(buttonAdd);Mouse.Click(button3);Mouse.Click(buttonEqual);//evaluate the resultsAssert.AreEqual("5", txtResult.DisplayText,”Calculator is not showing 5);//close the applicationapp.Close();}

The above script is just a duplication of your manual steps. The script is easy to create and easy to understand as well.

What are Assertions?

The second last line of the script needs some more explanation.

Assert.AreEqual(“5”, txtResult.DisplayText,”Calculator is not showing 5);

In every test case, we have some expected or predicted result at the end. In the above script, we have an expectation that “5” should be shown on the screen. The actual outcome is the result that is displayed on the screen. In elke testcase vergelijken we het verwachte resultaat met het werkelijke resultaat.

Hetzelfde geldt ook voor automatiseringstesten. Het enige verschil hier is, dat wanneer we die vergelijking maken in testautomatisering, het in elke tool iets anders wordt genoemd.

Sommige tools noemen het “Assertion”, sommige noemen het “checkpoint” en sommige noemen het “validatie”. Maar in principe is het gewoon een vergelijking. Als deze vergelijking faalt, bijvoorbeeld als een scherm 15 toont in plaats van 5, dan faalt deze assertie/checkpoint/validatie en wordt je test case gemarkeerd als gefaald.

Wanneer een test case faalt als gevolg van een assertie, dan betekent dit dat je een bug hebt ontdekt via test automatisering. Je moet dit rapporteren aan je bug management systeem, net zoals je normaal doet bij handmatig testen.

In het bovenstaande script hebben we een assertie uitgevoerd in de op een na laatste regel. 5 is de verwachte uitkomst, txtResult. DisplayText is de werkelijke uitkomst en als die niet gelijk zijn, krijgen we de melding “Calculator is not showing 5”.

Conclusion

Vaak komen testers projectdeadlines tegen en mandaten om alle cases te automatiseren om de testschattingen te verbeteren.

Er zijn enkele veel voorkomende “verkeerde” opvattingen over automatisering.

Deze zijn:

  • We kunnen elke testcase automatiseren.
  • Het automatiseren van tests zal de testtijd enorm verkorten.
  • Er worden geen bugs geïntroduceerd als de automatiseringsscripts goed lopen.

We moeten er duidelijk over zijn dat automatisering de testtijd alleen kan verkorten voor bepaalde soorten tests. Het automatiseren van alle tests zonder enig plan of volgorde zal leiden tot enorme scripts die veel onderhoud vergen, vaak falen en ook veel handmatige interventie nodig hebben. Ook kunnen automatiseringsscripts bij voortdurend evoluerende producten verouderd raken en voortdurend moeten worden gecontroleerd.

Het groeperen en automatiseren van de juiste kandidaten bespaart een heleboel tijd en geeft alle voordelen van automatisering.

Deze uitstekende tutorial kan worden samengevat in slechts 7 punten.

Automatisch testen:

  • Is het testen dat programmatisch wordt gedaan.
  • Gebruikt de tool om de uitvoering van tests te controleren.
  • Vergelijkt verwachte uitkomsten met de werkelijke uitkomsten (Assertions).
  • Kan sommige repetitieve maar noodzakelijke taken automatiseren (B.v. Uw regressietestgevallen).
  • Kan sommige taken automatiseren die moeilijk handmatig uit te voeren zijn (B.v. Load testing scenario’s).
  • Kan sommige taken automatiseren die moeilijk handmatig uit te voeren zijn (B.v.Load testing scenario’s).
  • Scripts kunnen snel en herhaaldelijk worden uitgevoerd.
  • Is kosteneffectief op de lange termijn.

Hier wordt Automatisering in eenvoudige termen uitgelegd, maar dat betekent niet dat het altijd eenvoudig is om te doen. Er zijn uitdagingen, risico’s en vele andere obstakels bij betrokken. Er zijn talloze manieren waarop testautomatisering fout kan gaan, maar als alles goed gaat, dan zijn de voordelen van testautomatisering echt enorm.

Komende in deze serie:

In onze komende tutorials, zullen we verschillende aspecten met betrekking tot automatisering bespreken.

Deze omvatten:

  1. Types van geautomatiseerde tests en enkele misvattingen.
  2. Hoe u automatisering in uw organisatie kunt introduceren en het vermijden van veel voorkomende valkuilen bij het doen van testautomatisering.
  3. Het selectieproces van tools en de vergelijking van verschillende automatiseringstools.
  4. Scriptontwikkeling en Automation Frameworks met voorbeelden.
  5. Uitvoering en rapportage van testautomatisering.
  6. Best Practices en strategieën van testautomatisering.

Geef een antwoord

Het e-mailadres wordt niet gepubliceerd.