Ce este testarea automatizării (Ghidul final pentru a începe testarea automatizării)

Un ghid complet pentru a începe testarea automatizării în proiectul dumneavoastră:

Ce este Testarea de automatizare?

Testarea de automatizare este o tehnică de testare a software-ului pentru a testa și compara rezultatul real cu rezultatul așteptat. Acest lucru poate fi realizat prin scrierea de scripturi de testare sau prin utilizarea oricărui instrument de testare de automatizare. Automatizarea testelor este utilizată pentru a automatiza sarcinile repetitive și alte sarcini de testare care sunt dificil de realizat manual.

Vreți să începeți testarea prin automatizare a proiectului dumneavoastră, dar vă luptați cu cei mai de bază pași menționați mai jos:

• Cum să introduceți automatizarea în proiectul dumneavoastră?
• Cum să selectați cel mai bun și corect instrument de automatizare?
• Cum să dezvoltați scripturi în mod eficient?
• Cum să executați și să mențineți scripturile de testare?
• Și, în cele din urmă, care sunt cele mai bune practici pe care trebuie să le urmați pentru o testare de automatizare de succes?

Astăzi, am planificat să vă îmbogățim cunoștințele cu o serie de tutoriale despre „Noțiuni de bază despre testarea de automatizare”. Această serie de tutoriale de automatizare va răspunde la toate întrebările de mai sus într-o manieră pas cu pas, cu exemple simple.

Să aruncăm o privire la seria de tutoriale privind începerea automatizării în proiectul dvs.!!!

Procesul de automatizare de la un capăt la altul:

Tutorial #1: Cel mai bun ghid pentru începerea automatizării pe proiectul dvs
Tutorial #2: Tipuri de teste automatizate și câteva concepții greșite
Tutorial #3: 10 pași pentru a introduce automatizarea pe proiectul dvs: Executarea și raportarea automatizării
Tutorial #7: Cele mai bune practici și strategii de automatizare a testelor

Sugestii de automatizare:

Tutorial #8: 10 sfaturi pe care ar trebui să le citiți înainte de a vă automatiza activitatea de testare
Tutorial #9: Cum diferă planificarea testelor pentru proiectele manuale și cele de automatizare
Tutorial #10: Când să optați pentru automatizare?
Tutorial #11: Provocările testelor de automatizare
Tutorial #12: Ghid pentru implementarea Proof of Concept (POC) în automatizare
Tutorial #13: Cum să selectați cazurile de testare corecte pentru automatizare
Tutorial #14: Cum să traduceți cazurile de testare manuală în scripturi de automatizare

Cariera de automatizare:

Tutorial #15: Sfaturi pentru a deveni un tester de automatizare mai bun
Tutorial #16: Automatizarea testelor – este o carieră specializată? Pot testatorii normali să facă și automatizare?

Instrumente populare de automatizare:

Tutorial #17: Tutoriale Selenium 31+ Cele mai bune tutoriale gratuite de instruire Selenium
Tutorial #18: Tutoriale QTP
Tutorial #19: Instrumentul de testare a serviciilor web SoapUI
Tutorial #20: HP LoadRunner pentru testarea performanței

Cadru de automatizare:

Tutorial #21: De ce avem nevoie de framework-uri pentru automatizare
Tutorial #22: Cele mai populare framework-uri de automatizare

Automatizarea în Agile:

Tutorial #23: Cum să implementăm o automatizare eficientă în lumea Agile

Alte instrumente de automatizare:

Tutorial #24: Cele mai bune instrumente de testare de automatizare
Tutorial #25: Instrumentul de automatizare GUI Sikuli
Tutorial #26: PowerShell: Automatizarea interfeței de interfață a aplicațiilor desktop cu PowerShell
Tutorial #27: Katalon Automation Recorder (alternativă la Selenium IDE)
Tutorial #28: Instrumentul Geb: Automatizarea browserului utilizând Geb Tool
Tutorial #29: AutoIt: Cum să gestionați ferestrele pop-up folosind AutoIt
Tutorial #30: Cucumber: Automatizarea folosind instrumentul Cucumber și Selenium
Tutorial #31: Instrumentul de testare Protractor pentru testarea end-to-end a aplicațiilor AngularJS

