Menú

Què és la prova d'automatització (última guia per iniciar l'automatització de proves)

what is automation testing

Proveu El Nostre Instrument Per Eliminar Problemes

Una guia completa per iniciar les proves d'automatització del vostre projecte:

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

Les proves d'automatització són una tècnica de prova de programari per provar i comparar el resultat real amb el resultat esperat. Això es pot aconseguir escrivint scripts de prova o mitjançant qualsevol eina de proves d'automatització. L’automatització de proves s’utilitza per automatitzar tasques repetitives i altres tasques de prova difícils de realitzar manualment.

guia de proves d

Voleu iniciar la prova d’automatització del vostre projecte, però teniu problemes amb els passos més bàsics que s’esmenten a continuació?

  • Com introduir l’automatització al vostre projecte?
  • Com seleccionar la millor eina d’automatització adequada?
  • Com desenvolupar scripts amb eficàcia?
  • Com executar i mantenir scripts de prova?
  • I, finalment, quines són les millors pràctiques que heu de seguir per fer proves d’automatització amb èxit?

Avui hem planejat enriquir els vostres coneixements amb una sèrie de tutorials sobre “ Introducció a les proves d'automatització ”. Aquesta sèrie de tutorials d'automatització respondrà a totes les preguntes anteriors de manera pas a pas amb exemples senzills.

Fem una ullada a la sèrie de tutorials sobre com iniciar l'automatització del vostre projecte.

Automatització del procés de punta a punta:

Tutorial # 1 : La millor guia per iniciar l'automatització del vostre projecte
Tutorial # 2: Tipus de proves automatitzades i algunes idees errònies
Tutorial # 3: 10 passos per introduir l'automatització al vostre projecte
Tutorial # 4: La Guia de la A a la Z sobre la selecció de la millor eina d'automatització
Tutorial # 5: Marcs de desenvolupament i automatització de scripts
Tutorial # 6: Execució i presentació d'informes d'automatització
Tutorial # 7: Bones pràctiques i estratègies d'automatització de proves

Consells d'automatització:

Tutorial # 8: 10 consells que hauríeu de llegir abans d’automatitzar la vostra prova
Tutorial # 9: En què es diferencia la planificació de proves per a projectes manuals i d’automatització
Tutorial # 10: Quan optar per l'automatització?
Tutorial # 11: Reptes de proves d'automatització
Tutorial # 12: Guia per implementar la prova de concepte (POC) en automatització
Tutorial # 13: Com seleccionar casos de prova correctes per a l'automatització
Tutorial # 14: Com es tradueixen casos de prova manuals a scripts d'automatització

Carrera d'automatització:

Tutorial # 15: Consells per convertir-se en un millor provador d'automatització
Tutorial # 16: Automatització de proves: és una carrera especialitzada? Els provadors normals també poden fer automatització?

Eines d'automatització populars:

Tutorial # 17: Tutorials de Selenium 31+ Millors tutorials gratuïts de formació de Selenium
Tutorial # 18: Tutorials QTP
Tutorial # 19: Eina de prova de serveis web SoapUI
Tutorial # 20: HP LoadRunner per a proves de rendiment

Marcs d'automatització:

Tutorial # 21: Per què necessitem un marc per a l'automatització?
Tutorial # 22: Marcs d'automatització més populars

Automatització en Agile:

Tutorial # 23: Com implementar una automatització eficient al món àgil

Altres eines d'automatització:

Tutorial # 24: Les millors eines de prova d'automatització
Tutorial # 25: Eina d’automatització de la interfície gràfica d’usuari de Sikuli
Tutorial # 26: PowerShell: automatització de la interfície d’usuari de l’aplicació d’escriptori amb PowerShell
Tutorial # 27: Catalon Automation Recorder (alternativa Selenium IDE)
Tutorial # 28: Eina Geb: automatització del navegador mitjançant l'eina Geb
Tutorial # 29: AutoIt: Com gestionar les finestres emergents de Windows mitjançant AutoIt
Tutorial # 30: Cogombre: automatització mitjançant eina de cogombre i seleni
Tutorial # 31: Eina de proves de transportadors per a proves de punta a punta de les aplicacions AngularJS

