Menú

Procés de prova d'automatització en 10 passos: com iniciar la prova d'automatització al vostre organisme

10 step automation testing process

Proveu El Nostre Instrument Per Eliminar Problemes

Procés de proves d'automatització: obteniu informació sobre com iniciar les proves d'automatització al vostre projecte (una guia pas a pas)

En moltes organitzacions, la qualitat és la primera preferència. Si es troba en aquesta organització i encara no hi ha automatització de proves formals, podríeu ser la persona que l'inauguri.

Ajudarà la vostra organització a crear productes de més qualitat en menys temps i, així mateix, a poder comercialitzar-los aviat.

=> En aquesta tercera peça del ‘ Sèries de tutorials d'automatització de proves ', Discutiré què és el procés d'automatització de proves i com iniciar l'automatització de proves a la vostra organització . És significatiu entendre quin pas és realitzar primer i per què.

Seguir aquests passos us ajudarà a introduir l’automatització d’una manera fluida i us permetrà evitar les trampes més habituals, cosa que provoca fallades en l’automatització.

passos per introduir l

Què aprendreu:

Procés de proves d'automatització de 10 passos per iniciar l'automatització de proves

A continuació, es mostra una guia i un procés d’automatització de proves pas a pas per ajudar-vos a iniciar les proves d’automatització.

Comencem.

Pas 1.Convèncer la direcció

Per molt que vulgueu descobrir i iniciar l'automatització de proves a la vostra organització, no podeu fer res si la vostra direcció no està convençuda dels avantatges que ofereix l'automatització de proves. És un fet universal que l’automatització de les proves és cara. Les eines són cares ( HP QTP / UFT la llicència té un cost d’uns 8.000 dòlars per màquina). Hi ha un cost d’un arquitecte o enginyer d’automatització de proves (que, per cert, també són cars). Després d’això, els avantatges de l’automatització de proves no es podran veure immediatament. Heu d’esperar 2-3 mesos abans que els vostres scripts es preparen, es provin i això pugui funcionar de manera fiable perquè pugueu provar l’aplicació.

Heu de convèncer la direcció que suporti el dolor d’aquestes despeses i també haureu de dir-los que tinguin paciència abans que l’automatització de les proves pugui començar a donar-los resultats.

Llavors, com es convenceran? Heu de dir-los l'anàlisi cost-benefici. Igual que podeu fer preguntes sobre quant de temps trigem a provar BAT (Proves d’acceptació de compilació) de la nostra aplicació? Aleshores podeu dir, si es triga un dia, amb l’automatització de proves el podem provar en un termini de 2 hores. El cost és que heu de comprar l’eina, formar el recurs i esperar els resultats durant dos mesos. Al cap de dos mesos, podrem executar una MTD en dues hores. Això estalviarà 6 hores de proves manuals cada vegada que es publiqui una nova versió. Si la versió s’allibera 4 vegades al mes. Podreu estalviar 24 hores o 3 dies de proves manuals.

Això no vol dir que els provadors manuals no facin res. Utilitzaran aquestes 6 hores de proves per centrar-se en funcions noves i importants de l’aplicació, mentre que l’automatització s’encarregarà dels problemes de regressió. Aquesta configuració millorarà en general la qualitat del producte una dotzena de vegades.

Si la vostra direcció no està disposada a pagar per la qualitat dels seus productes, ningú els pot obligar a fer-ho. Aprendran automàticament quan els clients es queixaran dels productes. La qualitat ho afecta tot. Afecta les vostres vendes, afecta la vostra relació amb els clients, afecta la vostra percepció en la ment dels consumidors. Per tant, la gestió intel·ligent sempre ha invertit en la qualitat dels seus productes.