Testarea de automatizare mobilă:

Tutorial #32: Appium Studio Hands-on Tutorial
Tutorial #33: Appium Tutorial pentru începători
Tutorial #34: Selendroid Tutorial: Android Mobile Automation Framework
Tutorial #35: Tutorial Ranorex: Un instrument puternic de testare desktop, web și mobil

Exemple de automatizare specifice domeniului:

Tutorial #36: Automatizarea aplicațiilor JAVA/J2EE

Pregătirea pentru interviuri pentru joburi de automatizare:

Tutorial #37: Întrebări pentru interviuri de testare de automatizare
Tutorial #38: Întrebări pentru interviuri Selenium

Să explorăm primul tutorial din seria „Ghidul suprem de testare de automatizare”!!

Ce este Automation Testing?

Dacă un software poate face orice, atunci, de ce nu poate un software să testeze un software?

Vă sună logic această afirmație?

Dacă da, atunci felicitări, acum vă gândiți la Test Automation, care este punctul central pe care îl vom discuta în această serie de tutoriale informative.

Imaginați-vă n prima zi la locul de muncă ca SQA. Vi se prezintă o aplicație care urmează să fie testată. Este o aplicație ERP care conține 100 de formulare și mii de rapoarte. Vă începeți testarea exploratorie prin deschiderea unui formular care conține aproximativ 50 de câmpuri diferite.

Încercați să introduceți date aleatorii în acest formular, ceea ce a durat aproximativ 20 de minute. Apoi apăsați trimiterea. Wolla!!! Se afișează un mesaj de eroare care arată ca o excepție netransmisă. Devii foarte fericit. Vă notați cu mândrie pașii și raportați eroarea în sistemul de gestionare a erorilor. Mare efort, vă simțiți foarte încrezător și energic. Continuați testarea până la sfârșitul zilei și mai găsiți câteva erori. „Uimitoare prima zi”, v-ați gândit.

Acum vine ziua următoare, dezvoltatorul a rezolvat problema și lansează o nouă versiune de build. Testați același formular cu aceiași pași și ați constatat că bug-ul este rezolvat. O marcați ca fiind rezolvată. Mare efort. Ați contribuit la calitatea produsului prin identificarea acelei erori și, pe măsură ce această eroare este rezolvată, calitatea este îmbunătățită.

Acum vine a treia zi, un dezvoltator a lansat din nou o versiune mai nouă. Acum trebuie din nou să testați acel formular pentru a vă asigura că nu se găsește nicio problemă de regresie. Aceleași 20 de minute. Acum vă simțiți puțin plictisit.

Acum imaginați-vă că de acum încolo, timp de 1 lună, versiuni mai noi sunt lansate constant și la fiecare lansare, trebuie să testați acest formular lung plus alte 100 de formulare asemănătoare, doar pentru a vă asigura că nu există nicio regresie.

Acum vă simțiți supărat. Vă simțiți obosit. Începi să sari peste etape. Completați în jur de doar 50% din totalul câmpurilor. Acuratețea dvs. nu mai este aceeași, energia dvs. nu mai este aceeași și, cu siguranță, pașii dvs. nu mai sunt aceiași.

Și într-o zi, clientul raportează același bug în același formular. Vă simțiți jalnic. Vă simțiți neîncrezător acum. Credeți că nu sunteți suficient de competent. Managerii îți pun la îndoială abilitățile.

Am o veste pentru tine; aceasta este povestea a 90% dintre testerii manuali de acolo. Dumneavoastră nu sunteți diferit.

Problemele de regresie sunt cele mai dureroase probleme. Noi suntem oameni. Și nu putem face același lucru cu aceeași energie, viteză și acuratețe în fiecare zi. Asta este ceea ce fac mașinile. Pentru asta este nevoie de automatizare, pentru a repeta aceiași pași cu aceeași viteză, acuratețe și energie cu care au fost repetați prima dată.

Sper că ați înțeles ce vreau să spun!!!

