Meniu

Tipuri de teste de automatizare și unele concepții greșite

types automation testing

Încercați Instrumentul Nostru Pentru Eliminarea Problemelor

Aflați diferitele tipuri de testare a automatizării cu unele concepții greșite despre automatizarea testelor:

În această a doua parte a seria de tutoriale de automatizare a testelor Voi descrie pe scurt tipurile de teste automate și, cel mai important, voi șterge câteva concepții greșite despre automatizarea testelor.

Ce este testarea automatizării?

Testarea automatizării poate fi definită ca o modalitate de a rula un set de teste repetate fără a fi nevoie să le executați manual. Introducerea testelor de automatizare în strategia dvs. de testare este o modalitate de a economisi bani și timp.

tipuri de teste de automatizare

Ce veți învăța:

Tipuri de teste de automatizare

Tipurile de teste de automatizare definesc ce tip de suite de testare pot fi automatizate. Mulți testeri confundă acest subiect cu tipurile de cadre de automatizare care definesc modul în care vă veți proiecta suita de testare într-un pachet de automatizare care poate fi executat convenabil.

În acest articol, vom analiza cu atenție tipurile de testare a automatizării și, în cele din urmă, vom arunca o scurtă privire asupra cadrelor de automatizare.

Tipuri de automatizări

Să înțelegem în detaliu clasificările de mai sus:

Automatizare bazată pe tipul de testare

Automatizarea testelor funcționale:

Testele funcționale sunt scrise pentru a testa logica de afaceri din spatele unei aplicații. Automatizarea acestor înseamnă scrierea de scripturi pentru a valida logica de afaceri și funcționalitatea așteptată de la aplicație.

Automatizarea testelor nefuncționale:

Testele nefuncționale definesc cerințele non-comerciale ale aplicației. Acestea sunt cerințele legate de performanță, securitate, baze de date etc. Aceste cerințe pot rămâne constante sau pot fi scalate în funcție de dimensiunea software-ului.

Automatizare bazată pe faza de testare

Automatizarea testelor de unitate:

Aceste teste sunt executate în timpul fazei de dezvoltare în sine, în mod ideal de către dezvoltator după finalizarea dezvoltării și înainte de a preda sistemul testerilor pentru testare.

Automatizarea testelor API:

site-uri web care vă permit să descărcați videoclipuri YouTube

Testele API se execută în timpul fazei de integrare. Acestea pot fi rulate de echipa de dezvoltare sau testare și pot fi rulate înainte sau după ce stratul UI este construit pentru aplicație. Aceste teste vizează testarea pe baza cererii și răspunsului pe care este construită aplicația.

Automatizarea testelor bazate pe interfața de utilizare:

Testele bazate pe interfața de utilizare sunt executate în timpul fazei de execuție a testului. Acestea sunt executate în mod specific de testeri și sunt rulate o singură dată înainte ca UI-ul aplicației să fie predat acestora. Acestea testează funcționalitatea și logica de afaceri a aplicației din partea frontală a aplicației.

Automatizare pe baza tipului de teste

Teste unitare:

Testele unitare sunt testele care sunt construite pentru a testa codul unei aplicații și sunt de obicei încorporate în codul în sine. Acestea vizează standardele de codare, cum ar fi modul în care sunt scrise metodele și funcțiile.

Aceste teste sunt scrise mai des de dezvoltatori înșiși, cu toate acestea, în lumea de astăzi, testerilor de automatizare li se poate cere, de asemenea, să le scrie.

Executarea acestor teste și obținerea de erori de la acestea va însemna că codul dvs. va fi compilat și rulat fără probleme de cod. Aceste teste nu vizează, de obicei, aspectele funcționale ale aplicației și, deoarece vizează codul, este mai adecvat să le automatizați astfel încât să poată fi rulate ca și când este necesar de către dezvoltator.

Teste de fum:

Testul de fum este un test celebru efectuat în ciclul de viață al testului. Acestea sunt teste post-build, sunt executate imediat după ce orice build a fost scoasă din aplicație pentru a se asigura că aplicația funcționează în continuare după finalizarea construirii.

Aceasta este o suită de testare mică și este ceva ce va fi executat de mai multe ori și, prin urmare, are sens să o automatizăm. Aceste teste vor fi de obicei de natură funcțională și în funcție de tipul de aplicație poate fi ales un instrument pentru ele.

Teste API:

Testarea API a devenit foarte faimoasă în ultimii ani. Aplicațiile construite pe arhitectura API pot efectua această testare.

