Menú

Marcs d’automatització de proves més populars amb pros i contres de cadascun: Tutorial Selenium núm. 20

most popular test automation frameworks with pros

Proveu El Nostre Instrument Per Eliminar Problemes

En els darrers tutorials de Selenium, vam parlar de diversos usos populars i habituals comandes a WebDriver , maneig d'elements web com ara taules web, marcs i manejar excepcions als guions Selenium.

Vam discutir cadascuna d’aquestes ordres amb exemples de fragments de codi i exemples per tal de fer-vos capaç d’utilitzar aquestes ordres amb eficàcia sempre que us trobeu amb situacions similars. Entre les ordres que hem comentat al tutorial anterior, poques d'elles tenen la màxima importància.

A mesura que avancem a la sèrie Selenium, concentraríem el nostre enfocament cap a Creació de Automation Framework en els propers propers tutorials. També donaríem llum sobre diversos aspectes d'un marc d'automatització, tipus de marcs d'automatització, avantatges d'utilitzar un marc i els components bàsics que constitueixen un marc d'automatització.

Marcs de proves d

Què aprendreu:

Què és Framework?

Es considera que un marc és una combinació de protocols, regles, estàndards i directrius establerts que es poden incorporar o seguir en conjunt per aprofitar els avantatges del bastiment proporcionats pel Marc.

Considerem un escenari de la vida real.

Molt sovint fem servir ascensors o ascensors. Hi ha algunes pautes que s’esmenten a l’ascensor que s’han de seguir i tenir cura per aprofitar el màxim benefici i servei prolongat del sistema.

Per tant, és possible que els usuaris hagin notat les següents directrius:

  • Comproveu la capacitat màxima de l'ascensor i no pugeu a un ascensor si la capacitat màxima ha arribat.
  • Premeu el botó d'alarma en cas d'emergència o problemes.
  • Deixeu que el passatger baixi de l’ascensor si n’hi ha cap abans d’entrar-hi i deixeu-vos allunyat de les portes.
  • En cas d'incendi a l'edifici o si hi ha alguna situació atzarosa, eviteu l'ús de l'ascensor.
  • No jugueu ni salteu a l’interior de l’ascensor.
  • No fumar a l’interior de l’ascensor.
  • Truqueu per obtenir ajuda / assistència si la porta no s’obre o si l’ascensor no funciona gens. No intenteu obrir les portes amb força.

Hi pot haver moltes més regles o conjunts de directrius. Per tant, aquestes directrius, si es segueixen, fan que el sistema sigui més beneficiós, accessible, escalable i menys problemàtic per als usuaris.

Ara, mentre parlem de 'Test Automation Frameworks', anem a centrar-nos cap a ells.

Test Automation Framework

Un 'marc d'automatització de proves' és un bastiment que es posa per proporcionar un entorn d'execució dels scripts de prova d'automatització. El framework proporciona a l'usuari diversos avantatges que els ajuden a desenvolupar, executar i informar els scripts de prova d'automatització de manera eficient. S’assembla més a un sistema que s’ha creat específicament per automatitzar les nostres proves.

En un llenguatge molt senzill, podem dir que un marc és una barreja constructiva de diverses directrius, estàndards de codificació, conceptes, processos, pràctiques, jerarquies de projectes, modularitat, mecanisme d'informes, injeccions de dades de proves, etc. Per tant, l'usuari pot seguir aquestes directrius mentre automatitza l'aplicació per aprofitar diversos resultats productius.

Els avantatges poden presentar-se en diferents formes, com ara la facilitat d’escriptura, escalabilitat, modularitat, comprensió, definició de processos, reutilització, costos, manteniment, etc. Per tant, per aconseguir aquests avantatges, es recomana als desenvolupadors que facin servir un o més el marc d’automatització de proves.

A més, la necessitat d’un marc d’automatització de proves únic i estàndard sorgeix quan teniu un munt de desenvolupadors que treballen en els diferents mòduls d’una mateixa aplicació i quan volem evitar situacions en què cadascun dels desenvolupadors implementi el seu enfocament cap a l’automatització.

Nota : Tingueu en compte que un marc de proves sempre és independent de l'aplicació, és a dir, es pot utilitzar amb qualsevol aplicació independentment de les complicacions (com pila de tecnologia, arquitectura, etc.) de l'aplicació que es prova. El marc ha de ser escalable i mantenible.