Când apare o astfel de situație, ar trebui să vă automatizați cazul de testare. Automatizarea testelor este prietenul tău. Vă va ajuta să vă concentrați asupra noilor funcționalități în timp ce vă ocupați de regresii. Cu automatizarea, puteți completa acel formular în mai puțin de 3 minute.

Scriptul va completa toate câmpurile și vă va spune rezultatul împreună cu capturi de ecran. În caz de eșec, acesta poate identifica locația în care a eșuat cazul de testare, ajutându-vă astfel să îl reproduceți cu ușurință.

Automatizarea – o metodă rentabilă pentru testarea regresiei

Costurile automatizării sunt într-adevăr mai mari inițial. Acesta include costul instrumentului, apoi costul resursei de testare a automatizării și instruirea acesteia.

Dar atunci când scripturile sunt gata, acestea pot fi executate de sute de ori în mod repetat cu aceeași precizie și destul de rapid. Acest lucru va economisi multe ore de testare manuală. Astfel, costul scade treptat și, în cele din urmă, devine o metodă rentabilă pentru testarea de regresie.

Scenarii care necesită automatizare

Scenariul de mai sus nu este singurul caz în care veți avea nevoie de testarea de automatizare. Există mai multe situații, care nu pot fi testate manual.

De exemplu,

1. Compararea a două imagini pixel cu pixel.
2. Compararea a două foi de calcul care conțin mii de rânduri și coloane.
3. Testarea unei aplicații sub încărcarea a 100.000 de utilizatori.
4. Panmarks de performanță.
5. Testarea aplicației pe diferite browsere și pe diferite sisteme de operare în paralel.

Aceste situații necesită și ar trebui să fie, testate prin instrumente.

Atunci, când să automatizăm?

Aceasta este o eră a metodologiei agile în SDLC, în care dezvoltarea și testarea vor merge aproape în paralel și este foarte dificil să decidem când să automatizăm.

Considerați următoarele situații înainte de a păși în automatizare

• Produsul poate fi în stadiile sale primitive, când produsul nu are nici măcar o interfață de utilizator, în aceste stadii trebuie să avem o idee clară cu privire la ceea ce dorim să automatizăm. Trebuie reținute următoarele puncte.
  • Testele nu ar trebui să fie învechite.
  • Pe măsură ce produsul evoluează, ar trebui să fie ușor de preluat scripturile și de adăugat la acesta.
  • Este foarte important să nu ne lăsăm purtați de val și să ne asigurăm că scripturile sunt ușor de depanat.
• Nu încercați să automatizați interfața de utilizator chiar în etapele inițiale, deoarece interfața de utilizator este supusă unor modificări frecvente, ceea ce va duce la eșecul scripturilor. În măsura în care este posibil, optați pentru automatizarea la nivel de API/Non UI până când produsul se stabilizează. Automatizarea API este ușor de reparat și de depanat.

Cum să decideți cele mai bune cazuri de automatizare:

Automatizarea este o parte integrantă a unui ciclu de testare și este foarte important să decidem ce dorim să obținem cu ajutorul automatizării înainte de a decide să automatizăm.

Beneficiile pe care pare să le ofere automatizarea sunt foarte atractive, dar, în același timp, o suită de automatizare prost organizată poate strica întregul joc. Testatorii pot ajunge să depaneze și să repare scripturile în cea mai mare parte a timpului, ceea ce duce la pierderea timpului de testare.

Această serie vă explică despre modul în care o suită de automatizare poate fi făcută suficient de eficientă pentru a prelua cazurile de testare corecte și pentru a produce rezultatele corecte cu scripturile de automatizare pe care le avem.

De asemenea, am acoperit răspunsurile la întrebări precum Când să automatizăm, Ce să automatizăm, Ce să nu automatizăm și Cum să stabilim o strategie de automatizare.

Testele potrivite pentru automatizare

Cel mai bun mod de a aborda această problemă este să găsim rapid o „Strategie de automatizare” care să se potrivească produsului nostru.

Ideea este să grupăm cazurile de testare astfel încât fiecare grup să ne dea un tip diferit de rezultat. Ilustrația dată mai jos arată cum am putea grupa cazurile noastre de testare similare, în funcție de produsul/soluția pe care o testăm.