În testarea API, testerii validează stratul de activitate al aplicației verificând combinațiile cerere-răspuns pentru diferitele API-uri pe care este construită aplicația. Testele API se pot face și ca parte a testelor de integrare de mai jos.

Teste de integrare:

Testul de integrare, așa cum sugerează și numele, înseamnă testarea aplicației prin integrarea tuturor modulelor și verificarea funcționalității aplicației.

Testarea integrării se poate face prin testarea API sau se poate face prin stratul UI al aplicației.

Teste UI:

Testele UI se fac din stratul UI sau din frontend-ul aplicației. Acestea pot viza testarea funcționalității sau pur și simplu testarea elementelor de interfață ale unei aplicații.

Automatizarea interfeței pentru a testa funcționalitatea este o practică obișnuită. Cu toate acestea, automatizarea caracteristicilor GUI este una dintre automatizările mai complicate.

Teste de regresie:

Una dintre suitele de testare cele mai frecvent automatizate este suita de testare de regresie. Regresia, după cum probabil știți deja, este testul care se face la sfârșitul testării unui nou modul pentru a se asigura că niciunul dintre modulele existente nu a fost afectat de acesta.

Se repetă după fiecare nouă iterație de testare și principalele cazuri de testare rămân fixe, de obicei cu câteva adăugiri noi după o nouă iterație. Deoarece este frecvent rulat, aproape toate echipele de testare încearcă să automatizeze acest pachet.

Automatizarea ca integrare continuă:

Integrarea continuă poate rula din nou pe testele de regresie automate, însă, în realizarea CI, activăm suita de regresie sau de testare identificată să fie rulată de fiecare dată când se realizează o nouă implementare.

Teste de securitate:

Testarea securității poate fi atât funcțională, cât și un tip nefuncțional de testare care implică testarea aplicației pentru vulnerabilități. Testele funcționale vor compune teste legate de autorizare etc., în timp ce cerințele nefuncționale pot testa testarea injecției SQL, scriptarea între site-uri etc.

Teste de performanță și control al calității:

Testele de performanță sunt teste nefuncționale care vizează cerințe precum testarea sarcinii, stresului, scalabilității aplicației.

Teste de acceptare:

Testele de acceptare se încadrează din nou în testele funcționale care se fac de obicei pentru a se asigura dacă au fost îndeplinite criteriile de acceptare date de client.

Până în prezent, am descris tipul de teste care pot fi automatizate și diverse clasificări ale acestora, toate clasificările în cele din urmă vor duce la automatizarea acelorași rezultate finale ale unui set de teste. După cum am spus mai devreme, este necesară o mică înțelegere a modului în care acestea sunt diferite de cadre.

Odată ce ați identificat testele pe care doriți să le automatizați din clasificarea de mai sus, atunci va trebui să vă proiectați logica într-un mod pentru a executa aceste teste fără probleme, fără prea multă intervenție manuală. Acest design al unei suite de testare manuale într-o suită de testare automată este locul în care cadrele intră.

Acum vom explora Top 3 tipuri de automatizări de testare

  1. Testarea unitara
  2. Testarea API
  3. Testarea GUI

# 1) Teste automate de unitate

Teste automate de unitate sunt scrise pentru a testa nivelul codului. Bugurile sunt identificate în funcțiile, metodele și rutinele scrise de dezvoltatori.

Unele companii solicită dezvoltatorilor să facă singuri testarea unității și unele angajează resurse specializate de automatizare a testelor. Aceste resurse au acces la codul sursă și scriu teste unitare pentru a sparge codul de producție.

Datorită prezenței testelor unitare, ori de câte ori se compilează codul, toate testele unitare rulează și ne spun rezultatul că dacă toate funcționalitățile funcționează. Dacă un test de unitate nu reușește, atunci înseamnă că există acum un bug prezent în codul de producție.

Unele dintre cele mai populare instrumente prezente pe piață includ NUnit și JUnit . Microsoft oferă, de asemenea, propriul cadru pentru testarea unității numit MSTest . Accesați site-urile web ale acestor instrumente și vă vor oferi mai multe exemple și tutoriale despre cum să scrieți teste unitare.

#Două) Servicii web automatizate / Teste API

O interfață de programare a aplicațiilor (API) permite software-ului să vorbească cu alte aplicații software. La fel ca orice alt software, API-urile trebuie testate. În acest tip de testare, GUI nu este de obicei implicată.

ce poate face c ++