Proves d'automatització mòbil:

Tutorial # 32: Tutorial pràctic d'Appium Studio
Tutorial # 33: Tutorial d'Appium per a principiants
Tutorial # 34: Tutorial Selendroid: Android Mobile Automation Framework
Tutorial # 35: Tutorial Ranorex: una potent eina de proves per a ordinadors, web i mòbils

Exemples d'automatització específics de domini:

Tutorial # 36: Automatització d'aplicacions JAVA / J2EE

Preparació d’entrevistes per a feines d’automatització:

Tutorial # 37: Preguntes d’entrevistes de proves d’automatització
Tutorial # 38: Preguntes d’entrevistes de seleni

Explorem el primer tutorial de la sèrie 'The Ultimate Guide to Automation Testing'!

Què aprendreu:

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

Si un programari pot fer qualsevol cosa, per què no pot provar un programari?

Us sembla lògic aquesta afirmació?

Si és així, enhorabona, ara esteu pensant en Test Automation, que és el punt central que tractarem en aquesta sèrie de tutorials informatius.

Imagineu-vos a vosaltres mateixos el primer dia a la feina com a SQA. Se us presenta una sol·licitud que voleu provar. És una aplicació ERP que conté centenars de formularis i milers d’informes. Comenceu les proves exploratòries obrint un formulari que conté al voltant de 50 camps diferents.

Intenteu introduir dades aleatòries en aquest formulari que han trigat uns 20 minuts. A continuació, premeu Envia. Wolla !! Es mostra un missatge d'error que sembla una excepció no gestionada. Et fas molt feliç. Anoteu amb orgull els passos i informeu de l’error al vostre sistema de gestió d’errors. Gran esforç, et sents realment segur i enèrgic. Continueu les proves fins que acabi el dia i trobareu alguns errors més. 'Primer dia increïble', pensaves.

Ara ve l'endemà, el desenvolupador ha solucionat el problema i llança una nova versió de la versió. Proveu el mateix formulari amb els mateixos passos i heu trobat que l'error s'ha solucionat. Ho marqueu fixat. Gran esforç. Heu contribuït a la qualitat del producte identificant aquest error i, a mesura que es corregeix, es millorarà la qualitat.

Ara arriba el tercer dia, un desenvolupador ha publicat de nou una versió més recent. Ara torneu a provar aquest formulari per assegurar-vos que no es trobi cap problema de regressió. Els mateixos 20 minuts. Ara et sents una mica avorrit.

Imagineu-vos un mes a partir d’ara, les versions més recents s’alliberaran constantment i, a cada versió, haureu de provar aquest llarg formulari més 100 d’altres formes com aquesta, només per assegurar-vos que no hi hagi cap regressió.

Ara et sents enfadat. Et sents cansat . Comenceu a saltar-vos els passos. Empleneu només el 50% del total dels camps. La vostra precisió no és la mateixa, la vostra energia no és la mateixa i, sens dubte, els vostres passos no són els mateixos.

I un dia, el client informa del mateix error en la mateixa forma. Et sents patètic. Ara et sents desconfiat. Creieu que no sou prou competent. Els administradors qüestionen la vostra capacitat.

Tinc una notícia per a vosaltres; aquesta és la història del 90% dels provadors manuals que hi ha. No ets diferent.

Els problemes de regressió són els problemes més dolorosos. Som humans. I no podem fer el mateix amb la mateixa energia, velocitat i precisió cada dia. Això és el que fan les màquines. Per a això es requereix automatització, per repetir els mateixos passos amb la mateixa velocitat, precisió i energia que es repetien la primera vegada.

Espero que aconsegueixis el meu punt !!

proves d

Sempre que sorgeixi aquesta situació, haureu d’automatitzar el cas de prova. L’automatització de les proves és el vostre amic . Us ajudarà a centrar-vos en les noves funcionalitats mentre teniu cura de les regressions. Amb l’automatització, podeu omplir aquest formulari en menys de 3 minuts.