Lasă-ne acum să ne scufundăm în profunzime și să înțelegem ce ne poate ajuta fiecare grup să realizăm:

#1) Realizați o suită de teste cu toate funcționalitățile de bază Teste pozitive. Această suită ar trebui să fie automatizată, iar atunci când această suită este rulată împotriva oricărui build, rezultatele sunt afișate imediat. Orice script care eșuează în această suită duce la un defect S1 sau S2, iar acel build specific poate fi descalificat. Așadar, am economisit mult timp aici.

Ca un pas suplimentar, putem adăuga această suită de teste automatizate ca parte a BVT (Build verification tests) și putem verifica scripturile de automatizare QA în procesul de construire a produsului. Astfel, atunci când construcția este gata, testerii pot verifica rezultatele testelor de automatizare și pot decide dacă construcția este potrivită sau nu pentru instalare și pentru procesul de testare ulterioară.

Acest lucru atinge în mod clar obiectivele automatizării, care sunt:

• Reduceți efortul de testare.
• Descoperirea erorilor în stadii mai timpurii.

#2) În continuare, avem un grup de teste End to End.

În cadrul soluțiilor mari, testarea unei funcționalități end to end deține cheia, în special în timpul etapelor critice ale proiectului. Ar trebui să avem câteva scripturi de automatizare care să atingă și testele soluției end to end. Atunci când această suită este rulată, rezultatul ar trebui să indice dacă produsul în ansamblu funcționează așa cum se așteaptă sau nu.

Suita de teste de automatizare ar trebui să fie indicată dacă vreuna dintre piesele de integrare este stricată. Această suită nu trebuie neapărat să acopere fiecare mică caracteristică/funcționalitate a soluției, dar ar trebui să acopere funcționarea produsului ca întreg. Ori de câte ori avem o versiune alfa sau beta sau orice altă versiune intermediară, atunci astfel de scripturi vin la îndemână și oferă un anumit nivel de încredere clientului.

Pentru a înțelege mai bine, să presupunem că testăm un portal de cumpărături online, ca parte a testelor de la un capăt la altul ar trebui să acoperim doar pașii cheie implicați.

După cum este dat mai jos:

• Intrarea utilizatorului.
• Browse and select items.
• Payment Option – aceasta acoperă testele frontale.
• Backend order management (implică comunicarea cu mai mulți parteneri integrați, verificarea stocului, trimiterea de e-mailuri către utilizator etc.) – acest lucru va ajuta la testarea integrării pieselor individuale și, de asemenea, la miezul produsului.

Așa că atunci când un astfel de script este rulat, oferă o încredere că soluția în ansamblu funcționează bine.!

#3) Al treilea set este cel al testelor bazate pe caracteristici/funcționalități.

De exemplu, Putem avea funcționalitatea de a naviga și de a selecta un fișier, astfel încât atunci când automatizăm acest lucru putem automatiza cazurile pentru a include selectarea diferitelor tipuri de fișiere, dimensiuni ale fișierelor etc., astfel încât să se facă testarea caracteristicilor. Atunci când există modificări/adăugiri la acea funcționalitate, această suită poate servi drept suită de regresie.

#4) Următoarea pe listă ar fi testele bazate pe UI. Putem avea o altă suită care să testeze funcționalitățile bazate exclusiv pe interfață utilizator, cum ar fi paginarea, limitarea caracterelor din căsuța de text, butonul de calendar, drop-down-uri, grafice, imagini și multe alte caracteristici centrate exclusiv pe interfață utilizator. Eșecul acestor scripturi nu este, de obicei, foarte critic, cu excepția cazului în care interfața de utilizator este complet căzută sau anumite pagini nu apar așa cum era de așteptat!

#5) Putem avea încă un set de teste care sunt simple, dar foarte laborioase pentru a fi efectuate manual. Testele plictisitoare dar simple sunt candidații ideali pentru automatizare, de exemplu introducerea detaliilor a 1000 de clienți în baza de date are o funcționalitate simplă dar extrem de plictisitoare pentru a fi efectuată manual, astfel de teste ar trebui să fie automatizate. În caz contrar, de cele mai multe ori ajung să fie ignorate și să nu fie testate.

