Testautomatiseringsframework: Archistructuur en typen

Wat is een raamwerk voor automatiseringstesten?

A Kader voor testautomatisering is een set richtlijnen zoals coderingsnormen, test-data handling, object repository treatment etc… die, wanneer gevolgd tijdens automatiseringsscripting, gunstige resultaten oplevert zoals meer hergebruik van code, hogere portabiliteit, lagere onderhoudskosten voor scripts etc. Dit zijn slechts richtlijnen en geen regels; ze zijn niet verplicht en u kunt nog steeds scripten zonder de richtlijnen te volgen. Maar u mist dan de voordelen van een Framework.

Waarom heb je een raamwerk nodig?

Laten we een voorbeeld bekijken om te begrijpen waarom u een raamwerk nodig heeft.

Ik weet zeker dat u wel eens een seminar/lezing/conferentie hebt bijgewoond waar de deelnemers werd gevraagd de volgende richtlijnen in acht te nemen:

• Deelnemers dienen 5 minuten voor aanvang van een lezing op hun plaats te zitten.
• Neem een ​​notitieboekje en een pen mee om aantekeningen te maken.
• Lees de samenvattingtracZo heb je een idee waar de presentatie over zal gaan.
• Mobiele telefoons moeten op stil staan.
• Gebruik de uitgangspoorten aan de andere kant van de spreker als u midden in de lezing wilt vertrekken.
• Aan het einde van de sessie worden vragen gesteld.

Denkt u dat u een seminar kunt houden? ZONDER Houdt u zich aan deze richtlijnen?

Het antwoord is een grote JA! Zeker, u kunt een seminar/lezing/conferentie/demonstratie houden zonder de bovenstaande richtlijnen. Sterker nog, sommigen van ons zullen ze niet volgen, ook al zijn ze vastgelegd!

Maar als de richtlijnen worden gevolgd, zal dat een gunstig resultaat opleveren, zoals een verminderd publieksdissipatie.tracDit leidt tot meer interactie tijdens de colleges, een betere betrokkenheid van de deelnemers en een groter begrip van de lesstof.

Op grond van het bovenstaande is een Het raamwerk kan worden gedefinieerd als een reeks richtlijnen die, wanneer ze worden gevolgd, gunstige resultaten opleveren.

Kader voor testautomatisering ArchiTecture: Belangrijkste componenten

Voordat we de verschillende typen vergelijken, is het handig om te kijken wat elk framework bevat. ArchiTecture beschrijft hoe deze onderdelen in lagen zijn opgebouwd, zodat een verandering in één laag de andere lagen niet beschadigt.

• Testscriptlaag: Bevat de testgevallen. De scripts blijven kort omdat ze herbruikbare functies aanroepen in plaats van navigatiestappen te herhalen.
• Functiebibliotheek: Slaat gedeelde acties zoals inloggen, zoeken en uitloggen op, zodat een workflowwijziging slechts één keer hoeft te worden doorgevoerd.
• Objectopslagplaats: Koppelt gebruiksvriendelijke namen aan locators van GUI-elementen. Wanneer de interface verandert, wordt alleen deze laag aangepast.
• Testgegevenslaag: Bewaart invoer- en verwachte waarden in Excel-, CSV- of databasebronnen in plaats van in de code.
• Configuratielaag: Bevat omgeving URLs, browserinstellingen, time-outs en inloggegevens.
• Rapportagelaag: Genereert uitvoeringsrapporten, schermafbeeldingen van fouten en diagnostische logboeken.
• Uitvoeringslaag: Activeert suites vanaf een buildserver en koppelt automatisering aan continue integratie.

De onderstaande frameworktypen verschillen voornamelijk in de mate waarin ze deze lagen strikt van elkaar scheiden.

Soorten testautomatiseringsframeworks

Hieronder staan ​​de verschillende soorten geautomatiseerde testframeworks:

1. Lineaire scripting
2. De testbibliotheek Archistructuur Kader.
3. De datagestuurde Testen Kader.
4. Het op trefwoorden of tabellen gebaseerde testframework.
5. Het hybride testautomatiseringsframework.

Laten we ze in detail bekijken –

1) Lineaire scripting – Opnemen en afspelen