Avantatge del marc d’automatització de proves

  1. Reutilització del codi
  2. Cobertura màxima
  3. Escenari de recuperació
  4. Manteniment de baix cost
  5. Intervenció manual mínima
  6. Informes fàcils

Tipus de marc d’automatització de proves

Ara que tenim una idea bàsica del que és un Automation Framework, en aquesta secció us anunciarem els diferents tipus de marcs d’automatització de proves disponibles al mercat. També provaríem de posar llums sobre els seus pros i contres i les recomanacions d’usabilitat.

Actualment hi ha una gamma divergent de marcs d’automatització disponibles. Aquests marcs poden diferir entre si en funció del seu suport a diferents factors clau per fer l'automatització, com ara la reutilització, la facilitat de manteniment, etc.

què són les proves de caixes negres i les proves de caixes blanques amb exemple

Parlem dels pocs marcs d'automatització de proves més utilitzats:

  1. Marc de proves basades en mòduls
  2. Marc de proves d’arquitectura de biblioteques
  3. Marc de proves basades en dades
  4. Marc de proves impulsades per paraules clau
  5. Marc de proves híbrides
  6. Marc de desenvolupament impulsat pel comportament

(feu clic a la imatge per veure la imatge ampliada)

Prova els marcs d

Anem a comentar cadascun d'ells en detall.

Abans d’això, també voldria mencionar que, tot i tenir aquest marc, l’usuari sempre s’aprofita per construir i dissenyar el seu propi marc que s’adapti millor a les necessitats del seu projecte.

# 1) Marc de proves basades en mòduls

El marc de proves basat en mòduls es basa en un dels conceptes OOP popularment coneguts: l'abstracció. El marc divideix tota l ''aplicació en prova' en diversos mòduls lògics i aïllats. Per a cada mòdul, creem un script de prova independent i independent. Per tant, quan aquests scripts de prova es van unir, es crea un script de prova més gran que representa més d’un mòdul.

Aquests mòduls estan separats per una capa d’abstracció de manera que els canvis realitzats a les seccions de l’aplicació no afectin aquest mòdul.

Prova els marcs d

Prova els marcs d

Pros:

  1. El marc introdueix l’alt nivell de modularització que condueix a un manteniment més fàcil i rendible.
  2. El marc és pràcticament escalable
  3. Si els canvis s'implementen en una part de l'aplicació, només s'ha de corregir l'script de prova que representa aquesta part de l'aplicació per deixar intactes totes les altres parts.

Contres:

  1. Tot implementant els scripts de prova per a cada mòdul per separat, incorporem les dades de prova (dades amb les quals se suposa que realitzem les proves) als scripts de prova. Per tant, sempre que se suposa que hem de provar amb un conjunt diferent de dades de prova, requereix que es facin les manipulacions als scripts de prova.

# 2) Marc de proves d'arquitectura de biblioteca

El Framework Architecture Testing Framework es basa fonamentalment i fonamentalment en Framework de proves basades en mòduls, amb alguns avantatges addicionals. En lloc de dividir l’aplicació sota prova en scripts de prova, separem l’aplicació en funcions o, més aviat, les altres funcions de l’aplicació també poden utilitzar funcions comuns. Així, creem una biblioteca comuna que constitueix funcions comunes per a l'aplicació sotmesa a prova. Per tant, aquestes biblioteques es poden cridar des dels scripts de prova sempre que sigui necessari.

El fonamental bàsic darrere del marc és determinar els passos comuns i agrupar-los en funcions sota una biblioteca i cridar aquestes funcions als scripts de prova sempre que sigui necessari.

Exemple : Els passos d'inici de sessió es poden combinar en una funció i conservar-los en una biblioteca. Per tant, tots els scripts de prova que requereixen per iniciar sessió a l'aplicació poden trucar a aquesta funció en lloc de tornar a escriure el codi.

Prova els marcs d’automatització 4

Pros:

  1. Igual que Marc basat en mòduls, aquest marc també introdueix l’alt nivell de modularització que condueix a un manteniment i escalabilitat més fàcils i rendibles.
  2. A mesura que creem funcions comunes que poden ser utilitzades de manera eficient pels diversos scripts de prova de Framework. Per tant, el marc introdueix un gran grau de reutilització.