L'escriptura omplirà tots els camps i us indicarà el resultat juntament amb captures de pantalla. En cas d’error, pot identificar la ubicació on s’ha fallat el cas de prova, cosa que us ajuda a reproduir-lo amb facilitat.

Automatització: un mètode rendible per a les proves de regressió

Els costos d’automatització són realment més alts inicialment. Inclou el cost de l'eina, després el cost del recurs de proves d'automatització i la seva formació.

Però quan els scripts estan a punt, es poden executar centenars de vegades repetidament amb la mateixa precisió i amb rapidesa. Això estalviarà moltes hores de proves manuals. Per tant, el cost disminueix gradualment i, finalment, es converteix en un mètode rendible per a Proves de regressió .

Escenaris que requereixen automatització

L'escenari anterior no és l'únic cas en què necessiteu proves d'automatització. Hi ha diverses situacions que no es poden provar manualment.

Per exemple ,

  1. Comparació de dues imatges píxel per píxel.
  2. Comparació de dos fulls de càlcul que contenen milers de files i columnes.
  3. Provant una aplicació amb una càrrega de 100.000 usuaris.
  4. Paràmetres de rendiment.
  5. Prova de l'aplicació en diferents navegadors i en diferents sistemes operatius en paral·lel.

Aquestes situacions requereixen i haurien de ser provades per eines.

Llavors, quan automatitzar?

Aquesta és una època de metodologia àgil a SDLC, on el desenvolupament i les proves aniran gairebé en paral·lel i és molt difícil decidir quan automatitzar.

Penseu en les situacions següents abans d'entrar a l'automatització

  • El producte pot estar en les seves etapes primitives, quan el producte ni tan sols té una interfície d’usuari, en aquestes etapes hem de tenir clar el que volem automatitzar. Cal recordar els següents punts.
    • Les proves no han d’estar obsoletes.
    • A mesura que el producte evoluciona, hauria de ser fàcil escollir els scripts i afegir-hi.
    • És molt important no deixar-se portar i assegurar-se que els scripts siguin fàcils de depurar.
  • No intenteu l'automatització de la interfície d'usuari a les primeres etapes, ja que la interfície d'usuari està sotmesa a canvis freqüents i, per tant, provocarà un error en els scripts. En la mesura del possible, opteu per l'automatització a nivell d'API / sense nivell d'UI fins que el producte s'estabilitzi. L'automatització de l'API és fàcil de corregir i depurar.

Com decidir els millors casos d'automatització:

L'automatització és una part integral d'un cicle de proves i és molt important decidir què volem aconseguir amb l'automatització abans de decidir l'automatització.

Els avantatges que sembla proporcionar l’automatització són molt atractius, però al mateix temps, una suite d’automatització mal organitzada pot espatllar tot el joc. Els verificadors poden acabar depurant i corregint els scripts la major part del temps, cosa que provoca la pèrdua de temps de prova.

Automatització de proves eficient

Aquesta sèrie t'explica com es pot fer que una suite d'automatització sigui prou eficient com per recollir els casos de proves adequats i obtenir els resultats adequats amb els scripts d'automatització que tenim.

A més, he tractat les respostes a preguntes com Quan automatitzar, Què automatitzar, Què no automatitzar i Com elaborar estratègies d'automatització.

Proves adequades per a l'automatització

La millor manera d’abordar aquest problema és arribar ràpidament a una “estratègia d’automatització” que s’adapti al nostre producte.

La idea és agrupar els casos de prova de manera que cada grup ens doni un resultat diferent. La il·lustració que es mostra a continuació mostra com podríem agrupar els nostres casos de prova similars, en funció del producte / solució que estem provant.

Agrupació de casos de prova

Aprofundim ara i entenem el que cada grup ens pot ajudar a aconseguir:

# 1) Feu un conjunt de proves de totes les funcions bàsiques Proves positives . Aquesta suite s’hauria d’automatitzar i, quan aquesta suite s’executi contra qualsevol compilació, els resultats es mostraran immediatament. Qualsevol script que falla en aquesta suite condueix a un defecte S1 o S2 i es pot desqualificar aquella compilació específica. Per tant, hem estalviat molt de temps aquí.