Ceea ce testăm aici este, de obicei, funcționalitatea, conformitatea și problemele de securitate. În aplicațiile web, putem testa cererea și răspunsul aplicației noastre, dacă acestea sunt sigure și criptate sau nu.

Acesta este unul dintre exemplele în care putem folosi testarea API. Cel mai popular instrument pentru testarea API este SOAPUI care are atât versiuni gratuite, cât și plătite. Există și alte instrumente, pe care le puteți utiliza în funcție de nevoile dvs.

# 3) Teste GUI automate.

Acest tip de testare automată este cea mai dificilă formă de automatizare, deoarece implică testarea unei interfețe cu utilizatorul a aplicației.

Este dificil, deoarece GUI-urile sunt foarte supuse modificărilor. Dar acest tip de testare este, de asemenea, cel mai apropiat de ceea ce vor face utilizatorii cu aplicația noastră. Deoarece utilizatorul va folosi mouse-ul și tastatura, testele GUI automate imită, de asemenea, același comportament, folosind mouse-ul și tastatura pentru a face clic sau a scrie pe obiectele prezente pe interfața utilizatorului.

Datorită acestui fapt, putem găsi erori mai devreme și poate fi utilizat în multe scenarii, cum ar fi testarea de regresie sau completarea formularelor care necesită prea mult timp.

Cele mai populare instrumente de testare GUI includ Micro Focus Unified Functional Testing (UFT) , Seleniu , Test finalizat și UI codată Microsoft (care face parte din edițiile finale și premium ale Visual Studio).

La fel ca și tipurile de teste de automatizare, există și mai multe tipuri de cadre.

Cadre de automatizare

Unele cadre de automatizare utilizate în mod obișnuit includ:

  • Liniar (Înregistrare și redare)
  • Cuvânt cheie condus
  • Date Driven
  • Model de obiect de pagină
  • Modular

Lecturi suplimentare => Cadre de automatizare

Tipuri, cadru și instrumente

După cum puteți vedea, primul pas în procesul de automatizare este identificarea tipului de automatizare, atunci puteți identifica cadrul de proiectat și ținând cont de acestea, puteți selecta instrumentele care se potrivesc nevoilor dumneavoastră.

Instrumente de automatizare

Pe baza tipului de testare pe care îl vizați și a tipului de cadru pe care poate doriți să îl construiți în jurul acestuia, sunt disponibile următoarele instrumente:

  • Seleniu : Instrument foarte puternic pentru testarea aplicațiilor web. Oferă suport pentru mai multe browsere.
  • Junit și Nunit: Instrumente utilizate în principal pentru testarea unității de către dezvoltatori.
  • QTP : Instrument excelent pentru aplicații non-web și vine cu un depozit de obiecte încorporat.
  • Sikuli: Instrument open source pentru testarea GUI.
  • UI săpun: Instrument pentru testarea API.
  • Fiți siguri: Biblioteca pentru a crea un cadru de testare API.
  • appium : Instrument care acceptă testarea mobilă, testarea aplicațiilor native, testarea hibridă și a aplicațiilor web mobile.
  • Jmeter : Un instrument care este utilizat pentru testele de performanță.
  • TestNG: TestNG nu este un instrument de automatizare în sine, însă oferă un suport deosebit cadrelor de automatizare construite cu seleniu, appium, fiți siguri etc.

Lecturi suplimentare => Instrumente de automatizare a testelor

Concepții greșite despre testarea automatizării

De-a lungul anilor, am auzit câteva concepții greșite despre automatizarea testelor. Cred că ar trebui să le șterg și în acest articol.

Concepție greșită # 1. Automatizarea este aici pentru a înlocui testerele manuale.

Automatizarea testelor este pentru a ajuta testerii să facă testarea mai rapidă și într-o manieră mult mai fiabilă. Nu poate înlocui niciodată oamenii.

Gândiți-vă la automatizarea testelor ca la o mașină. Dacă mergeți, veți avea nevoie de aproximativ 20 de minute pentru a ajunge la casa dumneavoastră. Dar dacă folosești o mașină, vei ajunge în două minute. Șoferul mașinii ești încă tu, un om, dar .. mașina îl ajută pe om să își atingă obiectivul mai repede. De asemenea, cea mai mare parte a energiei tale este economisită, deoarece nu ai mers. Astfel, puteți folosi această energie pentru a efectua lucruri mai importante.

cum se execută un fișier jar în Windows

Același lucru este valabil și cu testarea automatizării. Îl folosiți pentru a testa rapid majoritatea testelor repetate, lungi și plictisitoare și pentru a economisi timp și energie pentru a vă concentra și testa funcționalități noi și importante.