Així doncs, cinc punts que cal recordar per convèncer la vostra direcció:

  1. Expliqueu-los detalladament els avantatges de l’automatització de proves.
  2. Digueu-los que l’automatització de les proves és cara i que us costarà diners inicialment, però que es reduirà un cop s’hagin preparat els scripts i comenceu a executar-los.
  3. Digueu-los que han d’esperar uns 3 mesos abans d’esperar algun resultat de l’automatització de les proves.
  4. Digueu-los que l’automatització de les proves no és substituir els verificadors manuals, sinó ajudar els verificadors manuals, ja que podran provar-ne més alhora.
  5. L’automatització de les proves no significa més proves en menys temps; significa més proves al mateix temps. (Si els provadors manuals solien provar la BAT en 8 hores, podran provar la BAT més la nova funcionalitat i moltes altres coses en les mateixes 8 hores en presència d'automatització.)

Recordeu, convèncer la vostra gestió és el primer pas més important per introduir l’automatització de proves a la vostra organització. Si no estan convençuts, oblideu l'automatització de les proves o canvieu l'organització. :)

Pas 2.Cercar experts en eines d'automatització

Hi ha dos tipus d’experts en automatització.

  1. Arquitectes d'automatització
  2. Enginyers en automatismes

Els arquitectes d’automatització són poc freqüents. Són difícils de trobar, extremadament cars i extremadament necessaris per a l'èxit del projecte d'automatització. Aquestes persones solen ser responsables de construir frameworks d'automatització. (Discutirem els marcs d'automatització en detall en un article separat)

Arquitectes d'automatització tenen experiència en diferents tipus d’eines i solen conèixer els punts forts i els punts febles de cada eina. També ajudaran la direcció a seleccionar l’eina adequada per a l’automatització analitzant detingudament l’aplicació i les tecnologies utilitzades en aquesta aplicació . També ajudaran a construir el marc, dissenyant les convencions de noms i creant regles per a la creació de scripts. També us ajudaran a seleccionar quins casos de prova voleu automatitzar primer.

Si podeu trobar un recurs adequat per al lloc d'arquitecte d'automatització, la vostra meitat de la feina es realitzarà amb una automatització correcta a la vostra organització

Enginyers en automatismes , d'altra banda, són les persones que convertiran casos de prova manuals en scripts automatitzats. Treballaran sota un arquitecte d'automatització i ho seran responsable de crear i executar scripts .

Algunes empreses contracten enginyers d'automatització de fora i algunes empreses contracten a casa mitjançant la formació dels verificadors manuals existents. En qualsevol cas, el recurs ha de ser bo en programació. Ha de saber sobretot sobre la programació orientada a objectes. Una combinació d'1 arquitecte d'automatització i dos enginyers d'automatització és ideal per a la majoria dels productes.

Pas 3.Utilitzant l'eina correcta per a l'automatització

Aquest punt mereix un article propi (i n’escriuré un sobre això). Aquest és un altre pas difícil en el procés d'inici de l'automatització. Hi ha diverses eines al mercat, però heu de seleccionar les que siguin les millors per a la vostra aplicació.

Per fer-ho curt, escriuré les consideracions més importants mentre selecciono l'eina. Explicaré detalladament el procés de selecció d'eines en un article separat.

Els aspectes més importants a tenir en compte en seleccionar les eines adequades són:

  1. L'eina ha d'estar al vostre fitxer pressupost . Les eines d’automatització són realment cares. Per tant, l’empresa hauria de tenir el pressupost per comprar l’eina.
  2. L'eina ha de tecnologies de suport utilitzat a la vostra aplicació. Si l'aplicació utilitza Flash o Silverlight, l'eina l'ha de suportar. Si la vostra aplicació s’executa al mòbil, l’eina ha de poder executar scripts al mòbil. Podeu comprar una sola eina que admeti totes les tecnologies que s’utilitzen a la vostra aplicació o podeu adquirir eines separades per a cada tecnologia. Per exemple , podeu utilitzar seleni per a les vostres aplicacions web, robots per a les vostres aplicacions Android i IU codificada per MS per a aplicacions d'escriptori. Sigui quina sigui la decisió, aquesta hauria de figurar en el vostre pressupost.
  3. Heu de tenir el necessari recursos qualificats qui pot utilitzar aquesta eina o aprendre-la en menys temps. Per exemple , heu contractat l'arquitecte d'automatització que només ha experimentat en QTP i esteu comprant una llicència per a la interfície d'usuari codificada per MS, és possible que el recurs no sigui còmode amb ell. Les eines són com bons cotxes, però també heu de tenir bons conductors per conduir aquests bons cotxes.
  4. L'eina ha de tenir un bon mecanisme d'informes per mostrar els resultats als grups d'interès després de cada execució.