Ce NU trebuie automatizat?

După cum sunt prezentate mai jos câteva teste care nu ar trebui să fie automatizate.

#1) Teste negative/teste de eșec

Nu ar trebui să încercăm să automatizăm testele negative sau de eșec, deoarece pentru aceste teste testerii trebuie să gândească analitic, iar testele negative nu sunt cu adevărat directe pentru a da un rezultat de trecere sau de eșec care să ne ajute.

Testele negative vor necesita multă intervenție manuală pentru a simula un scenariu real de tip recuperare în caz de dezastru. Doar pentru a exemplifica, testăm caracteristici cum ar fi fiabilitatea serviciilor web – pentru a generaliza aici, scopul principal al unor astfel de teste ar fi de a provoca eșecuri deliberate și de a vedea cât de bine reușește produsul să fie fiabil.

Simularea eșecurilor de mai sus nu este simplă, poate implica injectarea unor stub-uri sau utilizarea unor instrumente între ele, iar automatizarea nu este cea mai bună cale de urmat aici.

#2) Teste ad-hoc

Este posibil ca aceste teste să nu fie cu adevărat relevante pentru un produs în orice moment și acest lucru poate fi chiar ceva la care testerul s-ar putea gândi în acea etapă de inițiere a proiectului și, de asemenea, efortul de a automatiza un test ad-hoc trebuie să fie validat în raport cu criticitatea caracteristicii pe care testele o ating.

De exemplu, un tester care testează o caracteristică care se ocupă de compresia/criptarea datelor ar fi putut face teste ad-hoc intense cu varietatea de date, tipuri de fișiere, dimensiuni de fișiere, date corupte, o combinație de date, folosind diferiți algoritmi, pe mai multe platforme etc.

Când planificăm automatizarea s-ar putea să dorim să prioritizăm și să nu facem o automatizare exhaustivă a tuturor testelor ad-hoc doar pentru acea caracteristică și să rămânem cu puțin timp pentru automatizarea celorlalte caracteristici cheie.

#3) Teste cu pre-configurare masivă

Există teste care necesită niște pre-condiții enorme.

De exemplu, Este posibil să avem un produs care se integrează cu un software terț pentru unele dintre funcții, așa cum produsul se integrează cu orice sistem de coadă de mesagerie care necesită instalarea pe un sistem, configurarea cozilor, crearea de cozi etc.

Software-ul terț ar putea fi orice, iar configurarea poate fi de natură complexă, iar dacă astfel de scripturi sunt automatizate, atunci acestea vor depinde pentru totdeauna de funcția/configurarea acelui software terț.

Precondițiile includ:

În prezent, lucrurile pot părea simple și curate, deoarece se fac configurări de ambele părți și totul este în regulă. Am văzut în numeroase ocazii că, atunci când un proiect intră în faza de mentenanță, proiectul este mutat la o altă echipă, iar aceștia ajung să depaneze astfel de scripturi în care testul real este foarte simplu, dar scriptul eșuează din cauza unei probleme a unui software de la o terță parte.

Ceea de mai sus este doar un exemplu, în general, fiți cu ochii pe testele care au setări prealabile laborioase pentru un test simplu care urmează.

Exemplu simplu de automatizare a testelor

Când testați un software (pe web sau desktop), în mod normal folosiți un mouse și o tastatură pentru a efectua pașii. Instrumentul de automatizare imită aceiași pași prin utilizarea scripturilor sau a unui limbaj de programare.

De exemplu, dacă testați un calculator și cazul de testare este că trebuie să adăugați două numere și să vedeți rezultatul. The script will perform the same steps by making use of your mouse and keyboard.

The example is shown below.

Manual Test Case Steps:

1. Launch Calculator
2. Press 2
3. Press +
4. Press 3
5. Press =
6. The screen should display 5.
7. Close Calculator.

Automation Script:

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

The above script is just a duplication of your manual steps. The script is easy to create and easy to understand as well.

