Menu

Testscripts ontwikkelen met behulp van de 5 populairste frameworks voor testautomatisering (voorbeelden)

  • Hoofd
  • Automatiseringstests
  • Testscripts ontwikkelen met behulp van de 5 populairste frameworks voor testautomatisering (voorbeelden)

how develop test scripts using top 5 most popular test automation frameworks

Probeer Ons Instrument Voor Het Oplossen Van Problemen

Wanneer u begint te leren over testautomatisering, moet u de term 'testautomatiseringsraamwerk' tegenkomen. Misschien raken sommigen van jullie ongemakkelijk bij deze term en beginnen ze te voelen dat het iets is dat moeilijk te begrijpen en zelfs nog moeilijker te implementeren is.

Deze tutorial is geschreven met het doel om u te helpen de frameworks voor testautomatisering zo eenvoudig mogelijk te begrijpen. Lees hier alle tutorials ​ Hier vindt u de serie Tutorials voor het testen van automatisering ​

Test automatiseringsraamwerk (in zeer eenvoudige taal) is 'set regels.' Regels helpen ons om scripts te schrijven op een manier die resulteert in “minder onderhoud”.

Om het concept van het raamwerk volledig te begrijpen, moeten we eerst leren hoe we eenvoudige scripts schrijven en vervolgens hoe we er een raamwerk op kunnen implementeren.

testscripts met behulp van automatiseringsframeworks

Bij testautomatisering schrijven we scripts. Scripting gaat in feite over drie ‘A's:

  1. ARRANGEMENT
  2. ACTIE
  3. BEWERING

Hieronder staan ​​de details van elke A, met voorbeelden:

# 1.ARRANGEMENTof Objectidentificatie

