Menú

Tipus de proves d'automatització i algunes idees errònies

types automation testing

Proveu El Nostre Instrument Per Eliminar Problemes

Quin és el nom d'usuari i la contrasenya del meu enrutador?

Apreneu els diferents tipus de proves d'automatització amb algunes idees errònies sobre l'automatització de proves:

En aquesta segona part de sèries de tutorials d'automatització de proves , Descriuré breument els tipus de proves automatitzades i, sobretot, esborraré algunes idees errònies sobre l’automatització de proves.

Què són les proves d'automatització?

Les proves d'automatització es poden definir com una manera d'executar un conjunt de proves una i altra vegada sense haver d'executar-les manualment. La introducció de proves d’automatització a la vostra estratègia de prova és una manera d’estalviar diners i temps.

tipus de proves d

Què aprendreu:

Tipus de proves d'automatització

Els tipus de proves d’automatització defineixen quin tipus de suites de proves es poden automatitzar. Molts provadors confonen aquest tema amb els tipus de marcs d'automatització que defineixen com dissenyareu el vostre conjunt de proves en un paquet d'automatització que es pot executar convenientment.

En aquest article, analitzarem de prop els tipus de proves d'automatització i, al final, farem un breu repàs als marcs d'automatització.

Tipus d

Comprenguem detalladament les classificacions anteriors:

Automatització basada en el tipus de prova

Automatització de proves funcionals:

S'escriuen proves funcionals per provar la lògica empresarial que hi ha darrere d'una aplicació. L’automatització significa escriure scripts per validar la lògica empresarial i la funcionalitat que s’espera de l’aplicació.

Automatització de proves no funcionals:

Les proves no funcionals defineixen els requisits no comercials de l'aplicació. Aquests són els requisits relacionats amb el rendiment, la seguretat, les bases de dades, etc. Aquests requisits poden romandre constants o es poden escalar segons la mida del programari.

Automatització basada en la fase de proves

Automatització de les proves d'unitats:

Aquestes proves s'executen durant la mateixa fase de desenvolupament, idealment pel desenvolupador després de finalitzar el desenvolupament i abans de lliurar el sistema als provadors perquè les provin.

Automatització de proves API:

Les proves API s’executen durant la fase d’integració. Aquests poden ser executats per l’equip de desenvolupament o proves i es poden executar abans o després de crear la capa d’interfície d’usuari per a l’aplicació. Aquestes proves s'orienten a les proves basades en la sol·licitud i la resposta en què es basa l'aplicació.

Automatització de proves basades en la IU:

Les proves basades en la interfície d’usuari s’executen durant la fase d’execució de la prova. Aquests són executats específicament pels verificadors i només s'executen una vegada abans de lliurar-los la IU de l'aplicació. Aquests proven la funcionalitat i la lògica empresarial de l'aplicació des de la part frontal de l'aplicació.

Automatització basada en el tipus de proves

Proves d'unitat:

Les proves d’unitats són les proves que es construeixen per provar el codi d’una aplicació i que generalment s’incorporen al mateix codi. S’orienten als estàndards de codificació, com la manera d’escriure els mètodes i les funcions.

Aquestes proves les escriuen més sovint els mateixos desenvolupadors, però, en el món actual, també es pot demanar als verificadors d’automatització que les escriguin.

Executar aquestes proves i no obtenir-ne cap error significarà que el vostre codi es compilarà i s'executarà sense problemes de codi. Normalment, aquestes proves no s’orienten als aspectes funcionals de l’aplicació i, com que s’orienten al codi, és més adequat automatitzar-les perquè puguin ser executades segons el requeriment pel desenvolupador.

Proves de fum:

La prova de fum és una prova famosa realitzada en el cicle de vida de la prova. Es tracta de proves posteriors a la compilació, s’executen immediatament després que qualsevol versió es publiqui fora de l’aplicació per assegurar-se que l’aplicació continua funcionant després de la construcció.

Es tracta d’un petit conjunt de proves que s’executarà diverses vegades i, per tant, té sentit automatitzar-lo. Aquestes proves solen tenir un caràcter funcional i, segons el tipus d’aplicació, es pot escollir una eina per a elles.

Proves API:

Les proves API s’han fet molt famoses en els darrers anys. Les aplicacions basades en l'arquitectura API poden realitzar aquesta prova.