La fel de James Bach a spus un citat minunat:

„Instrumentele nu testează. Testează doar oamenii. Instrumentele efectuează doar acțiuni care „ajută” oamenii să testeze. „

Instrumentele pot face clic pe obiecte. Dar unde să faceți clic va fi întotdeauna spus de un tester manual. Cred că îmi faci rost acum.

Concepție greșită # 2 . Totul sub soare poate fi automatizat

Dacă încercați să automatizați 100% din cazurile de testare, poate veți putea face acest lucru, dar dacă ați putea face acest lucru, atunci primul nostru punct devine fals. Dacă totul este automatizat, atunci ce va face un tester manual?

Confuz? Dreapta?

De fapt, ideea este că nu puteți automatiza 100% din cazurile de testare. Pentru că noi, ca testeri, credem că nicio aplicație nu poate fi testată 100%. Vor exista întotdeauna niște scenarii pe care le vom rata. Întotdeauna vor exista erori care apar numai atunci când aplicația dvs. va fi utilizată de clienți.

Dacă aplicația nu poate fi testată 100%, atunci cum puteți promite automatizarea 100%?

De asemenea, există o șansă foarte mică de a putea automatiza toate cazurile de testare existente. Există întotdeauna scenarii dificil de automatizat și mai ușor de realizat manual.

De exemplu , Un utilizator va introduce datele, al doilea utilizator va aproba datele, al treilea utilizator va vizualiza datele, iar al patrulea utilizator este interzis să vizualizeze datele. Aceste scenarii pot fi automatizate, dar vor necesita mult timp și efort. Deci, va fi mai ușor dacă faceți asta manual.

Amintiți-vă, folosim mașini pentru a merge la distanțe, dar pot exista semnale lungi pe drum, va exista consum de combustibil, vor exista probleme de spațiu de parcare, taxe de parcare și mult mai multă durere de cap. În unele scenarii, mergem pe jos și ajungem la destinație :) .

Astfel, nu ar trebui să încercați să automatizați totul. Automatizați doar acele scenarii care sunt importante și cele care necesită mult timp pentru a le face manual.

Concepție greșită # 3 . Automatizarea implică doar înregistrarea și redarea.

Vă rog să nu trăiți într-o lume fantastică. Această fantezie este de fapt creată de reclame false de la diferiți furnizori de instrumente de automatizare. Se spune că doar înregistrați și redați pașii dvs., iar cazurile dvs. de testare vor fi automatizate. Ei bine, asta este o mare minciună!

Automatizarea este totul și nu doar înregistrarea și redarea. Inginerii de automatizare pură nu folosesc deloc funcția de înregistrare și redare. Înregistrarea și redarea sunt utilizate în general pentru a vă face o idee despre modul în care instrumentul generează un script pentru pașii noștri.

Odată ce cunoaștem scripturile, folosim întotdeauna scripturile pentru a crea teste automate. Tine minte, trebuie să știți programarea dacă doriți să faceți automatizarea testelor . Pe de altă parte, nu vă descurajați dacă nu cunoașteți programarea. La fel ca orice altă sarcină, programarea poate fi învățată și cu practică și dăruire.

Cunosc oameni care nici măcar nu provin din domeniul informaticii, dar învață să programeze și acum sunt ingineri de automatizare minunați. La Microsoft, angajează testeri care pot face programare. Ei sunt numiti, cunoscuti SDET (Ingineri de dezvoltare software pentru test). Prima linie din descrierea postului spune „SDET’s scrie o mulțime de cod ....”.

Vă rugăm să învățați să programați, nu fugiți de ea. Vă va face un tester uimitor .

Concluzie

Sper că acest articol v-ar fi ajutat să clarificați câteva concepte legate de automatizarea testelor.

Am acoperit un nivel ridicat de diferite tipuri de teste de automatizare, cu diferite modalități de clasificare.

Principalele clasificări includ:

  • Automatizare bazată pe tipul de testare (funcțională sau nefuncțională).
  • Automatizare bazată pe faza de testare (unitate, API sau UI).
  • Automatizare bazată pe diferitele tipuri de teste (tipuri multiple de testare).

De asemenea, am enumerat diversele instrumente care pot fi utilizate pentru aceste tipuri de teste automate.

În viitorul nostru articol, vom discuta despre procedura pas cu pas a cum să începeți automatizarea testelor în organizația dvs. .

PREV Tutorial # 1 | URMATORUL Tutorial nr. 3

Lectură recomandată

^