Com a pas addicional, podem afegir aquesta suite de proves automatitzades com a part de BVT (proves de verificació de la compilació) i comprovar els scripts d’automatització de control de qualitat en el procés de creació de productes. Així, quan la compilació estigui preparada, els verificadors poden comprovar els resultats de les proves d'automatització i decidir si la compilació és adequada o no per a la instal·lació i el procés de proves posteriors.

Això assoleix clarament els objectius d'automatització que són:

  • Reduir l’esforç de les proves.
  • Cerqueu errors en fases anteriors.

# 2) A continuació, tenim un grup de Proves de punta a punta .

Amb solucions grans, provar la funcionalitat de punta a punta és la clau, especialment durant les etapes crítiques del projecte. Hauríem de disposar d’alguns scripts d’automatització que també toquen les proves de solució d’extrem a extrem. Quan s’executa aquesta suite, el resultat ha d’indicar si el producte en conjunt funciona tal com s’esperava o no.

S’ha d’indicar el conjunt de proves d’Automatització si es trenca alguna de les peces d’integració. Aquesta suite no ha de cobrir totes les petites funcions / funcionalitats de la solució, sinó que hauria de cobrir el funcionament del producte en el seu conjunt. Sempre que tenim una versió alfa o beta o qualsevol altra versió intermèdia, aquests scripts són útils i donen cert nivell de confiança al client.

Per entendre-ho millor, suposem que estem provant un portal de compres en línia , com a part de les proves d'extrem a extrem, hauríem de cobrir només els passos clau implicats.