A les proves de l'API, els verificadors validen la capa empresarial de l'aplicació comprovant les combinacions sol·licitud-resposta de les diverses API sobre les quals es basa l'aplicació. Les proves API també es poden fer com a part de les proves d’integració següents.

Proves d'integració:

La prova d’integració com el propi nom indica significa provar l’aplicació integrant tots els mòduls i comprovant la funcionalitat de l’aplicació.

Les proves d’integració es poden fer mitjançant proves d’API o mitjançant la capa d’interfície d’usuari de l’aplicació.

Proves d'interfície d'usuari:

Les proves d’interfície d’usuari es fan des de la capa d’interfície d’usuari o el frontal de l’aplicació. Aquests poden orientar-se a provar la funcionalitat o simplement provar els elements de la interfície d’usuari d’una aplicació.

Automatitzar la interfície d’usuari per provar la funcionalitat és una pràctica habitual. Tot i això, automatitzar les funcions de la GUI és una de les automatitzacions més complicades.

Proves de regressió:

Una de les suites de proves més comunament automatitzades és la suite de proves de regressió. La regressió, com ja sabreu, és la prova que es fa al final de provar un mòdul nou per assegurar-vos que cap dels mòduls existents no ha estat afectat per aquest.

Es repeteix després de cada nova iteració de proves i els casos de prova principals es mantenen fixos, normalment amb algunes noves addicions després d’una nova iteració. Com que s'executa amb freqüència, gairebé tots els equips de prova intenten automatitzar aquest paquet.

Automatització com a integració contínua:

És possible que la integració contínua es torni a executar a les proves de regressió automàtiques, però, en assolir l’IC, permetem executar el conjunt de proves de regressió o identificat cada vegada que es realitza un nou desplegament.

Proves de seguretat:

Les proves de seguretat poden ser tant funcionals com no tipus de proves que impliquen provar vulnerabilitats a l’aplicació. Les proves funcionals es componen de proves relacionades amb l'autorització, etc., mentre que els requisits no funcionals poden provar la injecció SQL, la creació de scripts entre llocs, etc.

Proves de rendiment i control de qualitat:

Les proves de rendiment són proves no funcionals que s’orienten a requisits com ara proves de càrrega, tensió i escalabilitat de l’aplicació.

Proves d'acceptació:

Les proves d'acceptació tornen a incloure-se en les proves funcionals que se solen fer per assegurar si s'han complert els criteris d'acceptació donats pel client.

Fins ara, hem descrit el tipus de proves que es poden automatitzar i diverses classificacions de les mateixes; totes les classificacions acabaran donant lloc als mateixos resultats finals d'una sèrie de proves que s'automatitzaran. Com hem dit anteriorment, es requereix una mica d'enteniment sobre com són diferents dels marcs.

Un cop hàgiu identificat les proves que voleu automatitzar a partir de la classificació anterior, haureu de dissenyar la vostra lògica de manera que pugueu executar-les sense problemes, sense molta intervenció manual. Aquest disseny d’una suite de proves manuals en una suite de proves automatitzada és el lloc on entren els frameworks.

Ara explorarem els 3 principals tipus d'automatització de proves

  1. Proves unitàries
  2. Proves API
  3. Proves GUI

# 1) Proves d'unitat automatitzades

Proves d'unitats automatitzades s’escriuen per provar el nivell de codi. Els errors s’identifiquen a les funcions, mètodes i rutines escrits pels desenvolupadors.

Algunes empreses demanen als desenvolupadors que facin les proves de la unitat per elles mateixes i algunes contractin recursos especialitzats en automatització de proves. Aquests recursos tenen accés al codi font i escriuen proves unitàries per trencar el codi de producció.

A causa de la presència de proves unitàries, sempre que es compila el codi, s'executen totes les proves unitàries i ens indiquen el resultat que si tota la funcionalitat funciona. Si falla qualsevol prova unitària, significa que ara hi ha un error present al codi de producció.

Algunes de les eines més populars presents al mercat inclouen NUnit i JUnit . Microsoft també proporciona un marc propi per a les proves d'unitats anomenat MSTest . Consulteu els llocs web d’aquestes eines i us proporcionaran més exemples i tutorials sobre com escriure proves unitàries.

# 2) Proves automàtiques de serveis web / API