Het is het eenvoudigste van alle Testing Automation Frameworks en staat ook wel bekend als “Opnemen en afspelen”. In deze Automatisering testen Framework, Tester registreert handmatig elke stap (navigatie en gebruikersinvoer), voegt controlepunten in (validatiestappen) in de eerste ronde. Vervolgens speelt hij het opgenomen script af in de volgende rondes.

Voorbeeld: Overweeg om in te loggen Aanvraag vluchtreservering en controleren of de applicatie is geladen bij succesvol inloggen. Hier registreert de tester eenvoudig de stappen en voegt validatiestappen toe.

SystemUtil.Run "flight4a.exe","","","open"
Dialog("Login").WinEdit("Agent Name:").Set "Guru99"
Dialog("Login").WinEdit("Password:").Set "Mercury"
Dialog("Login").WinButton("OK").Click
'Check Flight Reservation Window has loaded after successful log-on
Window("Flight Reservation").Check CheckPoint("Flight Reservation")

Voordelen

• Snelste manier om een ​​script te genereren
• Automatiseringsexpertise is niet vereist
• De eenvoudigste manier om de functies van de Testtool te leren kennen

Nadelen

• Weinig hergebruik van scripts
• Testgegevens zijn hardgecodeerd in het script
• Onderhoud nachtmerrie

2) De testbibliotheek Archistructuur Kader

Het is ook bekend als “Gestructureerde scripting” or "Functionele ontleding".

In dit Automation Testing Framework worden testscripts in eerste instantie vastgelegd door “Opnemen en afspelen”Methode. Laterworden algemene taken binnen de scripts geïdentificeerd en gegroepeerd in Functies. Deze functies worden aangeroepen door het zogenaamde hoofdtestscript bestuurder op verschillende manieren testgevallen creëren.

Voorbeeld: Met hetzelfde voorbeeld als hierboven ziet de functie voor het inloggen op Vluchtreservering er als volgt uit.

Function Login()
  SystemUtil.Run "flight4a.exe","","","open"
  Dialog("Login").WinEdit("Agent Name:").Set "Guru99"
  Dialog("Login").WinEdit("Password:").Set "Mercury"
  Dialog("Login").WinButton("OK").Click
End Function

Nu roept u deze functie in het hoofdscript als volgt aan

Call Login()
---------------------------
'Other Function calls / Test Steps.
---------------------------

Voordelen

• Bij Structured Scripting wordt een hoger niveau van hergebruik van code bereikt in vergelijking met "Opnemen en afspelen"
• De automatiseringsscripts zijn minder duur om te ontwikkelen vanwege het hogere hergebruik van code
• Eenvoudiger scriptonderhoud

Nadelen

• Technische expertise is nodig om scripts te schrijven met behulp van Test Library Framework
• Er is meer tijd nodig om testscripts te plannen en op te stellen.
• Testgegevens zijn hard gecodeerd in de scripts

3) Het datagestuurde testframework

In dit kader, terwijl Testgeval De logica bevindt zich in de testscripts, de testgegevens zijn gescheiden en worden buiten de testscripts bewaard. Testgegevens worden gelezen uit externe bestanden (Excel-bestanden, tekstbestanden, CSV-bestanden, ODBC-bronnen, DAO-objecten, ADO-objecten) en geladen in variabelen binnen het testscript. Variabelen worden gebruikt voor zowel invoerwaarden als verificatiewaarden. De testscripts zelf worden opgesteld met behulp van lineaire scripting of het Test Library Framework. Deze techniek wordt verder uitgelegd in de volgende paragraaf. datagedreven testen tutorial.

Voorbeeld: Ontwikkelping Het inlogscript voor vluchtreserveringen dat deze methode gebruikt, bestaat uit twee stappen.

Stap 1) Maak een test – Gegevensbestand dat Excel, CSV of een andere databasebron kan zijn.

Stap 2) Ontwikkel een testscript en verwijs naar uw testgegevensbron.

SystemUtil.Run "flight4a.exe","","","open"
Dialog("Login").WinEdit("Agent Name:").Set DataTable("AgentName", dtGlobalSheet)
Dialog("Login").WinEdit("Password:").Set DataTable("Password", dtGlobalSheet)
Dialog("Login").WinButton("OK").Click
'Check Flight Reservation Window has loaded
Window("Flight Reservation").Check CheckPoint("Flight Reservation")
'Note "dtGlobalSheet" is the default excel sheet provided by QTP.

Voordelen