What are Assertions?

The second last line of the script needs some more explanation.

Assert.AreEqual(„5”, txtResult.DisplayText,”Calculator is not showing 5);

In every test case, we have some expected or predicted result at the end. In the above script, we have an expectation that „5” should be shown on the screen. The actual outcome is the result that is displayed on the screen. În fiecare caz de testare, comparăm rezultatul așteptat cu rezultatul real.

La fel este valabil și pentru testarea automată. Singura diferență aici este că, atunci când facem această comparație în automatizarea testelor, atunci se numește altfel în fiecare instrument.

Câteva instrumente o numesc „Assertion”, altele o numesc „checkpoint” și altele o numesc „validare”. Dar, în principiu, aceasta este doar o comparație. Dacă această comparație eșuează, de ex. un ecran afișează 15 în loc de 5, atunci această aserțiune/punct de control/validare eșuează și cazul dvs. de testare este marcat ca eșuat.

Când un caz de testare eșuează din cauza unei aserțiuni, atunci înseamnă că ați detectat un bug prin automatizarea testelor. Trebuie să o raportați la sistemul dvs. de gestionare a erorilor, așa cum faceți în mod normal la testarea manuală.

În scriptul de mai sus, am efectuat o aserțiune în penultima linie. 5 este rezultatul așteptat, txtResult. DisplayText este rezultatul real și dacă acestea nu sunt egale, ni se va afișa un mesaj că „Calculator is not showing 5”.

Concluzie

De multe ori, testerii se întâlnesc cu termenele limită ale proiectelor și cu mandatele de a automatiza toate cazurile pentru a îmbunătăți estimările de testare.

Există câteva percepții comune „greșite” despre automatizare.

Acestea sunt:

• Pot fi automatizate toate cazurile de testare.
• Automatizarea testelor va reduce enorm timpul de testare.
• Niciun bug nu este introdus dacă scripturile de automatizare rulează fără probleme.

Ar trebui să ne fie clar că automatizarea poate reduce timpul de testare doar pentru anumite tipuri de teste. Automatizarea tuturor testelor fără niciun plan sau secvență va duce la scripturi masive care necesită o întreținere grea, eșuează des și necesită și o mulțime de intervenții manuale. De asemenea, în produsele în continuă evoluție, scripturile de automatizare pot deveni învechite și au nevoie de unele verificări constante.

Gruparea și automatizarea candidaților potriviți va economisi o mulțime de timp și va oferi toate beneficiile automatizării.

Acest tutorial excelent poate fi rezumat în doar 7 puncte.

Testarea prin automatizare:

• Este testarea care se face în mod programatic.
• Utilizează instrumentul pentru a controla execuția testelor.
• Compară rezultatele așteptate cu cele reale (Aserțiuni).
• Poate automatiza unele sarcini repetitive, dar necesare (De exemplu, cazurile tale de testare a regresiei).
• Poate automatiza unele sarcini care sunt dificil de realizat manual (E.g. Scenarii de testare a încărcării).
• Scriptele pot rula rapid și în mod repetat.
• Este rentabil pe termen lung.

Aici, Automatizarea este explicată în termeni simpli, dar asta nu înseamnă că este întotdeauna simplu de făcut. Există provocări, riscuri și multe alte obstacole implicate în ea. Există numeroase moduri prin care automatizarea testelor poate merge prost, dar dacă totul merge bine, atunci beneficiile automatizării testelor sunt cu adevărat uriașe.

Cele care urmează în această serie:

În următoarele noastre tutoriale, vom discuta mai multe aspecte legate de automatizare.

Acestea includ:

1. Tipurile de teste automatizate și unele concepții greșite.
2. Cum să introduceți automatizarea în organizația dvs. și cum să evitați capcanele comune atunci când faceți automatizarea testelor.
3. Procesul de selecție a instrumentelor și compararea diferitelor instrumente de automatizare.
4. Dezvoltarea de scripturi și cadre de automatizare cu exemple.
5. Executarea și raportarea automatizării testelor.
6. Bune practici și strategii de automatizare a testelor.

.