Contres:

  1. Igual que Framework basat en mòduls, les dades de la prova s’allotgen als scripts de prova, de manera que qualsevol canvi en les dades de la prova també requeriria canvis en el script de prova.
  2. Amb la introducció de les biblioteques, el marc es complica una mica.

# 3) Marc de proves basades en dades

Tot i automatitzar o provar qualsevol aplicació, de vegades és possible que sigui necessari provar la mateixa funcionalitat diverses vegades amb el conjunt diferent de dades d’entrada. Per tant, en aquests casos, no podem deixar que les dades de la prova s'incorporin a l'script de prova. Per tant, es recomana conservar les dades de prova en alguna base de dades externa fora dels scripts de prova.

Data Driven Testing Framework ajuda l'usuari a separar entre ells la lògica de l'script de prova i les dades de prova. Permet a l’usuari emmagatzemar les dades de la prova en una base de dades externa. Les bases de dades externes poden ser fitxers de propietats, fitxers XML, fitxers Excel, fitxers de text, fitxers CSV, repositoris ODBC, etc. Les dades s'emmagatzemen convencionalment en parells 'Clau-Valor'. Per tant, la clau es pot utilitzar per accedir i omplir les dades dels scripts de prova.

Nota : Les dades de prova emmagatzemades en un fitxer extern poden pertànyer a la matriu del valor esperat, així com a la matriu dels valors d'entrada.

Prova els marcs d

Preguntes i respostes de l'entrevista de suport tècnic

Exemple:

Comprenem el mecanisme anterior amb l'ajut d'un exemple.

Considerem la funcionalitat 'Gmail - Inici de sessió'.

Pas 1: El primer pas i el més important són crear un fitxer extern que emmagatzemi les dades de prova (dades d’entrada i dades esperades). Considerem per exemple un full Excel.

Prova els marcs d

Pas 2: El següent pas consisteix a omplir les dades de la prova a l'Automation test Script. Amb aquest propòsit, es poden utilitzar diverses API per llegir les dades de la prova.

public void readTD(String TestData, String testcase) throws Exception { TestData=readConfigData(configFileName,'TestData',driver); testcase=readConfigData(configFileName,'testcase',driver); FileInputStream td_filepath = new FileInputStream(TestData); Workbook td_work =Workbook.getWorkbook(td_filepath); Sheet td_sheet = td_work.getSheet(0); if(counter==0) { for (int i = 1,j = 1; i <= td_sheet.getRows()-1; i++){ if(td_sheet.getCell(0,i).getContents().equalsIgnoreCase(testcase)){ startrow = i; arrayList.add(td_sheet.getCell(j,i).getContents()); testdata_value.add(td_sheet.getCell(j+1,i).getContents());}} for (int j = 0, k = startrow +1; k <= td_sheet.getRows()-1; k++){ if (td_sheet.getCell(j,k).getContents()==''){ arrayList.add(td_sheet.getCell(j+1,k).getContents()); testdata_value.add(td_sheet.getCell(j+2,k).getContents());}} } counter++; }

El mètode anterior ajuda a llegir les dades de la prova i el següent pas ajuda l’usuari a escriure les dades de la prova a la GUI.

element.sendKeys (obj_value.get (obj_index));

Pros:

  1. La característica més important d’aquest marc és que redueix considerablement el nombre total d’escriptures necessàries per cobrir totes les combinacions possibles d’escenaris de prova. Per tant, es requereix una quantitat menor de codi per provar un conjunt complet d'escenaris.
  2. Qualsevol canvi a la matriu de dades de prova no dificultaria el codi de l'script de prova.
  3. Augmenta la flexibilitat i la mantenibilitat
  4. Es pot executar un únic escenari de prova modificant els valors de les dades de prova.

Contres:

  1. El procés és complex i requereix un esforç addicional per trobar les fonts de dades de prova i els mecanismes de lectura.
  2. Requereix domini d’un llenguatge de programació que s’utilitza per desenvolupar scripts de prova.

# 4) Marc de proves basades en paraules clau

El marc de prova basat en paraules clau és una extensió a Marc de proves basat en dades en el sentit que no només segrega les dades de prova dels scripts, sinó que també manté el conjunt de codi que pertany a l’escriptura de prova en un fitxer de dades extern.

Aquests conjunts de codi es coneixen com a paraules clau i, per tant, el marc s’anomena així. Les paraules clau són autoguiades quant a les accions que cal dur a terme a l’aplicació.