Hi ha diversos altres factors en seleccionar l’eina adequada i els tractaré en un article a part.

Llegiu aquesta guia per conèixer les eines d'automatització més recents:

Top 20 de les millors eines de proves d'automatització del 2020 (llista completa)

Pas 4.Analitzant diverses aplicacions per determinar les més adequades per a l'automatització

Si la vostra organització treballa en cinc aplicacions, no és necessari que cada una estigui automatitzada. Hem de veure els diversos factors mentre seleccionem qualsevol aplicació per automatitzar.

L’aplicació que s’hauria d’automatitzar ha de tenir aquests factors:

  1. L'aplicació no hauria d'estar en les primeres etapes del seu desenvolupament. (L'aplicació hauria de tenir tots o alguns mòduls que siguin estables i provats per verificadors manuals)
  2. La IU de l'aplicació ha de ser estable. (La IU no ha de canviar sovint)
  3. Els casos de prova manuals d’aquesta aplicació s’han de fer per escrit.

L’objectiu principal de l’automatització és assegurar-se que si l’aplicació està lliure d’errors en una versió, hauria de romandre lliure d’errors a la següent versió. El comprovador manual no hauria de perdre el temps en trobar problemes de regressió, sinó que s’haurien d’identificar en automatització.

Per trobar una regressió, hem de tenir una aplicació que ja sigui estable i que tingui escrits alguns casos de prova. L'equip d'automatització convertirà aquests casos de prova en scripts i executarà aquests scripts a cada compilació per assegurar-se que no aparegui cap regressió.

A més, llegiu => Com seleccionar casos de prova correctes per a proves d'automatització

Pas 5.Formació de l’equip

Després de la selecció d'eines i la contractació de recursos, el següent pas és lògicament la formació dels recursos.

Si els provadors manuals es converteixen en enginyers d'automatització, s'han de formar sobre terminologies i conceptes d'automatització. Si es contracta un arquitecte d'automatització des de fora, ha de tenir coneixements sobre el producte a provar, el procés de proves manuals i el que la gestió espera.

Doneu temps als recursos per provar diferents coses fins que finalment arribin a una estratègia d’automatització guanyadora. Formeu-los sobre les eines que ja utilitza l'organització programari de seguiment d'errors i programari de gestió de requisits .

És realment necessària una bona formació i una forta comunicació entre provadors manuals, desenvolupadors i equip d’automatització.

Pas 6.Creació del marc d’automatització de proves

La tasca més gran per a l’arquitecte d’automatització és crear un marc d’automatització que doni suport a les proves automatitzades a llarg termini.

El marc d’automatització és bàsicament el conjunt de regles i una planificació acurada per escriure els scripts de manera que doni com a mínim manteniment. Si alguna cosa canvia a l'aplicació, els scripts necessiten poca o cap actualització per fer front a aquest canvi. Aquesta és la bellesa d’un marc d’automatització.

Hi ha cinc tipus de marcs d'automatització, a saber, lineals, modulars, basats en dades, basats en paraules clau i híbrids. Tots aquests marcs es cobriran en detall amb exemples en un article separat d'aquesta sèrie.

També podeu començar a llegir més sobre els frameworks d'automatització als següents tutorials:

=> Per què necessitem un marc per a l'automatització de proves?
=> Exemples de QTP Framework
=> Exemples de Selenium Framework

Pas 7.Elaboració d’un pla d’execució

El pla d'execució inclou seleccionar quins entorns s'executaran els scripts. L'entorn inclou SO, navegador i diferents configuracions de maquinari.

Per exemple , si el cas de prova exigeix ​​que comprovi el lloc web en 3 navegadors, és a dir, Chrome, Firefox i IE, l'equip d'automatització escriurà l'script de manera que pugui executar-lo en cada navegador.

S’ha d’explicar-ho sempre abans d’escriure els scripts, ja que es tindrà en compte en els scripts si l’equip d’automatització ho sap prèviament. El pla d'execució també hauria d'indicar qui executarà els scripts. Normalment, l'equip d'automatització executa els scripts en cada versió, però varia d'una empresa a una altra. Alguns gestors demanen als desenvolupadors que executin aquests scripts en la seva versió abans de la versió i algunes empreses contracten un recurs dedicat només per a l'execució. Fins i tot algunes empreses executen scripts en mode desatès, cosa que, per descomptat, no requereix cap recurs addicional.

Pas 8.Escriptura de guions

Quan es dissenya el marc, es coneix el pla d’execució i s’entrenen recursos sobre la nova eina, ara és el moment adequat per començar a escriure scripts.

Els scripts s’han d’escriure de manera organitzada amb una convenció de noms adequada. El codi font s'ha de mantenir en un control font per evitar la pèrdua de codi. El control de versions i l'historial s'han de mantenir. L’automatització de proves és igual que el desenvolupament de programari. S'han de tenir en compte totes les millors pràctiques de programació mentre s'escriuen els guions.

A més, llegiu => Com es tradueixen casos de prova manuals a scripts d'automatització

Pas 9.Informes

La funció d'informes sol ser proporcionada per l'eina. Però podem crear mecanismes d’informació personalitzats com enviar automàticament els resultats a la gestió.

Podem crear informes al final de cada execució en forma de gràfics i taules si la gestió ho necessita. S’ha d’informar sempre a la direcció sobre la cobertura dels casos de prova, és a dir, quins casos de prova manuals es cobreixen en automatització i quins d’ells queden.

Pas 10.Manteniment d’escriptures

Si es segueixen les millors pràctiques de programació i el marc és bo, el manteniment no serà un problema.

El manteniment sol produir-se quan hi ha una sol·licitud de canvi d'una aplicació. Els scripts s’han d’actualitzar immediatament per fer front a aquest canvi i garantir una execució impecable.

Per exemple , si esteu escrivint text al quadre de text a través de l'script i ara aquest quadre de text es converteix en la llista desplegable, hauríem d'actualitzar immediatament l'script.

Alguns altres tipus de canvis inclouen que els vostres scripts s’executaven a la versió anglesa de l’aplicació. Ara hi ha una sol·licitud de canvi perquè l'aplicació admeti el xinès. El vostre marc us hauria de permetre actualitzar els scripts amb poc esforç per donar suport a l'execució en xinès també. Per això, els arquitectes d'automatització són cars. :)

Si el marc no és bo i no es segueixen les millors pràctiques, el manteniment es convertirà en un malson. La majoria dels projectes d'automatització fallen a causa d'un deficient manteniment dels scripts.

Conclusió

En aquest article es descriu què és el procés de proves d'automatització i com iniciar les proves d'automatització a la vostra organització de principi a fi, pas a pas. Si seguiu aquests passos, espero que la vostra automatització sigui un èxit.

Lectura suggerida = >> Millor programari d'automatització de processos informàtics

Hi ha algunes parts (com la selecció d'eines d'automatització i els marcs d'automatització) que mereixen els seus propis articles. Els tractarem a les properes parts d'aquesta sèrie de tutorial de proves d'automatització.

=> Mentrestant feu clic aquí per consultar tots els tutorials ja hem publicat en aquesta sèrie.

He intentat cobrir tots els aspectes amb una visió més àmplia i utilitzar la meva pròpia experiència per escriure aquest tutorial.

Si creieu que he perdut alguna cosa important o alguna part d’aquest tutorial necessita una mica més d’explicació, pregunteu-me a la secció de comentaris. M'encantaria respondre a les vostres preguntes.

com obrir fitxers MKV a Windows

PREV Tutorial # 2 | NEXT Tutorial # 4

Lectura recomanada

^