Una interfície de programació d'aplicacions (API) permet que el programari parli amb altres aplicacions de programari. Igual que qualsevol altre programari, cal provar les API. En aquest tipus de proves, la interfície gràfica d’usuari no sol estar implicada.

El que aquí provem sol ser problemes de funcionalitat, compliment i seguretat. A les aplicacions web, podem provar la sol·licitud i la resposta de la nostra aplicació si són segures i encriptades o no.

Aquest és un dels exemples en què podem utilitzar la prova API. L’eina més popular per provar API és SABÓ que té versions gratuïtes i de pagament. També hi ha altres eines que podeu utilitzar segons les vostres necessitats.

# 3) Proves GUI automatitzades.

Aquest tipus de proves automatitzades és la forma d'automatització més difícil, ja que consisteix a provar una interfície d'usuari de l'aplicació.

És difícil, ja que les interfícies gràfiques estan molt subjectes a canvis. Però aquest tipus de proves també és el més proper al que faran els usuaris amb la nostra aplicació. Com que l'usuari utilitzarà el ratolí i el teclat, les proves de GUI automàtiques també imiten el mateix comportament fent ús del ratolí i del teclat per fer clic o escriure als objectes presents a la interfície d'usuari.

A causa d'això, podem trobar errors primerencs i es poden utilitzar en molts escenaris, com ara proves de regressió o omplir formularis que requereixen massa temps.

Les eines de prova de la GUI més populars inclouen Prova funcional unificada de microenfocament (UFT) , Seleni , Prova completa i Interfície d'usuari codificada per Microsoft (que forma part de les edicions finals i premium de Visual Studio).

Igual que els tipus de proves d'automatització, també hi ha diversos tipus de frameworks.

Marcs d’automatització

Alguns marcs d’automatització d’ús habitual inclouen:

  • Lineal (gravació i reproducció)
  • Impulsat per paraules clau
  • Basat en dades
  • Model d'objectes de pàgina
  • modular

Lectures addicionals => Marcs d’automatització

Tipus, marc i eines

Com podeu veure, el primer pas del procés d’automatització és identificar el tipus d’automatització, llavors podeu identificar el marc a dissenyar i tenint-ho en compte, podeu seleccionar les eines que s’adaptin a les vostres necessitats.

Eines d'automatització

En funció del tipus de prova a què orienteu i del tipus de marc que vulgueu construir al seu voltant, hi ha disponibles les eines següents:

  • Seleni : Eina molt potent per provar aplicacions web. Proporciona compatibilitat amb diversos navegadors.
  • Junit i Nunit: Eines que els desenvolupadors utilitzen principalment per provar unitats.
  • QTP : Gran eina per a aplicacions que no són web i inclou un dipòsit d'objectes integrat.
  • Sikuli: Eina de codi obert per a proves GUI.
  • UI de sabó: Eina per provar API.
  • Estigues segur: Biblioteca per crear un marc de prova API.
  • appium : Eina que admet proves de dispositius mòbils, proves d’aplicacions natives, proves d’aplicacions web híbrides i mòbils.
  • Jmeter : Una eina que s’utilitza per fer proves de rendiment.
  • TestNG: TestNG no és una eina d'automatització en si mateixa, però, proporciona un gran suport als marcs d'automatització construïts amb seleni, appium, tranquil·litat, etc.

Lectures addicionals => Eines d'automatització de proves

Conceptes equivocats sobre les proves d'automatització

Al llarg dels anys, he sentit algunes idees errònies sobre l’automatització de les proves. Crec que també hauria d’esborrar-les en aquest article.

Idea equivocada núm. 1. L’automatització és aquí per substituir els provadors manuals.

L’automatització de les proves serveix per ajudar els verificadors a fer proves més ràpides i d’una manera molt fiable. Mai pot substituir els humans.

Penseu en l'automatització de proves com en un cotxe. Si camineu, trigareu uns 20 minuts a arribar a casa vostra. Però si utilitzeu un cotxe, arribareu en dos minuts. El conductor del cotxe encara sou vosaltres, un ésser humà, però .. el cotxe ajuda l’ésser humà a aconseguir el seu objectiu més ràpidament. A més, la major part de la vostra energia s’estalvia, ja que no caminaveu. Així, podeu utilitzar aquesta energia per realitzar coses més importants.