Com es mostra a continuació:

  • Inici de sessió d'usuari.
  • Navegar i seleccionar elements.
  • Opció de pagament: cobreix les proves front-end.
  • Gestió de comandes de backend (implica comunicar-se amb diversos socis integrats, comprovar el material, enviar un correu electrònic a l'usuari, etc.): això ajudarà a la integració de proves de peces individuals i també el nucli del producte.

Per tant, quan s’executa un d’aquests scripts, es garanteix que la solució en general funciona bé.

# 3) El tercer conjunt és el Proves basades en funcions / funcionalitats .

Per a exemple És possible que tinguem la funcionalitat de navegar i seleccionar un fitxer, de manera que, quan automatitzem això, podem automatitzar casos incloure la selecció de diferents tipus de fitxers, mides de fitxers, etc. Quan hi ha canvis / addicions a aquesta funcionalitat, aquesta suite pot servir com a suite de regressió.

# 4) El següent a la llista seria Proves basades en la IU. Podem disposar d’un altre conjunt que provarà funcionalitats purament basades en la interfície d’usuari, com la paginació, la limitació de caràcters del quadre de text, el botó del calendari, els desplegables, els gràfics, les imatges i moltes d’aquestes funcions centrades només en la interfície d’usuari. El fracàs d’aquests scripts no sol ser molt crític tret que la interfície d’usuari estigui completament inactiva o que certes pàgines no apareguin com s’esperava.

# 5) Podem tenir un altre conjunt de proves senzilles però molt laborioses per realitzar manualment. Les proves tedioses però senzilles són els candidats ideals per a l'automatització, per exemple, introduir detalls de 1.000 clients a la base de dades té una funcionalitat senzilla, però extremadament tediós de realitzar-se manualment, aquestes proves haurien de ser automatitzades. Si no, la majoria s’acaben ignorant i no es posen a prova.

Què NO cal automatitzar?

A continuació es presenten algunes proves que no s’han d’automatitzar.

# 1) Proves negatives / proves de relleu

No hem d'intentar automatitzar proves negatives o de fallada , pel que fa a aquestes proves, els provadors han de pensar analíticament i les proves negatives no són realment senzilles per donar un resultat aprovat o fallat que ens pot ajudar.

Les proves negatives necessitaran molta intervenció manual per simular un escenari real de recuperació de desastres. Només per exemplificar, estem provant funcions com la fiabilitat dels serveis web; per generalitzar-la aquí, l'objectiu principal d'aquestes proves seria provocar errors deliberats i veure fins a quin punt el producte és fiable.

Simular les falles anteriors no és senzill, pot implicar injectar alguns talons o utilitzar algunes eines entremig i l’automatització no és la millor manera d’anar aquí.

# 2) Proves ad hoc

És possible que aquestes proves no siguin realment rellevants per a un producte en tot moment, i fins i tot pot ser alguna cosa que el provador pugui pensar en aquesta etapa d'inici del projecte, i també s'ha de validar l'esforç per automatitzar una prova ad-hoc contra la criticitat. de la característica que toquen les proves.

Per exemple , Un provador que estigui provant una funció que tracta la compressió / xifratge de dades pot haver fet proves intenses ad-hoc amb la varietat de dades, tipus de fitxers, mides de fitxers, dades corruptes, una combinació de dades, mitjançant diferents algoritmes, entre diversos plataformes, etc.

Quan ho planifiquem automatització és possible que vulguem prioritzar i no fer una automatització exhaustiva de totes les proves ad hoc només per a aquesta funció i acabar amb una mica de temps per automatitzar les altres funcions clau.

# 3) Proves amb una configuració prèvia massiva

Hi ha proves que requereixen uns enormes requisits previs.

Per exemple, És possible que tinguem un producte que s’integri amb un programari de tercers per a algunes de les funcions, ja que el producte s’integra amb qualsevol sistema de cua de missatgeria que requereixi instal·lació en un sistema, configuració de cues, creació de cues, etc.

El 3rdel programari de festa pot ser qualsevol cosa i la configuració pot ser de naturalesa complexa i, si aquests scripts s’automatitzen, dependran per sempre de la funció / configuració d’aquest programari de tercers.

Els requisits previs inclouen:

En l'actualitat, les coses poden semblar senzilles i netes ja que s'estan fent les dues configuracions laterals i tot està bé. Hem vist en moltes ocasions que quan un projecte entra en la fase de manteniment, el projecte es trasllada a un altre equip i acaben depurant aquests scripts en què la prova real és molt senzilla, però el script falla a causa d’un 3.rdproblema de programari de festa.

L'anterior és només un exemple, en general, vigileu les proves que tenen laborioses configuracions prèvies per a una prova senzilla que segueix.

Exemple senzill d'automatització de proves

Quan proveu un programari (al web o a l’escriptori), normalment utilitzeu un ratolí i un teclat per realitzar els vostres passos. L'eina d'automatització imita aquests mateixos passos mitjançant l'ús de scripts o un llenguatge de programació.

Per exemple , si esteu provant una calculadora i el cas de prova és que heu d'afegir dos números i veure'n el resultat. El guió realitzarà els mateixos passos fent servir el ratolí i el teclat.

A continuació es mostra l'exemple.

algoritme d'ordenació de selecció c ++

Passos manuals del cas de prova:

  1. Inicia la calculadora
  2. Premeu 2
  3. Premeu +
  4. Premeu 3
  5. Premeu =
  6. La pantalla hauria de mostrar 5.
  7. Tanca la calculadora.

Script d'automatització:

//the example is written in MS Coded UI using c# language. (TestMethod) public void TestCalculator() { //launch the application var app = ApplicationUnderTest.Launch('C:\Windows\System32\calc.exe'); //do all the operations Mouse.Click(button2); Mouse.Click(buttonAdd); Mouse.Click(button3); Mouse.Click(buttonEqual); //evaluate the results Assert.AreEqual('5', txtResult.DisplayText,”Calculator is not showing 5); //close the application app.Close(); }

L'escriptura anterior és només una duplicació dels passos manuals. El guió és fàcil de crear i fàcil d’entendre també.

Què són les afirmacions?

La segona última línia del guió necessita una explicació més.

Assert.AreEqual ('5', txtResult.DisplayText ', la calculadora no mostra 5);

En tots els casos de prova, tenim algun resultat esperat o previst al final. A l'script anterior, esperem que es mostri '5' a la pantalla. El resultat real és el resultat que es mostra a la pantalla. En tots els casos de prova, comparem el resultat esperat amb el resultat real.

El mateix passa amb les proves d'automatització. L'única diferència aquí és que, quan fem aquesta comparació en automatització de proves, es diu una altra cosa en totes les eines.

Algunes eines l’anomenen “ Afirmació ”, Alguns l’anomenen com“ punt de control ”I alguns l’anomenen“ validació ”. Però bàsicament, això és només una comparació. Si falla aquesta comparació, per Per exemple. una pantalla mostra 15 en lloc de 5, llavors aquesta afirmació / control / validació falla i el vostre cas de prova es marca com a fallit.

Quan un cas de prova falla a causa d'una afirmació, significa que heu detectat un error mitjançant l'automatització de la prova. Heu d'informar-ho al vostre sistema de gestió d'errors tal com ho feu normalment en les proves manuals.

En el guió anterior, hem realitzat una afirmació a la segona última línia. 5 és el resultat esperat, Resultat txt . DisplayText és el resultat real i, si no són iguals, se'ns mostrarà un missatge que indica que 'La calculadora no mostra 5'.

Conclusió

Sovint, els verificadors es troben amb els terminis i els mandats del projecte per automatitzar tots els casos per millorar les estimacions de les proves.

Hi ha algunes percepcions 'equivocades' comunes sobre l'automatització.

Ells són:

  • Podem automatitzar tots els casos de prova.
  • L’automatització de les proves reduirà enormement el temps de les proves.
  • No s’introdueixen errors si els scripts d’automatització funcionen sense problemes.

Hem de tenir clar que l’automatització només pot reduir el temps de proves per a certs tipus de proves. L’automatització de totes les proves sense cap pla ni seqüència donarà lloc a scripts massius, que són de gran manteniment, fallen sovint i també necessiten molta intervenció manual. A més, en productes en constant evolució, els scripts d’automatització poden quedar obsolets i necessitar una revisió constant.

Agrupar i automatitzar els candidats adequats estalviarà molt de temps i oferirà tots els avantatges de l’automatització.

Aquest excel·lent tutorial es pot resumir en només 7 punts.

Proves d'automatització:

  • És la prova que es fa per programació.
  • Utilitza l'eina per controlar l'execució de les proves.
  • Compara els resultats esperats amb els resultats reals (afirmacions).
  • Pot automatitzar algunes tasques repetitives però necessàries ( Per exemple. Els vostres casos de prova de regressió).
  • Pot automatitzar algunes tasques difícils de fer manualment (Per exemple.Escenaris de proves de càrrega).
  • Els scripts es poden executar de forma ràpida i repetida.
  • És rendible a la llarga.

Aquí s’explica l’automatització en termes senzills, però això no vol dir que sigui sempre senzill de fer. Hi ha reptes, riscos i molts altres obstacles. Hi ha moltes maneres en què l’automatització de proves pot sortir malament, però si tot va bé, els avantatges de l’automatització de proves són realment enormes.

Els propers d’aquesta sèrie:

En els nostres propers tutorials, parlarem de diversos aspectes relacionats amb l'automatització.

Això inclou:

  1. Tipus de proves automatitzades i algunes idees errònies.
  2. Com introduir l’automatització a la vostra organització i evitar les trampes més habituals a l’hora de fer l’automatització de proves.
  3. El procés de selecció d'eines i comparació de diverses eines d'automatització.
  4. Marcs de desenvolupament i automatització de scripts amb exemples.
  5. Execució i notificació de Test Automation.
  6. Bones pràctiques i estratègies d'automatització de proves.

Esteu desitjosos de saber més sobre tots i cadascun dels conceptes de proves d'automatització? Vigileu i estigueu atents a la nostra llista de propers tutorials d’aquesta sèrie i no dubteu a expressar els vostres pensaments a la secció de comentaris a continuació.

NEXT Tutorial # 2

Lectura recomanada

^