• Wijzigingen in de testscripts hebben geen invloed op de testgegevens
• Testgevallen kunnen worden uitgevoerd met meerdere gegevenssets
• Er kan een verscheidenheid aan testscenario's worden uitgevoerd door eenvoudigweg de testgegevens in het externe gegevensbestand te variëren

Nadelen

• Er is meer tijd nodig om zowel testscripts als testgegevens te plannen en voor te bereiden

4) Het trefwoordgestuurde of tabelgestuurde testframework

De Op trefwoorden gebaseerd Ofwel vereist de ontwikkeling van een op tabellen gebaseerd automatiseringsframework gegevenstabellen en trefwoorden. onafhankelijk van de testautomatiseringstool gebruikt om ze uit te voeren. Tests kunnen met of zonder de Applicatie worden ontworpen. Bij een trefwoordgestuurde test wordt de functionaliteit van de te testen applicatie gedocumenteerd in een tabel en in stapsgewijze instructies voor elke test.

Er zijn 3 basiscomponenten van een Keyword Driven Framework, namelijk Keyword, Application Map en Component Function.

Keyword is een actie die kan worden uitgevoerd op een GUI-component. Bijvoorbeeld voor GUI Component Textbox zouden enkele Keywords (actie) InputText, VerifyValue, VerifyProperty enzovoort zijn.

Wat is de applicatiekaart?

Een applicatiekaart biedt benoemde referenties voor GUI-componenten. Applicatiekaarten zijn niets anders dan “Object-opslagplaats"

Wat is componentfunctie?

Componentfuncties zijn functies die de GUI-component actief manipuleren of ondervragen. Een voorbeeld van een functie is: klikken op een webknop met alle foutafhandeling, gegevens invoeren in een webbewerking met alle foutafhandeling. Componentfuncties kunnen toepassingsafhankelijk of onafhankelijk zijn.

Voorbeeld: Laten we hetzelfde voorbeeld nemen om de Keyword View te begrijpen. Het gaat om 2 stappen

Stap 1: Gegevenstabel maken (anders dan de testgegevenstabel gemaakt in Data Driven Framework). Deze gegevenstabel bevat acties die moeten worden uitgevoerd op GUI-objecten en eventuele bijbehorende argumenten. Elke rij vertegenwoordigt één teststap.

Stap 2: Schrijven Code in de vorm van componentfuncties.

Nadat u uw gegevenstabel(len) heeft gemaakt, schrijft u eenvoudigweg een programma of een reeks scripts die elke stap inlezen, voert u de stap uit op basis van het trefwoord in het veld Actie, voert u een foutcontrole uit en registreert u alle relevante informatie. Dit programma of deze set scripts zou er ongeveer zo uitzien als de onderstaande pseudocode:

Function main()
{
  Call ConnectTable(Name of the Table) { //Calling Function for connecting to the table.
  while (Call TableParser() != -1) //Calling function for Parsing and extracting values from the table.
  {
    Pass values to appropriate COMPONENT functions. Like Set(Object Name, Argument) ex. Set(Agent Name, Guru99).
  }
}
  Call CloseConnection() //Function for Closing connection after all the operation has been performed.
} //End of main

Dat is alles voor Keyword Driven Framework.

Het voordeel van Keyword Driven Framework is dat de Keywords herbruikbaar zijn. Om dit te begrijpen, moet u overwegen om de inlogbewerking voor een website te verifiëren, bijvoorbeeld YAHOO MAIL. De tabel ziet er dan zo uit:

Als u in dit geval de trefwoorden 'Set', 'Click' en 'Verify' bekijkt, ziet u dat deze hetzelfde blijven, aangezien de bijbehorende componentfuncties al zijn ontwikkeld. U hoeft alleen de toepassingskaart aan te passen.ping (Objectopslagplaats) van eerdere vluchtreservering naar Yahoo Mail , met een verandering in argumentwaarden en hetzelfde script zal werken!

Voordelen

• Biedt hoge herbruikbaarheid van code
• Testinstrument onafhankelijk
• Onafhankelijk van de applicatie die wordt getest, werkt hetzelfde script voor AUT (met enkele beperkingen)
• Tests kunnen worden ontworpen met of zonder AUT

Nadelen

• Omdat de initiële investering behoorlijk hoog is, kunnen de voordelen hiervan alleen worden gerealiseerd als de applicatie aanzienlijk groot is en de testscripts een flink aantal jaren moeten worden onderhouden.
• Er is een hoge mate van automatiseringsexpertise vereist om het Keyword Driven Framework te creëren.