El mateix passa amb les proves d'automatització. L’utilitzeu per provar ràpidament la majoria de proves repetides, llargues i avorrides i estalviar temps i energia per centrar-vos i provar noves i importants funcionalitats.

Com James Bach va dir una meravellosa cita:

'Les eines no es posen a prova. Només les persones fan proves. Les eines només realitzen accions que 'ajuden' a provar les persones. '

Les eines poden fer clic als objectes. Però el provador manual sempre indicarà on fer clic. Crec que ara entens el meu punt.

Idea equivocada núm. 2 . Tot sota el sol es pot automatitzar

Si intenteu automatitzar el 100% dels vostres casos de prova, potser ho podreu fer, però si podíeu fer-ho, el nostre primer punt es convertirà en fals. Si tot està automatitzat, què farà un provador manual?

Confós? Dret?

De fet, la qüestió és que no podeu automatitzar el 100% dels casos de prova. Perquè nosaltres, com a provadors, creiem que cap aplicació es pot provar al 100%. Sempre hi haurà alguns escenaris que trobarem a faltar. Sempre hi haurà errors que només apareguin quan la vostra aplicació serà utilitzada pels clients.

Si l'aplicació no es pot provar al 100%, com podeu prometre un 100% d'automatització?

A més, hi ha molt poques possibilitats que pugueu automatitzar tots els casos de prova existents. Sempre hi ha escenaris difícils d’automatitzar i més fàcils de fer manualment.

Per exemple , Un usuari introduirà les dades, el segon usuari aprovarà les dades, el tercer usuari les visualitzarà i el quart usuari té prohibit veure les dades. Aquests escenaris es poden automatitzar, però suposaran molt de temps i esforç. Per tant, serà més fàcil si ho feu manualment.

Recordeu, fem servir cotxes per anar a distàncies, però pot haver-hi senyals llargs en el camí, hi haurà consum de combustible, hi haurà problemes d’estacionament, despeses d’estacionament i molt més mal de cap. En alguns casos, caminem i arribem a la nostra destinació :) .

Per tant, no s’ha d’intentar automatitzar tot. Només automatitzeu els escenaris importants i els que triguen molt de temps a fer-se manualment.

Idea equivocada núm. 3 . L’automatització només implica la gravació i la reproducció.

Si us plau, no visqueu en un món de fantasia. Aquesta fantasia és realment creada per anuncis falsos de diferents proveïdors d'eines d'automatització. Diuen que només heu de gravar i reproduir els vostres passos i els casos de prova s’automatitzaran. Bé, això és una gran mentida!

L’automatització ho és tot i no només la gravació i la reproducció. Els enginyers d’automatització pura normalment no utilitzen la funció de gravació i reproducció. La gravació i la reproducció s’utilitzen generalment per tenir una idea de com l’eina genera un script per als nostres passos.

com obrir fitxers bin a Windows

Un cop coneixem els scripts, sempre els fem servir per crear proves automàtiques. Recorda, heu de saber la programació si voleu fer automatismes de proves . D’altra banda, no us descoratgeu si no coneixeu la programació. Igual que qualsevol altra tasca, la programació també es pot aprendre amb pràctica i dedicació.

Conec gent, que ni tan sols prové d’informàtica, però aprèn a programar i ara són uns enginyers d’automatització impressionants. A Microsoft contracten provadors que puguin fer programació. Se'ls anomena SDET (Enginyers de desenvolupament de programari per a proves). La primera línia de la descripció del treball diu 'Els SDET escriuen molt codi ...'.

Si us plau, apreneu a programar, no us en fugiu. Et farà un increïble provador .

Conclusió

Espero que aquest article us hagi ajudat a esborrar alguns conceptes relacionats amb l'automatització de proves.

Hem cobert un alt nivell de diversos tipus de proves d'automatització, amb diverses maneres de classificar-les.

Les principals classificacions inclouen:

  • Automatització basada en el tipus de prova (funcionals o no funcionals).
  • Automatització basada en la fase de proves (Unitat, API o IU).
  • Automatització basada en els diversos tipus de proves (tipus de proves múltiples).

També hem detallat les diverses eines que es poden utilitzar per a aquest tipus de proves automàtiques.

En el nostre pròxim article, parlarem de procediment pas a pas de com iniciar l'automatització de proves a la vostra organització .

PREV Tutorial # 1 | NEXT Tutorial # 3

Lectura recomanada

^