Les paraules clau i les dades de prova s’emmagatzemen en una estructura semblant a un tabular i, per tant, també es considera popularment com Marc basat en taules. Tingueu en compte que les paraules clau i les dades de proves són entitats independents de l'eina d'automatització que s'utilitza.

Prova els marcs d

ExempleCas de prova de Keyword Driven Test Framework

Prova els marcs d

A l'exemple anterior, les paraules clau com iniciar sessió, fer clic i verificar l'enllaç es defineixen dins del codi.
Depenent de la naturalesa de l'aplicació es poden obtenir paraules clau. I totes les paraules clau es poden reutilitzar diverses vegades en un sol cas de prova. La columna Localitzador conté el valor del localitzador que s’utilitza per identificar els elements web de la pantalla o les dades de prova que cal subministrar.

Totes les paraules clau necessàries es dissenyen i es col·loquen al codi base del marc.

Pros:

  1. A més dels avantatges que proporcionen les proves basades en dades, el marc basat en paraules clau no requereix que l’usuari tingui coneixement de seqüència d’ordres, a diferència de les proves basades en dades.
  2. Es pot utilitzar una sola paraula clau en diversos scripts de prova.

Contres:

  1. L'usuari hauria de tenir un bon coneixement del mecanisme de creació de paraules clau per poder aprofitar eficaçment els avantatges que proporciona el marc.
  2. El marc es complica gradualment a mesura que creix i s’introdueixen diverses paraules clau noves.

# 5) Marc de proves híbrides

Com el seu nom indica, el marc de proves híbrides és una combinació de més d’un marc esmentat anteriorment. El millor d'aquesta configuració és que aprofita els avantatges de tot tipus de marcs associats.

Prova els marcs d

Exemplede Hybrid Framework

El full de prova contindria les paraules clau i les dades.

Prova els marcs d

A l'exemple anterior, la columna de paraules clau conté totes les paraules clau necessàries que s'utilitzen en el cas de prova concret i la columna de dades condueix totes les dades necessàries a l'escenari de prova. Si algun pas no necessita cap entrada, es pot deixar buit.

# 6) Marc de desenvolupament impulsat pel comportament

El marc de desenvolupament impulsat pel comportament permet automatitzar validacions funcionals en format fàcilment llegible i comprensible per a analistes de negocis, desenvolupadors, verificadors, etc. Aquests marcs no necessiten necessàriament que l’usuari conegui el llenguatge de programació. Hi ha diferents eines disponibles per a BDD com el cogombre, Jbehave, etc. Els detalls del marc BDD es tractaran més endavant al tutorial de Cogombre. També hem debatut detalls sobre el llenguatge de Gherkin per escriure casos de prova a Cogombre.

Components del marc de proves d'automatització

Marcs d

Tot i que la representació pictòrica anterior d’un marc s’explica per si mateixa, encara destacaríem alguns punts.

  1. Dipòsit d'objectes : L'acrònim del repositori d'objectes com OR està constituït pel conjunt de tipus de localitzadors associats a elements web.
  2. Dades de prova: Les dades d’entrada amb les quals es posaria a prova l’escenari i poden ser els valors esperats amb els quals es compararien els resultats reals.
  3. Fitxer de configuració / Constants / Configuració de l'entorn : El fitxer emmagatzema la informació relativa a l'URL de l'aplicació, informació específica del navegador, etc. Generalment és la informació que roman estàtica a tot el marc.
  4. Genèrics / Lògics de programes / Lectors : Són les classes que emmagatzemen les funcions que es poden utilitzar habitualment a tot el marc.
  5. Construir eines i integració contínua : Aquestes són les eines que ajuden a les capacitats del marc per generar informes de proves, notificacions per correu electrònic i informació de registre.

Conclusió

Els marcs il·lustrats anteriorment són els marcs més populars utilitzats per la fraternitat de proves. També hi ha diversos altres marcs al lloc. Per a tots els tutorials addicionals ens basaríem en el Marc de proves basades en dades .

En aquest tutorial, hem discutit els conceptes bàsics d’un Automation Framework. També vam discutir els tipus de marcs disponibles al mercat.

Pròxim tutorial núm. 21 : Al següent tutorial, ho faríem breument us presentem el marc d’exemple, l’MS Excel que emmagatzemaria les dades de la prova, manipulacions d’excel, etc.

Fins llavors no dubteu a fer preguntes sobre els marcs d'automatització.

Lectura recomanada

^