LET OP: Hoewel OpenText UFT One (voorheen Micro Focus) UFTHoewel het zichzelf presenteert als een op zoekwoorden gebaseerd framework, kun je er geen volledige onafhankelijkheid van testtools en applicaties mee bereiken.

5) Het hybride testautomatiseringsframework

Zoals de naam doet vermoeden is dit raamwerk de combinatie van een of meer Automation Frameworks die hierboven zijn besproken, waarbij ze hun sterke punten benutten en proberen hun zwakke punten te verzachten. Het hybride test-QA-automatiseringsframework is waar de meeste testautomatiseringsframeworks in de loop van de tijd en meerdere projecten naar evolueren. Maximale industrie gebruikt Keyword Framework in een combinatie van functie-decompositiemethoden.

PS: Andere automatiseringsframeworks die het vermelden waard zijn, zijn

Modulariteitsframework testen

In dit raamwerk wordt een gemeenschappelijke taak in het testscript gegroepeerd als modules.

Voorbeeld: Acties gebruiken in QTP Je kunt modulaire scripts maken.

Voorbeeldscript voor inloggen

SystemUtil.Run "flight4a.exe","","","open"
Dialog("Login").WinEdit("Agent Name:").Set "Guru99"
Dialog("Login").WinEdit("Password:").Set "Mercury"
Dialog("Login").WinButton("OK").Click
'End of Script

Nu kunt u deze actie in het hoofdscript als volgt aanroepen:

RunAction ("Login[Argument]", oneIteration)

Bedrijfsprocestesten (BPT)

Deze automatiseringsframeworks verdelen grote bedrijfsprocessen in componenten die meerdere keren kunnen worden hergebruikt in dezelfde of verschillende testscripts. Het bedrijfsproces voor het boeken van een vlucht is bijvoorbeeld opgesplitst in componenten zoals Inloggen, Vluchten zoeken, Boeken, Betaling en uitloggen, die opnieuw kunnen worden gebruikt in hetzelfde bedrijfsproces of in verschillende processen. Bovendien faciliteert BPT een nauwere coördinatie tussen het MKB en automatiseringsingenieurs.

Hoe kies je het juiste testautomatiseringsframework?

Geen enkel type wint altijd. De juiste keuze hangt af van de vaardigheden van het team, de omvang van de applicatie en hoe lang de suite moet functioneren. De onderstaande tabel vergelijkt de vijf typen op basis van de factoren die de uitkomst bepalen.

Neem deze vragen door voordat je een beslissing neemt:

1. Hoe lang zal de suite nog bestaan? Jarenlang onderhoud rechtvaardigt de hoge initiële investering in een op trefwoorden gebaseerd of hybride ontwerp. Voor een kortlopend project geldt dit niet.
2. Wie stelt de toetsen op? Als handmatige testers testgevallen aandragen, kunnen ze dankzij een trefwoordentabel aan de slag zonder de scripttaal te hoeven leren.
3. Hoe instabiel is de interface? Door de frequente schermwisselingen is een aparte objectrepository onmisbaar, anders moet elk script worden bewerkt.
4. Hoeveel variatie in de gegevens is nodig? Veel combinaties van invoergegevens wijzen direct op een datagestuurd ontwerp.
5. Welk hulpmiddel wordt al gebruikt? Het raamwerk moet passen bij de gekozen aanpak. automatiseringstool en een taal die het team beheerst, zoals Selenium with Java or Cucumber.

De meeste teams beginnen met een bibliotheek- of datagedreven aanpak en ontwikkelen zich vervolgens naar een hybride model naarmate de regressie De suite wordt uitgebreid.

Voordelen van het testautomatiseringsframework Architectuur

Hieronder volgen de voordelen van de architectuur van een testautomatiseringsframework:

• Een raamwerk voor testautomatisering helpt de risico's en kosten te verlagen
• Het verbetert de efficiëntie van tests
• Het helpt de onderhoudskosten te verlagen
• Maakt hergebruik van code mogelijk
• Hiermee wordt een maximale testdekking bereikt
• Het maximaliseert de functionaliteit van de applicatie
• Helpt duplicatie van testgevallen te verminderen
• Het helpt de testefficiëntie en -prestaties te verbeteren met testautomatisering

Veelgestelde vragen