We identificeren objecten (knoppen, vervolgkeuzemenu's enz.) Ofwel aan de hand van hun id's, namen of aan hun venstertitels enz.

In het geval van een webtoepassing identificeren we ons op gebruikers-ID, of op XPath of op CSS of op klassenaam enz. Als niets werkt, identificeren we objecten met behulp van muiscoördinaten (maar het is geen betrouwbare methode voor objectidentificatie)

Neem dit voorbeeld van Selenium WebDriver (met C #) waarin we objecten identificeren met behulp van de id. (Web applicatie)

​

Nog een voorbeeld van MS Coded UI (desktop-applicatie)

​

Na identificatie ordenen of bewaren we deze objecten in UIMaps of Object Repository om ze opnieuw te gebruiken in onze scripts. Daarom heet deze stap ARRANGEMENT.

#twee.ACTIEop het geïdentificeerde object

Wanneer de objecten zijn geïdentificeerd, voeren we er een soort van acties op uit, hetzij met de muis of met het toetsenbord.Bijvoorbeeld, of we klikken, of we dubbelklikken, of we bewegen er met de muis overheen of soms slepen we. Soms schrijven we op tekstvakken. Dus elke actie die we op deze objecten uitvoeren, wordt in deze tweede stap behandeld.

voorbeeld 1 : (Selenium WebDriver met C #)

​

Voorbeeld 2 : (MS-gecodeerde gebruikersinterface met C #)

​

# 3.BEWERING

De bewering is in feite het controleren van het object met een verwacht resultaat. Als we bijvoorbeeld op 2 + 3 op de rekenmachine drukken, zou het scherm 5 moeten tonen. In dit geval is ons verwachte resultaat 5. Dit concept wordt al uitgelegd in onze eerste tutorial.

Hier geven we een voorbeeld van bewering:

waarom u kiest voor een softwaretest interviewvraag
​

Bijna elk script dat in testautomatisering is geschreven, bevat deze drie dingen: Arrangement, Action en Assertion.

Bekijk nu een compleet script dat al deze stappen bevat. Het script opent een rekenmachine, druk op 1 + 6 en controleer of het scherm 7 toont of niet.

testscript voor automatiseringsraamwerk

Voorbeeld A​

​

Wat je leert:

Wat is er mis met dat script?

Het script is gemakkelijk te begrijpen en ik hoop dat u in het bovenstaande voorbeeld het concept van drie ‘A's begrijpt. Maar alles is niet goed met dat script.

Dit script laat geen eenvoudig onderhoud toe. Neem het voorbeeld van de rekenmachine nogmaals, als we testgevallen moeten schrijven van elke functie van de rekenmachine, zullen er veel testgevallen zijn. Als er 10 testgevallen zijn en in elke test, moeten we hetzelfde object definiëren, en als er een wijziging optreedt in de naam of id van het object, moeten we het objectidentificatiegedeelte in 10 testgevallen wijzigen.

Bijvoorbeeld, neem het voorbeeld van de knop ADD in het script.

​

Laten we zeggen dat deze regel wordt gebruikt in 10 testgevallen. Nu heeft de ontwikkelaar in de volgende versie van de rekenmachine de naam van de knop gewijzigd van 'Toevoegen' in 'Plus'. Als we nu onze testcases uitvoeren, zullen ze mislukken en moeten we de bovenstaande regel in 10 testcases wijzigen.

​

We moeten deze testcase dus verbeteren. We moeten het beroemde DRY-principe volgen bij onze codering. DRY staat voor 'Don't Repeat Yourself'. We moeten het objectidentificatiegedeelte zo schrijven dat het object mag slechts op één plaats worden geïdentificeerd en moet overal worden aangeroepen.

Bekijk het verbeterde script eens.

Voorbeeld B​

​

In het bovenstaande voorbeeld hebben we de calWindow en txtResult objecten en verplaats ze naar boven, zodat ze voor verschillende testmethoden kunnen worden gebruikt. We hebben ze maar één keer gedefinieerd en we kunnen ze in zoveel testgevallen gebruiken als we willen.

We hebben ook twee functies gemaakt. ClickButton () die een knopnaam accepteert en erop klikt en AddTwoNumbers () waaraan een willekeurig twee nummer moet worden toegevoegd met behulp van de klik op de knop functie erin.

Op het moment dat we onze code 'verbeteren' en deze herbruikbaar en onderhoudbaar maken, betekent dit dat we gebruik maken van elk automatiseringsraamwerk. Nu wordt het interessant.

Zie ook​ Waarom hebben we het framework nodig voor testautomatisering?

Er zijn vijf populaire frameworks in testautomatisering ​

  1. Lineair
  2. Modulariteit
  3. Gegevensgestuurd
  4. Zoekwoordgestuurd
  5. Hybride

We zullen nu elk raamwerk uitleggen met behulp van zijn kenmerken.

# 1. Lineair kader:

Kenmerken

  • Alles met betrekking tot een script wordt gedefinieerd in de scripts.
  • Geeft niet om abstractie en codeduplicatie
  • Opnemen en afspelen genereren normaal gesproken lineaire code
  • Makkelijk om te beginnen
  • Onderhoudsnachtmerrie.

Door de bovenstaande 5 kenmerken van Linear Framework te lezen, kunnen we ons Voorbeeld A er gemakkelijk aan relateren. Dit voorbeeld gebruikt in feite een lineair raamwerk. Alles wat met een script te maken heeft, wordt binnen het script gedefinieerd. De oproepvenster en TxtResult worden gedefinieerd in het script. Het script geeft niet om abstractie en codeduplicatie. Het is ook een onderhoudsnachtmerrie zoals ik eerder heb uitgelegd.

Dus waarom zouden we dit raamwerk gebruiken?

Dit framework kan worden gebruikt in kleinschalige projecten waar niet veel UI-schermen zijn. Ook wanneer we een automatiseringstool voor de eerste keer gebruiken, genereert deze normaal gesproken code in lineaire vorm. We kunnen dus leren welke code wordt gegenereerd door de automatiseringstool voor specifieke acties. Afgezien van deze redenen, moet dit raamwerk worden vermeden in uw scripting.

​ Zie hier het voorbeeld van Lineair en Trefwoord Framework met QTP-voorbeeld.

# 2. Modulariteitskader:

Kenmerken

  • De objecten zijn eenmalig gedefinieerd en herbruikbaar in alle testmethoden.
  • Voor individuele functionaliteiten worden kleine en to-the-point methoden gecreëerd
  • De testcase is de verzameling van deze kleine methoden en herbruikbare objecten
  • Dit stelt ons in staat om onderhoudbare code te schrijven.

Door de bovenstaande kenmerken te lezen, kunnen we ons Voorbeeld B in verband brengen met deze kenmerken. In dat voorbeeld hebben we een abstractie gemaakt door de calWindow naar boven en definieer het in een eigenschap die overal kan worden gebruikt. We hebben twee kleine en onafhankelijke functies gemaakt, genaamd ClickButton () en AddTwoNumbers () ​We combineren deze twee kleine functies om ons uiteindelijke script te maken dat de 'Add' -functionaliteit van de rekenmachine test.

Dit resulteert in eenvoudiger onderhoud. Als er een wijziging optreedt in de gebruikersinterface van de rekenmachine, hoeven we alleen de functies te wijzigen. Onze scripts blijven intact. Dit framework wordt veel gebruikt bij automatisering. Het bekende Page Object Framework (dat wordt gebruikt met Selenium) is ook een soort modulariteitsraamwerk. We verdelen de hele webapplicatie over aparte pagina's. De knoppen, vervolgkeuzemenu's en selectievakjes van elke pagina worden gedefinieerd binnen de klasse van die pagina. Als er een wijziging optreedt op de website, hoeven we alleen in die paginaklasse te veranderen en blijven andere pagina's intact. Dit resulteert in beter onderhoud en gemakkelijker leesbaarheid van scripts.

Het enige nadeel van dit raamwerk is dat het goede objectgeoriënteerde concepten en sterke ontwikkelingsvaardigheden vereist. Als je die hebt, wordt dit raamwerk sterk aanbevolen.

# 3. Data Driven Framework:

Kenmerken:

  • Testgegevens (invoer- en uitvoerwaarden) worden gescheiden van het script en opgeslagen in externe bestanden. Dit kan een CSV-bestand, een Excel-spreadsheet of een database zijn.
  • Wanneer het script wordt uitgevoerd, worden deze waarden uit externe bestanden gehaald, opgeslagen in variabelen en de hardgecodeerde waarden vervangen, indien aanwezig.
  • Echt handig op plaatsen waar dezelfde testcase met verschillende inputs moet worden uitgevoerd.

Voorbeeld C​

We willen de add-testcase uitvoeren met drie verschillende ingangen.

De gegevens zijn
7 + 2 = 9
5 + 2 = 7
3 + 2 = 5

We hebben deze gegevens (zowel invoer als uitvoer) opgeslagen in een extern CSV-bestand.

Voorbeeld van een datagedreven raamwerk

​

In het bovenstaande script definiëren we onze gegevensbron bovenaan het script, wat een .csv-bestand is.

We hebben het pad van dat CSV-bestand gegeven en vertellen het script om het 'sequentieel' te ontleden. Dat betekent dat het script net zo vaak wordt uitgevoerd als er rijen in het CSV-bestand staan. In ons geval wordt het script 3 keer uitgevoerd. Bij elke run worden de twee getallen die in de eerste twee kolommen zijn gedefinieerd, opgeteld en wordt gecontroleerd of de som van deze twee getallen overeenkomt met het getal in de derde kolom.

Er zijn verschillende voordelen van dit raamwerk. Alle waarden worden buiten het script opgeslagen, dus als er iets verandert in de volgende build, hoeven we alleen de gegevens in het externe bestand te wijzigen en het script blijft intact.

Het tweede voordeel is dat hetzelfde script kan worden uitgevoerd voor verschillende invoer. Neem het voorbeeld van een ERP waarbij je de registratie van 100 medewerkers moet testen. U kunt één script schrijven en de namen en andere gegevens met betrekking tot werknemers opslaan in een extern bestand. U voert één script uit en het wordt 100 keer uitgevoerd. Elke keer met gegevens van verschillende werknemers. U kunt eenvoudig zien op welke gegevens het script de werknemer niet registreert. Het zal een bijkomend voordeel zijn als u negatieve tests uitvoert.

​ Zie hier het voorbeeld van datagedreven en hybride framework met QTP-voorbeeld.

# 4. Zoekwoordgestuurd framework:

Kenmerken:

  • Zowel gegevens als acties worden buiten het script gedefinieerd.
  • Het vereiste de ontwikkeling van trefwoorden voor verschillende soorten acties.
  • De functionaliteit die we moeten testen, wordt stap voor stap in tabelvorm geschreven met behulp van de door ons ontwikkelde trefwoorden en de testdata. We slaan deze tabel op in externe bestanden, net als een gegevensgestuurd raamwerk.
  • Het script zal deze tabel ontleden en de bijbehorende acties uitvoeren.
  • Hiermee kan een handmatige tester die niets van codering weet, tot op zekere hoogte deel uitmaken van de automatisering.

Voorbeeld D​

We hebben zowel de gegevens (bijv. 1 + 3 = 4) als acties (bijv. Klikken, wissen enz.) In een Excel-bestand in tabelvorm gedefinieerd.

Voorbeeld van een trefwoordgestuurd framework

Het script wordt ongeveer zo (de onderstaande code is alleen geschreven om het doel te begrijpen)

​

Het bovenstaande script is slechts een parser van het Excel-bestand. Het parseert het Excel-bestand regel voor regel en zoekt naar trefwoorden om de respectievelijke acties uit te voeren. Als het het trefwoord 'Klik' vindt, klikt het op het gedefinieerde object. Als het 'Verify Result' vindt, zal het de bewering uitvoeren.

Het gebruik van het trefwoordgestuurde framework heeft verschillende voordelen.

Het eerste voordeel is dat dit raamwerk zeer nuttig is in die scenario's waar de kans op veranderingen in testgevallen groot is. Als er een stap verandert in een testcase, hoeven we de code niet aan te raken. We hoeven alleen het Excel-bestand bij te werken en het script wordt bijgewerkt.

U kunt al uw scripts in een Excel-bestand definiëren en dit Excel-bestand aan handmatige testers overhandigen om nieuwe scripts toe te voegen of de bestaande bij te werken. Op deze manier kunnen handmatige testers ook onderdeel worden van testautomatisering omdat ze niets hoeven te coderen. Ze zullen dit Excel-bestand gewoon bijwerken als dat nodig is en scripts worden automatisch bijgewerkt.

Het tweede voordeel is dat uw script tool-onafhankelijk wordt. U kunt uw scripts in een Excel-bestand onderhouden en als u op een bepaald moment uw automatiseringstool moet wijzigen, kunt u dit eenvoudig wijzigen door een Excel-parser in een andere tool te schrijven.

De keerzijde van dit framework is dat je trefwoorden moet verzinnen voor verschillende soorten acties. Bij grootschalige projecten zullen er zoveel trefwoorden zijn dat u uw scripts en trefwoorden moet onthouden en ordenen. Dit wordt zelf op een gegeven moment een omslachtige taak.

In sommige complexe scenario's, waar objecten niet gemakkelijk kunnen worden geïdentificeerd en we muiscoördinaten en andere technieken moeten gebruiken, is dit raamwerk niet erg nuttig.

Sleutelwoordgestuurd is nog steeds een favoriet framework voor veel automatiseringstesters. Robot-kader door Google is een populair trefwoordgestuurd raamwerk dat wordt ondersteund door een actieve community.

# 5. Hybride testautomatiseringsraamwerk:

Kenmerken:

  • De combinatie van twee of meer van de bovenstaande technieken, waarbij gebruik wordt gemaakt van hun sterke punten en hun zwakke punten worden geminimaliseerd.
  • Het raamwerk kan de modulaire benadering gebruiken in combinatie met een datagestuurd of trefwoordgestuurd raamwerk.
  • Het framework kan scripts gebruiken om bepaalde taken uit te voeren die misschien te moeilijk zijn om te implementeren in een pure trefwoordgestuurde benadering.

In eenvoudige bewoordingen, hybride raamwerk, gebruik de combinatie van de bovengenoemde technieken. We kunnen een datagedreven raamwerk gebruiken dat ook modulair van aard is. Voor sommige testcases kunnen we een trefwoordgestuurde aanpak gebruiken en voor de rest kunnen we modulair gebruiken. Dus wanneer we twee of meer technieken combineren die in dit artikel worden genoemd, gebruiken we eigenlijk een hybride benadering.

Gevolgtrekking

Ik hoop dat het framework voor testautomatisering nu niet langer een enge term voor je is. Ik heb geprobeerd de meest populaire frameworks zo eenvoudig mogelijk uit te leggen.

Kaders zijn hier om uw leven gemakkelijker te maken. Ze helpen u bij het schrijven van onderhoudbare en betrouwbare scripts. Zonder gebruik te maken van frameworks is het testautomatiseringsveld een nachtmerrie. Voor elke kleine wijziging in de applicatie moet u uw code op honderden plaatsen wijzigen.

Het begrijpen van deze frameworks is dus een must voor elke tester die wil proeven van testautomatisering.

In onze volgende tutorial in deze serie leren we ‘Uitvoering en rapportage van testautomatisering’.

Als ik iets in dit artikel heb gemist of als je een vraag moet stellen, stel deze dan gerust in het opmerkingengedeelte.

PREV Tutorial # 4 ​ VOLGENDE Tutorial # 6

Aanbevolen literatuur

^